An API integration is ready for production only when the team can explain what happens after timeouts, duplicate events, provider outages and data disagreements. Use this checklist before approving the implementation scope.
When this checklist is useful
Use it before building a new integration, replacing a provider or taking responsibility for an undocumented connection. It is especially important when a workflow changes money, bookings, inventory or customer permissions.
Contract and ownership
- Which system owns each business decision and each field?
- Are request, response and error formats versioned or documented?
- Which time zone, currency, decimal and identifier formats are used?
- What rate limits, payload limits and maintenance windows apply?
- Who owns provider communication when the contract changes?
Store a small set of sanitised request and response fixtures. They make regression testing possible without depending on a provider sandbox during every test run.
Authentication and secrets
- Keep API keys and certificates outside source control.
- Define rotation and expiration behaviour.
- Request only the scopes the integration needs.
- Validate webhook signatures before parsing business content.
- Prevent secrets and personal data from appearing in logs.
OAuth integrations also need a clear answer for revoked consent, refresh-token failure and reauthorisation.
Retries and idempotency
Every retryable operation needs an idempotency strategy. A timeout does not prove that the provider failed; the request may have completed while the response was lost.
Use stable request identifiers, bounded exponential backoff and a dead-letter or manual-review state. Do not retry permanent validation errors.
Webhook handling
Respond quickly after authenticating and persisting the event. Process slow work asynchronously. Record the provider event ID and reject duplicates without repeating the business action.
Assume events can arrive late or out of order. State transitions should validate the current state instead of blindly overwriting it.
Reconciliation
Critical integrations need a way to compare local and provider state. Payment, booking and inventory systems should have scheduled or on-demand reconciliation with a visible exception queue.
Without reconciliation, a successful HTTP response becomes the only evidence that two systems still agree.
Observability and support
Log correlation IDs, provider IDs, state transitions and safe error context. Create alerts for sustained failure rates, growing queues and expired credentials—not for every single transient error.
Finally, document who checks the alert, how to replay an event safely and when to escalate to the provider. A technically correct integration without an operating procedure is still unfinished.
Scope decision
Do not approve implementation until ownership, retry behaviour, reconciliation and support responsibility all have answers. A provider sandbox can prove connectivity; it cannot prove that the operating process is complete.
Related services
For production API, payment and webhook work, see API, Payment & Webhook Integration.