Going Live

You've built and tested against the sandbox. This checklist takes you to production safely — and keeps you running once you're there.

Pre-launch checklist

1. Switch from test to live keys

• [ ] Create a production key (ai92_live_) via the dashboard or POST /v1/account/keys with "kind": "production". Store the plaintext in your secret manager — it's shown once.
• [ ] Replace ai92_test_ with ai92_live_ in your production config only. Keep test keys for CI and staging.
• [ ] Scope each key to its job: set daily_credit_limit / monthly_credit_limit and, where you have fixed egress IPs, an ip_whitelist. One leaked, capped, IP-bound key is far less dangerous than one omnipotent key.
• [ ] Confirm no key is reachable from a browser or mobile bundle. Call AI92 from your server. See Authentication.

2. Verify credit accounting

• [ ] Read X-Credits-Consumed / X-Credits-Remaining on responses and reconcile against your own ledger.
• [ ] Confirm your code treats "credits_consumed": 0 correctly (inconclusive / empty results aren't charged).
• [ ] Make sure you have a comfortable starting balance — top up via POST /v1/billing/checkout, or attach a hybrid subscription for recurring credits + higher rate limits.

3. Set up webhooks

• [ ] Register your production endpoint and subscribe to the events you act on (campaign.reply, contact.verified, credits.low, …). See Webhooks.
• [ ] Verify the HMAC signature on every delivery and reject stale timestamps.
• [ ] Return 2xx within 10 seconds, then process asynchronously; make the consumer idempotent (dedupe on event.id).
• [ ] Have a plan to monitor and replay the DLQ.

4. Handle rate limits and retries

• [ ] Implement exponential backoff with jitter on 429 and 503, honoring Retry-After. See Rate limits.
• [ ] Throttle outbound concurrency to stay under your X-RateLimit-Limit.
• [ ] Send an X-AI92-Idempotency-Key on every billable POST/PATCH, and reuse the same key across retries so a retry can never double-charge. See Idempotency.

5. Wire up async jobs

• [ ] For creative, scan, and large bulk operations, submit → poll GET /v1/jobs/{job_id} → handle terminal completed / failed. Prefer the completion webhook over polling where available.
• [ ] Trust reserve-and-refund: a failed job costs 0; don't manually "refund" in your own logic.

6. Observability

• [ ] Log X-AI92-Trace-Id with each request so support can find it instantly.
• [ ] Track error rates by error.code, and alert on sustained 503s (upstream issues) or 402s (you're running dry).
• [ ] Review GET /v1/account/usage and the paginated GET /v1/account/usage/log for spend and latency trends.

Stay alive: never run out of credits

A 402 INSUFFICIENT_CREDITS mid-campaign is the most common production surprise. Defend against it on two fronts:

1. Low-balance alerts. Subscribe to the credits.low webhook and route it to a channel a human watches.
2. Auto-recharge. Enable automatic top-ups so your balance refills before it hits zero (OAuth scope account:write if you manage this via the API). Combine with a monthly subscription for a guaranteed recurring grant.
3. Poll the balance in long batch jobs: check GET /v1/account between large chunks and pause/top-up rather than hammering into a wall of 402s.

After launch

• Rotate keys on a schedule (90 days is sensible) and immediately on any suspected leak: create new → deploy → DELETE old.
• Keep an eye on the changelog for additive changes and any deprecations. The API is /v1-stable; build a tolerant reader. See Versioning.
• Re-test in the sandbox whenever you adopt a new endpoint or field before relying on it in production.

You're live. Welcome aboard.