groupId or emailId. Customers can see live generation, review emails together,
edit manually, and use the editor panel. No Clerk keys, Brew login, or browser
API key is required.
Create a Client App
Select the brand in Brew and open Settings → API → Client apps. Choose Create client ID, name the app, add its allowed origins, and save. Copy the client ID into your app. Allow exact origins such ashttps://app.example.com or
http://localhost:3500. Include the port when applicable. Paths, trailing slashes,
and wildcards are not accepted. HTTPS is required except for loopback development.
Choose whether customers can edit in the client app’s settings.
The embed entry points require an embed-capable SDK build and Brew deployment.
Published SDK 12.2.0 does not include them. Until a compatible release is published,
follow the local SDK packing instructions in the
open source demo.
Embed a Group or One Email
groupId with emailId. Passing both or neither is
rejected by TypeScript and at runtime. The client ID determines the brand and
editing permissions. You do not supply user, brand, permission, origin, or session
fields to the browser component.
React 18 and 19 are supported. The component defaults to 640px tall. Authentication
and automatic session renewal run inside the SDK without replacing the iframe.
The canvas works when third-party login cookies are disabled. The SDK keeps a public, per-client draft recovery ID in your app’s local storage so unsaved drafts can be recovered after a reload. Session ownership secrets stay in memory. If local storage is unavailable, the canvas still works, but cross-reload recovery is unavailable.
Use Another Framework
fitView(), focusEmail(emailId), and
flush() return promises. React exposes the same methods through an
EmailCanvasHandle ref. Await flush() before leaving; a failed save should keep
the canvas mounted so the customer can retry. Use onDirtyChange to warn before
navigation, onSaved for save feedback, and onSelectionChange for selection.
Use Brew Headlessly
Use the browser canvas as your editing surface and Brew’s API for generation and management. API keys stay on your backend:brew.emailGroups to manage
groups and brew.emails to manage designs. Return an authorized email ID when
opening a single-email editing step. A client ID cannot authorize API generation,
sending, or management.
Common uses include an email builder inside your SaaS product, a shared workspace
that displays generation results, a single-email editor within an approval flow,
and a review portal with editing disabled.
Understand the Access Boundary
Client IDs are public app credentials. Brew checks the browser request’s Origin against the client’s stored allowlist, issues short-lived credentials, and limits iframe framing to that exact origin. Every content, edit, and presence operation rechecks the client configuration and brand access. A client ID authenticates the configured app, not an individual person. Visitors to an allowed origin can request groups and emails within its bound brand. Opaque target IDs and hiding a target in your UI do not provide per-user access control. Non-browser callers can forge Origin headers. For tenant isolation, use a dedicated brand and client app per customer. For private per-user or per-target access, use your own login and the advanced server-authorized flow below. Revoking a client app in Settings ends its established canvas access. Changing origins or editing permissions invalidates existing sessions; customers can reopen the canvas. SDK unmount closes its owned session on a best-effort basis; server expiration handles lost connections. Multiplayer provides live presence, selections, and saved updates. One person edits an email at a time. It does not provide simultaneous character-level editing. The editor panel supports text, color, spacing, layout, image upload, and cropping. Workspace media search, logos, Giphy, and AI image generation require separate capabilities and are not included in the embedded panel.Advanced Per-User Authorization
Use this when individual users need narrower access than the client app’s brand. No specific login provider is required. ReplaceclientId with a provider that
calls your authenticated endpoint:
{ target, sessionId? }. Authenticate the caller, resolve
the allowed brand and target from your own data, and use a server-side API key to
call brew.canvas.sessions.create({ target, user: { externalId, name }, parentOrigin, permissions }).
Retain session ownership in your backend. Renew only the caller’s owned grant with
brew.canvas.sessions.refresh(sessionId), and revoke it when access ends.
A session ID alone is not proof of ownership. Never pass both clientId and
getSession.
Run the Open Source Demo
The MIT Next.js demo and README show client ID setup, group and single-email views, autosave feedback, failed-save recovery, and save-before-navigation. No authentication-provider keys or API key are needed to run the demo. The README includes local SDK setup, tests, deployment, and the headless use cases above. Before release, test your deployed HTTPS app from an allowed and a denied origin. Confirm the CDN preserves the iframe’s framing policy, then upload, crop, save, and reopen a real image. Local fixture tests do not verify production CDN or object-storage configuration.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 explore it further with ChatGPT or Claude.