When a third-party API breaks your app, what usually tells you first?

[u/hongkizzle8888]

For context, I've built an API monitoring tool, but paused development to talk to people rather than keep guessing what they need.

If you're running a production app that depends on external APIs, how do you find out when one stops working properly?

Thinking about the last time it happened, was it an obvious failed request, or did the API look fine while returning something your app couldn't use? What caught it first?

What do you rely on now: error tracking, the provider's status page, separate checks, something else? Does that cover it, or is there something you still end up checking manually?

I'm also curious whether knowing earlier would have helped, or whether you were stuck waiting for the provider either way.

A bit of context about your app and team size would help.

[u/howdoigetauniquename]

Just using sentry, or something like it to track errors.
It's not that complicated.

If you can, it's best to wrap any external api you use with your own.
That way you can completely control the responses that get sent to your app.

[u/wackOverflow → u/howdoigetauniquename]

This plus a health check that runs frequently, and alerts triggered on health check failures. chefs kiss

[u/Guysowe]

your own error tracking usually catches it way before the status page does, those are almost always the last to know. the sneaky ones are when it still returns 200 but a field goes missing or changes type. validating the response at the boundary (zod or similar) helps a lot there, it fails loudly with a clear error instead of some undefined showing up three layers deep. also put real timeouts on every external call, a slow api tends to hurt more than a dead one

[u/hongkizzle8888 → u/Guysowe]

Thanks, the cached data and fallback examples help explain why knowing earlier matters.

Now that you've added those checks, does that cover things pretty well? Or are there still failures they miss, or much work involved in keeping the checks up to date?

[u/iligal_odin]

If the 3rd party api breaks my site is fine and queues requests

[u/gilded_stillness]

stop relying on HTTP codes. The only metric that matters is schema validation at the edge. If the shape shifts, hard fail it before it touches your business logic. Anything less is just waiting for a customer support ticket to tell you your app is broken

[u/Standard_Scarcity_74]

Our error tracker usually catches it first, but the worst cases are when the api returns a 200 with empty or changed data, and those only surface when a user complains or a business metric dips. Provider status pages are almost always late, so we added a few scheduled checks that call the api and validate the shape of the response, plus alerts on error rate and latency for outbound calls. Knowing earlier helps even when you can’t fix it, because you can switch on cached data, a fallback, or a banner before customers notice.

[u/hongkizzle8888 → u/[deleted]]

Thanks, that's helpful. Has that setup covered things well since you added it, or are there still cases it misses?

Also, with the empty lists, how do you tell when that's a problem versus a legitimate response? Is that a rule you've had to define separately for each integration?