Software Development Kits

Providing code snippets, libraries, and full software development kits, or simply SDKs is considered standard operating procedure for APIs. Generating SDKs from OpenAPI has become common, and providing all of the top programming languages is expected by developers, making SDKs one of the essential API building block for any API operations.

Also known as: SDK, Client Library, Client, Bindings

Example

- type: SDKs
  url: https://developers.example.com/sdks

Standards

OpenAPI Initiative OpenAPI Specification 3.1
Project OpenAPI Generator
SemVer Semantic Versioning 2.0.0
Linux Foundation SPDX License List
ISO/IEC 5962 SPDX Specification
Package registry npm package.json
PyPA PyPI Core Metadata 2.3
Apache Maven Maven POM Reference
NuGet NuGet .nuspec
Go Project Go Modules Reference

OpenAPI Expression

info.contact (OpenAPI 3.x) — Often points to the SDK repository or maintainer.
externalDocs (OpenAPI 3.x) — Frequently used to link to the SDK index page.
info.license (OpenAPI 3.x) — License of the API description; SDKs typically carry their own SPDX identifier in package metadata.
x-codeSamples (Redoc / Redocly vendor extension) — Per-operation code samples in target SDK languages.

Link Relations

service-desc — IANA Link Relations

Governance Rules

info-contact (Spectral built-in) — `info.contact` must be present so SDK consumers can reach maintainers.
info-license (Spectral built-in) — `info.license` must be defined.
operation-operationId (Spectral built-in) — Every operation needs a unique operationId — SDK generators map these to method names.
operation-operationId-unique (Spectral built-in) —
operation-tag-defined (Spectral built-in) — Operations must be tagged consistently; many generators group methods by tag into namespaces or files.

Risk & Compliance

Compliance:

Export controls — SDKs that include or call cryptography may be subject to EAR/Wassenaar review
Open-source license compatibility — SDK license must be compatible with bundled transitive dependencies

Security: SDKs are a software-supply-chain surface. Signed packages, reproducible builds, SBOMs (SPDX/CycloneDX), and pinned transitive dependencies reduce typosquatting and dependency-confusion risk. SDKs that bundle credentials, telemetry, or auto-update behavior need explicit user disclosure.

Tools

OpenAPI Generator — SDK generator (Apache-2.0)
Speakeasy — SDK generator
Fern — SDK generator
Stainless — SDK generator
Kiota — SDK generator (MIT)
liblab — SDK generator

Suggested Metrics

sdk_language_coverage — Number of officially supported SDK languages.
sdk_release_lag_days — Days between an API release and matching SDK release across languages.
sdk_weekly_downloads — Package-manager download counts per language.
sdk_open_issues — Open issues and median time-to-close across SDK repos.
sdk_breaking_change_rate — Major-version bumps per quarter; high values erode integrator trust.

Example Implementations

Stripe — Eight+ official SDKs (Ruby, Node, Python, PHP, Java, Go, .NET, iOS, Android) maintained in-house.
Twilio — Multi-language helper libraries generated from internal API definitions.
AWS — SDKs across 10+ languages with consistent service/client patterns and SBOMs.
GitHub — Octokit family of SDKs covering REST and GraphQL surfaces.