API Integration Reliability: 6 Tests Before You Go Live

A CRM-to-ERP integration looks ready when a new customer appears in both systems. That proves the connection works once. It leaves a harder question unanswered: what happens when the destination saves the record, the response disappears, and the integration tries again?

For an operations leader or technology buyer, API integration reliability is a business requirement. A duplicate order, missing work item, or stale account status becomes someone’s cleanup job. Before signing off, ask the delivery team to demonstrate recovery as clearly as it demonstrates the normal flow.

Here are six acceptance tests you can add to an integration project. They are proposed buyer checks, not a claim that every integration needs the same architecture. Run them in a safe test environment using representative records and agree the expected business outcome first.

Define the business action before the test

Write one sentence describing the unit of work: “Create one ERP order for each approved CRM order.” Then identify the authoritative system for each field, the stable business identifier, and the longest delay operations can tolerate. “Keep the systems in sync” is too vague to test.

Use a fictional order, such as CRM order 1042, throughout the demonstration. Record its destination identifier and final status. Ask the team to show both the integration log and the business record. A green execution status does not prove the right outcome.

1. Deliver the same event twice

Send the same order event twice, then send two copies concurrently. The pass condition is one intended order and a visible record of how the duplicate was handled.

Stripe’s webhook documentation explicitly warns that endpoints can receive an event more than once. Your integration should use identifiers suited to the provider’s event model and the business action, rather than treating every arrival as new work.

Ask which identifier survives a retry and how long duplicate protection lasts. An event ID and an order ID serve different purposes. Two legitimate updates to one order must not be discarded just because the order already exists. Concurrent delivery should be tested because a simple “check, then create” sequence can race.

2. Lose the response after the write

Have the destination accept the order, then interrupt the response before the sender receives confirmation. This is the awkward case: the sender knows the request timed out, but does not know whether it succeeded.

The pass condition is that recovery establishes what happened before repeating an action that could create a second record. Ask whether the destination supports an idempotency key, a unique external reference, or a lookup that can reconcile the outcome.

Microsoft’s Idempotent Consumer pattern explains why external API calls cannot simply join a consumer’s local database transaction. An unresolved in-progress operation needs reconciliation or intervention. A local “processed” flag alone is not proof that a remote write happened exactly once.

3. Make the destination temporarily unavailable

Simulate a short outage and a rate-limit response. Keep sending representative work at the expected peak rate. The pass condition is a bounded backlog, controlled retries, and eventual processing within the recovery target agreed with operations.

AWS’s retry with backoff guidance recommends increasing waits between retries and warns that frequent retries can degrade a service. Ask which failures are retryable, how attempts are capped, and whether the provider’s retry instructions are honored.

A malformed record will not become valid by being sent repeatedly. It should enter an actionable exception path. Also ask what happens when the outage outlasts normal retries: where is unfinished work retained, who is alerted, and how is it resumed?

4. Send updates out of order

Deliver a newer status before an older one. For example, send “order dispatched,” then a delayed “order approved” event. The pass condition is that the destination ends in the correct business state rather than regressing to the last message received.

Stripe does not guarantee event delivery order. Check the ordering guarantees of your actual providers. Where order matters, the team should demonstrate a supported version check, an appropriate ordering mechanism, or a fetch of authoritative current state. An arrival timestamp is not automatically a business version.

5. Repair and replay one failed record

Introduce a missing required field, let the record fail, correct it, and replay just that item. The pass condition is that the intended action completes, unrelated records stay untouched, and the repair remains traceable.

Ask the team to distinguish a retry of the original operation from a new business instruction. A changed payload may require a deliberate new operation identifier. It must not silently reuse a key whose earlier result represents different data.

Then repeat the replay. It should not duplicate the completed action. Agree how long replay is supported and retain the necessary identifiers for that window. Recovery procedures need to work for operations staff without requiring them to edit production database rows.

6. Find the failure from the operator’s seat

Give the person who will support the workflow a deliberately failed order and ask them to locate it. They should be able to see the source identifier, destination outcome if known, current state, last attempt, next action, and responsible owner.

Measure time to detect and resolve the incident during the test. Set targets based on the cost of delay in your business. A daily account sync and a time-sensitive dispatch workflow should not inherit the same alert threshold.

Logs should support diagnosis without exposing unnecessary customer data or credentials. Access to replay should follow the same business permissions as the original action. Monitoring is useful only if someone can act on what it reports.

Put the evidence into the delivery scope

For each test, capture the input, injected failure, expected outcome, observed outcome, and recovery owner. Make that evidence part of launch acceptance alongside field mapping, permissions, monitoring, and support responsibilities.

Start with the highest-cost business action and expand from there. The goal is a workflow your team can recover confidently when a dependency misbehaves.

Nx Growth Partners’ software and integration services include APIs and system integrations, QA, and ongoing support. If you are scoping a connection between business systems, discuss a project with us. Bring the systems involved, the business action, and one failure your team currently has to fix by hand.