Current Client Surface
The TypeScript SDK is resource-oriented.Resources and Methods
brew.brands, brew.templates, and brew.usage are
organization-level resources and never send X-Brand-Id, including
from a client created with withBrand(). brew.brands.list() is the
bootstrap discovery call for either credential scope. Every other
authenticated resource above is brand-scoped.
Reads are flat: every resource has exactly one list(). Pass the
resource’s id key for a single row, and include to embed heavier
detail:
The contact read is
brew.contacts.search({ filters, audienceId?, search?, sort, count?, cursor }):
look up one address with a { field: 'email', operator: 'equals', value }
filter.
The public SDK surface is deterministic-only: brew.automations
and brew.automations.triggers do not expose AI authoring methods. AI
body generation is still available on brew.emails.generate({ prompt });
chain it with brew.automations.create({ … }) to assemble automations
programmatically. To ingest existing markup as an editable design, use
brew.emails.import({ format, content }).
Paginated list and search methods accept { limit, cursor } and return the
uniform { data, pagination } envelope. Loop while
pagination.cursor !== null. Manual-audience run history is a bounded
newest-first read with limit only.
contacts.searchAll, analytics.sends.listAll,
analytics.triggerInstances.listAll, and analytics.eventsAll are async
iterators that page through the whole result set for you via the shared
autoPaginate helper.
The SDK exposes the full strictly typed manual-audience lifecycle:
brew.brand.get() is read-only. There is no brand management
resource. It returns the single brand bound to your API key plus its
extraction readiness.
brew.help.get() hits GET /v1/help, a no-auth, machine-readable
catalog (auth, scopes, rate limits, per-operation credit metering, the error
envelope, and the full endpoint list) any MCP server or agent can parse
to self-discover the API.
Common Flow: Trigger → Emails → Automation → Publish → Fire
End-to-end deterministic recipe: create a custom trigger, mint each email body in parallel, assemble the graph referencing thoseemailIds,
publish, and fire. Every step returns a typed result.
Reading Sends + Trigger Instances
Send delivery splits in two: the write isbrew.emails.send(input)
(pass test: true for a one-off QA send), and every read lives on
brew.analytics.sends.list(), one flat read with identity in the query. To
pull back a scheduled or queued send before it goes out, call
brew.sends.cancel(sendId).
AutomationNodeInput: A Per-Kind Discriminated Union
AutomationNodeInput is a discriminated union by type; setting
node.type narrows node.config automatically. The five node kinds
map 1:1 to the server-side Zod schemas:
Each
sendEmail node’s subject / previewText support
{{variable | fallback}} interpolation against the trigger payload.
Source of Truth
The SDK follows the Brew OpenAPI contract. If you want the raw HTTP shape behind any method, use the API reference in this docs site.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:- Self-Service Tools
- Talk to Our Team
Search Documentation
Type in the “Ask any question” search bar at the top left to instantly find relevant documentation pages.
ChatGPT/Claude Integration
Click “Open in ChatGPT” at the top right of any page to analyze documentation with ChatGPT or Claude for deeper insights.