Transactional emails

Configure customer email templates and sending controls.

Transactional email setup has three separate parts: an email type and its compatible template, the control that triggers sending, and a verified sender with available email allowance. Saving a template or an assignment does not send an email or prove delivery. Merchant instructions are in Set up transactional emails.

Configure an email#

  1. Read /email-types to obtain key, template_type, category, variables, sample_variables, toggleable, and per_status. Do not infer these from a display name.

  2. Read /email-templates/limits, then page through /email-templates. Create a compatible block-document template if needed, or reuse a template with no specific type. Render previews without sending through /email-templates/render.

  3. Assign the template with PUT /email-type-settings/{type}. Include template_id on every write, even when you only want to change enabled. A successful template creation is separate from assignment; if assignment fails, keep the created template and retry assignment rather than creating it again.

  4. For order events, read or update /customer-notifications with Orders and Marketing scopes. Only email types with toggleable=true accept enabled=false in email-type-settings; currently this is restock_notification.

  5. Have the merchant verify a default sender in Settings > Email and review sending allowance and delivery history. Store API template endpoints do not manage sender DNS or provide a test-email send endpoint.

Custom order statuses#

Each enabled custom order status has its own assignment, keyed order_status:{statusId} in /email-type-settings. Its dedicated template_type is the same order_status:{statusId} key; it must not be assigned to a different status. Use the individual setting key when assigning a template; the generic order_status_update registry entry has per_status=true and describes the common variable catalog, not a standalone assignable template. Use a status-owned type when creating a status template; standalone template limits omit the generic definition. Creating a custom status provisions its templates; enabling its notifications also retries missing provisioning. Typed-template creation and assignment validate that the status belongs to the current store. Deleting an unused status removes its notification settings and dedicated templates; reusable untyped templates assigned to other events are preserved.

Template and delivery behavior#

Templates belong to one store. A typed template must match the email type; an untyped template is compatible with more than one type. A template that is still assigned cannot be deleted: reassign the email first. is_active controls template availability in pickers; it is not a replacement for the email or event's sending control. Existing assignments except newsletter_confirmation can still reference inactive templates. Keep the existing assignment visible rather than silently removing it from your UI.

For customer creation, send_welcome_email explicitly requests the configured welcome email. It defaults to false and is not a customer status, verification, marketing-consent, or webhook field. A successful customer creation confirms the profile operation, not email delivery. Retries and delivery status must not be interpreted as a reason to recreate the customer. See Customers.

Variables returned by /email-types describe the placeholders supported for that email. sample_variables supplies illustrative values for preview tooling, not customer or order data. Do not use sample links, codes or amounts as live values. Optional email values support {{NAME|fallback}}; unavailable values without a fallback render blank in customer-template subjects and content. Preserve the complete template_document on updates, and provide the inbox preheader through preview_text. Preview substitutions are examples; render does not look up a real customer's private data. Sending uses the data belonging to the triggering event. Test emails from Store Admin should go to a recipient you control.

The store newsletter double-opt-in setting applies to new opt-ins from storefront signup, checkout, merchant customer forms, CSV and customer API writes. With double opt-in enabled, accepts_marketing=true requests confirmation; customer responses and customer webhook payloads report false while confirmation is pending. Existing active subscriptions are preserved. accepts_marketing=false cancels active or pending consent. Omitting the field on update leaves consent unchanged.

Enabling double opt-in creates and assigns a normal editable newsletter_confirmation template if no usable assignment exists. Creation, assignment and the setting change succeed together. Existing valid assignments are preserved. Read the assignment through /email-type-settings/newsletter_confirmation and edit its template through /email-templates/{id}. The assigned template must remain active and contain a reachable Button with data.props.url set to {{CONFIRMATION_URL}}. Invalid edits or assignments return NEWSLETTER_CONFIRMATION_TEMPLATE_INVALID. An assigned template cannot be deleted; assign a valid replacement first.

