Build with Brew

Use the interface that fits where you work. All four act on the same Brew brands, email designs, contacts, and sends.

​

Choose Your Interface

Finish adding your brand first. Each quickstart generates a design and sends a test to your own inbox. Generation uses credits. A test with Brew’s default sender needs no audience or verified domain.

​

Designs, Sends, and Automations

• Email design: reusable content. Keep its emailId and, to pin a version, emailVersionId. Creating it sends nothing.
• Send: one production delivery job, identified by sendId. Read it for status and engagement statistics.
• Automation: a graph that sends designs when a trigger fires or a manual audience run starts.

A test returns its recipient and completed status without creating a production send row. The Data Model maps the remaining entities.

​

Authentication and Retries

A brand credential resolves its own brand. An organization credential has no default brand. Retry keys apply only to writes whose command or schema supports them. See API Authentication, MCP Authentication, and Idempotency. HTTP and SDK calls execute authorized writes directly. The CLI gates destructive commands; --yes confirms an authorized action. MCP uses confirmation requests on OAuth and organization connections. Brand API-key connections execute directly. Production marketing sends need a verified marketing domain and recipients who opted in. Event-driven delivery, including receipts and password resets, uses a published automation and its trigger. See Emails and Automations and What You Can Send.

​

References

• CLI Commands, SDK Resources, and MCP Tools describe each interface.
• Public API v1 owns HTTP request and response schemas.
• API Contracts owns shared errors, permissions, pagination, and limits.
• v1 Migration maps older routes and response shapes.

​

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: