# Templates with logic, rendered at send time.

Store a subject and body once, publish it as an immutable version, then send it by slug. Liquid conditionals, loops, and filters run when the message is generated, so the personalization logic lives in the template instead of scattered through your code. Author it in the dashboard builder, from the bird CLI, or let an agent do it over MCP.

## Store a template. Personalize at send.

## The markup already lives in Bird.

Templates are part of the Bird Email API. Store the layout and its logic once; each send names the template by slug or id and passes the values its tokens need. The final message is rendered on our side, so the same template backs one receipt, a batch of a hundred, or a broadcast to a whole audience.

## More than find-and-replace.

Liquid, resolved on Bird's side when the message is generated.

## Author it the way you already work.

Three ways in, all reaching the same template. The dashboard builder is the visual one. The bird CLI drives the whole lifecycle from a script or a deploy step, and an agent reaches the same operations over MCP. Already have React Email components? Render them to HTML and store the result, leaving Bird's tokens as literal text in the JSX so they survive the render instead of baking in a value when React runs.

## Versioned, like the rest of your code.

Editing happens on a draft and never touches what's live, because a send always resolves the current published version and drafts are never sent. Publishing freezes an immutable, numbered version and makes it live; if a change goes wrong, roll back to an earlier one. Saves carry the revision you last read, so if a teammate changed that language meanwhile the save is refused as a conflict rather than overwriting their work. Delivery and engagement stats break down per template, so you can see which one is actually landing.

## One template, up to 25 languages.

A template carries content in up to 25 languages, each with its own subject and body, keyed by a BCP-47 tag like en or pt-BR. A send names the language it wants, or leaves it off and gets the template's default. When a send asks for a language the template doesn't carry, on_missing_language decides what happens: fallback serves the closest match, so a request for pt-BR is answered by a stocked pt, and fail rejects the send outright, for content where the wrong language is worse than no send at all.

## Preview exactly what will ship.

Fill a template with sample values and get back the subject and the HTML and text bodies a send would deliver. Preview renders the draft, which is how you check a change before it goes live, or a published version when you want to see what is going out right now. Nothing is sent. It also runs the same personalization checks as publishing, so a construct that would be rejected shows up here first.

## Where templates are headed.

The visual builder and a starter library of forty built-in templates already ship, so you can copy one into your workspace and edit from there. Next on the list: describe a template in a prompt and get a draft to refine, a tighter compose surface for agents, and brand kits, which will hold your colors, type and voice at the workspace level and style a template from them. Each of those extends the same versioned model, so what you integrate today is what they build on.

## Go deeper in the docs.

The templates guide covers drafts, published versions, per-language content and the Liquid rules. The sending guide has the send-side contract, and email events and webhooks gets opens and clicks flowing back.

## Templates ship with the platform around them.

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