Skip to main content
Related records use Karsa identifiers returned by earlier uploads. This is why a dataset containing documents, a customer, transactions, and outcomes must be sent in dependency order.

​
Identifier rules

  1. Every Document response returns a stable resourceId and immutable versionId.
  2. The KYB dossier uses the Customer versionId and each Document versionId.
  3. The Customer response resourceId becomes the Account customerId.
  4. The Account response resourceId becomes the Transaction receiverAccountId; the Customer resourceId remains the receiverCustomerId.
  5. The same Customer resourceId becomes customerId on each Outcome.
  6. Each Outcome has exactly one subject identifier. The other subject fields remain null.

​
Idempotency

Every call has its own stable Idempotency-Key. Retrying the same logical request uses the same key. A later corrected observation uses a new key and can append a new immutable version to the same stable identity.

​
Result of this example

The nine accepted requests create one CustomerVersion, one immutable KYB dossier and workflow run, one AccountVersion, one TransactionVersion, three DocumentVersions, two OutcomeVersions, and nine ingestion receipts.