Solutions · transactional

Receipts and campaigns,
one platform.

Receipts and notifications on the same platform as your marketing, without mixing the two.

Permission first. Every brand distinct.
The problem

Two tools, two truths.

Transactional email usually runs through a separate service with its own templates, its own suppression list, and its own reporting. The result is a contact whose receipt history lives in one system and whose consent record lives in another — and nobody can answer what they actually received.

SendNectar sends transactional mail through the same API, brands, templates, and reporting as everything else, while keeping the message class distinct: transactional sends are not subject to marketing frequency caps or topic consent, and are routed on their own provider routes.

What you get

Transactional email, specifically.

01

One API call

Post a brand, a pinned template version, a recipient, merge variables, metadata, and an external reference. The send is queued and tracked like any other message.

02

Pinned template versions

Transactional sends target an immutable, hash-verified published version — so a template edit never silently changes what customers receive.

03

Separate message class

Transactional is a distinct class from marketing: not capped by frequency rules, not gated on topic subscription, and separately routable.

04

Its own routes and providers

Give transactional mail its own provider connection and sending routes, so a marketing burst never queues behind a password reset.

05

Live and test keys

API keys carry a live or test mode, explicit scopes, optional brand restrictions, and expiry. New tokens are shown exactly once.

06

One reporting surface

Transactional history, message events, and per-message status sit alongside campaign reporting — one place to answer what a contact received.

In the product

The transactional request.

A send is a small, explicit payload — no hidden template resolution, no implicit list membership.

brand_id
The brand the message is sent as — determines sender identity and footer
template_version_id
An immutable published version, not a live draft
to_email
Recipient address, optionally alongside a contact reference
external_reference
Your own identifier, for idempotency and reconciliation
variables
Merge data rendered into the pinned template version
metadata
Arbitrary key-values carried through to reporting

Bring your provider.
Keep your brands distinct.
Start today.

Set up your first workspace, connect a provider, and publish a workflow — free, in test mode, before you pay a thing.