Confirmation links expire after 24 hours. Repeated signup requests within one minute do not queue another confirmation email. After that interval a new request replaces the token, invalidating the previous link. Expired, replaced, unsubscribed and already-used tokens cannot activate subscriptions. Turning double opt-in off does not activate pending subscribers by itself; a new opt-in request follows the current setting. Campaign audiences exclude pending subscribers and consent is checked again immediately before sending.

The subscribers/create webhook announces activation, not a request awaiting confirmation. Customer account verification, welcome-email delivery and newsletter confirmation are separate. Confirmation email delivery still requires a ready transactional sender and available allowance. A subscription request accepted successfully is not proof of inbox delivery.

Endpoints#

Get email template limits

GET read_marketing

Fetch email-template limits and supported types.

Returns list, field-length, per-store, status, and template-type constraints for the block-document endpoints.

Headers

Name Type Description
Authorization required string

Bearer Store API token.

List email templates

GET read_marketing

List the store's reusable customer email templates.

Returns paginated transactional and promotional templates with their complete EmailBuilder block documents. Use template_type and status to narrow assignment choices.

Query parameters

Name Type Description
page integer

Page number.

Example: 1
limit integer

Page size.

Example: 20
search string

Search template names and subjects.

Example: order
template_type string

Filter by a supported template type.

Example: order_confirmation
status string

Filter by active or inactive.

Example: active

Headers

Name Type Description
Authorization required string

Bearer Store API token.

Errors

  • 400 STORE_API_INVALID_REQUEST_BODY

    Request body is invalid, incomplete, or contains an unknown field.

  • 400 INVALID_INPUT

    Pagination, filter, identifier, or template input is invalid.

  • 400 EMAIL_TEMPLATE_DOCUMENT_REQUIRED

    A complete block document is required.

  • 400 EMAIL_TEMPLATE_DOCUMENT_INVALID

    The block document has no valid root or cannot be rendered.

  • 400 NEWSLETTER_CONFIRMATION_TEMPLATE_INVALID

    The confirmation template must stay active and contain a confirmation button using {{CONFIRMATION_URL}}.

  • 409 EMAIL_TEMPLATE_IN_USE

    The template is assigned to a transactional email type and cannot be deleted.

  • 400 EMAIL_TYPE_ALWAYS_ON

    This security or access email cannot be disabled.

  • 400 EMAIL_TYPE_TEMPLATE_TYPE_MISMATCH

    The selected template is not compatible with this email type.

  • 404 EMAIL_TEMPLATE_NOT_FOUND

    The template does not exist in this store.

Create an email template

POST write_marketing

Create a block-document email template.

template_document is the canonical EmailBuilder document and must contain a renderable root. The Store API does not expose the removed raw-HTML template format.

Headers

Name Type Description
Authorization required string

Bearer Store API token.

Body parameters

Name Type Description
name required string

Merchant-facing template name.

Example: Order confirmation
description string

Internal template description.

Example: Sent after an order is placed.
subject required string

Email subject.

Example: Your order is confirmed
template_document required object

Complete canonical EmailBuilder document.

Example: {"root":{"type":"EmailLayout","data":{"childrenIds":["body"]}},"body":{"type":"Text","data":{"props":{"text":"Your order is confirmed."}}}}
preview_text string

Inbox preview text.

Example: We received your order.
is_active required boolean

Whether the template is available for assignment.

Example: true
template_type string

Compatible transactional email type.

Example: order_confirmation

Errors

  • 400 STORE_API_INVALID_REQUEST_BODY

    Request body is invalid, incomplete, or contains an unknown field.

  • 400 INVALID_INPUT

    Pagination, filter, identifier, or template input is invalid.

  • 400 EMAIL_TEMPLATE_DOCUMENT_REQUIRED

    A complete block document is required.

  • 400 EMAIL_TEMPLATE_DOCUMENT_INVALID

    The block document has no valid root or cannot be rendered.

  • 400 NEWSLETTER_CONFIRMATION_TEMPLATE_INVALID

    The confirmation template must stay active and contain a confirmation button using {{CONFIRMATION_URL}}.

  • 409 EMAIL_TEMPLATE_IN_USE

    The template is assigned to a transactional email type and cannot be deleted.

  • 400 EMAIL_TYPE_ALWAYS_ON

    This security or access email cannot be disabled.

  • 400 EMAIL_TYPE_TEMPLATE_TYPE_MISMATCH

    The selected template is not compatible with this email type.

  • 404 EMAIL_TEMPLATE_NOT_FOUND

    The template does not exist in this store.

