Skip to main content
Every request uses a source-bound bearer credential:
The authenticated principal determines the tenant, integration source, and actor. The request body cannot select or override them.

​
Credential boundary

​
Choose an environment

Use the sandbox for integration tests with synthetic data. Ask Karsa to provision your tenant and integration source in each environment, then obtain a source-bound credential for that environment. Sandbox and production have separate tenants, credentials, records, and webhook configuration. A sandbox credential does not grant access to production, and sandbox records are not promoted automatically. Resource and version IDs returned in one environment cannot be reused in the other. When moving to production, change the base URL and credential together, configure your production webhook destination, and submit your production source data. Keep the same source-ID strategy and retry behavior used during sandbox testing.

​
Source access

An active source-bound credential can call every ingestion route documented here. Karsa does not assign a separate permission to each customer, document, transaction, or outcome route. Tenant isolation and source ownership still apply. Suspending the source or revoking the credential stops ingestion through that credential.

​
Failure boundaries

  • 401 AUTHENTICATION_REQUIRED: no valid source-bound principal was established.
  • 409 SOURCE_IDENTITY_CONFLICT: the source identity is already bound incompatibly.
  • 422 FUTURE_EFFECTIVE_AT: the observation attempts unsupported future scheduling.
  • 429 RATE_LIMITED: the source exceeded its configured request rate.
Accepted and rejected calls carry a correlation requestId. Accepted calls also create an ingestion receipt visible on the tenant’s API page.