DEV Community: Data Galactica

Joining datasets that never shared a key: validate CIN, LEI and Wikidata IDs, then resolve them in Python

Data Galactica — Sat, 24 Oct 2026 03:31:38 +0000

Sunny Mittal works on marketing at Data Galactica. Corrections welcome in the comments.

You have three spreadsheets about the same companies. Finance keyed them by Indian CIN, the treasury team by LEI, and the research team pulled theirs from Wikidata, so every row has a Q-id. None of them shares a column you can join on. This post shows a small Python pipeline that (1) validates each identifier locally, so you don't pay to look up typos, and (2) resolves the survivors to one permanent key.

Step 1: know what a valid identifier looks like

Most bad joins start with bad IDs: a trailing space, a lowercase letter, an O where a 0 should be. Each scheme has a structure you can check for free.

Indian CIN (21 characters). Take L85110KA1981PLC013115:

Part	Value	Meaning
1 char	`L`	Listed (`U` = unlisted)
5 digits	`85110`	Industry code
2 letters	`KA`	State of registration
4 digits	`1981`	Year of incorporation
3 letters	`PLC`	Ownership type (e.g. `PLC`, `PTC`)
6 digits	`013115`	Registration number

LEI (20 characters, ISO 17442). The last two characters are check digits under ISO 7064 MOD 97-10: map letters to numbers (A=10 ... Z=35), read the whole thing as one integer, and a valid LEI leaves a remainder of 1 when divided by 97. That catches almost every single-character typo.

Wikidata Q-id. Q followed by digits, e.g. Q26989.

import re

CIN_RE = re.compile(r"^[LU]\d{5}[A-Z]{2}\d{4}[A-Z]{3}\d{6}$")
QID_RE = re.compile(r"^Q[1-9]\d*$")

def lei_ok(lei: str) -> bool:
    if not re.fullmatch(r"[A-Z0-9]{18}\d{2}", lei):
        return False
    digits = "".join(str(int(c, 36)) for c in lei)
    return int(digits) % 97 == 1

def normalise(raw: str):
    """Return (kind, cleaned) or (None, raw) if it fails validation."""
    s = raw.strip().upper().replace(" ", "")
    if CIN_RE.match(s):
        return "cin", s
    if lei_ok(s):
        return "lei", s
    if QID_RE.match(s):
        return "qid", s
    return None, raw

print(normalise(" l85110ka1981plc013115 "))  # ('cin', 'L85110KA1981PLC013115')
print(lei_ok("335800TYLGG93MM7PR89"))        # True
print(lei_ok("335800TYLGG93MM7PR98"))        # False: swapped check digits

Run this over every column first and log the rejects. In real data the reject list is usually where the interesting cleanup is.

Step 2: resolve every valid ID to one key

Now you need something that knows a CIN, an LEI and a Q-id can point at the same company. Data Galactica gives every organisation a permanent Galactica ID (DGC- plus 12 characters; people get DGP-), and its resolver accepts CINs and LLPINs, LEI-<lei>, GB-<number> for UK companies, CIK-<n> for SEC filers, Wikidata Q-ids, or a Galactica ID.

import requests

BASE = "https://api.datagalactica.com/api/v1"
HEAD = {"Authorization": "Bearer YOUR_KEY"}

PREFIX = {"cin": "", "lei": "LEI-", "qid": ""}

def resolve(kind: str, value: str):
    r = requests.get(f"{BASE}/resolve",
                     params={"id": PREFIX[kind] + value},
                     headers=HEAD, timeout=20)
    if r.status_code == 404:
        return None          # not found, and not billed
    r.raise_for_status()
    d = r.json()["data"]
    return d["galactica_id"], d["name"], d["quality"]

Feed it the three sources and build a crosswalk:

from collections import defaultdict

rows = [("finance", "L85110KA1981PLC013115"),
        ("treasury", "335800TYLGG93MM7PR89"),
        ("research", "Q26989")]

