# Understand your API

> Paste an OpenAPI spec, get a plain-English explanation.

Understand your API reads an OpenAPI specification and explains in plain English what the API does, how authentication works, and what a consumer needs to know before integrating.

Also: openapi explainer, explain openapi spec, what does this api do, understand an api, openapi documentation generator, api spec summary, summarize openapi spec, openapi to plain english, explain api spec.

## What it does

An OpenAPI document is written for machines, and reading one to work out whether an API does what you need is slow. This explains the document instead: what the API is for, how it authenticates, what the error model looks like, and where the surprises are. You choose the angle — a short overview, a technical integration brief, a resource-by-resource walkthrough — and can keep asking follow-up questions about the same document.

## When to use it

- You have been handed a specification and want to know what the API actually does.
- You are evaluating a third-party API and want the integration details before committing.
- You need to explain an API to someone who will not read the specification themselves.
- You want a specific question answered — how auth works, how pagination works — without reading the whole document.

## What you give it

| Input | Meaning |
| --- | --- |
| OpenAPI specification | Pasted in as YAML or JSON. Swagger 2.0 and OpenAPI 3.x documents are both understood. |
| Angle | Which explanation you want: a summary, a deep dive, a technical integration brief, or a product-level view. |

## What you get back

| Output | Meaning |
| --- | --- |
| Plain-English explanation | A written answer covering what the API does and how to work with it, formatted with headings, tables and code where it helps. |
| Follow-up answers | Answers to further questions about the same specification, in the same conversation. |

## Key terms

- **OpenAPI** — a standard, machine-readable description of an HTTP API — endpoints, parameters, request and response shapes, and authentication. Formerly called Swagger, which is why 2.0 documents still use a swagger key.
- **Error model** — the shape an API uses to report failures — the status codes it returns and what the body contains. It is one of the most consequential parts of an API to understand and one of the least documented.
- **Pagination** — how an API returns a long list in pieces. Cursor and offset pagination behave differently under concurrent writes, so which one an API uses changes how you consume it.

## Questions

### Which specification versions can it read?

Swagger 2.0 and OpenAPI 3.x, in either YAML or JSON.

### Can I ask follow-up questions?

Yes — the specification stays in context, so you can keep asking about the same document.

### Does it need a complete specification?

No. A partial or sparse document still gets an explanation, including what is missing from it.


## Privacy

Unlike the browser-only tools here, this one sends the specification you paste to an AI model to produce the explanation. The conversation is not saved and clears when you refresh, and no account is needed.

## Links

- [Use the tool](https://www.postman.com/tools/understand-your-api) — the interactive version of this page.
- [Postman Tools](https://www.postman.com/tools) — every free tool in this set.
- [OpenAPI docs](https://learning.postman.com/docs/design-apis/specifications/overview/) — Postman documentation.