Everyone reaches for OpenCorporates, gets back 401 Invalid Api Token, and concludes that clean company data now costs money. It does not. The company you just scraped filed a record with a government somewhere, and that government publishes the record for free, no key, no signup. SEC EDGAR turns a US ticker into a full XBRL filing. GLEIF turns any legal entity into a global LEI. A dozen national registers turn a name into a registration number. The paid enrichment vendor is for dedup and scoring on top, not for the primary ID.
A free company data API returns a company's legal identity (an ID, a jurisdiction, a registration record) without a paid vendor or an API key. The nine below need neither a key nor a signup. I re-verified each with a live curl on July 4, 2026 (HTTP 200), and every response you see is the real output, trimmed for length, not paraphrased. If you scrape or monitor companies like I do, your output is a messy list of names. These are the lookups that turn each name into something you can actually join on.
Let me be straight about what this is not. I am not claiming I ran an entity resolver across all 2,190 runs. That would be a lie. These are the free lookups I reach for when a scraped list has a company-name column and no IDs. One honest caveat up front: the live values below (a revenue figure, an employee count) drift with every filing, so trust the shape of the response, not the exact number, and run the curl yourself.
Here is the full set at a glance, grouped by the job each one does, then a section each.
| # | API | What it resolves | Example call | No key? |
|---|---|---|---|---|
| 1 | SEC EDGAR (US, 3 endpoints) | Ticker/CIK to issuer, financials, filings | GET data.sec.gov/submissions/CIK…json |
Yes (UA + ~10/s) |
| 2 | GLEIF | Name to a global LEI + jurisdiction | GET api.gleif.org/api/v1/lei-records?filter… |
Yes |
| 3 | OpenFIGI | ISIN or ticker to FIGI | POST api.openfigi.com/v3/mapping |
Yes (~25/min) |
| 4 | Brreg (Norway) | Name to orgnr + employees | GET data.brreg.no/…/enheter?navn= |
Yes |
| 5 | recherche-entreprises (France) | Name to SIREN/SIRET | GET recherche-entreprises.api.gouv.fr/search?q= |
Yes |
| 6 | Ariregister (Estonia) | Name to reg_code | GET ariregister.rik.ee/est/api/autocomplete?q= |
Yes |
| 7 | ARES (Czechia) | ICO to name + address | GET ares.gov.cz/…/ekonomicke-subjekty/<ico> |
Yes |
| 8 | KRS (Poland) | KRS number to full extract | GET api-krs.ms.gov.pl/api/krs/OdpisAktualny/<n> |
Yes |
| 9 | Wikidata SPARQL | Q-id to LEI + ISIN + registry IDs | GET query.wikidata.org/sparql?query= |
Yes |
Here is the thing that makes this list a list and not one API. Apple has no single ID. It is CIK 320193 at the SEC, LEI HWUPKR0MPOU8FGXBT394 at GLEIF, and FIGI BBG000B9XRY4 at OpenFIGI. One company, three identifiers, none of which the others know about. That fragmentation is the whole problem. Which source you hit depends on what you have and where the company is incorporated.
Group A: US public companies (issuer, financials, filings)
If the company files with the US Securities and Exchange Commission, you are done. EDGAR is the richest free company data source on the planet, and it is three keyless endpoints, not one. The catch is a fair-access rule people trip over daily, so I will say it loudly: SEC requires a non-empty User-Agent with a contact. Send a blank or default UA and you get a 403. Every SEC curl below carries one.
1. SEC EDGAR Submissions: ticker, exchange, SIC, EIN, state
Hand EDGAR a CIK (zero-padded to ten digits) and it returns the issuer's whole identity plus its filing history. This is the record everything else points back to.
# runnable, read-only
curl -A "my-tool/1.0 (you@example.com)" \
"https://data.sec.gov/submissions/CIK0000320193.json"
{"cik":"320193","name":"Apple Inc.","tickers":["AAPL"],"exchanges":["Nasdaq"],
"sic":"3571","sicDescription":"Electronic Computers","ein":"942404110",
"stateOfIncorporation":"CA",
"filings":{"recent":{ ... 10-K, 10-Q, 8-K forms ... }}}
That single call resolves CIK 320193 into the official name, ticker, exchange, industry code, EIN, and state of incorporation. It came back as 164 KB, most of it the filing index. The documented limit is about 10 requests per second without a key. Source: sec.gov/os/webmaster-faq#developers, and verify the current number before a bulk job.
When to use it: you have a US ticker or CIK and need the canonical issuer profile.
2. SEC EDGAR XBRL facts: structured financials, no HTML parsing
The same keyless host serves financials as clean XBRL JSON, so you never scrape a 10-Q table again. Ask for one GAAP concept:
# runnable, read-only
curl -A "my-tool/1.0 (you@example.com)" \
"https://data.sec.gov/api/xbrl/companyconcept/CIK0000320193/us-gaap/RevenueFromContractWithCustomerExcludingAssessedTax.json"
{"cik":320193,"entityName":"Apple Inc.",
"label":"Revenue from Contract with Customer, Excluding Assessed Tax",
"units":{"USD":[ ... ,
{"start":"2025-12-28","end":"2026-03-28","val":111184000000,
"form":"10-Q","fp":"Q2","fy":2026,"filed":"2026-05-01"}]}}
Apple's Q2 FY2026 revenue reads back as 111184000000, so $111.184 billion, straight from the filing. Want the whole financial profile in one shot? GET /api/xbrl/companyfacts/CIK0000320193.json returns roughly 3.75 MB across the dei and us-gaap taxonomies. Its DEI EntityCommonStockSharesOutstanding gave me 14,687,356,000 shares as of 2026-04-17. Same UA rule, same 10 req/s.
When to use it: you need a specific financial line for a US filer without touching HTML.
3. SEC EDGAR full-text search: any word to a filing
The third endpoint runs the other direction. Give it a phrase and it returns filings plus the issuer name, ticker, and CIK. That is reverse resolution: who mentions this thing?
# runnable, read-only
curl -A "my-tool/1.0 (you@example.com)" \
"https://efts.sec.gov/LATEST/search-index?q=%22battery%22&forms=10-K&startdt=2026-01-01&enddt=2026-06-30"
{"hits":{"total":{"value":787,"relation":"gte"},
"hits":[{"_source":{"ciks":["0001811414"],
"display_names":["QuantumScape Corp (QS) (CIK 0001811414)"],
"root_forms":["10-K"],"file_date":"2026-02-25"}}, ... ]}}
That is 787-plus 10-K filings mentioning "battery" in the first half of 2026, and the first hit hands you the issuer, ticker QS, and CIK 0001811414 for free. One gotcha I hit live: raw quotes break it. q="Tesla" with unencoded quotes returned HTTP 400 with an empty body. URL-encode the phrase as %22Tesla%22 and it works.
When to use it: finding filers by topic, or reverse-resolving a name mentioned in a document into a CIK.
Group B: the universal glue (one ID for the whole planet)
National registers stop at borders. Two keyless services do not.
4. GLEIF: any legal entity to a global LEI
The Legal Entity Identifier is the one cross-jurisdiction ID for companies, an ISO 17442 code issued under the Global LEI Foundation, a non-profit. Its API is fully open, no key. Search by name:
# runnable, read-only
curl "https://api.gleif.org/api/v1/lei-records?filter%5Bentity.legalName%5D=Apple%20Inc.&page%5Bsize%5D=1"
{"data":[{"attributes":{"lei":"HWUPKR0MPOU8FGXBT394",
"entity":{"legalName":{"name":"Apple Inc."},"jurisdiction":"US-CA",
"status":"ACTIVE","headquartersAddress":{"country":"US"}},
"registration":{"status":"ISSUED"}}}]}
The name Apple Inc. resolves to LEI HWUPKR0MPOU8FGXBT394, jurisdiction US-CA, status ACTIVE. You can also go direct: GET /api/v1/lei-records/HWUPKR0MPOU8FGXBT394 returns the same record by ID. This is the field I actually key on when a list spans countries, because it is the only ID that does.
When to use it: you need one identifier that works for a German GmbH and a US Inc. alike.
5. OpenFIGI: ISIN to ticker to FIGI
OpenFIGI (the Bloomberg-sponsored open FIGI standard) maps between security identifiers. It is the bridge between "a security" and "the company behind it." Two things to know before you write code: it is a POST with a JSON array, not a GET, and the keyless tier is rate-limited.
# runnable, read-only
curl -X POST "https://api.openfigi.com/v3/mapping" \
-H "Content-Type: application/json" \
-d '[{"idType":"ID_ISIN","idValue":"US0378331005"}]'
[{"data":[{"figi":"BBG000B9XRY4","name":"APPLE INC","ticker":"AAPL",
"exchCode":"US","compositeFIGI":"BBG000B9XRY4",
"securityType":"Common Stock","marketSector":"Equity"}, ... ]}]
ISIN US0378331005 maps to FIGI BBG000B9XRY4, ticker AAPL, across every exchange it trades on (the response had multiple exchange rows). Keyless is not unlimited: the documented cap is about 25 requests per minute without a key, up to 10 jobs per request. A free key lifts it toward ~250/minute. Batch by ten and grab the free key for bulk. Source: openfigi.com/api, verify the current number.
When to use it: you have a ticker or ISIN and want the company and every venue it lists on.
Group C: national business registers (the source of truth per country)
Here is the honest reality of company data: there is no world register. Each country runs its own, in its own language, returning its own ID type. That is not a bug to abstract away, it is why GLEIF exists on top. Five keyless registers, five formats, one pattern.
6. Brreg (Norway): name to orgnr, employees, industry
Norway's Bronnoysund register is open data by law. Search by name:
# runnable, read-only
curl "https://data.brreg.no/enhetsregisteret/api/enheter?navn=Equinor%20ASA"
{"_embedded":{"enheter":[{"organisasjonsnummer":"923609016","navn":"EQUINOR ASA",
"organisasjonsform":{"kode":"ASA","beskrivelse":"Allmennaksjeselskap"},
"registreringsdatoEnhetsregisteret":"1995-03-12","antallAnsatte":21467,
"naeringskode1":{"beskrivelse":"Utvinning av raolje"}}]}}
"Equinor ASA" resolves to org number 923609016, legal form ASA, registered 1995-03-12, antallAnsatte 21467 employees, industry "Utvinning av raolje" (crude oil extraction). That employee count is a real, non-round number pulled straight from the state register, no vendor in the loop.
When to use it: any Norwegian entity. Full open data, no key.
7. recherche-entreprises (France): name to SIREN and SIRET
France is a keyless-layer story worth telling. The raw INSEE Sirene API (api.insee.fr) now wants an OAuth token. The government convenience layer built on top of it, run by DINUM, does not.
# runnable, read-only
curl "https://recherche-entreprises.api.gouv.fr/search?q=Danone&page=1&per_page=1"
{"results":[{"siren":"552032534","nom_complet":"DANONE",
"siege":{"siret":"55203253400703","libelle_commune":"PARIS"},
"nature_juridique":"5599","activite_principale":"70.10Z"}],
"total_results":441}
"Danone" resolves to SIREN 552032534 (the entity-level ID) plus SIRET 55203253400703 (the specific establishment, its Paris head office). The total_results of 441 is your reminder that this is fuzzy search: check the name before you trust the top hit.
When to use it: any French company, when the raw statistics API's token requirement is more friction than you want.
8. Ariregister (Estonia): name to reg_code
Estonia is the poster child for open registries. Its autocomplete endpoint answers keyless, in English if you ask.
# runnable, read-only
curl "https://ariregister.rik.ee/est/api/autocomplete?q=Bolt&results_language=eng"
{"status":"OK","data":[{"company_id":9000439617,"reg_code":17449106,
"name":"Bolt App Services AS","status":"R",
"legal_address":"Harju maakond, Tallinn, Kesklinna linnaosa, Vana-Louna tn 15",
"zip_code":"10134"}]}
"Bolt" resolves to reg_code 17449106 for Bolt App Services AS, status R (registered), with the full Tallinn legal address. Clean, fast, keyless.
When to use it: Estonian entities, or a quick demo of what an open register should feel like.
9. ARES (Czechia): ICO to name, address, legal form
The Czech Ministry of Finance runs ARES as a keyless REST service. Here you query by the ICO (the Czech company registration number) directly.
# runnable, read-only
curl "https://ares.gov.cz/ekonomicke-subjekty-v-be/rest/ekonomicke-subjekty/00177041"
{"ico":"00177041","obchodniJmeno":"Skoda Auto a.s.",
"sidlo":{"textovaAdresa":"tr. Vaclava Klementa 869, Mlada Boleslav II, 29301 Mlada Boleslav"},
"pravniForma":"121"}
ICO 00177041 resolves to Skoda Auto a.s., full registered address, legal-form code 121. This one is a direct lookup by ID rather than a name search, which is faster when you already have the ICO.
When to use it: Czech entities where you hold the registration number.
10. KRS (Poland): registration number to the full extract
Poland's Ministry of Justice publishes the National Court Register (KRS) as a keyless API. One required trick: pass rejestr=P (the entrepreneurs register) or you get nothing back.
# runnable, read-only
curl "https://api-krs.ms.gov.pl/api/krs/OdpisAktualny/0000028860?rejestr=P&format=json"
{"odpis":{"naglowekA":{"numerKRS":"0000028860"},
"dane":{"dzial1":{"danePodmiotu":{"nazwa":"ORLEN SPOLKA AKCYJNA",
"formaPrawna":"SPOLKA AKCYJNA"}}}}}
KRS 0000028860 resolves to ORLEN SPOLKA AKCYJNA, legal form SA, and the full JSON carries the board, share capital, and address in nested dzial sections. It is verbose, but it is the primary record.
When to use it: Polish entities where you have the KRS number and want the complete current extract.
(That is nine providers; SEC EDGAR counts once with its three endpoints, and Poland's KRS is the fifth national register. The #10 heading is just its position in the walk-through.)
Group D: cross-jurisdiction resolution (one query, every ID)
11. Wikidata SPARQL: Q-id to LEI, ISIN, ticker, registry IDs at once
Every register above gives you one country's ID. Wikidata gives you the join across all of them. It is the only endpoint on this list that returns an LEI, an ISIN, a ticker, and national registry IDs in a single response, keyed off a Wikidata entity ID.
# runnable, read-only
curl -G "https://query.wikidata.org/sparql?format=json" \
-A "my-tool/1.0 (you@example.com)" \
--data-urlencode 'query=SELECT ?companyLabel ?isin ?lei WHERE { wd:Q312 rdfs:label ?companyLabel . FILTER(LANG(?companyLabel)="en") OPTIONAL { wd:Q312 wdt:P946 ?isin } OPTIONAL { wd:Q312 wdt:P1278 ?lei } }'
{"results":{"bindings":[{"companyLabel":{"value":"Apple Inc."},
"isin":{"value":"US0378331005"},"lei":{"value":"HWUPKR0MPOU8FGXBT394"}}]}}
Q312 (Apple) comes back with ISIN US0378331005 (property P946) and LEI HWUPKR0MPOU8FGXBT394 (P1278) in one call. Add P249 for the ticker, P5531 for the CIK, and national registry properties to pull them all together.
One honest disclosure, because I care about not padding this list. Wikidata is part of the Wikimedia family, and in an earlier keyless roundup I listed the Wikipedia REST API. This is not that. Wikipedia REST returns an article summary; this is the SPARQL graph, a different host doing a different job. I include it here because cross-jurisdiction resolution is a job no register can do, and it earns the slot on that alone. It wants a polite User-Agent too.
When to use it: you have a name or a Q-id and want every external ID in one hop, before you touch a paid vendor.
Bonus: validate an EU VAT number with VIES
This one is not name resolution, so it is a bonus, not a tenth register. VIES, the European Commission's VAT validation service, tells you whether an EU VAT number is live, keyless, via POST.
# runnable, read-only
curl -X POST "https://ec.europa.eu/taxation_customs/vies/rest-api/check-vat-number" \
-H "Content-Type: application/json" \
-d '{"countryCode":"ES","vatNumber":"A15022510"}'
{"countryCode":"ES","vatNumber":"A15022510","valid":true,"name":"---","address":"---"}
Be honest about what it does. It returns valid: true/false, but name and address often come back as "---" depending on the member state. A German VAT 811569869 validated true with the same blank name; an invalid number returned valid:false. So it answers "is this VAT live and in which country," not "who is this." Useful as a sanity check on a scraped VAT field, not as a resolver.
Why some "free" company APIs did not make the cut
This is the section that proves the opening claim. The popular aggregators went behind a key or a wall; the primary sources never did. Every code below is from a live curl on July 4, 2026.
-
OpenCorporates (
api.opencorporates.com/v0.4/companies/search?q=google) returnedHTTP 401{"error":{"message":"Invalid Api Token..."}}. The old go-to almost-keyless aggregator now requires a token. This is the literal trigger for the whole post. -
UK Companies House (
api.company-information.service.gov.uk/search/companies?q=tesco) returnedHTTP 401{"error":"Empty Authorization header"}. Genuinely free, but you register for an API key and use Basic auth. Honorable, not keyless. -
ABN Lookup (Australia) returned
HTTP 200, but the body was{"Message":"The GUID entered is not registered..."}. The 200 is a trap: it needs a registered GUID, which is a key in all but name. Technically 200, actually gated. -
Switzerland Zefix returned
HTTP 403empty from my server IP, likely a datacenter-IP block. It may work from a browser; I could not verify it from the server, so I left it off rather than guess. -
Denmark cvrapi.dk returned
HTTP 403empty (third-party proxy block). The official Danish CVR distribution wants authentication. -
INSEE Sirene direct (
api.insee.fr) now requires an OAuth token, which is exactly why number 5 uses the DINUM convenience layer on top of it instead. - Commercial enrichment (Clearbit, Abstract, Crunchbase, People Data Labs) are paid or key-gated by design. That is the layer my angle says you do not need for a primitive name-to-ID.
Keeping these alive under real traffic
The failure mode with free registers is never the first call, it is the pattern of calls. A few habits:
Cache the resolved ID, not the query. A company shows up many times across a scraped list. Resolve the name to an LEI or a CIK once, store it, and reuse the key. Registers reward a cache and punish a name-search loop.
Respect the two documented ceilings. SEC is about 10 requests per second and refuses a blank User-Agent. OpenFIGI is about 25 requests per minute keyless. Queue and sleep, or take the free OpenFIGI key for bulk. A burst that passes today is not a guarantee.
Resolve in the right order. If you have a US ticker, SEC first. If it is a global list, GLEIF first for the LEI, then the national register for local detail. Wikidata is the shortcut when you already have a clean entity match. There is no single order that fits every list.
Watch the name collisions. Fuzzy name search (total_results: 441 for Danone) is where a wrong match silently poisons a join. Confirm the top hit against a second field (jurisdiction, city) before you trust it.
For context, not a claim of scale: I build web-scraping and data-enrichment tool layers, currently 2,190 runs across 32 actors in production, and the output is always a list of things that needs enrichment columns. Security posture was last week's column. Location was the week before. Legal identity is this one. Same keyless, no-card enrichment layer, different question.
FAQ
What is the best free company data API with no API key?
It depends on jurisdiction. SEC EDGAR is unbeatable for US filers, GLEIF gives a global LEI for any legal entity, and national registers (Brreg for Norway, ARES for Czechia, KRS for Poland) cover the rest. All are keyless, no signup.
Does the SEC EDGAR API require an API key?
No key, but it requires a non-empty User-Agent header with a contact, or you get a 403. The documented limit is about 10 requests per second. It exposes submissions, XBRL financials, and full-text search, all keyless.
How do I resolve a company name into an ID for free?
GLEIF returns a global LEI from a name. For a local ID, hit the national register: SIREN in France, orgnr in Norway, reg_code in Estonia, KRS in Poland. Wikidata SPARQL returns several IDs in one query. All keyless.
Is OpenCorporates free?
Its API now requires a token and returns 401 Invalid Api Token without one. The first-party sources it aggregated (SEC EDGAR, GLEIF, and the national registers) stay keyless, so you can often skip the aggregator and go to the government source.
How do I map a ticker or ISIN to a company for free?
OpenFIGI. POST a JSON array to /v3/mapping with an ISIN or ticker and it returns the FIGI, name, and every exchange. Keyless at roughly 25 requests per minute; a free key raises the cap for bulk work.
Written by Aleksei Spinov. I build web-scraping and data-enrichment tool layers, currently 2,190 runs across 32 actors in production. Every API above was re-verified with a live curl (HTTP 200, real response) on July 4, 2026 before publishing; responses are trimmed, not paraphrased. IDs are stable, but revenue, employee counts, and result totals drift, so run the curl yourself before you wire one into anything that matters. Drafted with an AI assistant, fact-checked and edited by me.
Follow for the next batch of keyless tools I test for the enrichment layer. And tell me: what is your keyless resolution order, LEI first or the national register first, and where has a name collision quietly poisoned a join for you? I read every comment.
Top comments (0)