Skip to main content

Go-Live Checklist

Complete every item before switching from staging to production. Each item addresses a specific failure mode observed in real integrations.
Do not go live until every item on this checklist is verified. Skipping items leads to production incidents that are entirely preventable.

Credentials and endpoints

1. Replace staging API key with production key

Update your environment configuration to use the production API key. Staging keys do not work against the production URL.

2. Update base URL to production

Switch from the staging URL to the production URL. This must change everywhere your application makes Zenoo API calls.

3. Update webhook endpoint to production URL

Point Zenoo at your production webhook endpoint. Contact your Zenoo account manager to update the webhook URL, or configure it in the Zenoo dashboard.
Staging and production webhooks use different secrets. Update the secret in your configuration.

Security

4. Verify webhook signature validation works

Confirm that your webhook handler validates the X-Zenoo-Signature header on every request. Test by sending a webhook with a tampered payload and verifying that your handler rejects it.

Resilience

5. Implement exponential backoff retry logic

Your API client should retry 5xx errors and timeouts with increasing delays. Never retry 4xx errors without fixing the request.

6. Set up idempotency with external_reference

Include external_reference on every verification request. This prevents duplicate verifications caused by retries, user double-clicks, or race conditions.
Use a stable, unique identifier from your system: application ID, customer reference, or order number. If the same external_reference is submitted twice, Zenoo returns the existing case.

Result handling

7. Handle all verdict outcomes

Your application must handle all three overall_verdict values. Verify your decision logic:
Do not assume all results will be Pass. Test your Refer and Fail code paths with the staging test data.

8. Handle webhook edge cases

Your webhook handler must process all five event types, not just verification.completed:
Ignoring journey.abandoned or journey.expired events causes customers to get stuck in your onboarding flow.

9. Implement webhook deduplication

Zenoo may deliver the same webhook more than once. Your handler must be idempotent.
Always return 200 for duplicates to prevent unnecessary retries.

Monitoring

10. Set up monitoring

Track these metrics from day one: Use the request_id from error responses to correlate application logs with Zenoo server logs.

11. Test one real verification in production

After completing items 1-10, run a single real verification in production. Use a real company or individual (not test data). Confirm:
  • API call succeeds with 200 response
  • Response contains valid overall_verdict and risk_tier
  • Webhook is delivered to your production endpoint
  • Webhook signature verifies correctly
  • Your application processes the result correctly

12. Configure alerts for failures

Set up automated alerts for:
  • 5xx error spikes from the Zenoo API. These indicate server-side issues, contact Zenoo support.
  • Webhook delivery failures. If your endpoint returns non-2xx for more than 3 consecutive webhooks, investigate immediately.
  • Verification timeout increases. A sustained increase in response times may indicate provider degradation.
  • Unusual verdict distributions. A sudden spike in Fail verdicts may indicate a configuration issue, not actual compliance failures.

Summary

Complete all 12 items before going live. Each item addresses a real production failure mode.

Next steps