SDK vs API: What It Means When AI Writes Your Code
An API is the service's front door. An SDK is a toolkit that knocks on it for you. Here is how to tell which one your AI coding tool used, and why it matters.
SDK vs API comes down to this: an API is the way a service accepts requests, and an SDK is a ready-made toolkit in your programming language that makes those requests for you. AWS puts it as an API being a mechanism that enables two software components to communicate while an SDK is a set of platform-specific building tools like debuggers, compilers, and libraries. When an AI coding tool adds a payment service, an email service, or an AI model to your app, it either calls the API directly or installs the SDK. Knowing which it chose tells you what you are now maintaining.
The same job done both ways
Here is one job, sending a text message through a made-up service called Acme SMS, written both ways. The service is invented for illustration, but the shape is what you will see for real providers.
Calling the API directly means building the request yourself:
const res = await fetch('https://api.acme-sms.example/v1/messages', {
method: 'POST',
headers: {
'Authorization': 'Bearer ' + process.env.ACME_API_KEY,
'Content-Type': 'application/json'
},
body: JSON.stringify({ to: '+41790000000', text: 'Your table is ready' })
})
if (!res.ok) throw new Error('Send failed: ' + res.status)Using the SDK means installing a package and calling a function:
import Acme from 'acme-sms'
const acme = new Acme({ apiKey: process.env.ACME_API_KEY })
await acme.messages.send({ to: '+41790000000', text: 'Your table is ready' })Same result. The SDK version is shorter because the package already knows the web address, the headers, the error format, and often retries failed calls. The direct version has nothing extra to install, and every line of it is visible to you.
What actually changes in your project
Direct API call | SDK | |
|---|---|---|
Code you write | More, you build and check requests | Less, you call named functions |
Things you install | Nothing | A package that must be kept updated |
Language | Any language that can make web requests | Tied to one language or platform |
When the service changes | You edit your requests | You upgrade the package, sometimes with breaking changes |
Error handling | Yours to write | Often built in, but you must read how |
Debugging | Plain requests you can inspect | One more layer between you and the request |
AWS draws the same line: SDKs are meant to work with a specific programming language or platform, and APIs are more flexible because communication through a protocol works across languages. AWS also notes you can use both, building with an SDK and calling third-party APIs for specific features.
Why AI coding tools reach for the SDK
Models have seen enormous amounts of code that uses popular SDKs, so a fluent-looking SDK call is the path of least resistance. That is fine most of the time. It creates four specific problems that are worth knowing about.
Invented methods. The tool writes a call such as
acme.messages.sendBulk()that looks right and does not exist in the version you installed. The error appears only when that line runs. If a package itself does not exist, see AI hallucinated a package that does not exist.Version drift. The tool writes code in the style of an older release of the SDK, so it fails against the one it just installed. Why AI coding agents keep recommending deprecated packages explains how that happens.
Quiet extra dependencies. Each SDK is another package that can break or become a security risk. Stopping AI coding agents adding dependencies covers how to set that rule.
Hidden behaviour. Some SDKs retry failed calls automatically. That is helpful for a read and dangerous for a payment if the first attempt actually succeeded. Ask what the SDK does on failure before you rely on it.
How to choose between an SDK and an API
Use the SDK when the provider maintains an official one for your language, the feature set is large, and you want authentication, retries, and typed responses handled consistently.
Use the direct API when you need one or two calls, the provider has no SDK for your language, you want zero extra dependencies, or you want to see exactly what goes over the wire.
Be cautious with unofficial SDKs. A package with the provider's name that the provider did not publish is a common route for attacks and for abandoned code. Check the provider's own documentation for the official package name.
Whichever you choose, keep keys out of your code and out of chat. Pasting an API key into an AI chat is a mistake worth reading about before it happens to you.
A short prompt that surfaces the choice
When you ask your tool to add an outside service, add this line: "Tell me whether you are using the official SDK or calling the API directly, give me the exact package name and version, and link the documentation page for the call you used." If you can open the linked page and find the method, you can trust it far more. For the bigger picture of how these tools fit together, see the AI coding tools overview.
FAQ
Is an SDK an API?
No, but an SDK usually wraps an API. The SDK is code you install that talks to the service's API on your behalf.
Do I need an SDK to use an API?
No. Any tool that can send web requests can use an API directly. AWS notes that for an API you typically obtain keys or credentials and send requests to an endpoint.
Which is better for beginners?
The SDK, as long as it is official and your tool names the version it installed. It removes a lot of small decisions. Switch to direct calls only when you have a reason.
Can I use both in one app?
Yes, and most apps do. You might use an official SDK for a payment provider and a plain web request for a small service that has no SDK.
How did this land?
About the author

Staff Engineer, Platform
Carlo works on the platform that turns prompts into running apps. He writes the engineering deep dives and the changelog notes worth reading.


