Slate API Documentation: 2026 Guide and Alternatives

Slate API documentation is the original three-pane API reference generator: description on the left, code samples on the right, all built from Markdown and shipped as a static HTML site. It powered some of the most respected developer docs of the 2010s, including early Stripe, Travis CI, Best Buy, and Sony. If you have ever opened API docs and seen prose on one side and a syntax-highlighted curl command snapped to the other, you have seen the layout Slate popularized. This guide covers what Slate is, how to set it up, what the three-pane layout actually buys you, and the big change that just hit the project: the GitHub repository was archived on February 4, 2026. If you are picking a tool today, that fact reshapes the decision, and it is worth understanding before you commit. Most teams in this position end up evaluating one of the API documentation tools that have emerged in the years since Slate stopped getting major updates.

Key takeaways

• Slate is an open-source static site generator for API docs, built in Ruby on top of Middleman, originally created by Robert Lord in 2013
• The three-pane layout (nav left, prose middle, code samples right) became the dominant pattern for API references and was directly copied by Stripe, Twilio, and others
• You write Markdown, run bundle exec middleman server locally, and deploy a static HTML build to GitHub Pages or any static host
• The official repo at github.com/slatedocs/slate was archived in February 2026 in protest of GitHub's parent company contracts, ending active maintenance
• If you need to ship API docs in 2026, alternatives like Scalar, Redoc, or Stoplight Elements are better-supported renderers for OpenAPI-first workflows

What is Slate?

Slate is a static documentation generator designed specifically for API reference pages. You write your documentation in Markdown, drop in code samples in fenced blocks tagged by language, and Slate compiles everything into a single self-contained HTML page with a fixed left navigation, a center prose column, and a right column of code samples that scrolls in lockstep with the prose.

It was created by Robert Lord (then at TripIt) in 2013 and open-sourced under the Apache 2.0 license. The project lived at tripit/slate until 2018, when it moved to the slatedocs organization at slatedocs/slate. At its peak the repository had over 36,000 GitHub stars, making it one of the most popular API documentation projects on the platform.

The pitch in one sentence: take a Markdown file, get back a beautiful three-pane API reference that you can host anywhere for free.

Why the three-pane Slate layout matters

Slate did not invent the three-pane layout, but it standardized it. The pattern is now so dominant in API documentation that most developers expect it without thinking: navigation always visible on the left, the API description scrolling in the middle, and the code sample for the current endpoint pinned to the right in the language the reader has selected.

The reason it works for API docs specifically is that an API reference has two parallel tracks of information. The prose describes what an endpoint does, what parameters it accepts, what it returns, and when to use it. The code sample shows you exactly how to call it. Stacking those vertically forces the reader to scroll up and down constantly. Putting them side by side lets the reader's eye move horizontally, matching prose to call, the way you would read a textbook with diagrams in the margin.

Stripe took this pattern and built the most-imitated developer docs on the internet. Twilio, Plaid, and GitHub followed. Most modern API doc tools, from Scalar to Redoc, default to a three-pane variant. Slate was the open-source reference implementation that put the pattern in everyone's reach.

How Slate actually works

Slate is built on Middleman, a Ruby-based static site generator. The Ruby toolchain is the first thing you discover about Slate, and it is the thing that has driven a lot of teams to alternatives over the years. To run Slate locally you need:

• Ruby 2.6 or newer
• Bundler (gem install bundler)
• The Slate repository forked or cloned to your machine
• bundle install to pull in dependencies including Middleman, Rouge for syntax highlighting, and the Slate theme

Once you have those, the workflow is straightforward:

git clone https://github.com/slatedocs/slate.git
cd slate
bundle install
bundle exec middleman server

That last command starts a local server at http://localhost:4567 with live reload. Edit source/index.html.md, save, and the browser updates.

There is also an official Docker image at slatedocs/slate on Docker Hub that ships with Ruby and all dependencies preinstalled. If you do not want to manage a Ruby version on your machine, the Docker path is faster to get running, though you still inherit the Middleman build pipeline.

Writing Slate API documentation

A Slate documentation site is, structurally, one big Markdown file. The default source/index.html.md contains the full content of your API reference, organized by H1 sections for major resources and H2 sections for individual endpoints. The left navigation auto-generates from those headings.

The front matter at the top of index.html.md controls the site title, the languages that appear as tabs in the right column, the footer links, and a list of includes for splitting content across files. A minimal version looks like this:

---
title: API Reference
language_tabs:
  - shell: cURL
  - ruby
  - python
toc_footers:
  - <a href="https://example.com/signup">Sign up for an API key</a>
includes:
  - errors
search: true
---

For each endpoint, you write the prose explanation, then fence three or four code blocks tagged with the language. Slate places them in the right column and shows the one matching the currently selected language tab. A typical Slate documentation example for a single endpoint looks like:

## Get all kittens

```shell
curl "https://api.example.com/v1/kittens" \
  -H "Authorization: meowmeow"
```

```ruby
require 'kittens'
api = Kittens::APIClient.authorize!('meowmeow')
api.kittens.list
```