Render an email template document

POST read_marketing

Render a block document for preview.

Renders without saving or sending. Variables are preview substitutions only; unknown customer data is never loaded by this endpoint. preview_text is emitted as an escaped hidden inbox preheader.

Headers

Name Type Description
Authorization required string

Bearer Store API token.

Body parameters

Name Type Description
template_document required object

Canonical EmailBuilder block document with a root block.

Example: {"root":{"type":"EmailLayout","data":{"childrenIds":["body"]}},"body":{"type":"Text","data":{"props":{"text":"Your order is confirmed."}}}}
variables object

Preview-only variable substitutions.

Example: {"STORE_NAME":"Example Store"}
preview_text string

Inbox preview text to include in the rendered HTML.

Example: News from {{STORE_NAME}}

Errors

  • 400 STORE_API_INVALID_REQUEST_BODY

    Request body is invalid, incomplete, or contains an unknown field.

  • 400 INVALID_INPUT

    Pagination, filter, identifier, or template input is invalid.

  • 400 EMAIL_TEMPLATE_DOCUMENT_REQUIRED

    A complete block document is required.

  • 400 EMAIL_TEMPLATE_DOCUMENT_INVALID

    The block document has no valid root or cannot be rendered.

  • 400 NEWSLETTER_CONFIRMATION_TEMPLATE_INVALID

    The confirmation template must stay active and contain a confirmation button using {{CONFIRMATION_URL}}.

  • 409 EMAIL_TEMPLATE_IN_USE

    The template is assigned to a transactional email type and cannot be deleted.

  • 400 EMAIL_TYPE_ALWAYS_ON

    This security or access email cannot be disabled.

  • 400 EMAIL_TYPE_TEMPLATE_TYPE_MISMATCH

    The selected template is not compatible with this email type.

  • 404 EMAIL_TEMPLATE_NOT_FOUND

    The template does not exist in this store.

Get an email template

GET read_marketing

Fetch one email template and its complete block document.

The template must belong to the token's store.

Path parameters

Name Type Description
templateId required uuid

Email template id.

Example: 5ff7d4ea-3250-4a4d-9d26-07f64d917d31

Headers

Name Type Description
Authorization required string

Bearer Store API token.

Errors

  • 400 STORE_API_INVALID_REQUEST_BODY

    Request body is invalid, incomplete, or contains an unknown field.

  • 400 INVALID_INPUT

    Pagination, filter, identifier, or template input is invalid.

  • 400 EMAIL_TEMPLATE_DOCUMENT_REQUIRED

    A complete block document is required.

  • 400 EMAIL_TEMPLATE_DOCUMENT_INVALID

    The block document has no valid root or cannot be rendered.

  • 400 NEWSLETTER_CONFIRMATION_TEMPLATE_INVALID

    The confirmation template must stay active and contain a confirmation button using {{CONFIRMATION_URL}}.

  • 409 EMAIL_TEMPLATE_IN_USE

    The template is assigned to a transactional email type and cannot be deleted.

  • 400 EMAIL_TYPE_ALWAYS_ON

    This security or access email cannot be disabled.

  • 400 EMAIL_TYPE_TEMPLATE_TYPE_MISMATCH

    The selected template is not compatible with this email type.

  • 404 EMAIL_TEMPLATE_NOT_FOUND

    The template does not exist in this store.

Update an email template

PUT write_marketing

Replace one email template's editable definition.

Send the complete current block document. Complex nested blocks are retained exactly; no HTML conversion or document flattening occurs.

