The day the model provider deprecated the endpoint your feature used

A support team at a mid-market SaaS shipped an AI feature that drafted replies to customer tickets. It worked well for months. Then one Tuesday morning the queue filled with 500 errors and no drafts came out. Nobody had touched the code. Nothing had been deployed. The feature simply stopped.

The cause was buried in an email that had landed six weeks earlier. The provider was retiring the completions endpoint the feature called, and the deadline had arrived. The email went to a shared inbox that a departed engineer used to watch. It was read by no one. The deadline still counted.

I have seen this exact failure more than once, and the shape is always the same. A team treats a hosted API as a fixed thing, like a database schema they own. It is not. It is a product owned by another company, and that company will change it on its own timeline, for its own reasons, whether or not your feature is ready.

The API you build against is a moving target

The mistake is not that the provider changed something. Providers change things constantly, and most of the time they warn you well in advance. The mistake is assuming the version you integrated against will be there forever, and building as if a deprecation notice is somebody else’s problem.

When the support team wired up that endpoint, they wrote code that assumed one request shape, one response shape, and one URL. All three were controlled by the vendor. When any of them changed, the feature had no give in it. There was no place for the change to be absorbed. So it broke at the surface, in front of customers.

The fix is not clever engineering. It is treating the provider as what it is: an upstream dependency you do not control, with a lifecycle you have to watch.

What teams that survive deprecations do

They route provider notices to a channel a real person owns, not a shared inbox nobody reads. Deprecation emails get triaged like security advisories, because that is what they are.
They keep a short list of every provider endpoint and model version their product depends on, so when a notice lands they can answer “does this touch us” in minutes instead of days.
They put a thin layer between their code and the provider, so a changed request or response shape is handled in one place instead of scattered across the codebase.
They test against the provider’s newer version before the old one is pulled, and they schedule the migration as work, not as an emergency.
They set a calendar reminder before the deadline, not on it, so the switch happens while there is still room to fix a surprise.

None of this is exotic. It is the same discipline you already apply to a library you pin, a certificate that expires, or a third-party service with a maintenance window. AI providers deserve the same treatment. They earn it faster, because they iterate faster than most vendors your team has dealt with.

How we approach it at Density Labs

When we run an AI Opportunity Assessment, a fixed two-week engagement at $2,500, one of the first things we map is the provider surface a feature actually sits on. Which endpoints, which model versions, which behaviors the product quietly depends on. We look at where deprecation notices go today and whether anyone reads them. We check whether the integration has a single seam where a provider change can be absorbed, or whether it is spread across the code in a way that turns a routine deprecation into an outage.

We do this before anyone builds more on top of that surface, because the cheapest time to find a brittle integration is before you have shipped three more features that share it. The Diagnose scopes the real production work: the layer you need, the notices you should be watching, the migrations already on the horizon.

Track the notices. Build a seam where change can land. A deprecation should be a scheduled chore, not the reason your feature went dark.