You signed. What now?

You just executed an ISA Platform agreement. Here is what happens next, in order.

1. Credentials

Your test and live bearer tokens arrive by email within a few minutes of completing Stripe checkout at checkout.isaapi.com. Test tokens have the isa_test_ prefix; live tokens have the isa_live_ prefix. The subject line is "Your ISA Platform API credentials."

Both tokens are secrets — treat them like passwords. Store them in a secrets manager (AWS Secrets Manager, HashiCorp Vault, Doppler, etc.), never in source control or plaintext configuration files.

If you do not receive credentials within 15 minutes, contact [email protected].

2. Pick your language and follow the tutorial

Every tutorial ends with a working prequalify call returning priced plans. For the canonical response shape see the prequalify guide — POST /v3/prequalify is the active surface for all new integrations.

Each tutorial is under 60 minutes for a competent backend developer with no insurance domain knowledge. Start there before reading anything else.

3. Production readiness checklist

Work through this list before directing real traffic to your integration.

Authentication and credentials

• Credentials are stored in a secrets manager, not in source control.
• Your deployment pipeline reads credentials from environment variables.
• You have a rotation procedure documented and tested.
• Test (isa_test_*) and live (isa_live_*) tokens are kept strictly separate — no test token ever touches a production code path.

Idempotency

• Every mutating call uses an idempotency key.
• Your retry logic reuses the same idempotency key across attempts for the same logical operation.
• You catch IsaIdempotencyConflictException / IsaIdempotencyConflictError and alert on it — this is always a code bug, not a transient failure.

Retry logic

• Transient 5xx responses and 429 rate-limit responses are retried with exponential backoff.
• 400 validation errors are NOT retried (they are caller bugs).
• Retry loops cap at a maximum attempt count and a maximum delay.

Error handling

• Every error is logged with the requestId from the response (the first thing support needs).
• User-facing messages describe what the user should do, not what broke internally.
• 5xx errors are surfaced to your on-call rotation, not silently swallowed.

Rate limits

• You have reviewed the rate limits for your tier in the portal.
• Your system can gracefully degrade if it hits the per-second limit during a traffic spike.
• Batch jobs spread calls over time rather than bursting all at once.

Webhook receiver (if applicable)

• Your receiver validates the X-ZyINS-Signature header before processing any event.
• Your receiver returns HTTP 200 within 5 seconds (move heavy processing to a queue).
• Your receiver is idempotent: receiving the same event twice produces the same outcome.
• You have tested the receiver with the signature-verification test tool in the portal.
• Live webhook secrets are separate from test webhook secrets.

Observability

• You log requestId and idempotencyKey for every call.
• You have an alert on elevated 5xx error rates.
• You have an alert on elevated 429 rates.
• You are subscribed to the ISA Platform status page: support-and-status.

Deployment

• Your application restarts gracefully without dropping in-flight requests.
• Credential rotation does not require a deployment (credentials come from the environment at runtime, not at build time).
• You have tested credential rotation in staging before doing it in production.

4. Support

For API questions, integration issues, and billing inquiries:

[email protected]

Include your requestId in every support request. It is the fastest way for us to correlate your report to server-side logs.

For urgent production incidents, use the priority support channel listed in your agreement.