# Templates with logic, rendered at send time.

Store an email template in Bird and reference it by id. Conditionals, loops, and defaults render per recipient when the message is sent, so the personalization logic stays in the template instead of scattered through your code. Author it as HTML with declared variables, or render your React Email components.

## Store a template. Personalize at send.

## Send only the values that change per recipient.

Templates are part of the Bird Email API. Store the layout and its logic once; on each send you reference the template and pass a flat set of per-recipient values. Bird renders the final message on its side, so the same template drives one email or a million.

## More than find-and-replace.

Real templating logic, resolved on Bird's side, per recipient, at send.

## Author it the way you already work.

Send plain HTML with a list of declared variables through the API, and you have a working template, no new editor to learn. Prefer components? Render your React Email templates to HTML and store the result. The one thing to know: leave Bird's tokens as literal text in the JSX so they survive the render and get filled at send, instead of baking in a value when React renders.

## Versioned, like the rest of your code.

Editing happens on a draft and never touches what's live. Publishing freezes an immutable, numbered version and pushes it; if a change goes wrong, roll back to an earlier version and re-publish. Concurrent edits are caught rather than silently overwritten, so two people working on the same template don't clobber each other. Every version carries a stable identity, which is what lets per-template reporting attribute opens and clicks correctly.

## Keep every brand consistent.

A brand kit holds your colors, type, spacing, logo, and voice, and applies them to a template so the output looks and reads like you without restyling each one by hand. Kits live at the workspace level and a workspace can keep several, because a parent brand, a sub-brand, and your plain transactional mail rarely want the same look. Using a kit is optional: a template with none falls back to clean defaults.

## Preview exactly what will ship.

Fill a template with sample values and see the rendered message before anyone receives it. The preview runs through the same rendering path as the real send, so what you approve is what goes out, not a close-enough approximation that drifts once tokens and logic resolve for real recipients.

## Where templates are headed.

The stored-template model is the foundation for what comes next: describe a template in a prompt and generate a draft to refine, build one visually without writing HTML, and let coding agents compose on-brand templates over MCP, plus a library of starter templates to begin from. These build on the same versioned, brand-aware model, not a separate track, so the API you integrate today is the one they extend.

## Go deeper in the docs.

See how templates fit the sending guide, including rendering React Email, and wire up email events and webhooks so opens and clicks flow back per template.

## Templates are part of a platform, not a point tool.

Store, version, and personalize templates on the same Email API that handles sending, deliverability, suppression, and analytics. One set of keys.