Developer API and MCP Access in Mailbase

Overview

Everything the app does is reachable over a REST API scoped to one workspace. Tokens carry explicit scopes, the contract is published as OpenAPI, and webhooks report what happens after a send.

The REST API

Contacts, audiences, templates, campaigns, events and sending are all addressable under /api/v1, and the full contract is served at /api/v1/openapi.json so clients can be generated rather than hand-written. Every call is bearer-authenticated with a scoped token and rate-limited per token, with the limits reported in response headers.

Writes accept an idempotency key so a retried request replays the original response instead of sending twice. Workspace resolution is explicit: a token resolves exactly one workspace, and a request that cannot resolve one fails rather than guessing.

OpenAPI contract at /api/v1/openapi.json
Scoped, expiring API tokens
Per-token rate limits in response headers
Idempotency keys on writes
One token, one workspace

Webhooks And MCP

Outgoing webhooks deliver workspace events with a signature and a delivery log you can inspect and replay, so an endpoint that was down does not silently lose history.

An MCP server is also available for people who want to drive Mailbase from an editor. It is not how the product expects to be used, and it is not required for anything: OAuth-scoped clients stay pinned to the workspace they were authorized for, and a session that cannot resolve a workspace fails safely.

Signed outgoing webhooks
Delivery logs and replay
Optional MCP server
OAuth-scoped workspace pinning
No automatic sending

Common Mistakes

Choosing a tool before deciding who owns deliverability.
Treating DNS authentication as a one-time checkbox instead of an operating baseline.
Mixing product-critical transactional email with experimental marketing sends, with no clear boundary.
Trusting headline metrics (like open rate) that privacy proxies now inflate.