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

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.