By Roman Hotsiy
Originally published at medium.com/redoc-ly/from-redoc-to-redoc-ly on Apr 26, 2018
Today we’re announcing the next evolution of ReDoc. In this article, I will explain why and what “Redoc.ly” is.
As you probably know ReDoc was developed by Rebilly which is a payment/subscription company. Their main product is an API and it has a lot of endpoints and advanced payloads. They struggled to keep their docs up to date and that’s why they adopted OpenAPI (Swagger back then). Their API definition ended up using lots of advanced features from OpenAPI spec which were not supported by open-source or commercial documentation engines. So the idea of ReDoc as an engine for Rebilly Documentation was born.
ReDoc prototype proved that we can generate OpenAPI-powered documentation without introducing any vendor-specific extensions. It was generic enough to open-source it.
Since then, we’ve had lots of community engagement. Over 2500+ stars. 300+ issues, 63 PRs, and lots of articles mentioning ReDoc. It was adopted by many companies, and I even received a few testimonials to my personal email 💌. We’re very grateful for the interest and adoption.
We hooked up Jenkins continuous integration server to build the ReDoc rendered API docs for both the working branches (we called these previews) and the mainline branch (our master). Then, we created an initial proposal for the API.
ReDoc development is now driven by community needs. It has overgrown only Rebilly’s needs and has now become a standard for 3-panel OpenAPI powered documentation.
In the last year, I’ve received dozens of emails from different companies asking for customizations, some of which are beyond ReDoc as an open-source project and other are not possible to implement inside ReDoc as a single-page widget.
Many of those requests are similar in nature so we see the opportunity for a self-contained product around ReDoc. With this idea in mind, Rebilly founder Adam Altman and I decided to start a spin-off company called Redoc.ly with a mission to democratize API documentation portals.
ReDoc is what many companies start their API portals with but sooner or later everyone needs to have other pages like: introduction, tutorials, glossary, changelog, FAQ, etc. That’s what an API portal consists of according to industry standards.
Our vision is to create a solution for API documentation portals with the following design principles:
developer-friendly (docs like code) — markdown-powered, integrated with git (Github, Gitlab, Bitbucket)
fully-customizable — can customize parts of the site, whole pages, or even use custom widgets inside markdown
no vendor lock-in — open-source with commercial license, with your content housed in your preferred source control.
We want to go beyond markdown-based documentation and leverage the full power of OpenAPI to make it more interactive, user-friendly and easier to maintain.
We started working on it a while ago and since then we’ve accomplished the following:
incorporated and raised a small seed round
rewrote ReDoc in React as a base for the future product
built a prototype and tested it out internally
We are working on the prototype which we plan to release in a few months.
To better understand what should land in the first release we want to ask you which features you think are essential for an API documentation portal. Use the link to the short survey below:
Stay tuned by subscribing to RedocLy twitter.
Hello world, our mission is to perfect the API Developer
ReDoc was born out of frustration with rendering my OpenAPI definitions for API reference docs. Developer documentation is very important to a developer’s experience.
How API-First Design Helped Win a $22m Enterprise Deal
By the time ReDoc was released in 2015, I was more comfortable with the OpenAPI (fka Swagger) specification. We had a system to structure our API definitions…