Transparenzregister API

Overview

The Transparenzregister is Germany's beneficial ownership register, containing information about the ultimate beneficial owners (UBOs) of companies. Since August 2021, it operates as a full register rather than just a catch-all for entities not covered by other registers.

The entries are self-declarations by the companies themselves. For a notary-verified view of ownership and control, pair the Transparenzregister with the Handelsregister shareholder graph (see Ownership and control data below).

Identifiers

Companies in the Transparenzregister are referenced using their Handelsregister identifiers:

Data Available

Access: delegated credentials required

If you are a German obliged entity, or you serve a German client that is one, you reach the Transparenzregister through a delegated access setup: the obliged entity's credentials are deployed into Kausate's encrypted secret store and used to authenticate the calls on their behalf. Attempting a UBO request without configured credentials returns a clear "credentials not configured" error rather than data.

How delegated access works

Step 1 — Pass the credentials into the secret store

Use the Create Integration endpoint with the de-transparenzregister datasource. The credential pair is the email and password the obliged entity uses to sign in to the Transparenzregister:

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": "obliged-entity@example.de",
      "password": "the-account-password"
    }
  }'

The response confirms the stored datasource and its timestamps; it never echoes the values back:

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

Manage credentials over their lifetime with the companion endpoints — List (to see which datasources are configured, without exposing values), Update (to rotate the password), and Delete.

Step 2 — Separate multiple customers with customerId

If you provide UBO access to several German clients, each supplies their own obliged-entity credentials. The customerId flag keeps those credential sets separate: pass it when storing the credentials, and the same identifier later selects which set is used for a call.

# Store one client's credentials under their customerId
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.de", "password": "..." }
  }'

Step 3 — Retrieve beneficial owners

Place a UBO order with the Extract Ultimate Beneficial Owners endpoint. To use a specific customer's stored credentials, send their identifier in the X-Customer-Id header — it selects the matching credential set and scopes the resulting order to that customer:

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" }'

This returns an order you can poll at GET /v2/companies/ubo/{orderId} or receive via webhook. For a blocking call that returns the completed report directly, use Extract UBOs (sync). Pass the same X-Customer-Id to the poll endpoint to read back a customer-scoped order.

Ownership and control data

Germany exposes ownership and control through two complementary sources. They answer different questions, and for KYB the registry-backed signal is usually the stronger one:

For the shareholder graph and recursive ownership extraction (which need no delegated credentials), see the Handelsregister guide. Both can be combined: the shareholder graph reconstructs the verified ownership chain, while the Transparenzregister adds the entity's own UBO declaration.

FAQ