Templates

Email copy changes more often than the code that sends it. Templates keep the two apart: the wording lives in SendHeron and your application passes the variables, so fixing a typo is not a deploy.

A template is a reusable body with named variables filled in at send time. The same template works from a step inside a sequence and from a direct API call, which matters more than it sounds like it should: a message usually starts life as a one-off and later becomes part of an automated flow, and you should not have to rewrite it when that happens.

Because substitution happens at send time, the data you pass is the data that renders. There is no sync step and no stale copy of a customer's name sitting in an email platform going out of date.

Templates are full create, read, update and delete over the API, behind the templates:read and templates:write scopes. That split is the useful part: a key that can send email does not automatically get to rewrite what the email says.

Sending with one is a single call. You name the template and hand over the variables, and the rendered message goes out through the same delivery path as everything else.

The same object is what a send step in a sequence points at, so changing the copy changes it everywhere it is used, in the flow and in the one-off both.

Templates are also listable and fetchable over the API, which means the set of messages a workspace can send is something you can audit programmatically rather than something you have to click through to inventory. On a small team that is usually the difference between knowing what your product says to customers and assuming you know.

curl -X POST https://api.sendheron.com/api/v1/emails/send-template \
  -H "Authorization: Bearer $SENDHERON_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "templateId": "$TEMPLATE_ID",
    "to": "[email protected]",
    "variables": { "firstName": "Sam", "plan": "Growth" }
  }'

# Requires a key holding emails:send.

• Variable substitution from data you pass at send time
• Editable without a deploy
• Usable from a sequence step or a direct send
• Full create, read, update, delete over the API

Send with a template

The unglamorous part is the point. On a small team the person who notices the typo and the person who can deploy are often not the same person, and the gap between them is where bad email lives. Taking copy out of the deploy cycle closes it.

Scopes make that safe rather than reckless. Handing someone the ability to fix wording is not the same as handing them the ability to send to your whole list, and the API models that difference instead of asking you to trust everyone equally.

Honest about the scope of this: it is a body with variables, not a drag-and-drop designer with a component library and a theme system. If your existing templates are HTML they are portable, which is also why migrating them in is one of the easy parts of a move. Sequences are the hard part, and we say so on that page rather than here.