You POST. We deliver. You can prove it.
Calder is the email layer for apps that can’t afford “did they get it?” — OTPs, verification links, password resets, receipts. One endpoint, or plain SMTP if that’s your world. Honest statuses, and every event on the record.
No domain? No problem — start with Gmail, graduate when you grow.
How it works
Most email APIs are a black box with a prayer inside.
Here’s ours with the lid off: your request is validated, stored, and queued in milliseconds — then a worker walks the email to the provider and writes down everything that happens.
Two ways in
Use the interface you already know.
Modern app? POST JSON. Existing stack, WordPress, Laravel, cron scripts? Point your SMTP client at us. Either way there’s no mail server to run, no queue to babysit, no retries to implement — and delivery lands in the same observable pipeline.
POST /v1/emails → 202
{ "id": "em_9f2k41xq", "status": "queued" }host: smtp.calder.click
port: 587 (STARTTLS)
user: <project username>
pass: <generated secret>
→ 250 Queued (same pipeline)Start without a domain
Sixteen and learning Next.js? Send email today.
No domain to buy, no DNS to decipher, no SMTP server to babysit. Connect the Gmail account you already have — through Google’s own authorization, never your password — and send through the same API, logs, and events as everyone else. When the project grows up, verify a domain and graduate. Nothing rewrites.
$ curl https://api.calder.click/v1/emails \
-H "Authorization: Bearer calder_sk_test_…" \
-d '{"from":"myproject@gmail.com","to":"customer@example.com","subject":"Welcome!","html":"<h1>Welcome!</h1>"}'
// SDKs (npm install calder) land with v1 — the API above is stable now.How you start
Gmail sending is capped and rate-limited on purpose — it’s the on-ramp, not bulk infrastructure. Limits are always visible before you hit them. Full walkthrough: Gmail Quickstart →
Developer experience
Your first delivery in about five minutes.
No sales call, no credit card, no DNS homework to start. Test keys simulate the whole pipeline — queue, provider, events, webhooks — without a single real inbox involved.
- 01Grab a test key. Prefixed, revocable, hashed at rest. Lives in your .env in seconds.
- 02POST your email. Get a 202 back in milliseconds with an id you can track forever.
- 03Watch the webhook land. Signed, retried, and inspectable — proof of delivery, not vibes.
$ curl https://api.calder.click/v1/emails \
-H "Authorization: Bearer calder_sk_live_…" \
-H "Idempotency-Key: welcome-user-4815" \
-d '{
"from": "app@acme.com",
"to": "ada@example.com",
"subject": "Verify your email",
"html": "<p>Your code…</p>"
}'// 202 Accepted
{
"id": "em_9f2k41xq",
"status": "queued"
}
// …moments later, your webhook receives:
{
"event": "email.delivered",
"data": { "email_id": "em_9f2k41xq" }
}Why Calder
Sending an email is easy. Sending it exactly once, knowing it arrived, and proving it later — that’s the actual job.
Your API never waits on a mail server
Providers throttle, networks stall — that’s not your request’s problem. We persist, queue, and answer in milliseconds; delivery happens somewhere built to wait around.
Nobody gets two receipts
Your request timed out. Did it send or not? Hand us an Idempotency-Key and a retry returns the exact same result — same key, same outcome, one email.
- POST →
- 202 · created em_9f2k41xq, result stored
- POST ↻
- 200 · same key → original result replayed
- emails sent
- exactly one — that’s the whole point
Webhooks that show their work
A webhook that fires once into the void isn’t infrastructure — it’s a wish. Every send fans out signed, retryable events you can actually inspect.
“I never got the email.” Now you have an answer.
Every response carries a request ID. Every email gets a timeline from creation to open.
Your domain, verified. Your reputation, visible.
An email from you@yourproduct.com lands differently than one from a shared sending service — in the inbox and in the reader’s head. Verify with DNS, then watch what it earns you.
The signal
Every send emits a lifecycle. Every lifecycle is observable.
queued → sent → delivered → opened → clicked · bounced · complained · failed
The product
Everything in the box, nothing you have to glue together.
Providers, DNS, queues, retries, webhooks, suppression, billing — the fragmented mess scattered across providers, DNS consoles, queues you built yourself, and billing spreadsheets — already assembled into one dashboard and one API.
One account, every app and stage
Organize sending by organization, then split into projects — production, staging, that side-project. Test keys behave exactly like live ones except nothing ever leaves the building.
- Separate test and live API keys per project
- Per-project logs, events, and rate limits
- Revoke and rotate keys without touching code
- keys
- calder_sk_test_… · calder_sk_live_… — hashed, revocable
- isolation
- every query scoped to its project, always
Your name on every send
Paste three DNS records, wait for propagation, done — no redeploy required.
Emails your designer would sign off on
Versioned templates with variables, previews, and publishing — so “can you tweak the receipt?” stops meaning a code deploy. We’re building this right after the delivery core is bulletproof.
- Variables like {{ first_name }} with safe defaults
- Version history and one-click rollback
- Test sends before anything goes live
Know what it costs before finance asks
Every send is metered from the same durable records as everything else — not a counter that drifts. Watch usage climb toward your plan in real time, in naira or dollars, with hard limits instead of surprise overages.
- Live usage against plan quotas
- Invoices that match your dashboard, always
- NGN and USD plans with receipts included
Pricing · hypothesis, not promise
Priced for where you build.
Naira-first plans a Nigerian builder can actually pay — no per-seat arithmetic, no overage traps. Usage is metered from the same durable records as everything else, so the invoice always matches your dashboard. Final numbers lock after our unit-economics review.
3,000 emails / mo
- Gmail connection for beginners
- 1 custom domain
- API + SMTP + SDK
- Templates + basic logs + 1 webhook
~25,000 emails / mo
- Everything in Free
- 5 domains + campaigns
- Multiple webhooks
- Better retention
~75,000 emails / mo
- Everything in Builder
- 20 domains + improved analytics
- Larger retention
- Team functionality
~250,000 emails / mo
- Everything in Pro
- Significantly higher limits
- Advanced analytics
- Priority support
Hypothesis under unit-economics review (docs/PRICING.md) — locked plans publish at launch. Hard limits, no surprise overages. USD equivalents set at launch parity.
Get started
Go get your first delivery.
Not your first signup form, not your first dashboard tour — your first email, landing in an inbox, with the webhook to prove it. Test keys are free and can’t hurt anything. The only thing standing between you and that little delivered tag is one POST request.