slatedocs

slate

Web Development2013–2021

slatedocs / slate · Archived

slate

Beautiful static documentation for your API

Web Development Learning & Reference

Explore on GitHub Read Hacker News discussions

38Distinct people

41Mentions

1Explicit recommenders

36KGitHub stars

REPOSITORY AT A GLANCE

What to know before exploring

What it is

Beautiful static documentation for your API

GitHub

Where it is used

No documented product use was verified in the last source check.

What people are saying

I love middleman. I'm using it (via a modified version of Slate docs [1]) for all of our documentation at Catalyze [2]. 1.) https://github.com/tripit/slate 2.)…

ryanSrich used a recommendation phrase. One indexed comment matches. This is a phrase match, not a verdict.

No classified warning is attached to this page. Read the discussions before treating silence as approval.

Also in these discussions

No other repository is repeatedly linked in the same discussions.

This week on Hacker News

Nov 8–Nov 15 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/15/2026, 7:24:48 PM UTC.

No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.

Mentions over time

HN mentions by year41 dated mentions

Observed mentions: 2013-10-16 21:24:53 UTC to 2021-05-25 17:02:21 UTC.

Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.

View mention counts and date ranges

UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
Period	Start (UTC)	End (exclusive, UTC)	Mentions	Submissions	Comments
2013	2013-01-01 00:00:00 UTC	2014-01-01 00:00:00 UTC	1	1	0
2014	2014-01-01 00:00:00 UTC	2015-01-01 00:00:00 UTC	6	3	3
2015	2015-01-01 00:00:00 UTC	2016-01-01 00:00:00 UTC	10	1	9
2016	2016-01-01 00:00:00 UTC	2017-01-01 00:00:00 UTC	4	0	4
2017	2017-01-01 00:00:00 UTC	2018-01-01 00:00:00 UTC	9	3	6
2018	2018-01-01 00:00:00 UTC	2019-01-01 00:00:00 UTC	2	0	2
2019	2019-01-01 00:00:00 UTC	2020-01-01 00:00:00 UTC	4	1	3
2020	2020-01-01 00:00:00 UTC	2021-01-01 00:00:00 UTC	3	2	1
2021	2021-01-01 00:00:00 UTC	2022-01-01 00:00:00 UTC	2	0	2

What Hacker News says

10 sources

wise_young_man·Dec 22, 2015

There's an open source project called Slate [1] which is basically a static site generator for API docs you might consider which looks like Stripe's API docs. [1]: https://github.com/tripit/slate

In I analyzed 250 SaaS pricing pages

niftylettuce·Dec 9, 2015

Looks like they use https://github.com/tripit/slate

In NASA Open APIs

kimh·Jun 11, 2015

If the site looks cool and slick to you, then you should give a star to https://github.com/tripit/slate which I used to create the site. I found Slate is very easy to use and customize!!

In Show HN: Clojure by Example

anonfunction·Apr 10, 2015

Lot's of people seem to like https://github.com/tripit/slate

In Ask HN: What do you use for internal API docs?

simi_·Mar 13, 2015

I've looked at a lot of documentation systems and ended up using Slate too, it's pretty great. https://github.com/tripit/slate

In Fidor Bank API

ryanwjackson·Mar 11, 2015

The docs are an awesome repo by TripIt (https://github.com/tripit/slate). They aren't perfect, but they get you pretty far pretty quickly. Not sure what you mean by "links between your resources." Have an example? May be there (or we can build it if not). Correct on Unix time. Just being extra redundant.

In Show HN: Paid, an API for invoicing

mataug·Jan 22, 2015Submission

Beautiful API Docs

1 points · Open discussion

gamache·Jan 19, 2015

There have been an explosion of API specification formats in the last few years. No clear winner has emerged. JSON Schema and JSON Hyperschema are JSON-based formats for describing JSON and REST (hypermedia-driven) APIs. The formats make decent sense and can be used to generate docs, validators, client libraries, UIs, and more. http://json-schema.org/ API Blueprint is another emerging format for API description. It's written in Markdown, so it is very human-readable and -writable. It is not yet suitable for hypermedia APIs. Like JSON Schema, its tooling includes validators, client library generators, mock server generators, docs generators, etc. http://apiblueprint.org/ Swagger is a YAML-based format for specifying JSON APIs. It is meant to be created using the Swagger UI, rather than handwritten. It generates pretty docs, client

Read the rest

software, etc. but is not suited to describing hypermedia APIs. http://swagger.io Slate is an API documentation framework/template, designed to generate very handsome documentation pages. Its concern is more documentation than specification, and therefore doesn't concern itself with things like library or mock generation. https://github.com/tripit/slate WADL is an API description language which describes API interactions in an XML format. It resembles WSDL. Not many people use it. http://en.wikipedia.org/wiki/Web_Application_Description_Lan... Which of these is the best? Good question. I like JSON Hyperschema, but I am writing hypermedia APIs and the other formats here are lacking in their hypermedia support. API Blueprint is a nice format to write in a text editor and is easily read as-is or rendered from Markdown; no separate docs generator is necessary.

In Ask HN: What's the best way to write an API spec?

simi_·Jan 19, 2015

We tried a lot of options at Lavaboom (including apiary, readme.io, swagger, etc) and ended up using Slate: https://github.com/tripit/slate

In Ask HN: What's the best way to write an API spec?

conorgil145·Jan 6, 2015

I personally found this write up extremely interesting and exciting. I have always been interested in documentation and its order in the priority list of tasks which a development team has to tackle. It is not an original observation that documentation is critically important to the success of a project/code-base and yet it is often the last artifact produced (and many skip it altogether). I have recently been extremely interested in the idea that documentation should be moved to the top of the priority list and, rather than being a duplicative post-processing step, should be the "ground-truth" for generating lots of the follow on artifacts. For example, write API documentation first and use that to generate client side libraries, an API test suite, and server boiler plate code/skeleton. In my search for existing projects and approaches,

Read the rest

I came across many interesting things. Swagger: https://helloreverb.com/developers/swagger API Doc: http://apidoc.me/doc/gettingStarted Slate: https://github.com/tripit/slate Write the Docs: http://docs.writethedocs.org/ It was very interesting to read this GitHub post because they presented yet another approach to treating documentation as a first class citizen with different methods to write docs, host docs, and keep the docs updated. I recently updated the API docs at my workplace to use the Slate tool I referenced above. We manually write docs in a Markdown file, manually use Slate to compile the MD file into HTML, and then manually deploy it to our host. This is approach is incredibly basic and non-scalable, but is light years better than what we had previously, which was API docs directly in the repo's README file. I hope to learn more about the projects listed above (and many others!) as I explore different approaches for treating docs as a first class citizen and pick the approach which meets the requirements of my current team. [EDIT] I am also anxiously awaiting a beta invite for http://readthedocs.com

In How GitHub Uses GitHub to Document GitHub