APIs often break clients in ways that don’t show up in tests.

A change looks safe inside the service:

remove an unused field

tighten validation

adjust an error response

Everything still works locally. Tests pass. Deployment succeeds.

Then a mobile app crashes.

A partner integration fails.

An older frontend silently breaks.

Nothing is “wrong” in the service - but the contract changed .

The Problem: Internal Changes, External Breakage

Consider a response:

{ "id" : "ord_123" , "status" : "paid" , "customer" : { "id" : "cus_456" , "email" : "[email protected]" } }

Enter fullscreen mode

Exit fullscreen mode

Removing customer.email looks like cleanup.

But for a client, that field might:

power a receipt screen

feed an export pipeline

be required in a generated SDK

From the server’s perspective: harmless

From the client’s perspective: breaking change

Why This Keeps Happening

Most tests focus on correctness inside the service :

business logic

database state

request handling

They don’t protect…