SDK stands for software development kit, and it’s not the same thing as an API. The API is the interface a company exposes. The SDK is a helper package that makes that interface easier to use in a specific programming language.
Think about assembling office furniture. You could buy raw lumber, measure everything, and drill every hole yourself. Or the manufacturer gives you pre-cut pieces, labeled screws, and a tool that fits the bolts. You’re still building the furniture, the kit just saves you from starting with raw materials.
A payment company’s raw REST API might make you build each request by hand, set headers, format JSON, and parse the response. Its SDK wraps that into simpler code, so instead of constructing every request you write something closer to “create customer” or “refund payment.”
How it shows up
SDKs are usually installed as a dependency, so your project relies on someone else’s package. That’s normal, and it’s why versioning, docs, and supply chain safety matter. For agents this matters because they write code fast: if an SDK exists, the agent may use it instead of hand-building every call. That’s good when the SDK encodes the product’s patterns, and it goes wrong when the agent uses an old version or invents a method name.
Why you care
Tell the agent which SDK version and docs to follow when it matters. Don’t just say “connect to Stripe” and hope. An SDK turns raw API wiring into a usable kit, but you still need to know what you’re asking it to build.