Send a transactional email
Get an order confirmation or a sign-in code into an inbox within seconds, sent from your own domain so your name shows instead of a stranger's, with a delivery result telling you it really landed. Pay per use, no subscription.
This task is not available right now, so it cannot be purchased. Nothing is charged for it.
How it works & APIfrom your domain, with delivery events
Transactional email, not newsletters
Email from an application does two very different jobs. Newsletters can wait; a password reset, a receipt or a sign-in code cannot, because someone is staring at their inbox waiting for it. This tool is built only for the second job. It leaves out mailing lists, unsubscribe pages and campaign scheduling, so each message travels a short path and leaves fast. You give the recipient, the subject, a plain or formatted text and the sender address on your verified domain; the message is queued at once and sent a moment later, even during bursts of activity.
Where it fits and common slips
Typical uses are order confirmations sent the moment a payment clears, one-time sign-in codes that must arrive within seconds, and internal alerts, such as a failed payment or a stock shortfall, sent straight to the on-call inbox. Because the mail leaves from your own domain, it carries your name. The usual slips are trying to send marketing campaigns through it, using a sender address outside a verified domain, and assuming that an accepted request means the message arrived: check the delivery result before telling a customer it is on its way.
What you can do with it
Order confirmations
The moment a payment clears, a confirmation with order details goes out from your own domain, and the delivery event tells you it actually landed.
One-time login codes
A magic-link or code-based sign-in sends the message the instant it's requested, keeping the whole authentication flow inside a few seconds.
Internal ops alerts
A background job that detects a failed payment or an inventory shortfall emails the on-call inbox directly, no dashboard required.
FAQ
Is this free to use?
There's no free tier — free tiers get abused and slow everyone down. No subscription, no tokens, no invented credits, and a failed task is never charged.
What happens if the send fails?
The system retries automatically up to three times; only after that does it return a clear error, and you're never charged for a failed task.
How is this different from a bulk email tool?
It has no list management, no unsubscribe flows and no campaign scheduling — it's purpose-built for single, time-sensitive transactional messages, not marketing sends.
Can I send from my own domain?
Yes. Messages go out from a sender address on your verified domain, so the inbox shows your name rather than a generic sender shared with strangers. Without a verified domain, the message is recorded but not sent.
How do I know the email was delivered?
Each send is tracked on its own. The outcome comes back to your system through a signed notification, or you can check it through a signed link that stays valid for 24 hours, so you know the message landed and not only that it was queued.
Related tools
For developers — API access
Everything on this page is available programmatically. This section is for teams who want to wire it into their own systems; everyone else can just use the tool above.
API endpoint
One authenticated POST creates the task; the result comes back by webhook or a signed link. This capability is currently available through the API, not as an interactive Web tool.
Call it from your stack
curl -X POST https://api.kit.forhosting.com/notify/email \
-H "Authorization: Bearer $KIT_KEY" \
-H "Content-Type: application/json" \
-d '{"to":"ada@example.com","subject":"Tu informe"}'const res = await fetch("https://api.kit.forhosting.com/notify/email", {
method: "POST",
headers: {
"Authorization": `Bearer ${process.env.KIT_KEY}`,
"Content-Type": "application/json"
},
body: JSON.stringify({
"to": "ada@example.com",
"subject": "Tu informe"
})
});
const { task_id } = await res.json();import os, requests
res = requests.post(
"https://api.kit.forhosting.com/notify/email",
headers={"Authorization": f"Bearer {os.environ['KIT_KEY']}"},
json={
"to": "ada@example.com",
"subject": "Tu informe"
},
)
task_id = res.json()["task_id"]<?php
$res = file_get_contents("https://api.kit.forhosting.com/notify/email", false, stream_context_create([
"http" => [
"method" => "POST",
"header" => "Authorization: Bearer " . getenv("KIT_KEY") . "\r\nContent-Type: application/json",
"content" => '{"to":"ada@example.com","subject":"Tu informe"}',
],
]));
$task = json_decode($res, true);body := bytes.NewBufferString(`{"to":"ada@example.com","subject":"Tu informe"}`)
req, _ := http.NewRequest("POST", "https://api.kit.forhosting.com/notify/email", body)
req.Header.Set("Authorization", "Bearer "+os.Getenv("KIT_KEY"))
req.Header.Set("Content-Type", "application/json")
res, _ := http.DefaultClient.Do(req)Example request
{
"to": "ada@example.com",
"subject": "Tu informe"
}Example response
{
"task_id": "tsk_a1b2c3d4e5f6a1b2c3d4e5f6",
"type": "notify.email",
"status": "queued",
"_links": {
"result": "/tasks/tsk_…/result"
}
}The API is asynchronous: the call returns a task_id immediately and the result arrives by webhook. Polling is capped at 1 req/s per task.
Pricing
Published price — no tokens, no invented credits. A failed task is never charged.
Errors
| HTTP | Code | Meaning |
|---|---|---|
401 | unauthorized | Missing or invalid API key. |
402 | insufficient_balance | Your balance doesn't cover the task price. |
404 | unknown_type | That task type doesn't exist. |
429 | rate_limited | Too many requests. Use the webhook instead of polling. |
Technical notes
POST /notify/email sends a single message from your own domain and hands you back a task_id while the message actually leaves the queue. It exists for the moment a password reset, an order confirmation or a login code has to reach an inbox within seconds, not for marketing blasts.
Built for the message that can't wait
Application email splits into two very different jobs: bulk newsletters that tolerate a delay, and transactional messages — password resets, receipts, verification codes — that a user is staring at their inbox waiting for. This endpoint is built only for the second job. It skips list management, unsubscribe pages and campaign scheduling entirely, so the request path stays short and the delivery stays fast.
What the call actually does
Nothing about the process is synchronous, which is precisely why it holds up under bursts. You send recipient, subject, a plain-text or HTML body, and the from address on your verified domain; the API validates the payload, queues the send and immediately returns a task_id. The real delivery attempt happens on our global edge a moment later, and you get the outcome back through a signed webhook (recommended for anything running unattended) or a signed link that stays valid for 24 hours.
Domain authentication, not a shared reputation
Because you send from your own domain, the mail carries your name in the inbox, not a generic sender shared with strangers. That single fact is what separates a transactional API worth trusting from a marketing tool bolted onto a REST endpoint: your domain's sending reputation stays yours to build, protect or repair, and you're not sitting behind someone else's abuse history.
Delivery events close the loop
Sending is only half the story — the webhook payload also reports what happened after the send: accepted, delivered, bounced or failed. That event is what lets your system retry intelligently, flag a bad address, or simply mark an order as confirmed once it clears the recipient's server, instead of guessing based on silence.
Where it sits in an automated stack
A failed task is never billed — three retries happen automatically before you see a clear error, so you can wire this endpoint straight into a checkout flow, a signup form or an internal alert without wrapping it in your own retry logic first. It's one call in a pipeline, not a platform you have to configure.
Integration use cases
Password reset links
A user requests a reset; your backend calls the endpoint the instant the token is generated, and the link is in their inbox before the page finishes redirecting them.
Technical questions
How much does it cost?
$0.002 per request plus $0.0035 per email sent. A failed task is never charged.
Can I send from my own domain?
Yes, that's the whole point of the endpoint — messages send from a domain you've verified, not from a shared address.
How do I get the result — sync or async?
The call is asynchronous: you get a task_id immediately, and the outcome arrives via a signed webhook or a signed link valid for 24 hours.
What delivery events does it report?
Accepted, delivered, bounced and failed states are reported through the webhook so you can react to what actually happened after the send.
Can I send HTML and plain text together?
Yes, the payload accepts both an HTML body and a plain-text fallback in the same request.