If your product depends on someone else's API, there will be a day when it stops working. Maybe it's slow, maybe it's returning errors, maybe it's returning data that's obviously wrong. Your users won't know or care whose fault it is. They'll just see your product failing.
A lot of what we built at Travelxp depended on external systems: travel aggregators for inventory, payment gateways, content networks. Each one had its bad days. I learned that the best time to decide how to handle a partner failure is long before it happens.
I covered evaluating a partner before you integrate separately. This post is about what happens after.
Decide what each failure looks like to the user
| Failure | Possible product response | Trade-off |
|---|---|---|
| Slow responses | Show what you have, load the rest progressively | Partial results may confuse users |
| Errors from one partner | Hide that partner's results, show others | Fewer options, but nothing broken |
| Total outage of a critical partner | Clear message, suggest trying later | Honest, but loses the session |
| Stale or suspicious data | Show cached data with a note, or hide it | Risk of showing outdated prices |
| Partial failure mid-transaction | Hold the state, check status, don't double-charge | Needs careful design and support process |
There isn't one right answer for every case. But writing down a response for each type means engineering isn't making product decisions at 2am during an outage.
Set timeouts deliberately
If a partner API is slow, how long should you wait? Too short and you give up on responses that would have arrived. Too long and the whole page hangs.
This is partly a technical decision and partly a product one. I'd look at how long users are willing to wait on that page and set timeouts with that in mind. For a search results page, a slow partner shouldn't hold up results from faster ones.
Patterns like circuit breakers, where your system stops calling a failing service for a while instead of hammering it, help protect the rest of the product. 1 As a PM, I don't need to implement them, but I should know they exist and ask whether we have them.
Be careful with transactions
The riskiest failures are the ones in the middle of something important, like a booking where payment succeeded but supplier confirmation didn't come back.
For these, you need:
- A clear record of what's known and what isn't.
- A process to check the status and resolve it, automatic where possible.
- A message to the user that's honest without being alarming.
- A support process for the cases that need a person.
Never show "booking failed" if you don't actually know. The user might try again and end up with two bookings. The payment gateway post goes into the payment side of this.
Tell users the truth, briefly
"Something went wrong" isn't helpful. "We're having trouble loading some hotel results right now. You can still book from the options shown" is.
Users are surprisingly forgiving of a problem when they understand it and can still get something done. They're not forgiving of a broken page with no explanation.
Monitor partners, not just yourself
Track each partner's error rate and response time separately. If one partner's reliability slowly declines, you want to see it before it becomes an outage.
Share this data in your regular partner reviews. Concrete numbers make the conversation about reliability much more productive than "your API has been flaky."
Review incidents together
After a significant partner failure, review what happened with the partner if you can. What failed, how long it took to notice, how users were affected, and what would help next time. Then update your failure responses.
You can't stop partners from having problems. You can make sure their problems don't become a complete failure of your product.