Production integration checklist

Take a partner or consuming application from onboarding to a supportable production request path.

This is the integrator's end-to-end path. It links to the detailed procedure for each task instead of repeating it.

1. Receive the integration contract

Before writing code, obtain:

engine base URL;
application issuer;
engine organization UUID;
provider organization alias;
machine client credentials and/or the end-user sign-in route;
granted model identifiers and expected spend limits.

The platform operator creates those objects through platform setup. Treat client secrets as server-side credentials.

2. Choose the caller lane

Use a machine token for backend jobs and product-wide model calls. Use an end-user token for anything a person owns: conversations, personal connections, memories, and durable agent runs.

Do not emulate a user by adding headers to a machine request. The engine takes identity only from the verified token. See Authentication.

The end-user identifiers you assert must be opaque and pairwise — never an email address, a name, or a customer reference that means something in another system. This is data minimisation and it does not discharge erasure; see Send opaque, pairwise subject identifiers.

3. Prove readiness before traffic

curl -s "$BASE_URL/readyz"

curl -s "$BASE_URL/v1/readiness" \
  -H "Authorization: Bearer $ACCESS_TOKEN"

/readyz answers whether the deployment can serve. /v1/readiness answers whether this organization can use chat, retrieval, agents, memory, and guardrails. Do not replace either with a successful TCP connection.

/v1/readiness's connector-dependent components (model-served on chat, rag, and agents) attest configuration, not reachability: they confirm an enabled connector is registered to serve the granted model, not that the provider currently answers. A registered-but-dead connector still reports green here, and every chat call against it will 502. Call POST /v1/connectors/{id}/verify to prove a connector is actually live.

4. Make and classify one governed call

Start with GET /v1/models, then send one non-streaming chat request. Store the response status, typed error, and response X-Request-ID in your diagnostic context. Deeplinq mints that identifier; it correlates the transport response with provider calls, billing, audit, and conversation persistence.

Use the OpenAI SDK or Anthropic SDK guide for the concrete request.

5. Implement failure behavior

Status	Integrator action
`400`	Fix the request or use an end-user token when the route is user-owned
`401`	Obtain a fresh token and verify issuer, audience, and organization selection
`402`	Stop model work and surface the exhausted credit or hard limit
`403`	Treat the caller as not entitled; do not retry unchanged
`404`	Treat the resource as absent; Deeplinq may conceal forbidden resources as `404`
`409`	Re-read state and resolve the named conflict
`412` / `428`	Refresh the entity tag and retry the conditional update
`429`	Respect `Retry-After` when present and back off with jitter
`502` / `503`	Preserve `X-Request-ID`; retry only if the operation is safe to repeat

Do not retry a mutating POST unless that route documents idempotency. POST /v1/billing/topups requires Idempotency-Key; organization credit grants accept one to make an operator retry a no-op.

6. Add capabilities one at a time

Run the relevant readiness check and one failure-path test after each addition.

7. Complete the operational handoff

Record who owns tenant onboarding, model grants, credits, identity membership, credential rotation, and incident response. Give support teams a safe request transcript containing timestamps, paths, statuses, and X-Request-ID values — never access tokens, cookies, connector keys, or request content containing customer data.