SDK vs API
What an SDK Is and What It Adds to an API
SDK vs API: an SDK, or software development kit, is a package of tools that helps developers use a service in a particular programming language. Most SDKs contain a client library, which is code that wraps an API's raw requests in functions and objects. An API, by contrast, is the set of endpoints and rules a service exposes to any software that can send HTTP requests. For the basics, see what an API is.
Calling an API directly means building each request yourself: setting the URL and method, adding authentication headers, converting data to JSON, handling errors and parsing the reply. An SDK does much of this work. A developer might call a single method such as createAccount and receive an object with named fields, while the library handles authentication, serialization and common error cases.
SDKs often include extras such as pagination helpers, retry logic, sample code and command-line utilities. The API is still the underlying service. The SDK is a convenience layer on top of it.
When to Call the API Directly and When to Use an SDK
Neither option is always better. The right choice depends on the language, the task and the team's priorities.
- An SDK suits most application development, because it is faster to start with, follows the conventions of its language and usually receives updates when the API changes.
- Calling the API directly suits unusual situations, such as a language with no official or community SDK, a small one-off script or an environment where adding a dependency is difficult.
SDKs also have costs. They add a dependency that must be kept up to date, they can lag behind new API features, and a poorly maintained community library may stop working. Before adopting one, check when it was last updated and whether the API provider publishes it.
Some SDKs are generated automatically from a formal API description, such as an OpenAPI document. Generated code tends to cover every endpoint, but it may feel less natural to write with than hand-crafted code.
A Reseller Script Using a Hosting Provider's SDK
A web agency writes a script that creates staging sites for its clients on a hosting provider's platform. The provider offers an SDK for the agency's language, so the developers write a few lines that call the library, passing in their key from a protected configuration store.
The library takes care of signing requests, retrying a request that failed because of a brief network problem and turning error responses into exceptions the script can catch. When the provider adds a new option for site creation, the agency updates the SDK and uses the option, instead of rewriting request code.
Later, the agency needs to call one new endpoint that the SDK does not yet cover. Because the API is documented, the developers call it directly with the same key, so the project does not stall while the library catches up. For what hosting APIs usually expose, see hosting provider APIs.
Frequently asked questions
Is every SDK made by the API provider?
No. Some are published by the provider, some are written by the community and some are generated from an API description. Provider-maintained SDKs are usually the most reliable starting point, but any SDK should be checked for recent updates and clear license terms before a project depends on it.
Does using an SDK change how authentication works?
No. An SDK still sends the same credentials to the same API, and the API decides what the caller may do. The SDK simply formats the request for you. Keys should still be kept out of source code and stored in protected configuration, because anyone who obtains a key can use it through an SDK just as they could with a direct call.