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" : "ada@example.com" } } 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 what clients depend on .…