--- title: "Submit an email template version" method: POST path: "/v1/email/templates/{template_ref}/versions/{version_id}/submit" tags: ["email-templates"] --- # Submit an email template version `POST /v1/email/templates/{template_ref}/versions/{version_id}/submit` ## Request - Base URL: `https://us1.platform.bird.com` - URL: `https://us1.platform.bird.com/v1/email/templates/{template_ref}/versions/{version_id}/submit` - Auth: one of: - HTTP bearer - API key in cookie `bird_session` Submits the template's draft as a new immutable, numbered version and makes it the live version used by sends. The draft remains editable. Every language the draft has must have a subject and a body, and the default language must be present. Submission is all or nothing: an incomplete language rejects the request and the response reports every language error. A submit freezes every language the draft carries, so it cannot name a subset. The draft does not have to hold every language you plan to support: add more in a later version. Set `validate_only: true` to run the checks without creating a version. Set `expected_revision` to reject a concurrent edit. An unchanged draft is rejected. Submission is synchronous, and a returned `version` is live. ## Headers - `Idempotency-Key` string - `X-Workspace-Id` string - `X-Organization-Id` string ## Request body - EmailTemplateSubmit: Options for a submit. Every field here is optional, so an empty request body submits the draft exactly as it stands. - `validate_only` boolean: Check the draft without actually submitting it. Every language gets checked and every problem gets reported back to you, but nothing is frozen and no new version gets created. Give a validation run its own `Idempotency-Key`, separate from the real submit that follows it. You can also send no key. The validation request and real submit have different bodies, so using the same key for both is rejected as key reuse. - `expected_revision` integer: The draft revision you last read (from the template's `revision` field). A stale value returns a conflict so you can reload and retry. - `languages` LanguageTag[]: Languages to process when submitting an already-published version. Email templates accept submissions only for drafts, so setting this field for an email template is rejected. ## Response `200` The submit's outcome, including the frozen version unless this was a validation run. - EmailTemplateSubmitResult: The outcome of a submit. This has the same shape whether the submit was a validation run or a real one, so you can read `valid` and `version` the same way either time to see what happened. - `valid` boolean, required: Whether the version passed every check. - `errors` EmailTemplateSubmitProblem[], required: Every problem found across the draft's languages. Empty when `valid` is `true`. - `language` string: A language tag in BCP-47 form, for example `en` or `pt-BR`. - `field` string, nullable: Which field within that language has the problem, such as `subject` or `html`. Null when the problem is not about one particular field. - `code` string, required: The error code a real submit would fail with. Look it up in the error catalog to see what it means and what to do about it. - `message` string, required: What is wrong, worded so you can show it directly to whoever is authoring the template. - `version` EmailTemplateVersion - `id` string, required - `template_id` string, required - `version_number` integer, nullable: Sequential published-version number (1, 2, 3…). Null while the version is a draft. - `status` 'draft' | 'published' | 'archived', required: Whether this version is still being edited or has been published. It records the version's publication history: a version that a later one replaced stays `published`. The template's `live_version_id` names the version a send resolves to now. `archived` is reserved and no version carries it yet. Version retirement will produce it, so it is declared here ahead of that feature: a client written against this list today keeps working when the first archived version arrives, rather than the value's arrival being a breaking change. - `revision` integer, required: The version's revision counter. - `variables` TemplateVariable[], required: Input definitions this version uses, including caller parameters and reserved Bird inputs. An entry with `system` false is yours to send in `template.parameters`. An entry with `system` true names a reserved Bird key; supported paths receive Bird values. A draft can also report unsupported reserved paths, including bare `bird`, whose `constraint` explains that no Bird value fills them. Correct these paths before publishing. Naming a reserved Bird key in a send is rejected with a `422`. The list combines all the languages, because languages do not have to use the same inputs: if the English body uses `discount_code` and the French body uses `shipping_date`, both appear here. A send requires values only for the caller parameters referenced by its resolved language. Preview each language to see its inputs. Extra parameters are ignored; omitting a caller parameter referenced by the resolved language returns a `422` naming it. - `key` string, required: The key this slot is filled by. When `system` is true it is the reserved `bird` key or a dotted path beneath it, such as `bird.contact.first_name`, and naming it in a send is rejected. Otherwise, on email and SMS it is the key you set in the send's `parameters` object, and on WhatsApp the `name` you repeat on the matching parameter inside `components`, or, for a template whose placeholders are positional, the position itself as `1`, `2` and so on. - `type` string, required: The value type this slot accepts. Built-in SMS templates use typed slots (`code`, `amount` and the rest), each of which rejects a value that does not match its `constraint`. Email, WhatsApp and workspace SMS templates use `text`. Workspace SMS parameters must be scalar values. Open enum: treat an unrecognized value as a future type rather than an error. - `required` boolean, required: Whether the send must supply this variable. Omitting a required value returns `422` on email, SMS, and WhatsApp sends. Always false when `system` is true, because you do not supply that slot's value. - `constraint` string, required: A plain-language description of what values this variable accepts. When `system` is true it names where Bird takes the value from instead, because there is no value for you to send. - `sensitive` boolean: Whether this slot's value is redacted from stored message content. A placeholder replaces the sensitive value in message history; transport queues can still carry the text needed for delivery. - `system` boolean: Whether the value comes from Bird rather than from the send. Absent means false. Only email templates have system slots, identified by the reserved `bird` key or a dotted path beneath it; every SMS and WhatsApp slot is yours to fill. A draft can also name a reserved key no Bird value fills, including `bird` itself: `constraint` says so, and publishing that draft is rejected. - `languages` object, required: The content this version holds, keyed by language tag in BCP-47 form such as `en` or `pt-BR`. Publishing freezes every language together, so a version shows exactly what it would send in each of them. On a published version this is the send content. - `default_language` string, required: A language tag in BCP-47 form, for example `en` or `pt-BR`. - `created_at` string, date-time, required: When this version was created. - `published_at` string, date-time, nullable: When this version was published, or null if it has not been published. - `updated_by` Actor - `id` string, required: Actor identifier. - `type` string, required: New actor types may be added. Treat unrecognized values as future types, not errors. - `user`: a member's own session. - `api_key`: a workspace API key. - `oauth_token`: a token issued to a caller on a member's behalf. - `system`: an action we perform without a customer actor. - `sso`: an organization's SSO connection. - `service_account`: a workspace's connected Integration acting with no member behind it. - `automation`: an automation execution in your workspace. - `display_name` string, nullable: The label the actor is shown under: typically a member's name or email address, or the API key's name. Null when it could not be resolved. - `template_ref` string, required: The template this call addressed, as its id, even when you addressed it by slug. Send it back as `template_ref` on a follow-up call. - `version_id` string, required - `compatibility_severity` 'problem' | 'warning' | 'none', required: The worst severity across every finding the response was computed from, which is the authoritative reading: a response that caps how many findings it lists still accounts here for the ones it left out. Each response's `compatibility` says which content it covered. - `problem`: at least one finding is a `problem`. - `warning`: every finding is a `warning`. - `none`: there are no findings. - `compatibility` EmailCompatibilityFinding[], required: What the draft's HTML uses that mail clients remove, ignore, or render inconsistently, across every language, in alphabetical order of language tag and then the order the patterns appear. Empty when nothing is worth reporting. Advisory, and separate from `errors`: a finding never fails a submit, so the version froze either way. Each finding names the `language` it is in, and its line and column count in that language's HTML, which the language read returns as `content.html`. At most 200 findings come back, the first 200 in that order, so a draft that reaches the cap can omit a later language's findings entirely rather than trimming each language: read a language's own findings from its read or its write. `compatibility_severity` is derived from every finding the draft produced, including any beyond those 200. - `rule_id` string, required: Which rule produced a finding. - `html_script`: a `