A resilient endpoint doesn't break old apps

𝗔 𝗿𝗲𝘀𝗶𝗹𝗶𝗲𝗻𝘁 𝗲𝗻𝗱𝗽𝗼𝗶𝗻𝘁 𝗱𝗼𝗲𝘀𝗻'𝘁 𝗯𝗿𝗲𝗮𝗸 𝗼𝗹𝗱 𝗮𝗽𝗽𝘀

Did you ever change a field in a JSON response and suddenly apps you didn't even know were still active started failing? Happened to me 😅

In one of the systems I maintain, I had to evolve an endpoint: new fields, different logic, everything needed for the new client version. The problem is not every user updates at the same time — there were 𝗰𝗹𝗶𝗲𝗻𝘁𝘀 running old versions of the app that were going to stick around for months.

On the 𝘄𝗲𝗯 this barely exists: the 𝘀𝗮𝗺𝗲 deploy updates frontend and backend together, so new endpoints reach everyone at the 𝘀𝗮𝗺𝗲 𝘁𝗶𝗺𝗲. With 𝗶𝗻𝘀𝘁𝗮𝗹𝗹𝗲𝗱 𝗮𝗽𝗽𝘀 you don't get that luxury: the backend changes today, but the old client can stick around for weeks or months until the user updates (or never does).

That's when I understood an endpoint isn't just code — it's a 𝗰𝗼𝗻𝘁𝗿𝗮𝗰𝘁 with whoever consumes it. If I break it, I'm not breaking my backend — I'm breaking the experience of someone who doesn't even know I exist. What worked for me:

→ 𝗔𝗱𝗱𝗶𝘁𝗶𝘃𝗲 𝗰𝗵𝗮𝗻𝗴𝗲𝘀 first: add fields, never remove or rename the ones that already exist

→ 𝗘𝘅𝗽𝗹𝗶𝗰𝗶𝘁 𝘃𝗲𝗿𝘀𝗶𝗼𝗻𝗶𝗻𝗴 (/v1, /v2) when the change does break the 𝗰𝗼𝗻𝘁𝗿𝗮𝗰𝘁

→ 𝗗𝗲𝗽𝗿𝗲𝗰𝗮𝘁𝗲 with notice and a date, never overnight

→ Monitor which versions are still getting real traffic before deciding when to shut something down

The 𝗿𝗲𝘀𝗶𝗹𝗶𝗲𝗻𝗰𝗲 of an endpoint isn't measured only in uptime — it's measured in how many different versions of your consumers it can sustain without anyone noticing the change 🔥

How do you handle backward compatibility in your APIs? Versioning, feature flags, something else? Tell me 👇

Keep flying, Champions! ✈️