How Temply works

Keys

Every request carries a key as a bearer token: Authorization: Bearer tply_live_…. Create keys under Settings → API keys. A live key renders what you last published and counts toward your plan; live keys work on every plan, the free trial included. A test key (tply_test_…) renders your current draft, published or not, so staging always shows what you are working on; it is free on every plan and stops at 1,000 calls a month. Revoking a key takes effect on the next request.

List templates

GET /templates — every template this key can reach, newest change first, so your app can find them rather than be handed codes by hand. A live key lists what is published; a test key lists the drafts too.

curl -H "Authorization: Bearer tply_live_…" \
  https://temply.tacklabs.co.uk/api/public/v1/templates

templates

One entry per template: id, shortCode, title, previewText, publishedAt, updatedAt — the same fields as the single call.

mode

"live" or "test" — which copies the list describes.

Get a template

GET /templates/:id — the id is the tpl_… code shown at the top of the editor. It returns what your app needs to decide whether to re-render: nothing about the content itself.

curl -H "Authorization: Bearer tply_live_…" \
  https://temply.tacklabs.co.uk/api/public/v1/templates/tpl_AbCd1234

id

The internal id. Use shortCode for requests.

shortCode

The tpl_… id this template answers to.

title

The template’s name, which is also its subject line.

previewText

The line inboxes show under the subject.

publishedAt

When it was last published; null if never.

updatedAt

When the copy this key serves last changed. Cache on this.

mode

"live" or "test" — which copy the key is reading.

Render a template

POST /templates/:id/render with a JSON body carrying the data for this send. You get back the email as HTML and as plain text, with your data already in it.

curl -X POST https://temply.tacklabs.co.uk/api/public/v1/templates/tpl_AbCd1234/render \
  -H "Authorization: Bearer tply_live_…" \
  -H "Content-Type: application/json" \
  -d '{"data":{"firstName":"Ada","isMember":true}}'

html

The full email document, ready to hand to your provider.

text

The same email with the markup stripped, for the multipart alternative.

shortCode

Echoed back.

updatedAt

As on GET — when the served copy last changed.

mode

"live" or "test".

The data object

Each key in data matches a variable in the template: {{firstName}} reads data.firstName. Every variable in the template needs a value: a missing one is a 422 that lists what to add, never a silent stand-in — the placeholder set in the editor is for previews only. A pill marked optional renders as nothing when its value is missing. Booleans drive “Show if”: a block gated on isMember is dropped when data.isMember is false and kept when it is true or absent. Omit data entirely and you get the email with every placeholder intact and every block showing — the same thing the editor’s composing view shows.

{
  "data": {
    "firstName": "Ada",
    "isMember": true
  }
}

A Repeat block reads a list. Its “Repeat over” key names an array in data, and the blocks inside come out once per item: a variable inside the block reads the current item first ({{name}} is items[0].name, then items[1].name…), and falls back to the top level of data when the item has no such field. An empty list, or no key at all, renders the block zero times. A value that is not a list is a 422 naming the key.

{
  "data": {
    "firstName": "Ada",
    "items": [
      {
        "name": "Notebook",
        "price": "£12"
      },
      {
        "name": "Pen",
        "price": "£3"
      }
    ]
  }
}

Send it

Temply stops at the finished email; your provider delivers it. The subject is the template’s title, from the metadata call, and the render’s html and text are the two parts of one multipart message — send both, so inboxes that prefer plain text get the same email. Resend is shown because it is what Temply itself sends through; any provider takes the same three things.

# 1. The subject line
curl -H "Authorization: Bearer tply_live_…" https://temply.tacklabs.co.uk/api/public/v1/templates/tpl_AbCd1234
# → { "title": "Welcome email", ... }

# 2. The email for this recipient
curl -X POST https://temply.tacklabs.co.uk/api/public/v1/templates/tpl_AbCd1234/render \
  -H "Authorization: Bearer tply_live_…" \
  -H "Content-Type: application/json" \
  -d '{"data":{"firstName":"Ada","isMember":true}}'
# → { "html": "<!doctype html>...", "text": "Welcome, Ada...", ... }

# 3. Hand both parts to your provider (Resend shown)
curl -X POST https://api.resend.com/emails \
  -H "Authorization: Bearer re_..." \
  -H "Content-Type: application/json" \
  -d '{"from":"you@example.com","to":"ada@example.com","subject":"Welcome email","html":"...","text":"..."}'

Every call counts, so render once per email, not once per recipient, and cache on updatedAt rather than fetching metadata before every send: it moves only when the copy your key serves changes — on publish for a live key, on save for a test key. Caching shows the pattern.