crosswalk = defaultdict(list)
for source, raw in rows:
    kind, value = normalise(raw)
    if kind is None:
        print("reject", source, raw)
        continue
    hit = resolve(kind, value)
    if hit:
        crosswalk[hit[0]].append((source, kind, value))

for gid, refs in crosswalk.items():
    print(gid, refs)

All three rows above land on the same key, because they are Infosys Limited's CIN, LEI and Wikidata id. That key is now the column you join on, and it doesn't change when a company renames itself or a better source turns up; the record improves and keeps its ID.

Step 3: fetch full records in batches

Once you have the unique Galactica IDs, don't call one record at a time. POST /batch takes up to 50 ids and returns {id, found, record} for each:

def batch(ids):
    r = requests.post(f"{BASE}/batch", json={"ids": ids},
                      headers=HEAD, timeout=30)
    r.raise_for_status()
    return {x["id"]: x["record"] for x in r.json()["data"]["results"] if x["found"]}

ids = list(crosswalk)
records = {}
for i in range(0, len(ids), 50):
    records.update(batch(ids[i:i + 50]))

Things that will bite you

Don't treat the grade as truth. Every record carries a grade (bronze, silver, gold, verified). Keep it as a column and filter on it for anything that matters.
Name-only matches are probabilistic. This pipeline avoids names on purpose. If you must match on names, keep the confidence score and review the low ones by hand. The About the data page is upfront that matching a typed employer to a registered company can be wrong.
Cache resolutions. An ID-to-key mapping is stable, so store it and you only pay once per identifier.
Validate before you call. Step 1 is free; lookups are billed per successful call.

Cost and setup

At the time of writing the API page offers Rs 50 of free credit to start, and the OpenAPI spec lists /resolve and /batch at Rs 0.16 per successful call or record found, with 404s not billed. Check the page for current pricing before you budget a big backfill.

If you use another resolver, steps 1 and 3 still apply: validate locally, resolve once, cache the key, batch the reads.

Verify a company by name in 3 API calls (curl + Python)

Data Galactica — Fri, 23 Oct 2026 03:27:14 +0000

Sunny Mittal works on marketing at Data Galactica. This post compares Data Galactica with other tools using each vendor's public pages as of the publish date; corrections welcome.

Onboarding forms collect a company name, and company names are messy. "Infosys Ltd", "INFOSYS LIMITED" and "Infosys" might be the same company, or they might not. In this tutorial we'll take a typed name and go to a single verified record in three HTTP calls, using the Data Galactica API. Each call is shown with curl and with Python.

Step 0: get a key

Sign up at datagalactica.com/signup with your e-mail address and the code it sends you. The account is approved straight away, and your first key comes with â‚¹50 of free credit, which the API page says is about 312 calls. After that, each answered call costs â‚¹0.16 from a prepaid wallet. Errors and not-found answers are free, and so are a few lookup endpoints, including the one in Call 1.

export DG_API_KEY="your_key_here"

The base URL is https://api.datagalactica.com/api/v1, and the key goes in an Authorization: Bearer header.

Call 1 (free): see who shares the name

Before you verify anything, see how many records share the name. /suggest is a free typeahead endpoint and doesn't need a key:

curl "https://api.datagalactica.com/api/v1/suggest?q=infosys&type=company"

The first three results when I ran it:

DGC-8SFS42RSWAX9  gold    Infosys Limited  Bangalore, India
DGC-QH4XM7Q9189S  bronze  Infosys          Kolkata, India
DGC-36DSG3SV65YH  bronze  Infosys          Faridabad, India

This is the whole reason to verify. All three are called "Infosys", and only one is the IT company. The grade (bronze, silver, gold, verified) describes the contact details the registry holds, not whether two records are the same entity. Data Galactica's own notes for developers say exactly this, and use these Infosys records as the example. To tell records apart, use the place, the identifiers and the sources.

DGC- means an organisation and DGP- means a person. A Galactica ID doesn't change once it's issued.

Call 2: verify what the customer typed

