Technical documentation is read again and again, months after it was written, by someone who was not in the room when it was decided.
Payments API
Every request carries a bearer token scoped to one merchant. Tokens expire after an hour; refresh them with the endpoint below.
Sixty requests a minute per token. Exceeding it returns 429 with a retry-after header; batch endpoints count as one request.
A document read once can get away with being a wall of text. One that is read repeatedly needs structure that survives that — headings a returning reader can jump to directly, and a record of what changed and when, so someone coming back to it can see how it got here, not just where it ended up.
Headings that build the contents panel
A heading is also a jump point, so a returning reader reaches the section they need without scrolling past the ones they do not.
A passage written once and mirrored everywhere
A page reused across your documentation — a glossary, a support contacts page — is embedded rather than copied, so editing the source updates every document that mirrors it.
Long references stay scannable
A reference can be switched between sections instead of stacked end to end, detail can fold out of the way until it is needed, and documentation already written in Markdown comes in without a rewrite.
A history that says what changed — and which part still gets reopened
Every version is dated and kept, so a reader can see exactly what changed from one edit to the next, a running record of how the document evolved rather than a single verdict on where it stands today. You also see which heading a returning visitor opens again, months after they first saw it, the clearest evidence of which section of the record still earns a look.
An example — not your document. Sections are the document’s own headings.
Most of their attention went to “Mirrored passage” — 2m 14s of 4m 00s.
Time each section spent on screen, counted only while the tab was in front and the reader was active. It shows what was in front of them, not what they read.
This page is about what a technical documentation has to do. For the blocks the editor is built from — see the editor.
The template is one finished example. This page is about the structure that keeps any reference document readable as it grows — the contents panel, the history, and blocks kept in sync.
Yes — paste it into the editor and it becomes real headings, tables and commands that keep their formatting, or import a .md file directly.