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