Environments
Conduit provides two environments. Both expose the same API and use the same authentication mechanism.
Sandbox is available immediately after sign-up — generate a sandbox key and start integrating right away. Production access requires completing Conduit’s organization onboarding and activation process; once your organization is activated, switch the dashboard toggle to live and generate live keys.
API Keys
All requests require an API key passed in thex-api-key header.
The prefix is validated on every request. A
ck_sandbox_ key presented to the production API (or vice versa) is rejected with 401 API_KEY_INVALID. Keys are scoped to a single organization and environment. Generate and revoke keys from the Conduit dashboard.
Access level
Each key is read-only or read-write:
You choose the access level when creating a key in the dashboard; new keys are read-only by default. A key’s access level is fixed for its lifetime — to change it, revoke the key and create a new one. Use read-only keys for reporting and reconciliation integrations that never need to write.
Request Headers
Conduit also returns an
x-correlation-id header on every response — a server-generated trace ID useful for support requests.
Sandbox-specific behavior
Use your sandbox API key (ck_sandbox_...) against https://api.sandbox.conduit.financial. Sandbox and production keys are not interchangeable — a production key on the sandbox host returns 401 API_KEY_INVALID.
Idempotency cache: The idempotency-key header is required on all money-moving POST requests. In both sandbox and production the cache TTL is 300 seconds (5 minutes). A replay of a successful request within that window returns the cached response, marked with an Idempotency-Replayed: true header; error responses are not cached, and a replay after expiry re-executes the request. Use crypto.randomUUID() (or uuidgen in bash) to generate a fresh key for each new operation.
Rate limits. Responses on rate-limited routes carry X-RateLimit-Limit, X-RateLimit-Remaining, and X-RateLimit-Reset (seconds until the bucket refills). These headers are present on both successful responses and 429 errors; they are omitted only when the rate-limit service is temporarily unreachable and the request is allowed through anyway. When a request exceeds the limit you receive 429 RATE_LIMITED with a Retry-After header and a retryAfterSeconds body field; sleep that many seconds then retry. Limits use a token bucket: live keys get 50 requests/second sustained with a burst of 100; sandbox is more permissive (200 req/s sustained, 400 burst). Per-organization overrides are available through your support contact when your sustained workload exceeds the defaults. A handful of expensive endpoints (order execute, document upload, application submit) carry tighter dedicated buckets (5 req/s, 10 burst on live).
Cross-environment errors: A 401 API_KEY_INVALID against the sandbox base URL means you are using a live key, not a sandbox key. If your sandbox key is valid but your organization’s sandbox environment has not been provisioned yet, you receive 409 SANDBOX_NOT_PROVISIONED (not a 401) — provisioning happens automatically after sign-up and is retried, so wait a few moments and retry; contact support if it persists. Do not rotate or regenerate the key for this case — the key is valid.