Developer Docs•stable•Updated 2026-07-06

Production Checklist

Verify that Kadryn developer integrations are secure, observable, attributable and retry-safe before production rollout.

Use this checklist before sending production AI traffic or production usage events to Kadryn.

Secrets

  • Kadryn API key is stored server-side only.
  • Provider keys are not in frontend code.
  • Secrets are stored in a secret manager or trusted deployment system.
  • No secrets are committed to Git.
  • Authorization headers are not logged.
  • Rotation ownership is documented.

Authentication

  • Backend sends Authorization: Bearer $KADRYN_API_KEY.
  • Key belongs to the correct workspace.
  • Production services use production keys.
  • Local and staging traffic use separate metadata.
  • Read-only users cannot rotate keys.

Gateway

  • Gateway route is ready.
  • Provider key is configured and tested.
  • Production request includes project metadata.
  • Production request includes feature metadata.
  • Production request includes environment metadata.
  • Request group IDs are stable for workflows.
  • Retryable requests use idempotency keys.
  • Logs & Traces show a successful test request.

Direct ingest

  • Events contain timestamp, provider, model, tokens and cost.
  • Costs are sent as cents strings.
  • Events include project, feature and environment.
  • Retries reuse stable idempotency keys.
  • Invalid and rejected attempts are monitored.
  • Backfills are clearly labeled.

Metadata

  • Project names are stable.
  • Feature names are stable.
  • Environment values are normalized.
  • Team or cost center metadata exists where needed.
  • Customer or tenant metadata avoids sensitive data.
  • Policies and allocation rules match metadata values.

Tracing

  • Trace IDs are propagated.
  • Request group IDs are logged.
  • Kadryn request IDs are preserved when available.
  • Provider request IDs are preserved when available.
  • Support can search Logs & Traces using application logs.

Webhooks

  • Endpoint uses HTTPS.
  • Signatures are verified using raw body.
  • Timestamp tolerance is enforced.
  • Endpoint is idempotent.
  • Heavy work is queued asynchronously.
  • Test delivery succeeds.
  • Redelivery behavior is understood.

Error handling

  • Permanent errors are not retried blindly.
  • Rate limits use backoff and jitter.
  • Timeouts use bounded retries.
  • Retryable writes use idempotency.
  • Policy blocks are surfaced as governance decisions.
  • Provider key errors trigger operational action.

Observability

  • Logs & Traces shows Gateway traffic.
  • Logs & Traces shows direct ingest attempts if used.
  • Webhook deliveries are visible.
  • Diagnostics readiness is reviewed.
  • Alerts or dashboards monitor failures.
  • No sensitive payloads are logged.

Rollout

  • Start with staging.
  • Test one service.
  • Verify costs and metadata.
  • Verify policy behavior.
  • Enable production gradually.
  • Monitor first 24 hours.
  • Document incident response.

Related pages