Free API Response Explainer: Map JSON Fields, Types, and Errors

API responses become expensive when a nested field reaches a component before anyone has checked its shape, so paste a representative payload into the tool above to map fields, surface pagination and error signals, and generate a starting type or schema without sending the payload to an external AI service.

Start with a response that represents the endpoint

A happy-path payload tells you how the endpoint behaves when everything works. A list response like the one below gives the tool an array, a metadata object, and an explicit error field to inspect.

{
  "data": [{"id": "u_1", "name": "Ada", "role": "admin"}],
  "meta": {"page": 1, "next": null},
  "error": null
}

Choose Explain Response when you need a field map before you write client code. Choose TypeScript, Zod, or JSON Schema when the next task is a typed client, a runtime validator, or an API contract document.

Use the field map to find the contract boundary

The map calls out paths such as data[].id and meta.next, which is more useful than reading a formatted blob of JSON. A list view can rely on the item fields, while pagination logic belongs near the metadata fields.

Generated output describes only the payload you paste, so compare optional values, nulls, and enum-like strings with the API documentation before you rely on a type or schema.

Match the output to the code you are writing

TypeScript mode produces interfaces from the sample. Zod mode produces a runtime schema, which helps when an API can change shape without a compile-time signal.

JSON Schema suits validation tooling and documentation pipelines. Example Requests gives you a small request for the selected language, so you can test status handling before you connect the response to a UI.

Run an error response through the tool too

A client that only models successful responses fails at the first rate limit or validation error. Paste a known error body after the success sample and compare the field maps.

{
  "error": {"code": "rate_limited", "message": "Try again later"},
  "retryAfterMs": 3000
}

The error sample above exposes an error object and a retry delay. Your client can use that information to show a useful message, wait before retrying, or route the failure to the part of the application that owns recovery.

Generated code needs a contract check

The tool only sees the payload you paste. It cannot infer undocumented fields, permissions, or differences between API versions.

That limitation is useful because it gives you a short review sequence: paste one success response, paste one error response, compare the output with the endpoint documentation, then add the generated type or schema to your client. The final comparison catches the assumptions that a formatted JSON sample hides.

Keep the sample close to the bug or feature

Use a captured response from the endpoint you are changing rather than a generic example. A representative payload makes the field map useful during code review and gives the next person a concrete shape to test.

Paste the smallest response that reproduces the decision you need to make. That keeps the output readable and makes differences between success, empty, and error states easier to spot.