Send receipts, sign-in codes and alerts by email and push.
Send from your app through one API. Your team designs templates in Kirora, your code supplies the data, and delivery logs and signed webhooks help you follow each message.
# An address and your own HTML, from your verified domain
curl https://api.kirora.io/v1/transactional/messages \
-H "Authorization: Bearer kirora_…" \
-H "Content-Type: application/json" \
-H "Idempotency-Key: reset-ada-0915" \
-d '{
"to": { "email": "[email protected]" },
"email": {
"from": "Shop <[email protected]>",
"subject": "Reset your password",
"html": "<p>Reset it here: …</p>"
},
"sensitive": true
}'# A template your team designed, filled with your data
curl https://api.kirora.io/v1/transactional/messages \
-H "Authorization: Bearer kirora_…" \
-H "Content-Type: application/json" \
-H "Idempotency-Key: order-1042-receipt" \
-d '{
"to": { "email": "[email protected]" },
"email": { "template": "order-receipt" },
"data": { "order_id": "1042", "total": 29.50 },
"correlationId": "order-1042"
}'# Push first, email only if the push can’t be sent
curl https://api.kirora.io/v1/transactional/messages \
-H "Authorization: Bearer kirora_…" \
-H "Content-Type: application/json" \
-H "Idempotency-Key: order-1042-shipped" \
-d '{
"to": { "externalId": "user_8812" },
"push": { "title": "Your order is on its way", "body": "#1042" },
"email": { "template": "order-shipped" },
"fallbackOrder": ["push", "email"],
"correlationId": "order-1042"
}'Messages · last minuteLive
- EmailReceipt #1042order-receipt · correlationId order-1042Delivered · 1.2s
- PushYour order is on its wayiPhone and web · order-1042Sent · 0.8s
- EmailYour sign-in codesensitive · content not keptDelivered · 0.9s
- EmailBooking remindersendAt 14 Oct, 09:00Queued
- Accepted09:00:00.120
- Sent09:00:00.410
- Delivered09:00:01.330
Send from any HTTP client, the Node.js, Go or .NET SDK, or the CLI.
- cURL
- Any HTTP client
- Node.js SDK
- Go SDK
- .NET SDK
- CLI
One request, email and push together.
Give the email and the push in one call. Send both, or send push first and the email only if the push can’t be sent. Each channel reports its own result.
Email
From your own verified domain, with templates your team designs, attachments up to 10 files and replies that thread into the customer’s conversation.
Push
To each registered device of a customer who opted in, on your iOS, Android or web apps. Or put push first, and the email follows only if the push can’t be sent.
Follow each message’s delivery status.
See when Kirora accepted a message, handed it to the provider and received a delivery update, so support can answer a customer and your code can react. Email delivery means the receiving mail server accepted it; push acceptance doesn’t guarantee a displayed notification.
- Template
- order-receipt
- correlationId
- order-1042
- Delivered in
- 1.2s
- Accepted09:00:00.120
- Sent09:00:00.410 · message.sent
- Delivered09:00:01.330 · message.delivered
Also for order-1042
- Push · Order shipped Sent
- iPhone Sent
- Pixel 7 Device gone
- Email · Review request Queued
- Sent
- 48,210
- Delivered
- 47,880
- Bounced
- 214
- Failed
- 116
Delivered Bounced Failed
A report of its own
Sent, delivered, bounced and failed, day by day, apart from your campaigns. Click a status to see its messages.
Bounces, handled for you
A hard bounce, or a spam complaint about a receipt, stops further transactional mail to that address. Leaving your newsletter doesn’t stop a receipt.
Your team designs it. Your code sends it.
- Designed in Kirora. Receipts, resets and reminders in the email designer, with a line for every item ordered and rows that appear only when there’s data.
- Sent by a readable name. Your app sends order-receipt with its own data; change the template without touching your code.
- Versions you can trust. Mail in flight always uses the published version, never a draft, and any version can be restored.
- Templates as code. Keep a template’s JSON in your repository and publish it through the API or CLI.
Built the way you would build it.
Safe retries for the same request
Send an idempotency key with each request. Retry with the same key and request body to get the existing message back, without creating another send, so a timeout doesn’t become a second receipt.
Batches of 100
Up to 100 messages in one call, each answered on its own, so one refused message never stops the rest.
Send later, or cancel
Hold a reminder for up to 90 days and cancel it before it goes, and its share of your allowance is returned.
Errors you can act on
A refusal names its reason, such as SUPPRESSED or PUSH_DESTINATION_MISSING, with the details to fix it.
Test addresses that act it out
[email protected], [email protected] and [email protected] trigger their webhooks, with nothing delivered and nothing counted.
Attachments and threads
Attach invoices and tickets, up to 10 files, and send a support reply into the customer’s existing conversation.
POST /webhooks/kirora
X-Webhook-Event: message.delivered
X-Webhook-Event-Id: 018f3a…
X-Webhook-Attempt: 1
X-Webhook-Timestamp: 1790418662
X-Webhook-Signature: sha256=9f86d08188…
// Verify the HMAC of timestamp.body with your secret,
// deduplicate on the event id, then update the order.# A refusal names its reason, so your code can act on it
HTTP/1.1 409 Conflict
{
"error": {
"code": "SUPPRESSED",
"message": "…",
"details": { },
"requestId": "0192f1c4-…"
}
}# Same Idempotency-Key and body: the existing message, no second send
HTTP/1.1 202 Accepted
Idempotency-Replay: true
{ "data": { "messages": [
{ "channel": "email", "status": "queued", "correlationId": "order-1042" }
] } }- message.sent
- message.delivered
- message.opened
- message.clicked
- message.bounced
- message.complained
- message.failed
- message.skipped
Tracked only when you ask
Opens and clicks are off unless a send asks for them, and never tracked for contacts in the EEA and the UK.
Secrets aren’t kept
Mark a reset link or a one-time code sensitive and its content is deleted once sending finishes.
Apart from marketing
Transactional messages have their own reports and logs, so a receipt never skews a campaign’s numbers.
Transactional questions
Something not covered here? Ask us, or read the transactional guide.
Is transactional email included on every plan?
Yes. Transactional email and push are on every plan, with the API, webhooks and templates.
Which channels can one request use?
Email and push. Give both and choose: every channel the customer can receive, or one first and the other as a backup. With push first, the email waits and goes only if the push fails or is skipped; if the push is sent, the email is never charged.
Will a receipt go to someone who unsubscribed from marketing?
Yes. Transactional mail doesn’t follow marketing preferences. It still isn’t sent to an address that bounced, or that marked a transactional email as spam, and every send passes Kirora’s safety and usage checks.
What stops a message being sent twice?
An idempotency key. A retry with the same key and the same request body gets the existing message back, as it stands now, without another send. The same key with a different body is refused. The key is optional, but without one a retry after a timeout can send twice.
How do I test without emailing real people?
Send to addresses at example.com or other reserved domains. They pass every check, then stop, and three of them act out a delivery, bounce or complaint so you can test your webhooks.
Can I send marketing through it?
No. Promotions belong in campaigns, which check marketing consent and add an unsubscribe link. Campaigns can also be sent from your code to a list of up to 5,000 contacts, each with their own details.
Build your next customer campaign with Kirora.
Create a free workspace, verify your sending domain and import your contacts. Build a campaign or automate a welcome journey, then review it before sending.
See our Acceptable Use Policy, Terms and Privacy Policy.