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 workflow starts with a company ID:
  • Onboarding: Pass the ID to /v2/onboarding to prefill customer forms
  • 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: For most queries, we leverage the search capabilities of official company registries directly. This gives you authoritative, up-to-date results. The registry’s own search algorithm determines relevance—some registries have sophisticated fuzzy matching, while others only support exact matches. For select countries, we maintain a local index of company data. This enables:
  • Faster results: Sub-second response times without registry latency
  • Better fuzzy matching: Our own search algorithms handle typos and partial matches
  • Consistent behavior: Same matching quality regardless of registry quirks
  • Higher availability: Results even when the registry is temporarily down
When both sources are available, we query them in parallel and merge the results. This gives you the speed of cached search with the comprehensiveness of live registry data.
Use streaming mode to display results as they arrive. In countries with multiple sources, your users see initial results almost instantly while additional results load in the background.

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.
Match TypeMeaningReliability
idExact match on a unique identifier (VAT, registration number, etc.)Guaranteed correct
exactLegalNameLegal name exactly matches your queryVery high
partialIdMatched on a partial identifier that isn’t globally uniqueHigh, but verify
defaultGeneric match from registry searchDepends on registry
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 workflows.

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.

Searching Effectively

Search by Identifier When Possible

If you have a company’s VAT number, registration number, or tax code, 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—registries don’t always order by relevance.

Use Streaming for Interactive UIs

In interactive applications, enable streaming to show results progressively. This improves perceived performance significantly—users see initial results in under a second rather than waiting for all sources to complete.

Search in the KYB Flow

Search is the critical first step in a typical KYB onboarding workflow:
  1. Search: Customer finds their company, you capture the ID
  2. Onboard: Use the ID with /v2/onboarding to prefill forms quickly (€0.50, P90 < 5s)
  3. Verify: Use the ID with /v2/company to fetch authoritative register data
  4. Monitor: Use the ID to track changes and stay compliant
The search step costs nothing and typically completes in under 5 seconds. It’s designed to minimize friction at the very start of your funnel.

KYB Onboarding Best Practices

Learn how to combine search with onboarding 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:
CapabilityDescription
Name searchMost countries support searching by company name
ID searchMost countries support searching by registration number or VAT
Fuzzy matchingVaries by registry—some handle typos well, others require exact matches
Response timeFrom ~200ms (cached index) to ~10s (slow registries)
Countries with cached indexes generally offer faster responses and better fuzzy matching. For detailed country-specific information, see Country Specifics or our Coverage Map.
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
  • Cache 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: