Dashboard

Open Email in your workspace sidebar to see all email services. Each service is a logical sender with its own keys, domains, webhooks and stats — one per app or per environment is the typical setup.

Email services list

The list page shows every service with a status badge:

• Sandbox — service is in sandbox mode (delivers only to verified recipients).
• Production — service has a verified sending domain and can send to anyone.

The New Service button opens a dialog where you give the service a name (up to 64 characters, unique within your workspace). Optionally you can pre-verify your own email so it works as a sandbox recipient right away.

Service detail page

Inside a service there are five tabs.

Overview

The Overview adapts to the service’s mode.

Sandbox overview (no verified domain yet) walks you through the next steps: create an API key, add a sandbox recipient, send a test, then verify your sending domain to switch to production.

Production overview (after at least one domain is verified) shows:

• Stats — sent / delivered / bounced / complained / opened / clicked counts over a rolling window.
• API keys summary — a quick view with shortcuts to create or revoke.
• Quick send — a code-snippet panel with your endpoint and a key placeholder you can copy in cURL, JavaScript, Python, Node.js, Go or PHP.

Domains

The list of sending domains attached to this service. For each domain:

• Status — pending, verified or failed.
• DNS records — click into a pending domain to see the SPF, DKIM and DMARC records you need to add at your registrar.
• Verify — re-checks the DNS once propagation is done.
• Delete — removes the domain.

The full DNS walkthrough lives at Sending domains.

API Keys

Per-service API keys.

• Create Key — give it a name (e.g. production, staging, ci), the dashboard returns the full key once. Format: rs_eml_… (40 characters total).
• List — shows the prefix (e.g. rs_eml_a8K2…), name, last used timestamp and status.
• Revoke — disables the key instantly. Any client still using it gets 401 Unauthorized on the next call.

Full key management details: API keys.

Webhooks

Per-service webhooks for delivery events.

• Add Webhook — pick a URL and one or more events (delivered, bounced, complained, opened, clicked). On creation Runsite returns a signing secret (looks like whsec_…) — copy it once and stash it in your backend’s environment.
• List — shows URL, subscribed events, status. Toggle off or delete at any time.

Signature format and payload schemas: Webhooks.

Settings

• Service name — rename without losing keys, domains or stats.
• Sandbox mode — read-only indicator. You leave sandbox by verifying a sending domain.
• Danger Zone — Delete Service. Removes keys, domain registrations and history.

One service per environment is the cleanest setup

Spin up myapp-dev, myapp-staging and myapp-prod as separate services. Each gets its own keys (so you can rotate prod independently), its own webhooks (different URLs per env) and its own stats — making it obvious whether traffic is real or test.