Promoting from test to live

This checklist covers every step to take before sending real production traffic through the ISA API. Work through it top-to-bottom. Every item that doesn't apply to your integration is a deliberate skip — note why, not just that you skipped it.

1. Credentials

You have your live bearer token (isa_live_*) stored in your production secrets manager, not in source code or a .env file.
The token has the minimum scopes your service needs. A prequalification-only service should carry only the prequalify scope, not cases, usage, or webhooks.
You have a credential rotation plan documented and tested (see Rotating tokens).
Test tokens (isa_test_*) are absent from production environment configuration.

2. Endpoints and base URL

Your integration targets https://zyins.isaapi.com. There is no separate hostname for live mode.
ISA_BASE_URL is unset or explicitly set to production. Staging overrides must not survive in production config.
Your integration does not have any hardcoded URLs pointing to non-production hosts.

3. Idempotency keys

Every mutating request (POST, PUT, PATCH, DELETE) sends a UUID v4 Idempotency-Key header.
Retry logic reuses the same key — it does not mint a new key per retry attempt.
Your persistence layer stores idempotency_key alongside request_id and livemode on every business record.

4. Error handling

Your integration matches on err.code (stable enum), not on HTTP status codes or message text.
5xx errors trigger a retry with the same idempotency key and exponential backoff. The SDK handles this automatically; verify you have not disabled retries.
4xx errors (other than 429) do not retry — they are deterministic failures your code must fix.
429 rate_limit_exceeded respects the Retry-After header. The SDK does this automatically.
Your integration does not swallow errors silently. Every API error surfaces to your logging system with request_id.

5. Webhooks

Webhook subscriptions are re-registered in live mode. Test-mode subscriptions do not carry over.
Your webhook endpoint verifies the X-ZyINS-Signature header using HMAC-SHA256 and a constant-time comparator.
Your endpoint returns 200 OK before doing any slow processing (queue the work, ack immediately).
Your endpoint is idempotent on event.id — at-least-once delivery means you may receive the same event twice.
The webhook signing secret is stored in your production secrets manager and not committed to source control.

6. Livemode guard

Your application reads result.livemode from the response envelope and asserts it matches the expected mode before persisting the result.
Your monitoring alerts on unexpected livemode: false responses in production.

7. Quota and rate limits

You know your live quota (requests per day, requests per month). Check the dashboard if unsure.
High-volume batch jobs use a concurrency limit that keeps peak RPS under your rate limit.
You have a quota_exceeded alert wired to notify your team before the cycle resets, not after.

8. Observability

Every API call logs request_id at INFO or DEBUG level. This is your fastest path to support resolution.
5xx and 429 rates are in your alerting system with a page-worthy threshold.
You are subscribed to incident notifications via the email on your account. (See support-and-status; a public status page launches at GA.)

9. Service continuity

You have tested the unhappy path: what happens when the ISA API returns 503 service_unavailable? Your application should degrade gracefully, not crash.
Downstream consumers of prequalify/quote results are tolerant of temporary gaps (queue-based, not synchronous).

10. Security

No token or signing secret appears in application logs, error reports, or crash dumps.
TLS verification is enabled on your HTTP client (it is by default on all ISA SDKs — do not disable it).
Your server's outbound firewall allows connections to zyins.isaapi.com on port 443.

You're ready

When every applicable item is checked, swap ISA_TOKEN to your live token (isa_live_*), deploy, and verify the first live request's livemode: true in your logs.

If anything looks unexpected after going live, check support-and-status for active incident emails first, then contact [email protected] with the request_id from the failing call.