Path parameters

Name Type Description
templateId required uuid

Email template id.

Example: 5ff7d4ea-3250-4a4d-9d26-07f64d917d31

Headers

Name Type Description
Authorization required string

Bearer Store API token.

Body parameters

Name Type Description
name required string

Merchant-facing template name.

Example: Order confirmation
description string

Internal template description.

Example: Sent after an order is placed.
subject required string

Email subject.

Example: Your order is confirmed
template_document required object

Complete canonical EmailBuilder document.

Example: {"root":{"type":"EmailLayout","data":{"childrenIds":["body"]}},"body":{"type":"Text","data":{"props":{"text":"Your order is confirmed."}}}}
preview_text string

Inbox preview text.

Example: We received your order.
is_active required boolean

Whether the template is available for assignment.

Example: true

Errors

  • 400 STORE_API_INVALID_REQUEST_BODY

    Request body is invalid, incomplete, or contains an unknown field.

  • 400 INVALID_INPUT

    Pagination, filter, identifier, or template input is invalid.

  • 400 EMAIL_TEMPLATE_DOCUMENT_REQUIRED

    A complete block document is required.

  • 400 EMAIL_TEMPLATE_DOCUMENT_INVALID

    The block document has no valid root or cannot be rendered.

  • 400 NEWSLETTER_CONFIRMATION_TEMPLATE_INVALID

    The confirmation template must stay active and contain a confirmation button using {{CONFIRMATION_URL}}.

  • 409 EMAIL_TEMPLATE_IN_USE

    The template is assigned to a transactional email type and cannot be deleted.

  • 400 EMAIL_TYPE_ALWAYS_ON

    This security or access email cannot be disabled.

  • 400 EMAIL_TYPE_TEMPLATE_TYPE_MISMATCH

    The selected template is not compatible with this email type.

  • 404 EMAIL_TEMPLATE_NOT_FOUND

    The template does not exist in this store.

Delete an email template

DELETE write_marketing

Delete an unused email template.

Deletion is blocked while any transactional or promotional email type is assigned to the template. Reassign the type first so customer communications never silently lose their template.

Path parameters

Name Type Description
templateId required uuid

Email template id.

Example: 5ff7d4ea-3250-4a4d-9d26-07f64d917d31

Headers

Name Type Description
Authorization required string

Bearer Store API token.

Errors

  • 400 STORE_API_INVALID_REQUEST_BODY

    Request body is invalid, incomplete, or contains an unknown field.

  • 400 INVALID_INPUT

    Pagination, filter, identifier, or template input is invalid.

  • 400 EMAIL_TEMPLATE_DOCUMENT_REQUIRED

    A complete block document is required.

  • 400 EMAIL_TEMPLATE_DOCUMENT_INVALID

    The block document has no valid root or cannot be rendered.

  • 400 NEWSLETTER_CONFIRMATION_TEMPLATE_INVALID

    The confirmation template must stay active and contain a confirmation button using {{CONFIRMATION_URL}}.

  • 409 EMAIL_TEMPLATE_IN_USE

    The template is assigned to a transactional email type and cannot be deleted.

  • 400 EMAIL_TYPE_ALWAYS_ON

    This security or access email cannot be disabled.

  • 400 EMAIL_TYPE_TEMPLATE_TYPE_MISMATCH

    The selected template is not compatible with this email type.

  • 404 EMAIL_TEMPLATE_NOT_FOUND

    The template does not exist in this store.

List email types

GET read_marketing

List the transactional and promotional customer-email registry.

Returns every supported email type, delivery category, compatible template type, whether merchants may disable it, and its variables with illustrative sample_variables. per_status identifies a registry definition whose templates are configured for individual order statuses. Use the returned category for classification rather than inferring it from an email name. Promotional campaigns use the marketing sender and consent rules.

Headers

Name Type Description
Authorization required string

Bearer Store API token.

List transactional email settings

GET read_marketing

Read the selected template and enabled state for every email type.

