APIs Categorized by Access Type: The 7-Minute Guide

We recently looked at different types of APIs, but we were primarily interested in categorizing them by design pattern (such as REST, GraphQL, SOAP, and RPC). There is a different way to view APIs, and that is by access type.

Categorizing APIs by access type means we are looking at who can access the API. These broad categories completely disregard languages, protocols, and design patterns.

Understanding access types is beneficial if you are planning an API for your app and need to determine what access type provides your API users with the greatest benefits while maintaining needed data security.

We'll look at four types of APIs, one for internal and three for external use.

Here are the types of APIs by access type:

• Private APIs (internal)
• Partner APIs (external)
• Public APIs (external)
• Open APIs (external)

Now, let's look at each type in turn.

Private APIs

In one way, these are the simplest type of API to describe. In another way, they are the hardest. The simple part comes from these APIs only being accessible within a company's network. They are sometimes referred to as internal APIs for that reason. The hard part comes because they often don't follow standard development rules, are not as concerned with security, and don't need to be as polished as their partner or public API counterparts.

However, private APIs drive internal integration automation, which is critical to a business's health and overall effectiveness. This makes them very important within the enterprise but not something for which we can provide a list of examples. Internal APIs can include APIs provided with software you buy or subscribe to and APIs your devs build for custom or bespoke systems unique to your company.

Takeaway: Private APIs provide internal access to apps within the enterprise.

Partner APIs

Partner APIs are for trusted business partners. Because of this, access to partner APIs is more restricted than to open APIs or public APIs. These APIs also have rules governing their use which partners must agree to before gaining access. Partner APIs may be entirely free, or they may have access or usage fees.

When we say there are "rules" for partner APIs, what does that mean? The API owner wants to ensure that its API is used securely. The rules define standards and procedures to ensure valid authentication and authorization.

Partner APIs are a necessary piece of the app ecosystem for those SaaS companies that act as data hubs for their business partners.

Current examples of partner APIs are as follows:

• eBay (buying, selling, and everything else)
• Shopify (view financials and manage apps, themes, and jobs)
• Amazon (orders, shipments, payments, and more)

Takeaway: Partner APIs provide external access to business partners according to partner agreements and rules.

Public APIs

Public APIs occupy a middle ground between open APIs and partner APIs. Like open APIs, they are accessible to everyone. But, like partner APIs, you must follow the rules to use public APIs. And, unlike open APIs and many partner APIs, some public APIs will charge you for their use. The charges may vary considerably, depending on the API and what you are trying to use it for. But, to keep things exciting, other public APIs don't charge, making them look like open APIs. Some don't distinguish between open APIs and free public APIs, but we believe that a free public API's rules set it apart from an open API.

Because public APIs are accessible to anyone (like open APIs), they tend to be as close to bulletproof as we can find. Users of all different skill and ability levels will use and abuse them – and expect to get their money's worth, even if they didn't pay a dime.

Current examples of public APIs are as follows:

• Slack (query data from and send data to workspaces)
• Wolfram|Alpha (integrate computational knowledge into your apps)
• Gmail (read and manage mailbox data)
• Spotify (get metadata for artists, albums, and tracks)

Takeaway: Public APIs provide external access to public users in accordance with agreed-upon rules.

Open APIs

Open APIs are the closest thing to completely free APIs that exist. You don't need to pay the owner/host of the API to connect, though you may be paying for whatever system you use to make the connection. As a result, anybody can make use of open APIs. You don't need to sign-up or agree to specific rules.

And here's where the first bit of API confusion comes into play. OpenAPI (with no space) is a specification for self-documenting REST APIs. While it is possible to have an open API using OpenAPI, the open API could just as easily be using any other API specifications (or no proper spec at all).

The second confusing thing about open APIs is that while they may be open source, they don't have to be. An API might be built with proprietary code, yet the data accessible via the API may be free to access. This would make it an open API even though it uses "closed source" code.

Open APIs are used today to provide access to many different datasets. Current examples of open APIs are as follows:

• Archive.org (the internet, as of last week)
• Data USA (public data for the United States)
• JSONPlaceholder (test data for developers)
• reddit (everything on reddit)

Takeaway: Open APIs provide external access to everyone without agreements or rules.

What about composite APIs and unified APIs?

Neither the composite API nor the unified API is defined by access type, placing them in a class by themselves. However, you might see these referenced along with APIs by access type, so it's worth addressing them briefly in this context.

In general, an API is a data broker. An app or service asks an API for data (and receives it), offers data to the API (which accepts it), or does both. For each of these three scenarios, data passes through the API. But the API is not acting upon the data other than passively, such as ensuring that queries are valid.

For both the composite API and the unified API, the API becomes more than a data broker. It actively organizes the queries (composite) or the underlying system schemas (unified) to interact with the requests to the API and the results received from it.

• A composite API composes several sequential API requests into a batch and processes it as a single request. As a result, everything is returned in a single response.
• A unified API places an additional layer of programming functionality on top of any number of APIs and simplifies the data schemas for those underlying systems.

Every composite or unified API is also an open, partner, private, or public API.

Which type of API should you use?

You and your team are already using many different APIs. And, when it comes to working with APIs set up by others, you don't have much choice but to use what is available.

However, you do get to define the access type when setting up a new API for your app. You'll want to take your users into account, but it's better to start with strict security and then relax it as needed. Few users mind gaining greater access over time, but many of them would become disappointed if the data they previously accessed for free suddenly came with a price tag.

If you'd like to see more content on APIs and other integration topics, follow us on LinkedIn or Twitter.