Caching

Every call counts toward the month — a list, a metadata call and a render alike. Asking again for something that has not changed counts the same as the first time; there is no free not-modified answer. What keeps the bill down is calling less, and an email rarely changes between sends.

Render a broadcast once. When many people get the same email, render it once and hand the same html and text to every send: one call, not one per recipient. Render per recipient only where the content differs per recipient.

Cache on updatedAt. Keep each render under the template, the data you sent and the updatedAt that came back with it. updatedAt moves only when the copy your key serves changes — on publish for a live key, on save for a test key — so until it moves, the cached email is the one Temply would give you. Check it with one list call on a schedule or when you deploy, not before every send.

# 1. On a schedule, or when you deploy: one call dates every template
curl -H "Authorization: Bearer tply_live_…" \
  https://temply.tacklabs.co.uk/api/public/v1/templates
# → { "templates": [{ "shortCode": "tpl_AbCd1234", "updatedAt": "2026-09-01T09:30:00.000Z", … }] }

# 2. Only where updatedAt moved since you cached it: render once
curl -X POST \
  -H "Authorization: Bearer tply_live_…" \
  -H "Content-Type: application/json" \
  -d '{"data":{"campaign":"autumn"}}' \
  https://temply.tacklabs.co.uk/api/public/v1/templates/tpl_AbCd1234/render
# → keep { html, text } with that updatedAt, and send the same html to everyone

Never render on a page view, or on any request a visitor can repeat: a reload or a crawler then spends your calls. Render when you send, from your own server, and reuse what you rendered.

Errors and limits

Every error is JSON with a status, a message you can show, and an errors list. The codes:

401

No key, an unknown key, or a revoked one.

404

No template with that id on this account — or, with a live key, one that has never been published.

422

Data was sent but a variable has no value — the body lists them under missing — or a Repeat’s key holds something other than a list.

402

The workspace’s trial or plan has ended, so its live keys are paused. Nothing is deleted, and the key works again once someone subscribes on the Plan page. Test keys are not affected.

429

Either the key went past its per-minute burst — that answer carries a Retry-After header in seconds — or a workspace on the free trial has used its 10,000 live calls for the month, which lasts until the month turns or someone subscribes. The message says which.

500

The stored template could not be read. Open it in the editor and save.

Calls with a live key count toward a monthly total that resets on the first of each month, UK time. Every call counts — lists, metadata and renders, repeats included — so cache what you can. Test keys have their own 1,000 a month on every plan. On top of the month, one key may make 120 calls a minute (30 for a test key); past that the call is refused without counting, and Retry-After says how long to wait.

Two answers deserve code of their own. A 422 lists the values to add under missing, so the fix is in your data, not a retry. A 429 with Retry-After is the burst: the refused call was not counted, so waiting that long and trying again costs nothing. A 429 without it — the trial’s month is used up — and a 402 do not clear on a retry: someone has to subscribe, so stop and tell a person rather than loop.

curl -i -X POST https://temply.tacklabs.co.uk/api/public/v1/templates/tpl_AbCd1234/render \
  -H "Authorization: Bearer tply_live_…" \
  -H "Content-Type: application/json" \
  -d '{"data":{}}'
# HTTP/2 422
# { "status": 422, "message": "Missing values for: firstName", "missing": ["firstName"] }

# HTTP/2 429
# Retry-After: 12
# { "status": 429, "message": "...", ... }

# HTTP/2 402
# { "status": 402, "message": "...", ... }

Free trial

14 days, no card. 10,000 live calls a month, then a 429 until the month turns or someone subscribes. 5 live keys.

Team

$5 per user a month. 10,000 live calls a month included, then $1 per 1,000 on the next invoice, with no monthly cap. 5 live keys.

Enterprise

Volume agreed with you. Unlimited live keys.

Read-only

A trial or plan that ended unpaid. Live keys answer 402; test keys keep their 1,000 calls a month.

Text

• Text

  A plain paragraph. The default — start typing and you are already in one.

• Heading 1

  The largest heading. Use it once, for the line that says what the email is about.

• Heading 2

  A medium heading. Breaks a longer email into sections.

• Heading 3

  A small heading. For a label above a short run of text, when Heading 2 is too loud.

• Bullet List

  An unordered list. For items where the order does not matter — features, links, notes.

• Numbered List

  An ordered list. For steps someone has to follow in sequence.

• Blockquote

  Indented text with a rule down its left edge. To set a quote or a pulled-out remark apart from the body copy.

Media