/verify/company takes the typed name plus whatever else you have (country, city, website) and returns a verdict:

curl -H "Authorization: Bearer $DG_API_KEY" \
  "https://api.datagalactica.com/api/v1/verify/company?name=Infosys+Ltd&country=IN&website=infosys.com"

A trimmed response, from the API documentation:

{ "ok": true, "data": {
  "verdict": "match", "confidence": 1, "operating": true,
  "match": { "id": "DGC-8SFS42RSWAX9", "name": "Infosys Limited",
    "status": "operating", "quality": "gold" },
  "checks": { "name": { "ok": true, "score": 1 },
    "country": { "ok": true }, "website": { "ok": true } },
  "candidates": [ ... ]
} }

Three fields matter here. verdict gives the answer, checks shows which of your fields agreed, and operating tells you whether the company is still trading. If the verdict is possible_match, the developer guidance is to show the candidates to a person and stop, not to pick one automatically.

Call 3: fetch the full record by Galactica ID

Store the ID, not the name. Then fetch the record:

curl -H "Authorization: Bearer $DG_API_KEY" \
  "https://api.datagalactica.com/api/v1/company/DGC-8SFS42RSWAX9"

{ "ok": true, "data": {
  "id": "DGC-8SFS42RSWAX9", "name": "Infosys Limited",
  "status": "operating", "founded": "1981-07-02",
  "identifiers": { "cin": "L85110KA1981PLC013115",
    "lei": "335800TYLGG93MM7PR89", "wikidata": "Q26989" },
  "quality": { "overall": "gold" }
} }

The same endpoint accepts other identifiers in place of the Galactica ID. /company/L85110KA1981PLC013115 (the Indian CIN) gets you the same record, and so do the LEI, a UK company number, a US SEC CIK or a Wikidata ID. So if your CRM stores CINs and your finance system stores LEIs, both resolve to one key.

All three calls in Python

import os, sys, requests

BASE = "https://api.datagalactica.com/api/v1"
KEY = os.environ.get("DG_API_KEY")  # from datagalactica.com/signup
HEADERS = {"Authorization": f"Bearer {KEY}"} if KEY else {}

def get(path, **params):
    r = requests.get(f"{BASE}{path}", params=params, headers=HEADERS, timeout=30)
    body = r.json()
    if not body.get("ok"):
        sys.exit(f"{r.status_code} {body['error']['code']}: {body['error']['message']}")
    return body["data"]

# Call 1 (free, no key): which records share this name?
for hit in get("/suggest", q="infosys", type="company")["results"][:3]:
    print(hit["id"], hit["grade"], hit["name"], "|", hit["place"])

# Call 2 (billed): verify the company the customer typed
v = get("/verify/company", name="Infosys Ltd", country="IN", website="infosys.com")
print(v["verdict"], v["confidence"], v["match"]["id"], v["operating"])

# Call 3 (billed): full record by Galactica ID (a CIN or LEI works too)
c = get(f"/company/{v['match']['id']}")
print(c["name"], c["status"], c["identifiers"])

If you run it without a key, Call 1 still prints, and the script then stops cleanly on the 401 api_key_required error with a link to sign up. I checked that behaviour before publishing. In production, handle 402 insufficient_balance the same way: the API returns it when the prepaid wallet is empty.

Things to keep in mind

Names collide. Treat a single name match as unconfirmed until place or an identifier agrees.
Cite the ID. Data Galactica asks that answers cite the Galactica ID and the record's page URL.
People records are sensitive. The registry also holds records about people. If you're curious what it holds about you, the Galactica Check page shows your own records after you confirm a code sent to your e-mail, and lets you correct, hide or remove them.

That's it: one free call to see the ambiguity, one to resolve it, one to fetch the record. For bulk clean-up, the same API has /match, which takes up to 25 CRM rows per call and is billed per row matched.

Sunny Mittal works on marketing at Data Galactica. This post compares Data Galactica with other tools using each vendor's public pages as of the publish date; corrections welcome.