```python
import kittens
api = kittens.authorize('meowmeow')
api.kittens.list()
```

This endpoint retrieves all kittens.

### HTTP Request

`GET https://api.example.com/v1/kittens`

The code blocks render in the right column, the prose stays in the middle, and the navigation in the left column picks up the H2.

Slate also ships a small <aside> system for callouts (notice, warning, success) and supports tables, blockquotes, and the rest of standard Markdown via Redcarpet. For larger projects you split sections into _files.md partials in the source/includes/ directory and reference them in the front matter.

Slate documentation examples in the wild

The Slate readme historically listed dozens of well-known sites built on Slate. The ones worth knowing as benchmarks:

• Stripe: early Stripe API docs were built on Slate, and the visual DNA is still visible in today's docs. Stripe has since invested heavily in their own custom platform, but if you want to understand why the three-pane pattern matters for developer trust, read our Stripe API docs teardown
• Travis CI: the API reference at docs.travis-ci.com/api is a clean canonical Slate site that still serves as a reference for what good looks like
• NASA: multiple internal NASA APIs used Slate for public documentation
• Best Buy, Sony, Dwolla, Clearbit, Parrot, Axidraw, Mozilla localForage: all shipped public docs on Slate at various points

These examples are the reason "slate api documentation" still has steady search volume more than a decade after the project launched. The brand association is real. If you can ship docs that even loosely resemble Stripe's, you signal seriousness to developers.

Deploying a Slate site

Once you are happy with the local preview, build the static site with:

bundle exec middleman build

That produces a build/ directory containing a single index.html, the compiled CSS and JavaScript, fonts, images, and any other assets. It is fully self-contained. You can drop it on any static host.

The deployment path the Slate community optimized for is GitHub Pages. Slate ships with the middleman-gh-pages gem preinstalled. The shipped workflow is:

./deploy.sh

That script builds the site and pushes the build/ output to the gh-pages branch of your repository. Within minutes the docs are live at username.github.io/repo. Add a CNAME file and you can point a custom domain at it.

Other deployment options include Netlify (zero config, just point at the repo and set the build command), Vercel, Cloudflare Pages, or any S3 bucket with static hosting enabled. The output is plain HTML, CSS, and JavaScript, so anywhere that serves static files will work.

Slate vs Swagger and OpenAPI tools

The most common comparison search around Slate is Slate vs Swagger. They solve different problems and the distinction matters before you commit to either.

The clean rule: if your team treats the OpenAPI spec as the source of truth, you want a Swagger UI successor like Redoc or Scalar that consumes the spec directly. If you want to write docs by hand with the freedom to add narrative, context, and editorial polish that no spec generator produces, Slate's approach is genuinely different and still valuable.

The tradeoff is staleness. Docs that drift from the actual API are worse than no docs. Slate puts the burden of keeping them in sync on the writer. OpenAPI-driven tools put the burden on the spec, which often lives next to the code.

If you want the best of both worlds, the Slate-flavored workflow that worked for many teams was to use widdershins to convert an OpenAPI file into Slate-compatible Markdown, then layer hand-written narrative on top. It worked, but it added a build step and a meaningful learning curve.

What changed in February 2026

On February 4, 2026, the official Slate repository at github.com/slatedocs/slate was archived. The maintainer, Robert Lord, explained the decision on his blog as a protest against GitHub's parent company Microsoft and its contracts with ICE and the Israeli Defense Forces. A read-only mirror lives at code.lord.io/slate, but the GitHub repository is now frozen.

What that means practically:

• No new releases. Version 2.13.1, shipped January 31, 2023, is the final release
• No bug fixes for Ruby version compatibility as Ruby moves forward
• No dependency upgrades, including security patches for Middleman, Rouge, or the various supporting gems
• No new features
• Forks are still possible, but the ecosystem is fragmented. A few community forks exist, none with the canonical status the upstream repo carried

Slate itself still works. If you fork the archive today and use a compatible Ruby version, you can build and deploy a Slate site this afternoon. The site you produce will look identical to one built six months ago. But the project has stopped moving, and any team picking Slate today is picking a frozen artifact.

This does not make Slate worthless. Static HTML is exceptionally durable. Plenty of production docs sites are still happily running on years-old Slate builds and will continue working for years. It does mean the question shifts from "should I use the best version of Slate" to "is the static output Slate produces still the right answer for my docs in 2026."

When Slate API documentation still makes sense

Three situations where Slate is still a reasonable pick despite the archive:

1. You already have a Slate site and it works. There is no urgent reason to migrate. The output is static HTML and will keep serving traffic indefinitely. Migration is a project. Do not start it without a real reason.
2. You have one stable API and a small team that prefers writing prose to maintaining an OpenAPI spec. Slate's content model rewards careful editorial work. If your docs benefit from voice and narrative more than from auto-generated coverage, Slate's Markdown-first approach is still pleasant to write in.
3. You want maximum control over the rendered HTML and you are comfortable in Ruby. Slate is small enough that you can read the entire codebase in an afternoon. Forking and customizing is straightforward if you know your way around Middleman and SCSS.

