Skip to main content
Search is the entry point to Topograph. Before you can retrieve company data, download documents, or set up monitoring, you need the company’s unique identifier. Search gives you that identifier.
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/company with mode: "prefill" to prefill customer forms (modes)
  • Verification: Pass the ID to /v2/company to fetch authoritative register data
  • Documents: Use the ID to retrieve official PDFs from public registers
  • Monitoring: Use the ID to track changes over time
Search is how you get that ID. It’s free, fast, and designed to handle the complexity of finding companies across different countries with different identifier formats.

How Search Works

Topograph combines multiple data sources to give you the best possible results: 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. 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. Add stream=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 an event: 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):
Do not expect one event per source or any fixed number of 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-in fetch. 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.
Keep your Topograph API key on your server. For a browser interface, call your own backend and forward the result updates to the browser. Do not put the API key in frontend code or a query string.
If you use Axios on Node.js, set 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 without complete or error, 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 id and countryCode for 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.
A streaming search can remain open for several minutes; see timeouts. Receiving no immediate event does not mean there are no matches. Streaming search also does not apply the 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 a matchReason 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.
Results with matchType: "default" depend entirely on the underlying registry’s search quality. Always verify these matches when precision matters, especially for automated processing.

Result Ordering

Results are automatically sorted by match reliability:
  1. id: Guaranteed matches appear first
  2. exactLegalName: Exact name matches second
  3. partialId: Partial identifier matches third
  4. default: Generic matches last
This ordering ensures the most trustworthy results appear at the top. When building UIs, consider visually distinguishing high-confidence matches from default matches to help users make informed selections.

Active companies only

Add activeOnly=true to GET /v2/search to leave out companies the register reports as no longer active: dissolved, struck off, deregistered or closed.
The filter only removes what a register positively reports as inactive. When a search source returns a company without any status, the company is kept rather than hidden, so a result is not proof that the company is active: read 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.
An LEI search returns that company or nothing. It never returns companies with a similar name, so there is no list to choose from. 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 return id 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 with default 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:
  1. Search: Customer finds their company, you capture the ID
  2. Onboard: Use the ID with POST /v2/company and mode: "prefill" to prefill forms quickly (10-second deadline per datapoint)
  3. Verify: Use the ID with /v2/company to fetch authoritative register data
  4. Monitor: Use the ID to track changes and stay compliant
Use the first relevant result to move the customer into the next step. Completion time depends on the sources queried for that country. 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.
Allow at least 30 seconds when setting a client-side timeout. Search returns once every source for that country has answered, and a country queried live against its register can take considerably longer than one served from a search index. The figures above are typical, not guaranteed. A standard search that runs past about 110 seconds returns 503 with the error code search_timeout, so a client timeout above that never cuts off an answer. A streaming search ends with an error event after 3 minutes.If your flow cannot wait that long, use streaming mode and act on results as they arrive. The first results usually land in about a second, so you can proceed without waiting for the slowest source.
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

  • Search by identifier (VAT, registration number) whenever available
  • Only trust id match types for fully automated processing
  • Filter by match type and queue default matches for manual review
  • Store the company IDs you retrieve for future API calls
  • 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 id matches
  • 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 id matches 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 endpoint

Verification 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