EMZETT.SDK
In short: Software Development Kit — a bundle of tools, libraries and documentation for developing software for a particular platform or system.
In more detail: Unlike the JDK (specific to Java), “SDK” is a general umbrella term — there are, for example, Android SDKs, iOS SDKs, or SDKs for individual cloud services. Typically contains APIs, compiler/build tools, sample code and often an emulator for testing.
In Depth
An SDK differs from pure API documentation in that it comes with finished, directly usable tools, not just a description of how you could address a service — specifically, usually: client libraries in several programming languages (ready-made code for conveniently calling the API, without building HTTP requests by hand), build and debugging tools, sample projects, and often an emulator/simulator for testing without a real target device (e.g. the Android emulator in the Android SDK).
Platform SDKs (Android SDK, iOS SDK) are usually mandatory for developing for the respective platform at all — without the Android SDK, you can’t build an Android app. Cloud service SDKs (e.g. the SDK of a payment provider or a cloud storage platform), by contrast, are usually optional: the underlying API can also be addressed directly via HTTP without the SDK, but the SDK saves time by already cleanly encapsulating authentication, error handling and data formats.
SDK vs. API vs. library
These three terms are often mixed up, but mean different things: an API is the abstract interface itself (an agreement on how to communicate with a system — e.g. which HTTP endpoints exist). A library is reusable code for a specific task (e.g. a function that parses JSON). An SDK is a larger bundle that typically combines several libraries, tools AND documentation for an entire development area — an SDK usually contains several client libraries for different APIs from the same provider, plus build tools, plus sample code. So you can use an API without installing an SDK (direct HTTP calls), but an SDK almost always comes with code that internally calls APIs.
Version management and breaking changes
SDKs are regularly updated, often with breaking changes between major versions — a new Android SDK version, for example, can introduce new permission models that make existing code incompatible. Larger providers therefore maintain several supported SDK versions in parallel (“deprecation policy”) with an announced deadline until older versions still work, before they’re finally shut down — for developers, this means regularly planning for SDK updates, instead of leaving a once-working integration permanently unchanged.
Example: the Stripe SDK
A concrete example from practice: the Stripe SDK bundles client libraries for several programming languages (Node.js, Python, PHP, Java, among others), which provide type-safe wrappers around the underlying REST API, including automatic retries on network errors, clean error objects instead of raw HTTP status codes, and webhook signature verification — all things you could also implement yourself with raw HTTP requests, but considerably more error-prone and effortful.