APIs change. Usually without warning.

Major API providers distinguish between breaking and non-breaking changes. Breaking changes get versioned and announced. Non-breaking changes — adding a new field, making a field nullable, loosening a type — get deployed silently because the provider assumes your code handles them gracefully.

Sometimes it does. Sometimes it doesn't.

// What the API used to return
{
  "user_id": 4521,        // integer
  "status": "active"
}

// What it returns now (provider considers this "non-breaking")
{
  "user_id": "4521",      // string — type changed
  "status": "active",
  "created_at": "..."     // new field added
}

Microsoft's own API documentation explicitly states: non-breaking changes "are typically communicated after implementation" and applications "should be designed to handle these changes without prior notice."

This one is the most common and the least dramatic. An engineer fixes a bug. The fix changes a field from required to optional, or from integer to string, or adds a null edge case that wasn't there before. They didn't touch the API documentation. Nobody filed a change notice. It wasn't intentional.

But your integration is now broken.

// Three years of API responses looked like this:
{ "user_id": 4521 }  // always an integer

// After a routine database migration:
{ "user_id": "4521" }  // now a string

// The type-strict parsing layer:
const id = response.user_id as number;  // TypeScript thinks it's fine
db.query("SELECT * FROM users WHERE id = ?", [id]);  // silent failure

// Result: blank screens for 30% of users
// Time to diagnose: 4 hours
// Cause: one field, one type change, zero announcements

The big providers — Stripe, Twilio, SendGrid — have dedicated developer relations teams, versioned APIs, and deprecation policies. Most APIs your integration depends on do not.

Data providers, regional payment gateways, logistics APIs, government data APIs, niche SaaS integrations — these often have no changelog, no versioning strategy, and no formal process for notifying consumers of changes.

# Incident 1: Rate limit changed overnight
# Before: 1,000 requests/hour
# After:  100 requests/hour
# Notice: None
# Discovery: Automated systems started failing

# Incident 2: Auth method changed
# Before: API key authentication
# After:  OAuth2 required
# Notice: None
# Discovery: All integrations broke simultaneously

# Incident 3: Response field renamed
# Before: { "customerID": "..." }
# After:  { "customer_id": "..." }
# Notice: One line in changelog nobody subscribes to
# Discovery: NullPointerException in production

This is the newest category and it's growing fast. When an AI tool refactors backend code or generates a migration, it optimises for correctness of behaviour — not stability of the API contract it exposes.

An AI-suggested refactor might change a response shape in a way that is functionally identical to the original intent but structurally different. The code works. The unit tests pass. The API consumers break silently.

// Original endpoint — team has been using this for 2 years
return res.json({
  success: true,
  data: { orderId: order.id, total: order.total }
});

// AI refactor for "cleaner structure" — passes all tests
return res.json({
  status: "ok",
  result: { order_id: order.id, amount: order.total }  // renamed fields
});

// Every integration reading response.data.orderId now breaks
// No tests caught it because the tests tested behaviour, not schema

Sometimes the provider does everything right. They write a changelog post. They send a deprecation email. They give 90 days notice. And your integration still breaks when the change goes live — because the email went to a billing inbox, the changelog post wasn't shared in Slack, and the 90 days slipped past a team focused on shipping features.

Communication failure is a system problem, not a blame problem.

[Jan 15] Provider sends deprecation email to billing@yourcompany.com
[Jan 15] Email read by finance team. Not forwarded to engineering.

[Feb 01] Provider posts changelog on docs.provider.com
[Feb 01] 3 of 200 API consumers see it.

[Mar 15] Provider's Slack community announcement
[Mar 15] Seen by developer who built the integration — now on parental leave.

[Apr 14] Breaking change deployed
[Apr 14] 08:47 — Integration breaks in production
[Apr 14] 09:15 — Someone notices from user complaints
[Apr 14] 11:30 — Root cause identified
[Apr 14] 14:00 — Fix deployed