• Image

  A full-width image with its own alignment and link. For a hero image or a screenshot that should span the card.

• Logo

  An image sized and aligned as a logo rather than as content. At the top of the email, where your mark belongs.

• Inline Image

  A small image that sits in the flow of a line of text. For an icon or a badge next to words, not on a line of its own.

• Link Card

  A bordered card with a title, description, image, and link. To point at one thing — an article, a doc, a release — with more weight than a link.

Layout

• Columns

  Splits the width into columns, each holding its own blocks. For side-by-side content. Many clients collapse them on narrow screens, so keep each column able to stand alone.

• Section

  A container with its own background, padding, and border around the blocks inside it. To band off part of the email — a highlighted note, a coloured panel.

• Spacer

  Vertical empty space of a set height. To open up a gap where the default block spacing is too tight.

• Divider

  A horizontal rule. To mark the seam between two parts of the email — usually before the footer.

Advanced

• Button

  A call-to-action button built from a table cell, so it renders as a solid block rather than a styled link. For the one action you want the reader to take.

• Repeat

  Loops the blocks inside it over an array from your data, once per item. For order lines, digest items, or anything whose length you do not know when you build the template.

• Custom HTML

  Raw HTML dropped into the email as written. Only when no block does what you need. Temply does not fix this markup for you, so it is on you to keep it email-safe.

Components

• Headers

  Three designed openings: a logo with text stacked or side by side, or a logo over a cover image. To start an email the way most do, then change the words and the picture.

• Footers

  Three designed closings, in the smaller footer style: a copyright line, a feedback call to action, a company signature. For the address, the unsubscribe line and the legal small print — pick the nearest and edit it down.

Shortcuts

The editor answers to more than its menus. Everything below works while the cursor is in the canvas; the same list is a click away in the editor itself, under the question mark beside the view switch.

Variables

Type @ where the text should change per recipient. A list of the variables already in the template appears; pick one, or type a new name to create it. The variable sits in the copy as a pill you can click, which is also where you set a Placeholder — the words previews, thumbnails and test sends show in its place. A real render never uses it: your data has to carry every value. Button labels and link URLs can be variables too.

In the rendered HTML a variable is a {{name}} placeholder. When you send no data with your request they pass through exactly like that, so you can take the markup and fill it with your own templating instead of Temply's. Send data and each one is replaced by the matching key.

The Preview data panel in the Preview view is where you check the filled version. It lists every variable the template uses; type a value and the preview redraws with real text, so you can see whether a long name breaks a line. Leave one empty and it stays a placeholder. Nothing you type here is saved with the template.

Show if

Select a block, open the eye button in its bubble menu, and put a key under Show if. The block then renders only when that key is true in the data you send. Leave it empty and the block always shows.

The key is a free-text name, not a value chosen from a fixed list. It means whatever the template and the backend doing the sending agree it means, so pick something your own code can answer — isMember, hasUnpaidInvoice. One template then covers several cases instead of splitting into near-identical copies. Keys already used elsewhere in the template are offered as suggestions, and hovering one outlines every block that uses it.

One rule worth knowing: a request that sends no data at all shows every conditional block, because there is nothing to test against. Once you do send data, a key that is missing from it counts as false and the block is dropped. So send the key, even when it is false.

With a block gated on isMember, this request keeps it, and the same request with false — or without the key — drops it:

{
  "data": {
    "firstName": "Ada",
    "isMember": true
  }
}

Repeat

A Repeat block turns a list in your data into a run of blocks. Insert one from the slash menu, set Repeat over to the key that holds the list, and build one item inside it: a line, a card, a row of columns. On render the block comes out once per item, and a variable pill inside it reads the current item first — so {{name}} is each item’s own name — and the top level of your data when the item has no such field. Anything typed in plainly repeats as written, so a Repeat is only as useful as the pills in it.

In the editor you edit one item, and the rows the list would add are drawn faded beneath it — as many as the sample data says, two unless you change it in the Data panel — so the rhythm of the repetition is on the canvas while you write. The copies follow every keystroke and take no typing of their own: click one and you are back in the row. The marker in the margin carries the count. A Show if on a block inside the repeat is answered by the item too, so one item can hide a line the next one shows.

With Repeat over set to items and a line inside reading {{name}} — {{price}}, this request renders two lines:

{
  "data": {
    "firstName": "Ada",
    "items": [
      {
        "name": "Notebook",
        "price": "£12"
      },
      {
        "name": "Pen",
        "price": "£3"
      }
    ]
  }
}

An empty list, or no items key at all, renders the block zero times. A value that is not a list is refused with a 422 that names the key.