API reference documentation · OpenAPI 3.1
API reference developers trust.
We write or repair the OpenAPI specification behind your API and build the documentation set around it: the reference developers integrate against, the quickstart that gets them to a first successful call in five minutes, and the pages every API needs and most lack, errors, pagination, rate limits, versioning.
10-day delivery · 2 free revisions
What changes for your team
- Onboarding tickets drop up to 30% on documented endpoints: the answer is in the docs before the question reaches support.
- Time to first successful call measured in minutes, not an afternoon of guessing.
- A reference that stays true: validated against the spec in CI, so it can't drift three sprints later.
- Integrators who self-serve, and partners who ship without a call with your engineers.
Deliverables
- A validated OpenAPI document (3.1, or 3.0 if your tooling requires it)
- Rendered reference for every endpoint: parameters, request bodies, responses, headers, error catalog
- Quickstart to a first successful call, authentication guide, core-concepts page
- Pagination, rate limits, versioning & deprecation, changelog pages
- Three working examples per operation, minimal, realistic, failing
- House style for specs and CI linting rules, so your team keeps it consistent
Standards, tools and formats
- OpenAPI 3.0 / 3.1
- Swagger 2.0 → 3.1 migration
- Spectral linting
- Swagger UI · Redocly · Stoplight
- Postman · Bruno
- Diátaxis: tutorial · how-to · reference · explanation
- Docs-as-code · Git · CI
- MkDocs · Docusaurus · Mintlify
- Markdown · MDX
- curl · SDK samples (TS · Python · Go)
- REST · GraphQL · gRPC · webhooks
How the engagement runs
- Audit the spec & probe the API We read your OpenAPI or Swagger file (or start from a sandbox), lint it against 40+ rules, and list every endpoint, parameter and error that is undocumented or wrong.
- Write the reference from the contract Summaries that start with a verb, a stable name for every operation (the operationId that SDK generators and Postman rely on), tags that become the navigation, one error format for the whole API, and three examples per operation: minimal, realistic, failing.
- Add what generators can't Quickstart, authentication how-to, core concepts, pagination, rate limits, versioning and changelog: the set of pages a public API needs.
- Validate, publish, hand over The spec passes the linter in your CI, the site builds docs-as-code from your repo, and your team gets the house style so the next endpoint is documented the same way.
Add-ons
- OpenAPI spec cleanup
- Postman collection
- Interactive code examples
- Endpoints 31 to 60
Questions
Do you need our engineers' time?
About two hours over the project: a kickoff for sandbox access and domain questions, and a review of the draft. Everything else we find by probing the API.
Our spec is Swagger 2.0, is that a problem?
No. We migrate it to OpenAPI 3.1 as part of the work, and keep a 3.0 output if one of your tools still needs it.
What counts as one API?
Up to 30 endpoints in the base price; larger surfaces are quoted per additional block of 30 endpoints, that is why the price shows as “from”.
Can it live in our existing docs site?
Yes, MkDocs, Docusaurus, Redocly, Stoplight, GitBook or plain Swagger UI. We deliver into your repo and pipeline.
Do you also write guides and tutorials?
The quickstart, authentication and concept pages are part of this package; deeper task guides are an add-on, or part of the SaaS launch pack.