Templates
A template lets your marketing team own the message while your product determines the moment it is sent. Build the subject, content, sender and customer data requirements in maxclicks; your application triggers the saved email for a recipient through REST or SMTP.
Templates have no campaign audience or schedule. There is no separate publication step: a new send uses the saved template configuration. Coordinate edits to a template used by a live application, because saving changes affects subsequent requests. An email already rendered for an attempt is not rewritten by a later edit. For a one-time send to a whole audience use a broadcast, and for a series that runs on its own use a workflow.
Build the template
Press New template on the Templates page. maxclicks asks two questions: which editor you want to write in, and the sending mode, marketing or transactional. The sending mode cannot be changed afterwards. The editor allows a few one-way moves: Switch editor in the composer takes a visual builder to a code editor, or the Dynamic Composer to Simple HTML, and none of them can be undone. Then the Composer tab is the email editor, where you write the content, set the sender, and preview it.
Decide what the email needs to know
Every template carries a list of the information it expects, and it can only reference what is on that list. Open the Data tab in the right rail to define the expected data and the recipient path. Use Personalize for the model and generation controls, and Checks to review outstanding readiness issues.
A receipt, for example, might expect three things: the customer it is addressed to, the order it is about, and a plain tracking value carrying the carrier name. The first two are records, pulled fresh from your data at send time; the last is a value you hand over with the send.
One entry on that list is marked as the recipient, under To. It has to be a contact, or, for transactional email only, an email address you pass in.
Send it
The Send tab is the fastest way to wire this up. It shows the list of what the template expects with your own key names, marks which one is the recipient, gives you a ready-made example request with those keys already filled in, and shows the template's ID for copying. The API reference covers the send call itself, the SDKs, and the idempotency key that stops a retry from sending twice.
For record entries, pass identifiers for the customer or object the email should use. The send operation resolves and upserts those records, then reads their stored data and the configured attribute expansions for rendering. For plain JSON entries, send values matching the declared shape. A record reference and a JSON value are different inputs: agree their keys and types with the developer before connecting the trigger.
Sending writes to your data. Every record you pass is saved before the email is built, so sending with a first name attached also updates that contact's first name. Pass identifiers, and pass fields only when you genuinely mean to change them.
Make retries a shared contract
Agree an idempotency key for each business message, such as the receipt for one order. Preserve the same key and payload when your application retries that logical send. A new key means a new operation and can send another email.
The API response includes the email ID and send status. HTTP success alone is not evidence of delivery: inspect the returned status, then use email activity for later delivery events. A failed or uncertain outcome may still follow completed data writes or a provider attempt. Reconcile the email before asking the application to send it again.
Review a live change
Before saving a change to an active template, preview realistic examples, confirm the Data contract still matches the application, inspect links and consent mode, and use Send test. A preview of one customer cannot prove the data for every future request will be complete. If you need a separate rollout, create a separate template and coordinate the template-ID switch with the application owner.
Who actually receives it
Before every send maxclicks checks the recipient's consent and your suppression list.
- Marketing email reaches only contacts who subscribed to email, and to the topic if the content is bound to one. It is skipped for any suppression, and it carries an unsubscribe link.
- Transactional email can use a contact or a valid direct address without a marketing subscription, and has no marketing unsubscribe link. Hard-bounce and repeated-soft-bounce suppressions still block delivery.
Why a send is refused
Most refusals are one of a handful of things, and each has an obvious fix:
| What happened | What to do |
|---|---|
| The data you sent does not match what the template expects | Compare your keys against the Send tab's list |
| The template is missing a recipient, a sender, or content | Open Checks and follow the readiness issues in the composer |
| The sending domain is not verified | Finish domain verification |
| Marketing content was addressed to a bare email address | Address it to a contact, or make the content transactional |
| The contact has not consented to the channel or the topic | Nothing to fix here: this is consent working |
| The recipient is suppressed | Check the suppression list |
| You are out of email allowance | See billing |
Watch what happened
Once the template is ready to send, two more tabs appear. Emails lists every email this template sent with its delivery state, and Metrics totals them up: delivered, opened, clicked, unsubscribed, and the rate behind each. A provider-accepted message is Sent; Delivered is a later event, and neither proves inbox placement. Rendering with Adaptyle adds usage separately from the email allowance, including applicable corrections and checks.
The public templates API lists, reads and sends saved templates; it does not create their content. Build and review the email in the app or with maxinja. The app's readiness check expects valid sample data and a successful preview. Actual sends validate the supplied data and current sending prerequisites, then render for the real recipient.
Related
- Email editor: where the content, sender and recipient are set.
- Contacts: identity, consent, and suppressions.
- Schemas: the shape of the records a template references.