What should we check before relying on one?

When it last changed, whether it covers the parts of the service you need, whether it supports the current version, and how quickly reported problems get answered. Those four take ten minutes together and are a better predictor of the integration experience than any amount of marketing material.

Does using one lock us in?

A little, and manageably. Code written against one provider's kit does not move to another without work, so anything you might plausibly switch is worth writing behind a thin layer of your own. That is a small discipline at the start and the difference between a week and a quarter later.

What if none exists for our language?

You work against the published interface directly, which is what the kit does anyway, and you take more care over retries, failures and credentials because nobody has taken it for you. It is a real cost and a predictable one, and worth including in an estimate rather than discovering during.

Glossary

SDKsoftware development kit

An SDK is a bundle of ready-made code a provider publishes so that developers can use its service without writing the connection, the error handling and the retries themselves.

In plain terms

Fittings supplied with the pipe. Everything an SDK does could be done by hand against the published interface, and the point is that nobody has to. Signing in, retrying sensibly, turning replies into something the surrounding code can use, and keeping up when the provider changes something are all handled for you already.

Why it matters

For anybody deciding rather than coding, it is a reasonable proxy for how much work an integration will be. A provider offering a well-maintained kit in the language your team uses has removed a week or two of unglamorous effort and, more importantly, has removed a week or two of subtle mistakes around retries and failures. A provider offering none, or one nobody has touched in a year, is telling you something about the size of the job.

How it works

It wraps the published interface rather than replacing it. Everything remains possible without one, which matters because it means an unsupported language or an unusual requirement is inconvenient rather than impossible. The kit is a convenience with the same capabilities underneath.

The valuable parts are the ones nobody enjoys writing. Handling a refusal for asking too quickly, retrying with increasing pauses, recognising which errors are worth another attempt, and keeping credentials out of places they should not be are all easy to do badly and are usually done properly here.

Each one is tied to a language and a provider, which is the small lock-in. Code written against one provider's kit does not move to another's without work, so anything you might want to switch is better written behind a thin layer of your own. That is a modest discipline with a real payoff at renewal time.

Maintenance is the signal worth reading. When did it last change, does it support the current version of the service, are reported problems answered. Those questions take ten minutes and tell you more about what integrating will be like than any documentation page does.

The same integration, with and without one

Every line on the right is something a competent developer can do, which is why the absence of a kit is a cost rather than an obstacle. The reason the left column is worth paying attention to when choosing a supplier is that the items on it are precisely the ones people rush. Sign-in gets hardcoded, retries get written as a loop with no pause, failures get treated as one undifferentiated category, and none of that shows up until the day traffic is heavy or the provider is briefly unavailable. A maintained kit has usually had those decisions made carefully once, by somebody who saw what went wrong for everybody else. That is the real saving, and it is larger than the week of typing it also removes.

Seen in the wild

Reach a service through a step that has already handled the sign-in and the retries, which is the same convenience without anybody writing code.
n8n
Compare using a routing service's published kit against making the requests directly, and notice what disappears: the retries, the errors and the credential handling.
OpenRouter
Use a generic request step for a service with no kit at all, which is the fallback and is perfectly workable with more care.
Make

Common misconceptions

People assume

Without one we cannot integrate.

In fact

You can, against the published interface directly, which is what the kit is doing underneath. The absence means more work and more opportunities to handle failures badly, not a closed door. It is a cost to price rather than a blocker.

People assume

It is only a developer's concern.

In fact

Whether one exists, in your team's language, and whether it has been maintained recently, are three questions that predict how long an integration takes and how well it behaves under load. Those are budget and timeline facts, and they are answerable in ten minutes by somebody non-technical.

Telling them apart

SDK vs API

SDK

A convenience layer in one language, wrapping the route and handling the tedious parts. Optional, and specific to a provider.

API

The published route itself, language-independent, and the thing every kit is built on top of.

The interface is the contract and the kit is a helper. If a kit does not exist for your language, the contract still does, which is why the absence slows a project rather than stopping it.

Questions

What should we check before relying on one?: When it last changed, whether it covers the parts of the service you need, whether it supports the current version, and how quickly reported problems get answered. Those four take ten minutes together and are a better predictor of the integration experience than any amount of marketing material.
Does using one lock us in?: A little, and manageably. Code written against one provider's kit does not move to another without work, so anything you might plausibly switch is worth writing behind a thin layer of your own. That is a small discipline at the start and the difference between a week and a quarter later.
What if none exists for our language?: You work against the published interface directly, which is what the kit does anyway, and you take more care over retries, failures and credentials because nobody has taken it for you. It is a real cost and a predictable one, and worth including in an estimate rather than discovering during.

Key takeaways

It is ready-made code wrapping a provider's published route, and everything remains possible without it.
Its value is the unglamorous parts: retries, failures, credentials and keeping up with changes.
It ties code to one provider and one language, which is worth isolating behind a thin layer of your own.
How recently it was maintained predicts the integration experience better than documentation does.
Its absence is a cost to price rather than a blocker.

Tools that use this

n8n
The same conveniences, with nobody writing code.
OpenRouter
Published kits against direct requests, where the difference is visible.
Make
A generic request step for services with no kit at all.

Last checked July 2026

All glossary terms