Best Practices for Navigating an API's Documentation
Tags: api, documentation, beginners
Published: 2019-12-17 18:37:41

_(This article originally appeared on [Bearer.sh](https://www.bearer.sh/blog/best-practices-for-navigating-api-documentation))_

At Bearer, we read tons of API documentation (docs). The good, the bad, and everything in-between.

Along the way, we've learned a few techniques to get the most out of an API's documentation in the shortest period of time. After all, your focus should be on building _your_ app, not struggling with someone else's.

Here are some ways our team approaches understanding a new API's documentation.

## Start with the overview

The overview is always a good place to begin. This is often the landing page of the documentation. It has guidance on basic usage, authentication methods, common errors, and any quirks or unique aspects to the API. You'll want to make note of the following in particular:

- **Guides**: Great documentation highlights common use cases. These range from sample apps, quickstart guides, and even deep dives into more complex aspects—like authentication.
- **Authentication**: The authentication section is a great place to understand the authentication procedures and requirements of an API. There are [three common ways of authenticating an API](https://www.bearer.sh/blog/the-three-most-common-api-authentication-methods). Each with pros and cons. Becoming familiar with them will help you measure how long it's going to take before making your first API call.
- **The Base URL**: For REST APIs, this will be the foundation for all your endpoints. For GraphQL APIs, this is the root endpoint that you'll send all requests to.
- **Rate Limiting**: The usage guidelines for how many requests you can make in a given time, the rate limits of APIs can vary wildly. Depending on your business needs, you may need to contact the provider to request more access, but when developing it is useful to see any initial limits you may run into.

![stripe-docs](https://blog.bearer.sh/content/images/2019/12/stripe-docs.png)

Stripe's docs are a great example of starting with the common use cases and guiding users.

<!-- The resources / endpoints / methods / reference -->

## Find and save the API reference

As many API providers shift toward more "use case" approaches to documentation, it is still valuable to keep the API reference section on hand. This portion of the _docs_ contains a complete list of methods and endpoints, along with their request and response objects. Sometimes this will be referred to as the API reference, the list of endpoints/resources, or the method reference.

**REST APIs** will normally provide a list of endpoints and their available actions, or a list of resources and their available methods.
![google-cal-api-docs](https://blog.bearer.sh/content/images/2019/12/google-cal-api-docs.png)
Google Calendar's API reference focuses on the methods of each resource such as `get`, `list`, and `delete` for the CalendarList instead of a list of endpoints and HTTP Verbs.

**GraphQL APIs** focus more on types, query methods, mutation methods, and any custom additions on top of the GraphQL spec.
![shopify-storefront-api](https://blog.bearer.sh/content/images/2019/12/shopify-storefront-api.png)
[Shopify's GraphQL Storefront API](https://help.shopify.com/en/api/storefront-api/reference) provides each query and mutation available, as well as custom scalar types.

## Take advantage of the "Explorer" or console

Many APIs will include an _API Explorer_, sometimes called the _console_. This allows you to perform calls against the API's resources as you view the documentation. Think of it as a no-code approach to exploring an API.

Explorers are a very powerful way of helping developers get used to a new endpoint, the required parameters, and how the response will be structured. As you begin to integrate an API, it is the easiest way to run a quick request and validate the API response. No need to open your IDE or launch Postman and configure authentication.

![google-explorer](https://blog.bearer.sh/content/images/2019/12/google-explorer.png)
On Google's APIs, the explorer lives alongside each resource.

![github-api-explorer](https://blog.bearer.sh/content/images/2019/12/github-api-explorer.png)
[GitHub's v4 GraphQL API Explorer](https://developer.github.com/v4/explorer/) uses a [graphiql](https://github.com/graphql/graphiql) style UI to let you experiment with the API, and view references in one place.

## Some features we love

Our favorite documentation sites put the user first.

### Code Examples

![twilio-split-docs](https://blog.bearer.sh/content/images/2019/12/twilio-split-docs.png)
[Twilio](https://www.bearer.sh/integrations/10/twilio-sms-api) takes the split approach in showing information about a resource alongside code examples in a variety of languages.

### User-specific data

![airtable-custom](https://blog.bearer.sh/content/images/2019/12/airtable-custom.png)
[Airtable](https://www.bearer.sh/integrations/24/airtable-api) requires you to log in, but once you choose your "base" (their name for a table or board), all the documentation will directly reference that base and it's properties.

### Inclusive Language

![eventbrite-api-docs](https://blog.bearer.sh/content/images/2019/12/eventbrite-api-docs.png)
It can be easy to forget that not all developers know everything about every domain. The [Eventbrite API](https://www.bearer.sh/integrations/40/eventbrite-api) doesn't assume you know everything and even goes so far as to explain what an API is.

### Methods of feedback

![stripe-feedback](https://blog.bearer.sh/content/images/2019/12/stripe-feedback.png)
Providing a user for a way to say "hey, this didn't work" makes everyone's life easier. [Stripe](https://www.bearer.sh/integrations/2/stripe-api) is one of the many API providers that offer an easy way to let them know if part of their documentation was helpful.

![twitter-feedback](https://blog.bearer.sh/content/images/2019/12/twitter-feedback.png)
The [Twitter API](https://www.bearer.sh/integrations/74/twitter-api) does the same on its pages. Selecting a negative response gives you a quick way to provide feedback.

## Take it from here

Starting with a new third-party API is a big endeavor. The faster you can get it integrated, the sooner you can assess the impact it will have on your application.

Stay tuned for more articles on learning APIs in the future.

<!-- Include on external crossposts -->
<!-- Want to skip the authentication step and use a single client for all your third party APIs? Take a look at [Bearer](https://bearer.sh) -->

_Discuss this article on Twitter and ping us [@BearerSH](https://twitter.com/BearerSH)._