By the Octri team · Updated
What is an SDK? Meaning, parts and examples
An SDK often enters a developer's life as an install command. You add a dependency, import a client and make a call. What disappears from view is the work that makes that call reliable: authentication headers, URLs, serialization, retry policy and the question of what to do when the server says no. Those details are still there. Somebody has made the decisions once so every application doesn't have to make them again.
What is in an SDK?
For a web API, the center of an SDK is a client object and a set of methods that express the API's operations in the language of the application. Around that center are request and response models, a transport, credential handling and error types. A mature client also gives callers control over timeouts and retries, makes pagination manageable, and ships examples that actually compile against the released package.
The parts aren't equally visible. A developer may never think about the HTTP transport until the first timeout, but its defaults shape every call. An SDK's job includes making those defaults understandable and overridable rather than hiding them permanently.
What does SDK stand for?
Software development kit is an old, broad label. The Android SDK is a collection of build tools, platform APIs and utilities because building an Android application requires a toolchain. A payment API's Python SDK is usually an ordinary installable library because the operating system and language runtime are already there.
The word kit survives because developers expect a complete starting point, not merely a helper function that sends JSON.
Two kinds of SDK
A platform SDK helps software run on a platform. It might include compilers, emulators, simulators, native bindings and deployment tools. An API SDK helps software talk to a service. It contains methods for the service's operations and the logic for translating them into HTTP requests.
People often call the second kind a client library. That's accurate. The naming matters less than knowing what the package takes responsibility for and what remains your application's job.
What an SDK call looks like
Creating a customer through an API may look like this at the HTTP layer:
curl https://api.stripe.com/v1/customers \
-u "$STRIPE_SECRET_KEY:" \
-d name="Ada Lovelace"With Stripe's Node.js library, the calling code expresses the business operation instead:
import Stripe from 'stripe';
const stripe = new Stripe(process.env.STRIPE_SECRET_KEY);
const customer = await stripe.customers.create({ name: 'Ada Lovelace' });
console.log(customer.id);The API still receives a request. The SDK decides how the name is encoded, where the credential belongs and how the response is represented. Changing the client library won't make an unsupported API operation suddenly possible, but it can remove a surprising amount of repeated infrastructure code.
SDK vs library vs framework
An SDK can be a library; most web API SDKs are. A framework is different because it generally organizes the application and calls your code at defined points. An SDK is more often a dependency your code calls whenever it needs the remote service.
The boundaries blur. An SDK for mobile payments may include UI components and lifecycle hooks, and a cloud provider may bundle a command-line tool alongside its libraries. Don't choose software by the label on the package page. Look for the particular capability you need, the environment it supports and the cost it adds to your dependency tree.
What an API SDK does for developers
The best way to understand the value is to consider the questions that disappear from the application: Is this request safe to retry? Where does the next page come from? What exception represents a rate limit? Which fields are required? An SDK answers these consistently across dozens or hundreds of methods.
There is a useful account of this shift from Ndeze Bonheur, writing about building OpenWA-Python. In July 2026, Bonheur described starting with the assumption that implementing HTTP requests would be the hard part. The work instead pushed toward naming, module organization, type hints and error handling. It was possible to build a technically functioning client that still required users to guess how to use it. The experience changed how Bonheur approached the API itself, because inconsistencies that are tolerable in isolated endpoints become obvious when you try to present them as one coherent library.
That's an SDK doing something valuable even before anyone installs it: forcing the provider to look at the API through the caller's code.
How API SDKs are made
A team can write every method by hand or generate much of the surface from an OpenAPI description. Generators are effective at the mechanical work: translating paths into methods, schemas into types, and descriptions into editor documentation. People still decide which names feel right in a language and whether a convenience method should combine several network calls.
The distinction is not absolute. A generated core with handwritten pagination helpers or framework integrations can be easier to maintain than either extreme. See generated vs handwritten SDKs for the tradeoffs.
How developers install an SDK
API SDKs normally arrive through the language's package manager. A JavaScript application might use npm install stripe; a Python project might use pip install openai. Pin a tested version in an application's lockfile and keep the SDK's package version separate in your mind from the service's API version.
Before copying a quickstart, check whether the SDK uses an environment variable by default and whether it supports your runtime. A five-line example built for Node.js may be unsuitable in a browser where a secret API key cannot be safely embedded.
Does your API need an SDK?
If a handful of internal scripts call three endpoints, direct HTTP may be perfectly reasonable. When customers repeatedly write authentication, pagination and error-handling code for the same public API, an official client starts to pay for itself.
Consider who maintains the package after launch. A published SDK creates an expectation: new endpoints appear, security fixes arrive and supported runtimes are tested. There is little value in eliminating a developer's first hour of boilerplate if the package then falls behind the API for a year.
What makes a good SDK: a checklist
Try the installation instructions in a clean project. Make a successful request, provoke an invalid request, trigger a rate limit and fetch a multi-page result. Read the returned types and the errors in your editor. Check whether credentials and timeouts can be configured. Finally, compare the SDK's newest methods with the API reference. If the experience survives those tests, the package is more than an attractive quickstart.
SDKs with Octri
Octri's SDK Studio starts from an API description and exposes choices about method naming, client initialization, transport and behavior. That matters because the best SDK surface often requires more judgment than an OpenAPI operationId can provide. A preview can help you assess how a call reads before you publish it to npm or PyPI.
If you're deciding where to begin, how to build an SDK covers the moving parts, while how to generate an SDK from OpenAPI explains the automated route.