Skip to main content

API plan

The API plan is a standalone, flat-rate plan for unlimited headless and unattended programmatic access — CI pipelines, agents, backends, and scripts that run with no human present. It coexists with per-seat on a single organization subscription, comes with a starter set of seats included (add more at the usual per-seat rate), and gates org-level service-account API keys (sk_) for automation at scale. Like per-seat, it can be billed monthly or annually — annual is the cheaper option.

Per-seat access still covers all interactive human use — the web app, CLI, and MCP server — plus a personal, low-throughput API key for light scripting.

info

v1 has no usage metering and no overage. The API plan is flat-rate: once an organization is on the plan, its service-account keys run at the higher rate tier with no per-call charges and nothing to true up.

How it fits with per-seat​

The API plan and per-seat are two separate things that live side by side on the same organization:

  • Billed to the owner. The API plan is added to the organization's subscription, billed to the organization owner, on top of (not instead of) per-seat — monthly or annually, with annual the cheaper option.
  • Includes seats. The API plan comes with a starter set of seats included; add more at the usual per-seat rate. Existing members keep their interactive access exactly as before. An organization can have seats and no API plan, or seats and the API plan together.
  • Different purpose. Seats pay for people; the API plan pays for unattended automation — and brings along seats to get a team started.

Seats vs. the API plan​

The dividing line is who holds the credential — a long-lived sk_ service-account key — not whether you call the API. Seats call the API too, via the CLI and the MCP server; that interactive, human-driven access is exactly what a seat is for.

Put precisely:

  • The seat plan covers interactive, human-driven access — the web app, the CLI, and the MCP server, all signed in through OAuth/Cognito — plus a personal, low-throughput sk_ key per seat for light, occasional scripting by that person.
  • The API plan covers headless, unattended access at scale through org-level service-account sk_ keys — credentials that belong to the organization, not to any one person, and that run with no human present.

Both can be true at once: a single organization can carry seats and the API plan together on one subscription (see How it fits with per-seat). The API plan also includes a starter set of seats, so a small team can get going on it without buying seats separately; beyond those, seats are added at the usual per-seat rate.

The table below maps each surface to the plan it belongs to, the kind of token it uses, and how long that token lives:

SurfaceWhich planToken kindLifetime
Web appSeatOAuth / Cognito sessionSession (short-lived, auto-renewed)
CLISeatOAuth / Cognito session, with an optional personal sk_ key for scriptingSession for sign-in; long-lived for the personal key
MCP serverSeatOAuth / Cognito (read-only)Session (short-lived, auto-renewed)
Personal scriptingSeatPersonal, low-throughput sk_ keyLong-lived until revoked
Headless automation at scaleAPI planOrg-level service-account sk_ keyLong-lived until revoked

So the question to ask is never "am I calling the API?" — both plans do. It is "is a person driving this, or is it running on its own?" A developer reaching for the CLI or MCP server is using their seat. A pipeline, an agent loop, or a backend service authenticating with a long-lived sk_ key belongs on the API plan.

MCP is not a substitute for the API plan​

The MCP server is read-only and OAuth-bound: an assistant calls it on a signed-in person's behalf, and it can only look things up — it cannot create, change, or delete anything, and it has no way to run with no human present. That makes MCP part of the seat, not a back door into headless automation. You can't drive unattended automation through MCP or through a seat generally; for that you need the API plan and an org-level service-account key.

What the API plan unlocks​

The API plan turns on org-level service-account API keys: long-lived sk_ credentials that belong to the organization rather than to a single person, and that are built for headless, unattended use. These keys are what you embed in CI, in agents, and in backend services that run with no human present, and they run at the API plan's higher rate tier. They are also the credential the official SDKs authenticate with — the SDKs are built for service-account keys, not personal seat keys or browser sessions.

The personal API key that comes with a seat is fine for occasional, light scripting, but it is low-throughput and tied to an individual rather than the organization — it is not the credential for automation at scale.

Because service-account keys are an entitlement of the plan, they follow it: if the plan later lapses, existing keys are suspended — not deleted — and resume automatically when the organization resubscribes. See If the API plan lapses.

Authentication and rate limits​

The credential model — how sk_ keys are issued, presented, and revoked — is covered in Authentication. Both the personal seat key and org-level service-account keys are sk_ keys and use the same Authorization header; the API plan governs which throughput tier a key gets and how many service-account keys an organization can hold.

Per-caller limits and how to handle a 429 are described in Rate limiting.

Getting started​

Adding the API plan is a billing change made by the organization owner — on monthly or annual billing, the same interval as the rest of the subscription. Once it is on, owners can mint org-level service-account keys for the organization. Setting up headless authentication and choosing between a seat key and a service-account key are covered in the authentication and CLI guides. To make your first call with a key, see Quickstart.

With a service-account key in hand, the first call looks like this — raw HTTP or through an SDK:

curl https://api.slothbox.dev/me \
  -H "Authorization: $SLOTHBOX_API_KEY"