15 Third-Party Integration Failure Scenarios Every Business App Should Handle

Integrations fail loudly (timeouts, outages, rate limits, rejected credentials, server errors) and quietly (changed data formats, duplicate or missing events, records drifting out of sync, partial failures in multi-step operations). A dependable business application sets timeouts, retries only safe and temporary failures, queues work, prevents duplicates, stops hammering failing services, reconciles data on a schedule, alerts a person when something needs attention, and tells users clearly what is happening.

This list is for product owners and developers of applications that depend on payment providers, CRMs, ERPs, shipping, email, identity or AI services. Patterns follow Microsoft's Azure Architecture Center guidance on retries and circuit breakers. For event-driven integrations specifically, see webhook use cases.

1. Slow responses and timeouts. Without a timeout, a slow service ties up your application until users give up. Handle: set explicit timeouts, and move slow calls into background jobs where the user does not need to wait.

2. Temporary errors (500, 502, 503). Handle: retry with exponential backoff and a cap. Test: simulate errors and confirm the retry stops after the limit.

3. Prolonged outage. Retrying a service that is down wastes resources and can make recovery harder. Handle: a circuit breaker stops calls after repeated failures, returns a fallback or a clear message, and lets a few trial calls through later. Microsoft describes its closed, open and half-open states.

4. Rate limits (429). Handle: respect the provider's limits and any retry-after information, spread bulk jobs over time, and use bulk APIs where offered.

5. Expired or revoked credentials. OAuth tokens expire, API keys are rotated and users disconnect apps. Handle: refresh tokens automatically, detect authorisation failures, stop retrying them, and alert the account owner to reconnect.

6. Permission changes. The integration user loses access to a field or object. Handle: treat permission errors as needing human action, not retries, and show which record and permission failed.

7. API version deprecation. Providers retire API versions on a schedule. Handle: track the versions you use, subscribe to provider changelogs, and test against new versions before the old one is switched off.

8. Changed data formats. A new field becomes required, an enum gains a value, a field is renamed. Handle: validate responses against the shape you expect, log unknown values instead of crashing, and alert on validation failures.

9. Duplicates from retries. A request times out but actually succeeded; retrying creates a second order or payment. Handle: use idempotency keys where the provider supports them, and unique references on your side.

10. Missed events. A webhook was not delivered or failed to process. Handle: log every event, process from a queue, and run a reconciliation job that compares recent records through the API.

11. Out-of-order events. An update arrives before the create, or "shipped" before "paid". Handle: fetch the current state before acting, or compare timestamps and versions.

12. Silent drift between systems. Stock, prices or customer details differ between systems with no error anywhere. Handle: define which system owns each field, run scheduled comparisons, and report mismatches to a person.

13. Partial failure in multi-step operations. The order was created in the ERP but the invoice step failed. Handle: record progress per step, make each step safe to retry, and have a compensating action or a clear manual fix for steps that cannot be undone.

14. Failures nobody notices. Errors written to a log no one reads. Handle: monitor error rates, queue age and failed jobs per integration, and alert the right person with enough context to act. See application monitoring and observability.

15. Users left guessing. A customer sees "Something went wrong" or a spinner that never ends. Handle: tell users what happened and what will happen next ("Your order is saved; confirmation may take a few minutes"), and give staff a screen showing failed syncs with a retry button.

Every integration will fail at some point; what matters is whether the application notices, stays safe and recovers. Set timeouts, retry only what is temporary and safe, prevent duplicates, queue and reconcile, alert people with context, and keep users informed. For choosing between APIs, events and queues in the first place, see integration architecture patterns.

Microsoft Azure Architecture Center, Circuit Breaker pattern and Retry pattern. Stripe documentation on webhook delivery behaviour. Accessed 28 October 2026.