SDK / Client Library
The vendor's package for your language that wraps their API in normal function calls, so you stop hand-building HTTP requests.
See it
What it is
An SDK (or client library) is the vendor's package for your language that wraps their HTTP API in ordinary functions. Instead of building a request with headers, a JSON body, and hand-rolled error handling, you write 'stripe.customers.create({ email })' and get a typed object back. The library carries the boring correctness for you: auth headers, retries with backoff, pagination helpers that auto-follow cursors, typed error classes, and often webhook signature verification.
Install the official one when it exists and you are calling from a server. Drop to raw fetch when the SDK is a 200 kB dependency for the one endpoint you need, when it lags behind an API feature you want, or when you are on an edge runtime the SDK does not support. Community SDKs are fine, just check the last publish date before you build on one.
Two traps. Server SDKs expect a secret key, so importing one into client-side code either fails to build or, much worse, ships your key to the browser: use the browser-safe package or an API proxy instead. And the SDK version is not the API version, so a major upgrade of the package can quietly move you to a new API version with renamed fields. Pin the version and read the changelog before bumping.
Ask AI for it
Replace these hand-written fetch calls with the official SDK for this service. Install the package, initialize a single shared client in a server-only module with the key from process.env, and swap each call for the equivalent SDK method with typed inputs and outputs. Use the SDK's auto-pagination helper for list calls, catch its typed error class instead of checking status codes by hand, and pin the exact package version in package.json. Keep the module server-side so no key reaches the client bundle.