In every other situation, the archive is a signal to look elsewhere.

When you should not pick Slate in 2026

The honest cases against Slate today:

• You are starting fresh and your API has an OpenAPI spec. Use a renderer that consumes the spec directly. Scalar, Redoc, and Stoplight Elements are all actively maintained and produce comparable or better output with far less ongoing maintenance.
• You do not want to manage a Ruby toolchain. Ruby is a perfectly good language, but if your team is JavaScript or Python end to end, adding a Ruby build is a real cost. Most modern API doc tools run on Node or ship as standalone binaries.
• You want a tool that is still getting features. The Slate output is good, but it has not improved in years. Newer tools have richer search, multi-version support, interactive consoles, and theming primitives that Slate never had.
• You are a SaaS founder or small team and you want docs that are not just an API reference. Slate is purpose-built for one job: rendering an API reference. If you also need guides, tutorials, a landing page, and a place to put product documentation alongside the reference, Slate becomes the wrong shape of tool. A platform like Docsio generates the full docs site, branded to match your product, from your existing website, and lets you edit everything with an AI agent instead of forking a Ruby project.

Slate alternatives worth looking at

The market has moved on from Slate, and the alternatives now fall into three buckets:

OpenAPI renderers for teams whose source of truth is the spec:

• Redoc: the open-source three-panel renderer most teams reach for after Swagger UI feels dated. Free, MIT, actively maintained
• Scalar: newer entrant, has a built-in API client, modern theming, and is the default API reference in ASP.NET Core 9. Free open-source renderer plus a paid hosted product
• Stoplight Elements: open-source web component that renders an OpenAPI spec into a three-panel reference. Lower configuration than Redoc, easier to embed in an existing site

Docs-as-code platforms for teams that want guides plus reference:

• Mintlify: hosted, opinionated, $300/mo. Strong for dev teams comfortable with Git-based workflows
• GitBook: WYSIWYG, collaborative, $300/mo for comparable features
• ReadMe: API-focused with an interactive console, $349/mo Business plan

AI-generated docs for SaaS founders and small teams who want a docs site without the manual setup:

• Docsio: generates a complete branded documentation site from your existing website URL. The three-pane API reference patterns Slate popularized are baked in. $0 to start, $60/mo per Pro site, custom domains free on all plans

If you came here looking for a free, open-source way to render API docs and you do not have an OpenAPI spec, Slate is still a defensible choice as long as you understand you are forking an archived project. If you came here looking for the easiest path to a published docs site this week, the AI-generated route is a different shape of answer that probably fits better.

Frequently asked questions about Slate API documentation

Is Slate still being maintained in 2026?

No. The official Slate repository at github.com/slatedocs/slate was archived on February 4, 2026 and is now read-only. The last release was version 2.13.1 in January 2023. The output still works, but there are no new releases, no security patches, and no official support. Forks exist, but none have inherited canonical maintenance status.

Is Slate the same as Slate.js?

No. Slate the API documentation generator is a Ruby static site project for rendering API references, originally built by Robert Lord at TripIt. Slate.js is an unrelated JavaScript framework for building rich-text editors, maintained by a different team. They share a name and nothing else. If you searched "slate" looking for the editor framework, the project lives at docs.slatejs.org.

What language is Slate built in?

Slate is built in Ruby on top of the Middleman static site generator. To run Slate locally you need Ruby 2.6 or newer plus Bundler. Slate also ships an official Docker image that bundles Ruby and dependencies so you can build a site without installing Ruby on your machine.

Can Slate consume an OpenAPI spec?

Not directly. Slate is Markdown-first. The community tool widdershins can convert an OpenAPI file into Slate-compatible Markdown, but it adds a build step and the conversion is not perfect. Teams whose source of truth is an OpenAPI spec are usually better served by Redoc, Scalar, or Stoplight Elements, which consume the spec natively.

Is Slate free?

Yes. Slate is open-source under the Apache 2.0 license. You can fork the archived repository, build a docs site, and host it for free on GitHub Pages, Netlify, Vercel, or any static host. There are no usage limits, no paid tier, and no telemetry.

Where can I see a Slate API documentation example?

The default Slate site at slatedocs.github.io/slate is the canonical example. Travis CI's API docs at docs.travis-ci.com/api are a polished real-world reference. Mozilla's localForage docs are another good production example. Stripe's modern docs are no longer pure Slate, but the three-pane layout patterns and visual DNA still trace back to the Slate era.

The verdict

Slate was the right tool for its moment and earned every one of those 36,000 stars. It taught a generation of developers what good API docs look like and made the three-pane layout the industry standard. If you already have a Slate site, you have nothing urgent to do. It will keep working.

If you are starting fresh in 2026, the archive is the deciding factor. Pick a tool that is still moving. For OpenAPI-driven docs, Redoc or Scalar are strong. For docs that need guides plus a reference, a platform that handles the full site, not just the API reference, will save you weeks of setup. The patterns Slate established live on in better-supported successors. That is probably the kindest thing you can say about a piece of open-source software.