Email your app can actually send.
No mail provider to sign up for, no API key to paste, no domain warm-up on day one. Every project can send from its first deploy, receive mail at a real address, and put both on a schedule.
One sentence becomes a standing job.
A recurring email is two small files: a schedule line and a handler. Your agent writes both, deploys, and it runs from then on without a machine of yours staying awake.
// runs Mondays at 13:00 UTC
[[cron]]
path = "/api/jobs/weekly-digest"
schedule = "0 13 * * 1"import { db, email } from 'hatchable';
export const access = 'scheduler';
export default async function (req, res) {
const { rows } = await db.query(
`SELECT name, created_at FROM customers
WHERE created_at > now() - interval '7 days'`
);
await email.send({
to: 'you@example.com',
subject: `${rows.length} new signups this week`,
html: render(rows),
text: renderText(rows),
});
res.json({ sent: 1 });
}The whole mail stack, minus the stack.
Sending, receiving, scheduling, and the unglamorous deliverability work that decides whether any of it reaches an inbox.
Working from the first deploy
One call with a recipient, a subject, and a body. Every project starts with its own sender address, so the first email works before you have configured anything at all.
Receipts, confirmations, password resets, alerts.
Mail that looks like you
Verify a domain you own and your app sends as that address, with the authentication records set up for you. Reply-to, cc and bcc, threading, and attachments unlock with it.
support@yourcompany.com instead of a platform subdomain.
Your app has an inbox
Mail sent to your project arrives as a normal request, already parsed into sender, subject, body, and attachments. Your app decides what to do with it.
A support inbox that files each message as a ticket by itself.
Digests that send themselves
Declare a schedule in your project and the platform runs it. Nothing of yours has to stay awake, and there is no queue service to keep alive.
Weekly summaries, monthly invoices, morning reminders.
The boring part, handled
Authentication records, bounce and complaint processing, and sender reputation isolation are managed for you. Each verified domain sends on its own reputation, so a noisy neighbour cannot drag yours down.
You write the message. We handle whether it arrives.
Change the copy by asking
The wording of every email your app sends lives in your project, so editing it is a sentence to your agent rather than a ticket for whoever built it.
"Make the welcome email warmer and mention the setup guide."
The spec sheet, including the limits.
Numbers current as of August 2026 and enforced by the same table the pricing page renders from.
Say it like this.
Ordinary sentences that turn into working mail, on both directions of the wire.
Asked and answered.
Do I need a Postmark or SendGrid account?
No. Sending is part of the platform. There is no mail provider to sign up for, no API key to paste, and no separate bill. Your app says what goes to whom and the message goes out.
What address does my app send from?
By default your app sends from its own address on hatchable.site, using your project name as the sender name. You can claim a free address on hatchable.email in one click, or verify a domain you own and send as that instead.
Can my app receive email too?
Yes. Mail sent to your project's address is delivered to your app as a normal request, already parsed into sender, subject, body, and attachments. Support inboxes, reply-by-email, and forward-to-file all work.
Who can my app email on the free plan?
From the shared platform address, a free project can email you, your collaborators, and anyone who has emailed it first. That keeps the shared sending reputation clean. Verifying a domain you own removes the limit and lets you email anyone.
Will the email land in the inbox?
Deliverability is the platform's job. Authentication records, bounce and complaint handling, and sender reputation isolation are all managed for you, so one noisy app cannot damage another's sending. What you control is the content, and that part still matters.
Can I send a newsletter to thousands of people?
Volume is capped per plan and sends are rate limited per minute, so bulk mail goes out in scheduled batches rather than one burst. That is a deliberate deliverability choice, not a missing feature. For genuinely large lists, a dedicated bulk sender is still the right tool.
More detail lives in the SDK reference and the pricing table.
Just ask it to send.
Connect the AI you already use, describe what should go out and when, and the mail starts working on the next deploy.
Want the technical surface? The SDK reference covers email.send and the scheduler.