What exactly does this endpoint return?

You don't own the API. Pin down the response shape, which fields can be null, and what an error looks like before you write a component against it.

Agree on the shape first

The UI and the API are two codebases, usually owned by different people. Assume a field is always there and you get a runtime crash the first time it comes back null.

For the endpoint I am consuming at [endpoint], which fields in the response can be null or missing, and how should the UI handle each of those cases?

Know what an error looks like

The success shape is only half the contract. Find out how the API reports failure before you write code that reads it.

For the endpoint at [endpoint], which HTTP status codes signal failure, and what fields does the error body contain so I can read the message instead of guessing?

Turn the shape into types

Generate TypeScript types from the agreed JSON so the build breaks before a mismatched shape ships. If the backend publishes an OpenAPI or Swagger spec, generate from that so the types track the real API.

Generate a TypeScript type from this sample response, then explain how I would regenerate it from an OpenAPI spec so it tracks the real API instead of drifting: [paste your JSON here].

Make the contract real at runtime

Types vanish at build time, so they catch nothing when a response breaks the shape in production. Parse the response at the boundary, inside your fetcher, with Zod. Give a wrong or missing field a safe fallback via .catch() or .default(), and one bad field degrades quietly instead of crashing the screen.

Using Zod, write a schema for this response and parse it inside my fetcher with safeParse. For [field], give a safe fallback with .catch() so the UI keeps working if the backend sends the wrong type or omits it: [paste your JSON here].

If you assume a field exists, the API will prove you wrong with a null the first time it ships.

Additional Resources

Explore these carefully curated resources to deepen your understanding and practice the concepts covered in this lesson.

MDN Fetch API

Documentation

The browser's built-in primitive for making HTTP requests.

https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API

MDN HTTP response status codes

Documentation

The full list of HTTP status codes an API can return and what each one means.

https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Status

Zod

Documentation

Parse a response at runtime against a schema, and supply a safe fallback with .catch() when a field is wrong or missing.

https://zod.dev

openapi-typescript

Documentation

Generate TypeScript types straight from an OpenAPI or Swagger spec, so your types track the real API.

https://openapi-ts.dev

PreviousNext