Email

Available

The Email service sends transactional email — sign-up confirmations, password resets, magic links, receipts, order updates, security alerts — through a small JSON-over-HTTPS API.

You authenticate with an API key, POST a payload, and track every message through delivery webhooks and the dashboard.

Pricing & plans

Comparing options or looking for the free tier? See plans, specs and pricing on the transactional email service page.

Transactional only

Runsite Email is built and tuned for one recipient (or a few) at a time, triggered by something a user did inside your app. It is not a bulk-email or marketing platform.

Allowed	Not allowed
Sign-up & verification emails	Newsletters and promotional blasts
Password resets, magic links, MFA codes	Mass marketing campaigns
Receipts, invoices, payment confirmations	Bulk announcements to lists you bought, scraped or imported
Order, shipping and account-status notifications	Cold outreach, sales prospecting
Per-user system alerts (security, errors, mentions)	Anything sent to recipients who didn’t explicitly request your product

Hard limit: up to 50 recipients per request across to, cc and bcc combined. There is no broadcast / list / segment functionality.

What you get

A dashboard in your workspace to create email services, manage sending domains, generate API keys, configure webhooks and watch delivery stats.
A public REST endpoint at https://api.runsite.app/emails that any backend (or HTTP client) can call directly.
Bring your own domain — verify with SPF + DKIM + DMARC and send from any address on your domain (hello@yourdomain.com, noreply@app.example.com, …).
Sandbox mode for safe development — a shared sender address that delivers only to recipients you explicitly verify.
Webhooks for delivery / bounce / complaint events with HMAC-signed payloads.

Concepts


Email service	A logical sender, scoped to your workspace. You can have several — one per app, one per environment (dev / staging / prod). Each service has its own API keys, domains, sandbox settings and stats.
Sending domain	A domain you own that has been verified (DNS records) for sending email.
API key	The credential clients send in the `Api-Key:` header to authenticate. Looks like `rs_eml_…`.
Sandbox mode	A safety mode every new service starts in. Delivers only to recipients you’ve explicitly verified, so you can build and test without spamming real users.
Production mode	Unlocked once you have at least one verified sending domain. Lets you send `From:` your domain to anyone.
Webhook	Your HTTPS endpoint that Runsite POSTs delivery events to. Each call is HMAC-signed.

Sandbox vs production at a glance

	Sandbox mode	Production mode
Default for new services	✅	—
Need a verified domain?	❌	✅
Who can receive?	Only recipients you explicitly verified inside the service	Anyone
`From:` address	Shared sandbox sender (`onboarding@runsite.app`)	Any address on your verified domain
Daily limit	Low — meant for development	Per-service quota that grows with reputation

Endpoint

There is one public endpoint for sending email:

POST https://api.runsite.app/emails
Api-Key: rs_eml_…
Content-Type: application/json

Everything else (creating services, adding domains, managing keys, configuring webhooks, viewing stats) lives behind the dashboard.

Where to next

Dashboard — every tab on an email service.
Sending domains — verify your domain with SPF / DKIM / DMARC.
Sandbox mode — test without spamming, then go to production.
API keys — issuing, scoping, rotating credentials.
Sending emails — endpoint, payload, full code examples.
Webhooks — delivery events and signature verification.

Need to send marketing or bulk email?

Runsite Email is for transactional traffic only. For newsletters, drip campaigns and segmented marketing use a dedicated marketing platform — they handle list management, unsubscribe, deliverability and reporting that bulk email needs.