What Happens When a Third-Party API Your Software Depends On Changes or Shuts Down?
When a third-party API your software depends on changes, breaks or shuts down, the feature that uses it stops working or returns wrong results until someone updates your code. A short outage usually clears on its own, but a breaking version change or a retirement does not: after the provider's cutoff date, requests simply fail.
Most providers publish changes well in advance, so this is rarely a surprise for a team that is watching. Keeping integrations current is ordinary upkeep, and it belongs in any custom software development plan from the first day.
Why does business software depend on third-party APIs?
Business software depends on third-party APIs because it is cheaper and safer to rent specialist services than to build them. An API (application programming interface) is the agreed way one system asks another to do something. A typical web application calls a payment processor to charge cards, an email service to send receipts, a maps service for addresses, an SMS gateway for login codes, an AI model for summaries or chat, and an accounting package to post invoices.
Each is run by another company under its own terms. Your software works only as long as each one keeps answering in the format your code expects.
How can a third-party API fail my software?
A third-party API can fail your software in five ways: an outage, a rate limit, a breaking version change, a price or plan change, or a retirement. They differ in how much warning you get and how long the damage lasts.
Outages and slow responses
The provider is down or slow for minutes or hours. If your code waits indefinitely for an answer, one slow provider can make your whole application hang.
Rate limits
Providers cap how many requests you can send in a period. Exceed the cap and the usual response is HTTP status 429, which MDN defines as the client having "sent too many requests in a given amount of time". It tends to happen in your busiest hour.
Breaking version changes
The provider renames a field, removes an option or restructures a response. Code written for the old shape throws errors or, worse, quietly records wrong data.
Price and plan changes
Nothing breaks technically, but a free tier shrinks or a feature moves to a higher plan. The bill, or a newly enforced quota, tells you later.
Retirement
The provider switches off a product, API version or AI model on a published date. This is the only permanent failure, and the only one you can fully plan for.
How do API providers announce changes and shutdowns?
Reputable providers announce changes through a public changelog, versioned APIs and a deprecation schedule with dates, usually backed by email to the account owner. "Deprecated" means still working but scheduled for removal. Three examples, all checked on October 6, 2026, show how much notice periods vary.
Stripe versions its API by date. Its versioning documentation says it releases new API versions monthly with no breaking changes, and twice a year issues a major release that starts with a version containing breaking changes; the current version is 2026-09-30.endive. Stripe's upgrade guide recommends that your code specifies the API version it was written against instead of relying on the account default.
Google Maps Platform keeps a deprecations page stating that a deprecated product, feature or version stays available through a deprecation period that is typically 12 months. It records that the Heatmap Layer in the Maps JavaScript API was deprecated in May 2025 and is unavailable as of May 2026.
AI model providers move faster. Anthropic's model deprecations page commits to at least 60 days' notice before retiring a publicly released model and states that requests to retired models will fail. It lists Claude Sonnet 4.5 as deprecated on September 30, 2026, with retirement on November 30, 2026.
What does well-built software do to survive API failures?
Well-built software assumes every outside service will fail at some point and confines the damage to one feature instead of the whole system. The standard techniques are:
- Timeouts: every outside call gives up after a set time instead of hanging.
- Retries with increasing delays: temporary failures are retried a few times. Payment retries must be safe to repeat; Stripe provides idempotency keys so a repeated request does not perform the same operation twice.
- Queues: work that can wait, such as sending email or syncing invoices, is held and processed when the provider recovers.
- Fallbacks: a degraded but acceptable behavior, such as taking the order and confirming later, or a second provider for critical paths.
- Version pinning: the code names the exact API and library versions it uses, so upgrades are deliberate and tested.
- Monitoring: error rates and response times are tracked per provider, and someone is alerted when they rise.
- A dependency inventory: one document listing every outside service, its version, its purpose, the account owner and its changelog address.
What are the common mistakes with third-party API dependencies?
The most common mistake is that nobody reads the provider's emails. Deprecation notices go to the address that opened the account, which is often a former employee, a freelancer or an unmonitored shared inbox.
Other frequent mistakes are treating a finished integration as permanent, running on the account's default API version so behavior shifts without a code change, having no test environment for trying a new version, calling the provider from dozens of places in the code so every change means dozens of edits, and letting a contractor hold the account and API keys in their own name. Leaving a migration until the final week turns a routine update into an emergency.
What should I ask my developers about API dependencies?
Ask your developers for evidence instead of reassurance: a written list tells you more than "it is handled". Useful questions are:
- Can I see every outside service we call, with the version of each?
- Which email address receives each provider's notices, and who reads it?
- What does a customer see if the payment, email or AI provider is down for an hour?
- Are API and library versions pinned, and when was each last upgraded?
- Does the company own every provider account and key?
What should I do next when an API retirement notice arrives?
When a retirement notice arrives, treat the cutoff date as fixed and start immediately. Work through these steps:
- Confirm the notice on the provider's official deprecation page and note the date and recommended replacement.
- Ask your developers which features and which parts of the code use the retiring item.
- Read the migration guide and get an estimate. A like-for-like replacement is a small job; a redesigned API is a project.
- Make and test the change in a staging environment, including edge cases such as refunds or failed payments.
- Release well before the deadline, watch error rates for a few days, then update the inventory.
If no notice has arrived, the next step is the inventory itself, because it shows where your exposure is. Ongoing upkeep of this kind is covered in our guide to software maintenance and support.
Quick answers
What does it mean when an API is deprecated?
Deprecated means the API, version or model still works but the provider has scheduled it for removal and recommends a replacement. After the published retirement date, requests to it fail.
How much notice do API providers give before shutting something down?
It varies by provider. As of October 6, 2026, Google Maps Platform describes a deprecation period that is typically 12 months, while Anthropic commits to at least 60 days' notice before retiring a publicly released AI model.
What is API version pinning?
Version pinning means your code states the exact API version it was written for, so the provider keeps responding in that format. Your software then changes behavior only when your developers deliberately upgrade and test.
Can my software keep working during a third-party API outage?
Partly, if it was built for it. Timeouts, retries, queues and fallbacks let the rest of the application keep running and complete delayed work once the provider recovers.
Who is responsible for updating my software when an API changes?
You are, through whoever maintains your software. The provider's responsibility ends with publishing the change and the date; adapting your code is part of your own maintenance.
Conclusion
Every outside service your software uses will change eventually, and some will be retired. The businesses that get hurt are the ones with no list of their dependencies, no one reading the notices and no room in the code for a provider to fail. An inventory, pinned versions, basic monitoring and a named person reading provider emails remove most of the risk.
Entrant Technologies builds websites, web applications, mobile apps and custom software. If you have received a retirement notice or are unsure what your software depends on, contact us and we will take a look.