Modern apps are API driven. They consume them, they rely on them, and they may even offer their own. Some are used directly; an HTTP request to a REST endpoint. Others rely on a library of code that abstracts the connection away.

When we talk about web service APIs, this library is similar to a Software Development Kit (SDK). SDKs come from more traditional software development. They tools to "hook into" the platform and develop applications. If you are building iOS apps, you'll use the iOS SDK. If you are writing Kotlin apps for android, you'll use the Kotlin and Java SDKs.

What makes an SDK?

While a software development kit can a wrapper around an API, it is often more than this. The meaning of SDK ends with "kit." They are a collection of tools and resources. Traditional SDKs may include documentation, example code, a full integrated development environment (IDE), utilities, device previews, and libraries. They can act as the full pipeline for developing on a platform.

One big advantage of this type of SDK is how connected all the pieces are. The IDE has direct hooks into the documentation and shows examples, making writing code easier. The build tooling can access utilities to optimize the output. You can see this in practice through tools like Xcode or Android Studio. They take the SDK concept in a holistic direction. They offer a complete development experience.

SDK? Library? Framework? Wrapper?

This concept becomes muddled on the web. SDK is the origin, but you will see the terms client, library, or module used when talking about web APIs. Realistically, SDKs do not exist for web APIs in the traditional sense.

An API is an interface into an application. You can think of clients, libraries, frameworks, and wrappers as interfaces for the API. That's right, an interface for an interface. That said, you will still come across libraries for web services that are labeled as SDKs. For example, Firebase offers an SDK for its services, as does Microsoft for many of its Azure services like the Computer Vision SDK.

They often handle authentication and configuration. They also abstract away the HTTP requests by creating a resource-based model. This means instead of targeting an endpoint, users will generally target a feature or dataset.

For example, consider an endpoint that creates a new user from a POST request:

curl -X POST "Content-Type: application/json" \
  -d '{"name":"Alex"}' \

A wrapper around this might look like this:

api.createUser({ name: "Alex" })

When to use an SDK or library

With this in mind, how useful is it to use an SDK when interacting with a third-party web API?

You might want to avoid them if:

  • The API doesn't require complex authentication.
  • There aren't many endpoints/resources.
  • The API uses a format like GraphQL that may not need abstractions.
  • Your app is sensitive toward third-party packages and package size.

A library might be a good choice if:

  • Authenticating with the API is complex. Think secret management, oAuth, etc.
  • The API surface is large and your IDE can benefit from the autocompletion that may come with including a library.
  • You use a "suite" of APIs from the same company. Google is a great example. Rather than interact with each API independently, you can use their libraries to handle much of the shared logic.


SDKs don't exist in the traditional sense for web APIs, even if though some services will call their libraries SDKs. Instead, we have wrappers around the API that make using it more user-friendly. You can use these libraries to make interaction with the API easier and more consistent. If you are building an API and want to offer an SDK or library, it can be a great way to include additional functionality and improve the developer experience for your API consumers.

Even if you use an SDK, there is still room to monitor and react to the inconsistencies of modern APIs. For this, give Bearer a try. Interested in more articles on development, monitoring, and APIs?

You may also like

Ready to take control?

Meet us and start getting out of the blur.