Always-on security and access-code emails are identified by the email-type registry and cannot be disabled.

Headers

Name Type Description
Authorization required string

Bearer Store API token.

Update transactional email settings

PUT write_marketing

Assign a compatible template or change a toggleable email's enabled state.

template_id is required on every write, including enabled-state changes. The template must belong to this store and either match the email type or have no specific template type. Only types with toggleable=true accept enabled=false; currently this is restock_notification. Other order-event sending controls are on customer-notifications. Creating a template does not assign it: call this endpoint after creation. A successful assignment does not confirm delivery. Sender verification, event controls, and available email allowance still apply.

Path parameters

Name Type Description
type required string

Email type from the email-types endpoint.

Example: order_confirmation

Headers

Name Type Description
Authorization required string

Bearer Store API token.

Body parameters

Name Type Description
template_id required uuid

Compatible email template id. Required even when changing enabled.

Example: 5ff7d4ea-3250-4a4d-9d26-07f64d917d31
enabled boolean

Enabled state for a toggleable email type.

Example: true

Errors

  • 400 STORE_API_INVALID_REQUEST_BODY

    Request body is invalid, incomplete, or contains an unknown field.

  • 400 INVALID_INPUT

    Pagination, filter, identifier, or template input is invalid.

  • 400 EMAIL_TEMPLATE_DOCUMENT_REQUIRED

    A complete block document is required.

  • 400 EMAIL_TEMPLATE_DOCUMENT_INVALID

    The block document has no valid root or cannot be rendered.

  • 400 NEWSLETTER_CONFIRMATION_TEMPLATE_INVALID

    The confirmation template must stay active and contain a confirmation button using {{CONFIRMATION_URL}}.

  • 409 EMAIL_TEMPLATE_IN_USE

    The template is assigned to a transactional email type and cannot be deleted.

  • 400 EMAIL_TYPE_ALWAYS_ON

    This security or access email cannot be disabled.

  • 400 EMAIL_TYPE_TEMPLATE_TYPE_MISMATCH

    The selected template is not compatible with this email type.

  • 404 EMAIL_TEMPLATE_NOT_FOUND

    The template does not exist in this store.

List customer notification settings

GET read_orders + read_marketing

Read the order-event notification matrix.

Each row separates Email from Message. Message is one toggle for the event; its exact SMS/WhatsApp delivery comes from message-channels and the response reports effective provider-ready channels. Reads require both Orders and Marketing visibility.

Headers

Name Type Description
Authorization required string

Bearer Store API token.

Update a customer notification

PUT write_orders + write_marketing

Set Email and Message delivery for one order event.

Send at least one of email_enabled or message_enabled. An omitted field keeps its current value, so independent channel updates do not overwrite each other. For a status:{uuid} event, the status must belong to this store. Tringify uses its stored name and creates and assigns editable templates before enabling notifications; retries preserve existing template edits. status_name is accepted but ignored. Enabling Message requires at least one selected, provider-ready channel; disabling remains allowed if a provider becomes unavailable. Writes require both Orders and Marketing authority.

Path parameters

Name Type Description
event required string

Core order event or status:{uuid} custom-status event.

Example: order_updated

Headers

Name Type Description
Authorization required string

Bearer Store API token.

Body parameters

Name Type Description
email_enabled boolean

Whether this event sends its configured email.

Example: true
message_enabled boolean

Whether this event uses its effective selected SMS/WhatsApp channels.

Example: false
status_name string

Optional; ignored. The stored status name is used.

Example: Ready for pickup

Errors

  • 400 STORE_API_INVALID_REQUEST_BODY

    The body contains an unknown field, an invalid value, or omits both email_enabled and message_enabled.

  • 400 INVALID_INPUT

    The event is unsupported, or a custom status identifier is invalid.

  • 404 ORDER_STATUS_NOT_FOUND

    The custom order status does not exist in this store.

  • 409 MESSAGE_CHANNEL_NONE_DELIVERABLE

    Message cannot be enabled because no selected channel has a ready provider.