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
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 — they may 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
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 where 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.
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
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 😉