Transactional email In design
Lands in seconds.
Lands in the inbox.
Order confirmations, receipts, password resets, OTPs, alerts — the email your customers are actually waiting for. We are building it, and we are not open yet. What follows is the design and the reasoning behind it, because the people who depend on this kind of email should shape it before it ships.
The most-sent, least-loved email
Transactional is the bulk of business email — and the most underserved
Most platforms treat transactional sends as fire-and-forget: push a payload in, get a status back, no intelligence in between. Our answer is not to point an agent at your password resets — the token has to be the token, and a model call cannot fit inside the latency budget these messages need. It is to give them the same rails, the same reputation protection and the same audit trail as everything else you send, on a pool a marketing campaign can never touch.
Built for moments that can't wait
Every message type gets the handling it needs
These are the targets the design commits to, and the shape we want argued with before it ships — not measurements. Nothing has been sent on this path yet.
Auth & OTP
Password resets and one-time codes go straight out, ahead of everything else. No batching, no timing logic.
Order confirmations
High-priority delivery on the transactional pool, so the receipt is there before the customer wonders.
Shipping updates
Timed to land close to the event that triggered them, while latency still allows it.
Invoices & receipts
Dependable delivery, with the option to add genuinely useful context — support links, account info — not spam.
Digests & alerts
Batched and timed to each recipient's predicted open window, so summaries actually get read.
One endpoint, two contracts
POST /v1/{org}/send is live. Send message_type: outbound with a brief and our agents write it. transactional returns 501 until this ships — one door, and you can see which room is furnished.
Reputation protection
A marketing campaign can never tank your password resets
The cardinal rule of transactional email is that it must never share sending reputation with marketing. That separation has to be architectural rather than bolted on later, which is why we are building it before we open the path rather than after. Today there is one reputation, and we own the infrastructure it sits on — the split into two is the work.
Visibility & trust
Every send is accountable
This is live for the mail we send today, and transactional inherits it unchanged — the log and the reasoning trail are not per-path.
Full audit trail
Every send is logged with what went out, when, and why — including what each agent decided and the reasoning behind it. The record compliance and support teams ask for.
Delivery you can see
Status callbacks and reasoning logs show exactly what happened to each message, not just an aggregate dashboard.
Replay when you need it
Re-send or re-process events without guesswork when a downstream system hiccups.
Who sends with Plink
From storefronts to systems of record
E-commerce & DTC
Order, shipping, and delivery emails that arrive the moment they should — and quietly carry the next useful thing.
SaaS & platforms
Auth codes, system alerts, and account notifications with the latency and reliability your product depends on.
Fintech & financial services
Statements, confirmations, and one-time codes with the audit trail and sovereignty controls regulators expect.
Marketplaces & logistics
High-volume status updates timed to the event, across both sides of every transaction.
Marketing and transactional, finally on one platform
One API. One quota. The reasoning layer on every send.
Request early access →