Skip to main content
Brew is the AI-native email platform. Agents with authenticated HTTP access can call its supported API operations, and compatible MCP clients can use its task-focused tools. What an agent can do depends on its connection scope, client capabilities, and workspace policy. For client setup, sign-in, and brand verification, follow your client’s guide: Connect Your MCP Client has setup steps for other clients. After setup, Run Your Email Ops from an AI Agent covers the shared draft, review, and send workflow.

Four Ways In

Choose the interface that fits your runtime. Use MCP when your client supports remote MCP, the CLI when your harness runs shell commands but doesn’t speak MCP, the TypeScript SDK when you write TypeScript, and the REST API for any other language or raw HTTP tool definitions. Coverage differs: some MCP tools combine several API operations, and some are MCP-only. Build with Brew compares the four and links each quickstart. Check the supported operations, authentication, and limits before you build.
Using a compatible MCP client? Add https://brew.new/api/mcp, complete authentication, then check the scope with get_brew_capabilities. Confirm a brand read works before requesting changes. See Connect Your Client for transport and authentication options.
No MCP, but a shell? npx @brew.new/cli runs without installing anything, which suits CI jobs and agent sandboxes. Output turns to JSON on its own when stdout isn’t a terminal. Exit codes are semantic, and irreversible commands stop and ask rather than firing. See Use from AI Agents.
Deploying on Vercel? Vercel Connect holds the Brew credential at the team level and hands your code a short-lived token. No Brew key or OAuth token sits in your environment variables. It reaches the MCP server over OAuth or the REST API with an API key.
The rest of this page covers the two API routes. One hands Brew to an agent that builds software. The other embeds Brew in the app that comes out. For an HTTP integration, confirm that your agent runtime can make authenticated server-side requests and handle errors and asynchronous results. These patterns fit platforms such as:
  • Claude (MCP, function calling, or computer use)
  • Cursor and Codex for agents that write your integration
  • OpenClaw
  • Replit agents
  • Lovable (worked example)
  • Viktor
  • Custom agents built on OpenAI, Anthropic, Google, or open-source LLMs

How It Works

For the API patterns below, call Brew’s public REST API directly or through the TypeScript SDK. Use the documented public endpoints and permission scopes. Your agent gets:
  • An API key from Brew (Settings → API)
  • The OpenAPI spec from the API Reference tab
  • The right scopes for what it needs (such as reading contacts, creating automations, or sending emails)
GET /v1/help returns the whole API as structured JSON, and GET /v1/llms.txt (https://brew.new/api/v1/llms.txt) is the prose agent operations guide. Neither needs authentication. The API Reference lists every v1 operation, and MCP Tools lists the tools. The agentic cookbook has end-to-end recipes. The trigger fire endpoint auto-upserts the contact derived from the payload, so most agent use cases don’t need to call POST /v1/contacts separately.

Let an Agent Write the Integration

Don’t describe the API to your coding agent from memory. Every entry in the API catalog at brew.new/api carries a copyable implementation prompt. It includes the endpoint, the docs link, the cost, the auth pattern, the SDK equivalent, the matching MCP tool, and every request field with its constraints. Run the capability in the catalog first, check the output, then paste the prompt into Claude Code or Cursor. Open in Claude in the catalog header does it in one click. The agent builds against the real surface instead of a guessed one.

Pattern: Function-Calling Agent

If your runtime supports tool calling, define the Brew operations your workflow needs as tools. A typical setup:
  1. Define the required Brew operations in your tool registry.
  2. Read the Brew API key on your server and provide authentication headers there.
  3. Instruct the agent to check readiness, show drafts, and request approval before sending or publishing.
  4. Inspect tool results and follow asynchronous work through its documented status reads.
In TypeScript, back each tool with the SDK rather than hand-rolled fetch calls. createBrewClient handles retries, idempotency keys, and typed errors, so a tool handler is one call:
In an MCP client, use MCP Tools instead of defining HTTP tools yourself. Check each tool’s schema before relying on it. For example, ask the agent to prepare a welcome email for yesterday’s signups who explicitly opted in. Check the selected audience and draft, approve the final send details, then inspect the send status.

Pattern: Backend Trigger

If your agent runs on a backend (Replit, Lovable’s Edge Functions, your own API), wire it to Brew’s trigger endpoints. Call them when events happen in your app:
  • New user signs up → trigger your user_signup event in Brew
  • Customer abandons cart → trigger cart_abandoned
  • Payment fails → trigger payment_failed
Configure and test the automation, then publish it when approved. Your backend can fire its trigger when the matching event occurs. Inspect the returned runs to confirm what happened.

Pattern: Chat-Driven Brand and Email Creation

Some agents (Lovable, Viktor) generate full apps and need to ship email as part of the build. Brew handles this too:
  1. Set up your brand in Brew and wait for extraction to finish.
  2. Create a brand-scoped API key under Settings → API, then store it on your server. Authentication covers key creation and scopes.
  3. Ask the agent to generate designs with POST /v1/emails and a prompt. Review the designs before using them in a one-off send or automation.
  4. Ask the agent to assemble the automation with POST /v1/automations. Test it, review the results, then approve publishing with PATCH /v1/automations/{automationId} and { published: true }.
  5. Wire your backend to fire the trigger from the matching event: POST /v1/automations/triggers/{triggerEventId}/fire { payload }, with a stable Idempotency-Key per business event. Idempotency covers how repeats replay.
Some setup and review steps still happen in Brew, a browser sign-in, or your inbox. After publishing, check the automation runs and delivery results to verify the integration.

Authentication

Authenticated REST calls send a key from Settings → API in the X-API-Key or Authorization: Bearer header. A brand key resolves its own brand, and an organization key also needs X-Brand-Id on every brand-scoped request. API Authentication owns keys and scopes, Organization and Brand Credentials covers the scoping rule, and MCP Authentication and Scoping covers MCP connections.
Read the key from an environment variable such as BREW_API_KEY on your server, and keep it out of chat, generated code, logs, and source control. Give the agent the variable name, not its value. See Authentication.

Brew MCP Server

Connect a compatible client, authenticate, and discover the tools available to your connection.

API Catalog

Run a capability in the dashboard, then copy the call or the implementation prompt.

API Reference

Full endpoint reference, authentication, and code examples.

Agentic Cookbook

End-to-end SDK recipes for agents driving automations start to finish.

Lovable

Worked example using Brew API from a Lovable app through Supabase Edge Functions.

Vercel Connect

Apps and agents on Vercel reach Brew with no key in your environment variables.

Automations

Build flows and configure the trigger events your agent will fire.

Need Help?

Our team is ready to support you at every step of your journey with Brew. Choose the option that works best for you:

Search Documentation

Type in the “Ask any question” search bar at the top left to instantly find relevant documentation pages.

Ask ChatGPT or Claude

Click here to open the Copy page menu at the top of this page, then send the page to ChatGPT, Claude, or your editor.