Use Cases: How to Make ReadMe Work for You APIs come in all shapes and sizes and while ReadMe is a great documentation solution for whatever kind of API you have, we’ve created this page to help you get the most out of the right features depending on your API’s use case. ✨ Read on for: Common API use cases for ReadMe customers Recommended ReadMe features for your API use case Example customers with a similar API use case already on ReadMe! For API-first companies… Your API is the foundation of your business, so users being able to successfully integrate is critical for both customer satisfaction and overall revenue growth. In your ReadMe hub, you’ll be documenting your core product — your API — which probably means multiple teams will be making updates and turning to your hub as a source of truth: Sales, Support, Product, Engineering, and more. Even more importantly, your developer experience is your customer experience, and your developer hub plays a key role in onboarding and implementation. If you’re an API-first company, we recommend you: Sync your OAS file so that changes to your API update in real time, and set up custom login with variables to populate their API keys directly in your docs Augment your API Reference with Guides that cover other aspects of your product experience: dashboard navigation, billing, or other technical topics beyond your API Build out Recipes for your most common customer use cases (they’re not only discoverable in your hub, but Sales and Support can share links directly with customers too!) Embed a live chat widget or add a clear contact link to reach out to your team, so they can support customers who need help in real time 🔍 Customer spotlight: See how the team at Scale uses ReadMe to create a seamless API onboarding and support experience for their developers here! For APIs used to build custom workflows or integrations with your core product… In this case, your API isn’t your core business, but it’s an important part of how customers work with your SaaS, app, or other product. Customizing internal workflows, syncing data between tools, or building other integrations correlates with product stickiness and revenue retention, so your APIs are still a really important part of your customer experience. Developers reading your docs should be able to quickly grasp what’s possible with your APIs and start building, especially since they might not be your core customer. In fact, it’s very likely that they’re just be helping out another team internally, or maybe they’re a new platform partner building an integration their customers are asking for. Helping them get started quickly and easily is key, as they may know very little about your product and APIs before landing on your docs. In this case, we recommend that you: Enable Try It in your API reference to allow developers to generate code and see what’s happening with their calls in real time, directly from your docs Create a landing page for your developer hub to help orient developers who are new to your docs and add Recipes for your most common custom workflows or integration types Use the glossary feature to call out and define important terms or phrases that may be native to your product, API, or documentation 🔎 Customer spotlight: Check out how Miro uses ReadMe to build out their developer hub to enable teams around the world to integrate with their APIs! For limited access or private APIs If you limit access to your APIs to only certain customers, partners, or employees, it’s critical that you have control over who can see your developer hub. This is particularly common in highly regulated industries like healthcare or finance. For companies in these industries (and many others), data privacy is paramount and where you have to be extra careful about the external developers who can safely access your API and documentation. If you need to limit access to your API: Our Enterprise plan allows you to enable login protection so that you can protect the privacy of your API and documentation With our Enterprise plan you can also decide whether your docs are public, hidden, or log-in protected Learn more about setting up Access Control and the various ways to authenticate your users here 🔎 We can’t highlight ReadMe customers with limited access APIs because, well, those hubs are private! But if you have any questions or want to learn more, don’t hesitate to reach out to our Enterprise team. If you have multiple products but want to house them under one developer hub… If your company has multiple products or multiple APIs, then it makes sense to collectively group them in one developer hub. This keeps documentation for each one separate and organized, while sharing search, navigation, branding, and a global landing page that feel cohesive and make it easy for developers to find what they’re looking for across all your offerings. If you have multiple products with APIs, our best solution for you is ReadMe’s Enterprise plan. With our Enterprise solution, you can easily manage multiple projects — each with their own API reference section — in one easy-to-maintain hub. This way, you can keep your APIs maintained in separate projects but enjoy all the benefits of: A global home for your developer hub, including unified navigation and search across all of your projects, and a customizable landing page to welcome developers to your hub Customizable design that allows you to unify the look and feel across all of your docs Comprehensive admin controls that allow you to easily manage projects, permission levels, and content across all of your projects’ documentation 🔎 Customer spotlight: Enterprise customers like Akamai and Dolby use ReadMe to power personalized and interactive developer experiences for the many developers using their APIs! Don’t have an API? While ReadMe’s bread 🥖 and butter 🧈 is in helping you transform your API documentation into an interactive developer hub, you can still use ReadMe even if you don’t have an API. At its core, ReadMe offers the best documentation solution for allowing teams to collaborate on publishing technical content, especially if your product has a complex implementation or caters to engineers. And by starting out with your technical docs in ReadMe, if — and when — you build an API in the future, you’ve already got a head start 😉