Scope and roadmap

The public surface is small on purpose. Each endpoint is a deliberate decision about what should be automated from outside. This page keeps the boundary honest.

Available today

• Write: POST and PATCH /api/v1/prospects (with ?campaign= to enrol), enrol existing prospects into a campaign, pause and resume a campaign, correct a reply classification, add and remove suppressions, add and remove event subscriptions.
• Read: prospects, campaigns (with progress, settings and stats), campaign enrollments, companies (with temperature), classified replies, offers (with visits and reading time), suppressions, subscriptions and mailboxes with domain health. All lists share one pagination scheme.
• Events: one workspace webhook (Settings) plus per-event subscriptions.
• MCP: the MCP server exposes the same operations as tools.

Being considered

Creating a campaign, starting a draft for the first time, re-running a completed campaign and editing steps are the next candidates; today each of those has a screen in the app because it involves a review step. Each is a decision about what should be automated from outside, and each will appear in the changelog with its page on the day it ships. Until it is listed there, it is not live.

Not in the API, by design

• Mailbox credentials, signing secrets, API tokens. Managed in the app only. Nothing in the API returns a credential.
• Bulk endpoints. One prospect per request, 60 a minute. Large lists go through CSV import in the app, where verification and duplicate detection run before anything is written.
• opened events. Inflated by privacy-protecting mail clients, so not a signal to automate on. Campaign stats expose opened only when your tracking domain is verified, labelled as an upper bound.
• Reply bodies and offer documents. Replies return a 160-character snippet, offers return metadata and reading data. The text itself stays in the app.
• Deleting prospects. Exclude people with a suppression instead; the history of what was sent stays intact for the company timeline.
• OAuth and browser calls. The API is for servers, workflow tools and scripts; there are no CORS headers.
• A CLI. Not built. The REST API and MCP server cover the same ground.

Machine-readable

The whole surface is described in an OpenAPI 3.1 file: import it into Postman or Insomnia, generate a client, or hand it to an assistant. It is kept in step with this documentation; when they disagree, the documentation page wins and the file gets fixed.

Stability

Paths are versioned by the /api/v1/ prefix. Within v1, fields are only ever added. Existing fields are never renamed or removed. Error messages are written for humans and may be reworded; branch on the status code and the code field, never on the message text.