How the samples are run

Every code sample on this site is a file in the repository that the test suite runs on the in-memory adapter. What that proves, and what it does not.

No page on this site carries TypeScript of its own. Every sample is a file under site/content/_examples/ in the repository, spliced into the page at build time. The test suite runs each one, and a page cannot show a file that was not run.

What the test does

Runs every sample as a script. A file that no other sample imports is run with Node. It must exit without an error. A file that only defines something, such as the outbound.ts in a guide that constructs a real adapter, is loaded and type-checked but makes no request: nothing on this site calls a vendor.
Compares the output. When a page shows a sample’s output, that text is a recorded file. The test fails if the script prints anything else.
Resolves outbound-sdk to the source in the repository, and only for subpaths the package exports, so a sample cannot import something you could not.
Refuses the network. fetch is replaced with a function that rejects. A sample runs on the in-memory adapter, or on a fetch the sample supplies itself.
Fixes the clock at 2026-11-14 12:00 UTC, so “the last 7 days” means the same days on every run and the recorded output does not rot.
Type-checks every sample with the same strict settings as the SDK.
Rejects other code on a page. Only commands, configuration and plain text may be written in a page directly.

What it does not prove

A sample that runs on the in-memory adapter proves the code is correct TypeScript, that it runs, and what the SDK does with the data it was given. It does not prove what Instantly, Smartlead or HeyReach return. What is verified says what was run against a live account.

Four things on the site are not run by the test and are marked where they appear: shell commands, agent client configuration (JSON), SQL shown for a database other than the one the sample uses, and the transcripts of a real model calling the tools, which were recorded once by a live run and cannot be reproduced exactly.

In a guide’s “what each vendor can serve” output, a vendor that is not refused has only passed the capability check on made-up data. It was not run against that vendor.

Running a guide as each vendor

The in-memory adapter declares every capability. A real vendor does not. Each guide therefore runs its code a second time on the in-memory adapter limited to what each vendor’s adapter declares, with this helper:

// The in-memory adapter, limited to what one real vendor declares it can do.
// It proves which calls a vendor's adapter would refuse. It does not prove
// what that vendor's API returns.
import { resolveCapabilities } from "outbound-sdk";
import type { Adapter } from "outbound-sdk";
import { heyreach } from "outbound-sdk/heyreach";
import { instantly } from "outbound-sdk/instantly";
import { memory } from "outbound-sdk/memory";
import type { MemoryData } from "outbound-sdk/memory";
import { smartlead } from "outbound-sdk/smartlead";

const DECLARED = {
  heyreach: () => heyreach({ apiKey: "not-used" }).capabilities,
  instantly: () => instantly({ apiKey: "not-used" }).capabilities,
  smartlead: () => smartlead({ apiKey: "not-used" }).capabilities,
};

export type Vendor = keyof typeof DECLARED;

export const VENDORS: readonly Vendor[] = [
  "instantly",
  "smartlead",
  "heyreach",
];

export const asVendor = (
  vendor: Vendor,
  data: MemoryData,
  workspaceId = "default"
): Adapter =>
  memory({
    // Resolved, so a capability the vendor's adapter leaves out is off.
    capabilities: resolveCapabilities(DECLARED[vendor]()),
    data,
    name: vendor,
    workspaceId,
  });

That run shows which calls a vendor’s adapter would refuse as Unsupported. It still says nothing about the vendor’s data.