Email 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. Most people run one per app, or one per environment.

Email services list

The list page shows every service with a status badge. Sandbox means the service delivers only to recipients you have verified. Production means it 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 three things: rolling stats for sent, delivered, bounced, complained, opened and clicked; a summary of your API keys with shortcuts to create or revoke one; and a quick-send panel with your endpoint and a key placeholder, copyable as cURL, JavaScript, Python, Node.js, Go or PHP.

Domains

The list of sending domains attached to this service. Each one carries a status of pending, verified or failed.

Click into a pending domain to see the SPF, DKIM and DMARC records to add at your registrar. Once they have propagated, Verify re-checks the DNS. Delete removes the domain.

The full DNS walkthrough lives at Sending domains.

API Keys

Per-service API keys.

Create Key asks for a name (production, staging, ci) and returns the full key once, in the format rs_eml_…, 40 characters in total. After that the list shows only the prefix (rs_eml_a8K2…), the name, the last-used timestamp and the status.

Revoke disables a key instantly. Any client still using it gets 401 Unauthorized on its next call.

Full key management details: API keys.

Webhooks

Per-service webhooks for delivery events.

Add Webhook takes a URL and one or more events: delivered, bounced, complained, opened, clicked. Runsite returns a signing secret (it looks like whsec_…) once, so copy it straight into your backend’s environment.

The list below shows each webhook’s URL, its subscribed events and its status. You can toggle one off or delete it at any time.

Signature format and payload schemas: Webhooks.

Settings

Rename the service here without losing its keys, domains or stats. Sandbox mode is a read-only indicator; you leave sandbox by verifying a sending domain.

The danger zone holds Delete Service, which removes the keys, domain registrations and history along with it.

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, so you can tell at a glance whether traffic is real or test.