Column has been busy. Rebuilding our documentation was always toward the bottom of the to-do list, partially because we were dealing with an annoying (and common) problem:
API documentation inevitably drifts from the API itself.
A fix would take time and energy, but documentation is a kind of front lawn that signals a lot about how you live and work. So we made time and came up with a solution: just make the docs and the API the same artifact. We recently rebuilt our documentation to do just that, with two major changes:
The spec is the source of truth, and...
Our assumed audience is large language models
Where we started
When we first launched the Column APIs, our product surface area was small enough that the documentation could be basic. We wanted to ship something simple, so we put everything on a single scrolling page, which conveniently doubled as a reason to skip building search — Cmd-F could handle anything users needed. That was the right shape for the API at the time.
It worked less well as the API kept growing.
The spec is the source of truth
That was the surface-level mess. Underneath it was a deeper one: the docs lived in a separate repository and on a separate site, with no real connection to the OpenAPI spec that defines the API. We were maintaining the source of truth twice — once in the spec our API server already uses to generate types, and again in hand-written markdown in a different codebase entirely.
Our fix was to move the docs into the same repo as the spec and write a generator: every build, the spec produces the complete API reference. A new endpoint and its documentation now arrive in the same pull request, get reviewed together, and ship in the same release. The two can't drift apart because they never ship apart.
A nice side effect is that depending on the spec improved the spec. Every team thinks they have a singl source of truth until you ask which two repositories it lives in.
Search and performance
With the structural problem solved, the rest of the rebuild was about the parts users feel directly — starting with search. The build produces a static index, the CDN serves it, the browser loads it once, and every query after that runs in memory. Everything is searchable now, from API references to written guides.
Performance, meanwhile, is a function of shape. The new site is static HTML, one file per page, served from the same S3 and CloudFront we were using before. Loading one endpoint loads one endpoint, and adding new content costs the new content rather than everyone else. The tradeoff is that build times grow with the corpus — at ten times our current content we'll need to do builds incrementally, but not yet.
Built for the way developers write code now
Those were the obvious upgrades. The bigger change was about who's actually reading the docs — increasingly, that isn't a developer in a browser but a language model the developer is talking to. We've been on the receiving end of this often enough — wiring up someone else's API through an LLM ranges from genuinely helpful to comically bad. We wanted ours on the helpful end, so we made that workflow first-class rather than something developers had to work around.
Every page is now published in two formats: the rendered version you see in the browser, and a clean markdown version alongside it with no UI components, no nav chrome, no JavaScript, just the text. A row of buttons on every page hands that markdown off: open in ChatGPT, open in Claude, or copy. The "open in" buttons launch a fresh chat with a prompt pointing the model at the markdown URL, so it reads our actual current content rather than guessing from its training data.
In essence, we'd rather your model read our docs than hallucinate them. Acknowledging that in 2026 feels about as weird as acknowledging mobile in 2012 — slightly awkward in the moment, fairly obvious in retrospect.
Navigating an expansive API
Reading docs through a model is one thing. Reading them yourself is a different problem. Against an API with as many objects and parameters as ours, you more often find yourself stuck on finding the right thing to read than trying to decipher what something means.
Every API page has a split layout, with parameter definitions on the left and a request/response example on the right. The two are wired together: hovering a parameter highlights the matching lines in the example, clicking one scrolls the example to that line, and clicking a line in the example scrolls back to the parameter's definition. After ten minutes of using it, a flat reference page feels oddly disconnected from itself.
The stack, briefly
Fumadocs, Tailwind, one catch-all route. Adding a doc is adding a file. If it's an API reference, the spec generates it for you. Stack sections used to be the part engineers read most closely — these days they're mostly a list to paste into Claude and ask whether it would have picked the same.
The result
The new docs keep pace with the API itself, surface what you're looking for, and meet you wherever you read them. If you're trying to understand how Column actually works, docs.column.com should now be the fastest way to get there. Take a look.
