What happens to our integration when a vendor changes their API?
Something breaks, and the dangerous case is when it breaks quietly. A removed field or a changed value does not always raise an error — it can produce reports that keep rendering with steadily wrong numbers. Durable integrations pin an API version, subscribe to deprecation notices, validate the shape of incoming data, and alert on volume anomalies rather than only on errors. Treat maintenance as a permanent line item, not a warranty issue.
Three ways an API change reaches you
- Loud failure. Authentication breaks or an endpoint disappears. Annoying but safe, because you find out immediately.
- Quiet failure. A field is removed or renamed. The call still succeeds, the value arrives empty, and every report built on it starts understating without complaint.
- Semantic change. The worst kind. The field still exists but now means something slightly different — a status that used to include one case and no longer does. Nothing errors, nothing is empty, and the numbers are simply wrong.
Defenses that actually work
Pin to a specific API version where the vendor supports it, so changes arrive on your schedule rather than theirs. Subscribe to the developer changelog for every connected platform; deprecations are usually announced well in advance and ignored just as reliably.
Then validate shape on ingestion. If a field that is normally populated ninety-plus percent of the time suddenly arrives empty, that should raise an alarm before it reaches a report. This kind of defensive ingestion is unglamorous and is most of what separates durable integrations from fragile ones.
Keep a short inventory of every connected endpoint and the fields you actually depend on. It sounds bureaucratic until a deprecation notice arrives and the only question that matters is whether it affects you, which should take minutes to answer rather than a day of reading code.
Monitor volumes, not just errors
The most useful alert in a data pipeline is not an exception. It is a comparison: today's record count against the same weekday's typical count. A Tuesday that returns a fraction of normal job records is a problem whether or not anything technically failed.
The same applies downstream. If your revenue reporting normally attributes a stable share of jobs to a source and that share collapses overnight, the likeliest explanation is a broken feed, not a sudden change in customer behavior.
Set the expectation up front
Every connected platform will change something eventually. Google, Meta, phone providers and operational software all ship breaking changes on their own timelines, and none of them consult you. An integration is a living system with an ongoing maintenance obligation, and any proposal that treats it as a one-time build is understating what you are taking on.
Decide early who watches for this and who fixes it. Whether that is your team or a partner matters less than the fact that someone is accountable and that the accountability is written down.
Topics: API changes · maintenance · monitoring · reliability
Have a version of this question about your own business?
The useful answer usually depends on which systems you run and how they're connected. That's a conversation, not a blog post.