> ## Documentation Index
> Fetch the complete documentation index at: https://docs.useasterisk.com/llms.txt
> Use this file to discover all available pages before exploring further.

> ## Agent Instructions
> Document only operations in the linked OpenAPI contract: the source-data ingestion operations and the source-scoped outbound webhook management operations.
> Treat the generated OpenAPI document as authoritative for request fields. Never invent compatibility fields, alternate endpoints, or additional source models.
> Preserve explicit nulls, decimal strings, timestamps, source identifiers, immutable version identifiers, and document-version links exactly as defined.

# Sequence a multi-record upload

> How identifiers returned by one upload are used by the next related record.

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.

```mermaid theme={null}
sequenceDiagram
  participant Source as Customer source system
  participant API as Karsa ingestion API
  Source->>API: POST document 1
  API-->>Source: document resourceId + versionId
  Source->>API: POST document 2
  API-->>Source: document resourceId + versionId
  Source->>API: POST document 3
  API-->>Source: document resourceId + versionId
  Source->>API: POST typed business customer
  API-->>Source: customer resourceId + versionId
  Source->>API: POST KYB dossier with customer version + 3 documents
  API-->>Source: dossierId + workflowRunId
  Source->>API: POST account with customerId
  API-->>Source: account resourceId + versionId
  Source->>API: POST transaction with receiverCustomerId and receiverAccountId
  API-->>Source: transaction resourceId + versionId
  Source->>API: POST outcome 1 with customerId
  API-->>Source: outcome resourceId + versionId
  Source->>API: POST outcome 2 with customerId
  API-->>Source: outcome resourceId + versionId
```

## 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.

## Related

* [Upload a complete customer dataset](/quickstart): run the complete flow
* [How records fit together](/concepts/source-schema): understand resource and version identifiers
* **API Reference**: inspect the exact route schemas and error responses


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.