Skip to main content
This guide covers the two API migrations introduced by the Data Product Model:
  • replace companyProfile with explicit datapoints where you want finer control
  • replace the legacy onboarding flow with POST /v2/company and mode: "onboarding"
Both legacy paths still work for backward compatibility.

​
What changed

BeforeAfter
companyProfile (one flag)company, legalRepresentatives, and optionally otherKeyPersons, establishments, shareholders, ultimateBeneficialOwners, …
POST /v2/onboardingPOST /v2/company with mode: "onboarding"

​
Step 1: Replace companyProfile (optional)

The legacy companyProfile datapoint still works. For billing and dispatch, it expands to company + legalRepresentatives only—the same pair used internally for the profile workflow. Many countries ship additional sections (other key persons, establishments, etc.) inside that profile response. To request those as first-class datapoints, add them explicitly: 
// After — equivalent billing to the legacy companyProfile + UBO request,
// with explicit company vocabulary
{
  "dataPoints": ["company", "legalRepresentatives", "ultimateBeneficialOwners"]
}

// After — when you also need other key persons and establishments as datapoints
{
  "dataPoints": [
    "company",
    "legalRepresentatives",
    "otherKeyPersons",
    "establishments",
    "ultimateBeneficialOwners"
  ]
}
Use company when you only need company-level data. Add legalRepresentatives when you also need directors and managers. Add otherKeyPersons for auditors and board members without signing authority. Add establishments for branch offices and secondary locations.
Do not mix companyProfile with the new granular names (company, legalRepresentatives, …) in the same request—the API rejects mixed legacy and new vocabulary.

​
Response keys

The dataStatus object uses the vocabulary you send. With the granular vocabulary, the response keys are explicit: 
{
  "dataStatus": {
    "dataPoints": {
      "company": { "status": "succeeded" },
      "legalRepresentatives": { "status": "succeeded" }
    }
  }
}
Legacy callers still see companyProfile echoed back in dataStatus, which is why existing integrations remain backward compatible.

​
Step 2: Replace the legacy onboarding flow

The /v2/onboarding endpoint is deprecated. Use /v2/company with mode: "onboarding" instead. 
# Before
curl -X POST https://api.topograph.co/v2/onboarding \
  -H 'x-api-key: <key>' \
  -d '{
    "countryCode": "DE",
    "id": "HRB123456"
  }'

# After
curl -X POST https://api.topograph.co/v2/company \
  -H 'x-api-key: <key>' \
  -d '{
    "countryCode": "DE",
    "id": "HRB123456",
    "dataPoints": ["company", "legalRepresentatives"],
    "mode": "onboarding"
  }'
This replaces the old onboarding profile request with the standard /v2/company endpoint. Use explicit datapoints and mode: "onboarding".

​
Compatibility

  • companyProfile still works.
  • /v2/onboarding still works, but it is deprecated.
  • New integrations should use company, legalRepresentatives, and POST /v2/company with mode: "onboarding".
  • See Data Retrieval Modes for the full behavior of onboarding mode.