Go-live

Production access prerequisites, cutover procedure, and rollback. Complete Certification before requesting production credentials.

• Production key created with least-privilege scopes — not a copy of your sandbox scope set
• Separate keys per service where practical
• Secrets in a managed secret store, never in source control
• Rotation procedure rehearsed (~60-second auth-cache window)
• IP allowlist configured when required; verified with GET /whoami-ip from production egress
• No key in client-side code, mobile apps, or logs

• All fixture values removed — no magic SKUs, no sandbox_* references
• Full commercial evidence set implemented, including real consumerIp from proxy headers — Order context
• Catalog sync includes the allocations merge — Catalog and allocations
• All paths versioned /api/seller/v1/...
• Idempotency-Key on every write, stable per logical order
• expectedUnitPriceCents echoed from preview on every order
• Entitlements persisted before the buyer response
• Webhook signatures verified with the raw body and constant-time comparison

• Alerting on error rate by code (see Monitoring and support)
• Alerting on webhook delivery failure, 402/409 rates, reconciliation drift, 429 spikes
• requestId captured in structured logs
• Reconciliation job scheduled
• Runbook for: sold out after payment, unknown order outcome, webhook endpoint down, key rotation, price mismatch spike
• Escalation path documented (support@avrix.io / partner contact)

• BMA active with each vendor — confirm hasActiveBma on GET /whoami
• Allocations granted for every SKU you intend to sell
• Territory pricing confirmed for every market you sell into
• Buyer-facing refund policy published and consistent with your PSP setup
• Settlement and invoicing understood by your finance team

1. Sign the API Revenue Share Channel Terms in the Console under Settings → Commercial Agreements. Until you do, production keys cannot be created (403 API_MODEL_AGREEMENT_REQUIRED).
2. Request production access with your certification evidence (support@avrix.io or your partner contact). Wait until Avrix confirms your company has production API access enabled — otherwise production keys return 403 PRODUCTION_ACCESS_NOT_APPROVED.
3. Create the production key with least-privilege scopes.
4. Configure the allowlist if you use one; verify from production infrastructure.
5. Register production webhooks. Sandbox registrations do not carry over. Store the new secret.
6. Cold-start the catalog against production. Discard the sandbox fixture mirror.
7. Verify with GET /whoami — environment must be production and hasActiveBma true.
8. Run one controlled live order — a single unit of a low-value SKU, ideally an internal purchase. Confirm key delivery, webhook verification, and reconciliation.
9. Enable buyer traffic gradually — percentage rollout or a single market first.
10. Watch for 24 hours — error rates by code, webhook delivery success, reconciliation drift.

Immediate. Disable affected SKUs or halt checkout at your storefront. This stops new exposure without touching Avrix.

If credentials are implicated. Revoke the production key in the Console. Requests stop within about 60 seconds. Availability is recoverable; leaked inventory is not.

If the webhook endpoint is failing. Disable it in the Console, fix it, then replay missed deliveries.

Reconcile before resuming: compare your order records against GET /orders for the affected window and resolve every discrepancy.

Monitor: error rate by code (a spike in CATALOG_PRICE_MISMATCH means stale catalog data), webhook delivery success, reconciliation drift, allocation depletion, and rate-limit headroom.

Maintain: rotate keys on schedule, keep catalog sync current, review new webhook events as they are introduced, and re-run the certification suite after significant checkout changes.

• Integration checklist
• Sandbox to production
• Authentication
• Monitoring and support
• Partner runbook