For endpoint details, request/response schemas, and code examples, see the Search API Reference.
Why Search Matters
Every Topograph integration starts with a company ID:- Prefill: Pass the ID to
POST /v2/companywithmode: "prefill"to prefill customer forms (modes) - Verification: Pass the ID to
/v2/companyto fetch authoritative register data - Documents: Use the ID to retrieve official PDFs from public registers
- Monitoring: Use the ID to track changes over time
How Search Works
Topograph combines multiple data sources to give you the best possible results:Live register search
Topograph searches official company registers directly. Each register determines which names and identifiers it supports and how it matches your query. Some support fuzzy matching; others require an exact match.Indexed search
In supported countries, an index of company data provides fast results and supports partial names and spelling variations. Recently registered companies or recent changes may appear in the live register before they appear in the index. When several sources are available, Topograph searches them in parallel and combines their results. This can include more than one live register. Each source has its own response time. A standard request waits for the search to finish and returns a JSON array. Streaming lets you display the results already found while the other sources continue searching.Streaming search
Addstream=true to GET /v2/search. The response uses Server-Sent Events (SSE) with a Content-Type of text/event-stream, instead of a single JSON response.
Use streaming for an autocomplete or company picker. Users can select a company as soon as it appears, without waiting for the slowest source. Streaming changes when you receive results; it does not make an individual source faster.
Try it with cURL
Replace<api-key> with your API key. --no-buffer prints each event as it arrives.
Events and result updates
Each event has anevent: line and a JSON data: payload, followed by a blank line. These are named events, so a client must handle progress, complete, and error explicitly.
Every
results array is the full result list so far, not a batch of new items. Replace your displayed list on each progress or complete event. Appending each array would create duplicate entries. Use the combination of countryCode and id as a stable item key; result order can change as more sources respond.
For example, a stream could look like this (illustrative company data):
progress events. A search may emit complete directly. Always process its results, even if no earlier event arrived.
Node.js example
This server-side example uses Node.js 22 or later and its built-infetch. It reads complete SSE events even when a network chunk splits a line or contains several events. The callback receives each current result list and whether the search is complete.
responseType: 'stream' and pass response.data to createInterface as the input stream. The same SSE event handling applies. Reading the response as JSON, or buffering the full response before parsing it, prevents progressive display.
Connect it to your interface
- Debounce typing before starting a request. When the query or country changes, cancel the previous connection and ignore any late updates from the old query.
- On each
progress, replace the displayed list and keep a loading indicator for the remaining results. Let users select a result immediately. - On
complete, replace the list one last time and stop loading. Show “No companies found” only if that final list is empty. - On an SSE
error, a failed HTTP response, or a connection closing withoutcompleteorerror, stop loading and offer a retry. You may keep earlier results visible, but mark the search as incomplete. - Once the user selects a company, preserve its
idandcountryCodefor the company data request. Cancel the search connection if you no longer need updates. - If your backend forwards the stream, disable response buffering on that route and any intervening proxy. Otherwise, the browser may receive all events together at the end.
transliterate option.
Search streaming and prefill mode are separate options.
stream=true controls delivery from GET /v2/search; mode: "prefill" controls data retrieval from POST /v2/company. The prefill deadline does not apply to search.Document lists can also arrive progressively, through webhooks or polling rather than this search SSE endpoint. See progressive document delivery.Understanding Results
Match Types
Every result includes amatchReason that explains how it was found. This helps you assess result quality and build appropriate logic around different confidence levels.
When
matchType is id or partialId, the response includes an identifier field showing exactly what matched (e.g., { "VAT": "02580590541" } or { "CCIAA": "TO", "REA Code": "1234567" }).
When matchType is default, the result came from the registry’s own search algorithm. Quality varies significantly: some registries return highly relevant results, others may include tangential matches. Consider default results as suggestions that benefit from user confirmation.
Result Ordering
Results are automatically sorted by match reliability:id: Guaranteed matches appear firstexactLegalName: Exact name matches secondpartialId: Partial identifier matches thirddefault: Generic matches last
default matches to help users make informed selections.
Active companies only
AddactiveOnly=true to GET /v2/search to leave out companies the register reports as no longer active: dissolved, struck off, deregistered or closed.
company.status on POST /v2/company before relying on it.
How much the filter can do depends on the country: each country guide has an Active companies only paragraph under its search section, and each country’s entry in the catalog carries the same information as a search object:
Set
strictActiveOnly=true to also exclude companies whose search status is unknown. It implies activeOnly=true and returns only results explicitly reported as active. The status can come from a periodic snapshot; use the company endpoint when you need a current verification.
The worldwide search accepts the same strictActiveOnly option. Both Topograph MCP search tools expose it as strict_active_only.
There is no filter for inactive companies only. Without activeOnly, search results are not filtered on status.
Search by LEI
A Legal Entity Identifier (LEI) works as a query in every country. Send the 20-character LEI and the search returns the company it designates, under the registration number you pass to/v2/company.
The LEI decides where the company is registered. With
country=FR and the LEI of a German company, the result is the German company, with countryCode: "DE". Read countryCode from the result, not from your request.
An LEI is not always held by a company. Many funds, pension schemes, trusts and civil partnerships have one but appear in no company register, so searching their LEI returns an empty list. That is the expected answer, not a failure.
LEI records come from GLEIF, the organisation that publishes every LEI, and are refreshed daily. An LEI issued today can take a day to become searchable. Only entities that applied for an LEI have one: most large companies, banks and funds do, most small companies do not.
Search by LEI works in development environments too, with the same outcomes for each LEI and a generated company in place of the real one.
Searching Effectively
Search by Identifier When Possible
If you have a company’s VAT number, registration number, tax code or LEI, search with that. Identifier searches returnid match types, guaranteed 1:1 matches with no ambiguity. This is always the most reliable approach.
Scope by Country
Always specify the country. Country-scoped searches are faster and return more relevant results. If you’re building an onboarding flow, you likely already know the customer’s country from earlier in your form.Handle Ambiguous Results
When your search returns multiple results withdefault match types, present them to the user for selection rather than auto-selecting. The first result isn’t always the right one, and registries don’t always order by relevance.
Use Streaming for Interactive UIs
Use streaming search to display results as they arrive. Users can select a company while other sources are still responding.Search in the KYB Flow
Search is the critical first step in a typical KYB onboarding flow:- Search: Customer finds their company, you capture the ID
- Onboard: Use the ID with
POST /v2/companyandmode: "prefill"to prefill forms quickly (10-second deadline per datapoint) - Verify: Use the ID with
/v2/companyto fetch authoritative register data - Monitor: Use the ID to track changes and stay compliant
No country? Use global search
Every/v2/search call needs a country. When you only have a name (a shareholder listed in a foreign filing, a counterparty on an invoice), send it to POST /v2/search/global with anything else you know, in one line of text: "Bamberger GmbH, Wien". It returns ranked candidates across every country Topograph covers, each with its country, registration number and an explanation.
Each US state is its own register, so an American company needs its state. To search every state at once, send "countries": ["US"] to global search: it finds the state and searches nothing outside the United States.
Global Search
How to send what you know, read the answer, and stream the search as it runs.
Fair Use
Search is free under a fair use policy, proportional to the company lookups it leads to. It’s the resolution layer that gives you the ID you pass to/v2/company, so search volume is expected to track the company data you go on to retrieve.
Typeahead is exactly what search is built for. Search accepts partial names and identifiers (a 2-character minimum applies), so you can wire it straight into an autocomplete. Debounce on the client so you send a request when the user pauses typing rather than on every keystroke, and use streaming mode for instant feedback.
What sits outside fair use is using search as a standalone database: high-volume exploratory querying that rarely converts into a company lookup, or enumerating a register to harvest its index. Those patterns may be rate-limited. If you expect very high search throughput, get in touch so we can size limits to your flow.
KYB Onboarding Best Practices
Learn how to combine search with prefill and verification endpoints to build high-conversion KYB flows.
Country Considerations
Search capabilities vary by country due to differences in registry APIs and data availability:
Countries with fast search indexes generally offer faster responses and better fuzzy matching. For detailed country-specific information, browse Country Guides.
Company ID formats vary by country. German IDs combine register and city (e.g., “Augsburg HRB 34617”). French IDs are SIREN numbers (9 digits). Italian searches can use VAT, Codice Fiscale, or CCIAA+REA combinations. The ID returned by search is always the correct format to use with other Topograph endpoints.
Best Practices
For Automated Workflows
For Automated Workflows
- Search by identifier (VAT, registration number) whenever available
- Only trust
idmatch types for fully automated processing - Filter by match type and queue
defaultmatches for manual review - Store the company IDs you retrieve for future API calls
For User Interfaces
For User Interfaces
- Use streaming mode for instant feedback as results arrive
- Display match type indicators to help users assess result confidence
- Show the matched identifier (VAT, registration number) when available
- Let users confirm their selection rather than auto-selecting ambiguous matches
- Consider showing a “Verified” badge for
idmatches
For High-Volume Operations
For High-Volume Operations
- Prefer identifier-based searches for maximum reliability
- Stored source data company IDs from search results for subsequent API calls
- Set strict match type requirements, only process
idmatches automatically - Handle lower-confidence matches in a separate review queue
Next Steps
Once you have a company ID from search, you’re ready to retrieve data:Data retrieval modes
Verification vs prefill (
mode) for the same /v2/company endpointVerification Data
Authoritative data fetched directly from public registers
API Reference
Complete endpoint documentation with request/response schemas
Country Guides
Country-level details on search capabilities and identifier formats