Adapters

What an adapter is, the four that ship, what each can and cannot do in one table checked against the code, and how much of each vendor's API is covered.

An adapter is the part that knows one vendor. It describes each request and maps the response to the SDK’s records. It never retries, sleeps or walks pages: createOutbound does that around it, the same way for every vendor. You pass one adapter to createOutbound and call the same methods whichever vendor is behind it (see usage).

Each vendor adapter has two layers: normalized reads that mean the same thing on every vendor, and a typed native catalog of the vendor’s own reads for everything else.

The adapters

combine from outbound-sdk/combine puts several of them, or several keys for one of them, behind one instance.

Every vendor factory takes the same core options:

Constructing an adapter makes no request.

How far each is verified

One line each, from what is verified, which is the page to read before relying on a number:

• Instantly is beta: its reads were run, read-only, against one live workspace on 2026-11-14.
• HeyReach is beta: its reads were run, read-only, against one live workspace on 2026-11-14.
• Smartlead is unverified: written from Smartlead’s public documentation and tested offline only.
• In-memory is stable: it has no vendor behind it.

outbound.maturity reports this at run time, and outbound.caveats lists what the adapter assumes and has not confirmed. Each adapter’s page shows its caveats in full.

What each adapter can do

A filter is server (the vendor filters), client (the SDK filters after fetching and marks the result derived) or no. A stat is exact, derived or no. A call that needs a no is refused as Unsupported before any request leaves. The repository’s test suite checks this table against the adapters’ own declarations (packages/outbound-sdk/test/adapters-doc.test.ts). See capabilities for what each key gates and how to branch on it.

The in-memory adapter declares everything except native, events.parse, events.verify and deletionDetection.

What stays no, and why

What a vendor’s API cannot answer stays no. The SDK does not fill the gap with a guess.

• HeyReach has no campaign settings, subsequences, tags or per-lead counts. Its API can set a campaign’s schedule but not read it, a campaign has one sequence tree, no endpoint lists the workspace’s tags, and no lead carries open or reply counts.
• HeyReach has no per-step stats and no warmup: LinkedIn accounts are not warmed up.
• HeyReach replies carry no category. Its auto-tags describe the lead, not a message; the newest one is the lead’s interest.
• HeyReach has no list of every lead. Leads are read per campaign or per saved list, or found by profile or email.
• HeyReach cannot list workspaces with a workspace key.
• Smartlead cannot list the leads of a saved list, and its per-lead counts are documented only as a placeholder response.
• Instantly’s per-mailbox stats are derived: its mailbox analytics exist per day only, so the adapter sums them.
• No adapter reveals deleted records. The reconcile plugin compares what you stored with what the vendor still lists.

How much of each vendor’s API is covered

Every endpoint in each vendor’s API reference is listed on its coverage page with how the SDK reaches it: through a normalized read, through the native catalog, excluded with a reason, or a write the SDK does not make.

A read is excluded only when it returns secrets (API keys, mailbox passwords, proxy credentials), duplicates another endpoint’s data exactly, reports nothing about campaigns, leads, senders or results (billing, marketplace pricing, search filter lists), or returns a file the SDK cannot carry. Reads that spend vendor credits are listed as writes.

Rate limits each adapter declares

The SDK spends share (default 0.5) of these numbers, because the vendor’s limit is shared with the customer’s other tools. Rate limits explains the budget, and what is verified says which of these numbers were measured.

The provider catalog and choosing an adapter at run time

outbound-sdk/providers lists every provider with its channels, its maturity and the environment variables it reads, without importing any adapter. outbound-sdk/loader builds the adapter that OUTBOUND_SDK_PROVIDER names, reading that adapter’s own key from the environment; the CLI picks its adapter this way.

import { createOutbound } from "outbound-sdk";
import { fromEnv, loadableProviders } from "outbound-sdk/loader";
import { providers } from "outbound-sdk/providers";

// The catalog imports no adapter, so it is safe in a config screen.
for (const provider of providers) {
  const required = provider.envVars
    .filter((variable) => variable.required)
    .map((variable) => variable.name);

  console.log(provider.id, provider.maturity, provider.channels, required);
}

// fromEnv() builds the adapter OUTBOUND_SDK_PROVIDER names, or the one you
// pass. Only that adapter's code is loaded.
console.log(loadableProviders());

const outbound = createOutbound({
  adapter: await fromEnv({ provider: "memory" }),
});

const campaigns = await outbound.campaigns.list();

console.log(outbound.provider, campaigns.items.length);

instantly beta [ 'email' ] [ 'INSTANTLY_API_KEY' ]
smartlead unverified [ 'email' ] [ 'SMARTLEAD_API_KEY' ]
heyreach beta [ 'linkedin' ] [ 'HEYREACH_API_KEY' ]
memory stable [ 'email', 'linkedin' ] []
[ 'heyreach', 'instantly', 'memory', 'smartlead' ]
memory 2

Writing an adapter

The adapter contract is the Adapter type exported from outbound-sdk. The checklist for adding one is in the repository, in docs/new-adapter.md, with the research note each existing adapter was written from under docs/research/.