Handling API Versioning as a Consumer

The plain-language idea

An API a frontend client depends on will change over time — fields get added, fields get deprecated, whole response shapes evolve. A frontend client needs real, concrete patterns for surviving that, rather than assuming the shape it was built against is permanent. Three patterns matter in practice:

• Defensive parsing. Read only the specific fields the code actually needs, instead of assuming the entire response matches exactly the shape it had when the code was written. This connects directly to the earlier lesson on validating API responses at runtime — a validation schema is itself a form of explicit, checked defensive parsing, catching a shape mismatch loudly instead of letting it fail silently somewhere downstream.
• Feature-detecting a new field. Check whether a newly-added field exists before relying on it, rather than assuming every deployed client is already talking to a version of the API that has it. This matters most during a gradual rollout, or when the frontend build itself might be deployed slightly ahead of or behind the backend it calls.
• Living with versioned endpoints. A URL or header-based version (/v2/orders existing alongside /v1/orders) is a real, common pattern during a migration window, and a frontend team has to know how to navigate it — including the operational reality that a deprecated version eventually gets removed, and migrating off it has to actually happen before that date, not sit indefinitely.

See it in a real thing: a field that gets added mid-rollout

type OrderResponse = {
  id: string;
  total: number;
  // Added in a later API rollout — not guaranteed present yet on every request
  discountCode?: string;
};

function renderOrderSummary(order: OrderResponse) {
  const discountLine =
    "discountCode" in order && order.discountCode
      ? `Discount applied: ${order.discountCode}`
      : null;

  return { total: order.total, discountLine };
}

The "discountCode" in order check is the feature-detection: this code works correctly whether it's talking to a backend that has shipped the field yet or not, instead of crashing (or silently rendering undefined) on whichever side hasn't caught up.

// Defensive parsing: pull out only what's needed, don't assume the rest
function getOrderTotal(raw: unknown): number {
  if (
    typeof raw === "object" &&
    raw !== null &&
    "total" in raw &&
    typeof (raw as { total: unknown }).total === "number"
  ) {
    return (raw as { total: number }).total;
  }
  throw new Error("Unexpected order shape: missing numeric total");
}

What people usually miss

Watch out

• "It's always worked so far" is not evidence a shape is stable. An API contract can change the moment its owners have a reason to, and code that assumes an exact shape forever has no defense when that happens — this is exactly why the earlier lesson's runtime validation approach exists.
• Feature detection is not the same as optional chaining alone. order.discountCode?.toUpperCase() handles a missing value gracefully at the point of use, but it doesn't tell you why it's missing — genuinely absent this order, or not yet rolled out on the backend the client is talking to — which matters when deciding whether to show a fallback UI or just omit the feature entirely.
• A deprecated API version isn't deprecated forever — it eventually gets removed. Treating /v1/ as safe to keep calling indefinitely because it "still works" is how a team gets caught by a real breaking removal on a schedule they weren't tracking.
• Versioning is a frontend concern, not purely a backend one. A frontend team that never plans a migration path off an old version is choosing to be surprised by its removal instead of migrating on its own schedule.

Why this matters in interviews

"An API you depend on adds a new field or bumps its version — how does your client handle that without breaking?" is a real, practical question, and naming defensive parsing, feature detection, and a real migration plan off a deprecated version — not just "we'd update the code eventually" — shows you've actually maintained a client against a changing API.