Most teams already have an OpenAPI specification. It is generated from the code, it is accurate on the day it is generated, and it lives in a repository where no customer will ever read it.
The documentation those customers do read is usually a separate, hand-maintained thing that drifts a little further from the spec with every release.
Import the spec you already have
Paste or upload an OpenAPI or Swagger specification — JSON or YAML, up to 10 MB — and FinalDoc turns it into browsable reference documentation.
The import keeps the detail that makes reference docs useful:
- Every operation becomes its own endpoint page, with its method, path and summary.
- Parameters carry through with their location, type, description and whether they are required.
- Request bodies and response codes are preserved, so a reader sees both what to send and what comes back.
- Tags become resource groups. Your
OrdersandCustomerstags turn into navigable sections, with their descriptions intact. - Deprecated operations are flagged rather than quietly dropped, because readers still hit them.
Safe to run on every release
The import is designed to be repeated. Re-importing an updated spec matches existing endpoints on method and path and updates them in place — it does not accumulate duplicates, so you can wire it into your release routine and stop thinking about it.
Specs are validated before anything is written. A malformed file is rejected with an explanation, and your existing documentation is left exactly as it was — no half-finished import to clean up.
Code samples your readers can paste
Every endpoint gets working request examples in six languages — cURL, JavaScript, Python, PHP, Ruby and Go — built from that endpoint's real path, parameters and body, not from a generic template. A developer lands on the page, copies the language they use, and goes.
A console that actually sends the request
Reference documentation answers "what does this endpoint do". A reader usually wants to know "what does it do for me".
Each endpoint has a Try It panel: fill in the parameters, headers and body, send the request, and see the real status code, response body and how long it took. It is the difference between reading that an endpoint returns a customer object and watching it return your customer object.
Browsers block cross-origin requests to most APIs, which is what makes try-it consoles fail on other platforms. Ours can route the call through FinalDoc instead, so the console still works against APIs that do not send CORS headers to a browser.
Reference and prose in one place
API references are read alongside guides — authentication, rate limits, webhooks, the tutorial that explains why any of it matters. Because your reference lives in the same knowledge base as your written documentation, readers search once and get both, and your API docs inherit your branding, custom domain and access rules.
Each knowledge base version holds its own set of endpoints too, so v1 and v2 of your API can be documented side by side without one overwriting the other.
Getting started
Open API Docs in the sidebar, pick the version to import into, and paste your spec. If you would rather start from nothing, you can create resources and endpoints by hand — the editor is the same either way, and a hand-built endpoint gets the same code samples and console as an imported one.