Production REST API Integration Checklist

Write down the integration boundary before implementing HTTP nodes.

• Endpoint, method, payload and response contract are documented.
• The source of truth for each important field or state is explicit.
• Pagination or cursor termination behavior is understood.
• Expected availability and unavailable-system behavior are defined.
• A technical and operational owner exists for failures and credential changes.

Credentials change after launch; the workflow must survive that lifecycle safely.

• Secrets live in credential storage or a secret manager, not workflow content.
• OAuth refresh or token expiration behavior is understood where applicable.
• Required scopes are minimized and documented.
• Rotation does not require editing secrets into exported JSON.
• Authentication failures alert operators instead of entering blind retry loops.

Completeness and capacity controls are part of correctness.

• All result pages or cursors are consumed to a known termination condition.
• Long pulls can checkpoint progress where recovery requires it.
• Rate-limit headers or documented limits are respected where available.
• Concurrency cannot unintentionally overload the provider or database.
• 429 and quota conditions have an explicit wait, defer or escalation policy.

A syntactically valid JSON response can still violate the business contract.

• Request data is validated before a side effect is attempted.
• Response fields and types required downstream are validated explicitly.
• Unsupported enum or status values do not silently map to a default state.
• Repeated schema violations are visible as an integration health signal.
• Provider version changes have a deliberate mapping or migration path.

A missing response is not the same thing as a failed business operation.

• Connection and read timeouts are bounded.
• Transient and terminal error classes are separated.
• Retries have a maximum attempt count and suitable delay/backoff.
• Side-effecting timeouts trigger reconciliation before unsafe repetition.
• Retry policy accounts for request cost, rate limits and duplicate risk.

Protect the business action, not merely the workflow execution.

• Repeat-sensitive writes have a stable business or event identity.
• Provider idempotency keys are used where suitable and supported.
• Database writes use unique constraints or upserts where that represents the correct business rule.
• Replay passes through the same duplicate protection as live execution.
• An operator can distinguish not-attempted, uncertain and confirmed side-effect states.

Operators need enough evidence to trace one integration event end to end.

• A correlation or business ID connects intake to downstream calls.
• Dependency status and error category are retained.
• Attempt count and final recovery state are visible.
• Authentication, rate-limit and schema failures can be monitored separately.
• Logs avoid leaking credentials or unnecessary sensitive payload data.

Production readiness includes the path after failure, not only the happy path.

• Terminal failures preserve enough context for diagnosis and controlled replay.
• A runbook explains retry, replay, reconcile, correct-data and escalation decisions.
• Representative duplicate, timeout and malformed-payload cases have been exercised.
• The integration can be paused or contained if it starts creating harmful side effects.
• The expected downstream business outcome can be verified after recovery.