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

# Upload a complete customer dataset

> Send one business, its KYB dossier, three documents, one account, one transaction, and two outcomes.

This flow uploads one complete customer dataset. It creates three documents, one customer, one
customer-linked account, one transaction, two outcomes, and one KYB dossier through the same routes
used by every integration.

## Prerequisites

* A Karsa API base URL provisioned for your organization.
* A source-bound bearer credential.
* Stable source identifiers for the customer and related records.
* Base64-encoded bytes and metadata for each document.

Start with `https://api.sandbox.useasterisk.com` and a sandbox credential, using synthetic data.
Production uses `https://api.useasterisk.com` and a separately provisioned credential.
See [environment and credential boundaries](/concepts/authentication#choose-an-environment).

## Upload order

| Order | Action | Identifier to keep |
| - | - | - |
| 1–3 | [Upload each document](/concepts/documents) | Each Document `versionId` |
| 4 | [Upload the customer](/concepts/customers) | Customer `resourceId` |
| 5 | [Submit the KYB dossier](/guides/kyb-dossiers) | Dossier and workflow IDs |
| 6 | [Upload the account](/concepts/accounts) | Account `resourceId` |
| 7 | [Upload the transaction](/concepts/transactions) | Transaction `resourceId` |
| 8–9 | [Upload each outcome](/concepts/outcomes) | Each Outcome `resourceId` |

The dossier uses the Customer `versionId` returned by request 4 and the three Document `versionId`
values. The account uses the Customer `resourceId`. The transaction uses the Account `resourceId`;
both customer outcomes use the Customer `resourceId`.

Every request includes `Authorization`, `Idempotency-Key`, and `Content-Type` headers. Each model
page includes a complete cURL request and response. The API Reference contains the exact field
contract and error responses.

## What success looks like

* `201 CREATED`: the stable resource and first immutable version were created.
* `200 VERSION_CREATED`: the same source record received a changed immutable snapshot.
* `200 UNCHANGED`: the submitted snapshot already matches the current version.

## Inspect the result

The tenant's **API** page shows each accepted request, its route, status, and the fields that were
present or omitted. The Customer record page shows the uploaded customer together with its linked
documents, transaction, and outcomes.

## Related

* [Business onboarding guide](/guides/business-onboarding): create a business and its UBO Customers atomically
* [Request ordering](/guides/upload-flow): see how returned identifiers move between requests
* [Authentication](/concepts/authentication): configure credentials, scopes, and idempotency
* [How records fit together](/concepts/source-schema): understand stable resources and versions


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