Jurisdictions

Kausate reaches official business registers country by country. The way you call them is the same everywhere — this page — and what differs is on each jurisdiction's own page: which operations are available there, which identifiers it accepts, which documents you can order, and whether it needs your own registry account.

How to read a jurisdiction page

Each page lists operations with a platform-wide status:

An operation that is not listed is not available there. Pages are generated from what the platform can actually do, so absence is deliberate rather than an omission.

Status is platform-wide; whether your organisation may call something also depends on your entitlements. GET /v2/platform/jurisdictions returns the same statuses plus an enabled flag scoped to your API key.

The operations

The same nine operations exist across the platform, and a jurisdiction page lists only the ones that jurisdiction has. What each one does never varies by country, so it is said here rather than on every jurisdiction page:

Finding and identifying a company

Three ways in, depending on what you already hold:

• A kausateId — co_de_4JFFrsbQ99t1nmRw2JgzmG. Search returns it and it never changes. Report, ownership, financials and document operations take only this, so search first, then order.
• A name or a registration number — send them to search as companyName and companyNumber alongside the jurisdictionCode. Both work in every jurisdiction, which is what makes one code path able to cover many countries. You never say which kind of number you hold: it is matched against the schemes that jurisdiction uses.
• An advancedQuery — when you need to be exact. Nearly every jurisdiction accepts one, but the fields are its own: Austria takes fnr, gisaCode and zvrNumber, Italy takes rea, partitaIva and cciaa, Germany takes a court, a register type and a register number.

Advanced fields rarely carry across a border, and which combinations a register accepts, rejects or silently ignores is specific to it — so read How to search on the jurisdiction page before building a query. Registration numbers are not interchangeable either, and some countries have several that look alike but identify different things; where that is a trap, the page says so under Local notes. The same schemes label what comes back in a company's identifiers, and each page lists them under Company identifiers.

Ordering data

Every data operation comes in two forms, and the choice is yours per call:

• Asynchronous — you get an order back immediately, then poll it or receive a webhook when it completes.
• Synchronous — the call blocks and returns the finished result.

Registers are live systems and some are slow, so asynchronous is the default for anything that may take a while. Ordering the same thing twice in a day does not charge you twice.

Ordering documents

Documents are ordered in one of three ways, and each jurisdiction page's Documents you can order table tells you which applies to each one:

• By shortcut — a jurisdiction-agnostic name such as register_extract or annual_accounts. The same shortcut works in every country that has that document, so one code path covers many jurisdictions. Order it directly.
• By product code — for a document with no cross-jurisdiction equivalent, such as DEHRCD. Pass the code in the same field a shortcut goes in, so switching between the two costs nothing in your code.
• By document ID — for filings whose availability differs per company, such as individual historical filings. Call list documents for the company first, then order the ID it returns.

Connecting your own registry credentials

We reach most registers with our own access, and your Kausate API key is all you need. A few are legally restricted — access is granted to a named entity rather than sold — so there you connect your own registry account and we authenticate as you. A jurisdiction page says under Access whether this applies and which fields that register expects. The flow below is the same for every one of them.

curl -X POST "https://api.kausate.com/v2/integrations" \
  -H "X-API-Key: $API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "datasourceSlug": "de-transparenzregister",
    "secretValues": {
      "email": "registered-entity@example.com",
      "password": "the-account-password"
    }
  }'

{
  "datasourceSlug": "de-transparenzregister",
  "datasourceName": "Transparenzregister",
  "createdAt": "2026-06-06T10:00:00Z",
  "updatedAt": "2026-06-06T10:00:00Z"
}

curl -X POST "https://api.kausate.com/v2/integrations?customerId=acme-bank" \
  -H "X-API-Key: $API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "datasourceSlug": "de-transparenzregister",
    "secretValues": { "email": "kyb@acme-bank.example", "password": "..." }
  }'

curl -X POST "https://api.kausate.com/v2/companies/ubo" \
  -H "X-API-Key: $API_KEY" \
  -H "X-Customer-Id: acme-bank" \
  -H "Content-Type: application/json" \
  -d '{ "kausateId": "co_de_4JFFrsbQ99t1nmRw2JgzmG" }'

When something goes wrong

Errors use one shape and one vocabulary everywhere — the same status codes and the same dotted code values regardless of which register was behind the call. They are documented once, in Errors, including what happens when an asynchronous order fails after it was accepted.

All jurisdictions