Alert Destinations

Alert destinations let you route platform alerts to an external endpoint -- a webhook URL or a Slack incoming webhook. When a monitored event occurs (bounce rate spike, sender pause, reputation warning), Molted posts a notification to each active destination.

Alerts are evaluated on a schedule (about once a minute) for every tenant with at least one active destination, so a firing alert reaches its destination without anyone needing to poll alert status first. Checking alert status still notifies too, so an in-progress incident is never more than a status check away.

A destination is notified when which conditions are firing changes -- a new condition starts firing, one clears, or severity escalates -- not on every evaluation. An unchanged firing state gets at most one reminder notification per day. Recovery to ok never sends a notification itself, but resets the state so the next time something fires (even if it looks identical to before) notifies right away. This keeps one stuck condition from posting to your destination every few minutes all day, while still surfacing a real change immediately.

Create a destination

POST https://api.molted.email/v1/agent/alerts/destinations

curl -X POST https://api.molted.email/v1/agent/alerts/destinations \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "type": "webhook",
    "url": "https://hooks.example.com/molted-alerts"
  }'

{
  "id": "dest_abc123",
  "type": "webhook",
  "url": "https://hooks.example.com/molted-alerts",
  "isActive": true,
  "createdAt": "2026-03-31T12:00:00Z"
}

For Slack, use the incoming webhook URL from your Slack app configuration.

url must be a public http:// or https:// address; it's rejected (400) if it embeds credentials or resolves -- as a literal IP or via DNS -- to a private, loopback, link-local, or otherwise internal/reserved address (including cloud metadata endpoints like 169.254.169.254). This is re-checked on every alert delivery, not just at creation, and redirects are re-validated the same way rather than followed blindly.

List destinations

GET https://api.molted.email/v1/agent/alerts/destinations

curl https://api.molted.email/v1/agent/alerts/destinations \
  -H "Authorization: Bearer YOUR_API_KEY"

Delete a destination

DELETE https://api.molted.email/v1/agent/alerts/destinations/:id

curl -X DELETE https://api.molted.email/v1/agent/alerts/destinations/dest_abc123 \
  -H "Authorization: Bearer YOUR_API_KEY"

Send a test alert

Send a clearly-labelled test alert to one destination, to verify it's reachable and configured correctly. This bypasses the change-based notification logic above -- a test send never gets suppressed by, and never suppresses, a real firing alert. It has its own short throttle instead (one test send per destination per 30 seconds) to prevent abuse; a request within that window gets a 429.

POST https://api.molted.email/v1/agent/alerts/destinations/:id/test

curl -X POST https://api.molted.email/v1/agent/alerts/destinations/dest_abc123/test \
  -H "Authorization: Bearer YOUR_API_KEY"

{
  "success": true,
  "responseCode": 200,
  "error": null,
  "deliveryId": "del_xyz789"
}

List delivery attempts

GET https://api.molted.email/v1/agent/alerts/destinations/:id/deliveries

curl https://api.molted.email/v1/agent/alerts/destinations/dest_abc123/deliveries \
  -H "Authorization: Bearer YOUR_API_KEY"

Returns the most recent delivery attempts (real and test) for that destination, newest first, each with status (success or failure), responseCode, error, and createdAt.

Check alert status

Get the current alert status for your tenant -- any active alerts, severity, and the event that triggered them.

GET https://api.molted.email/v1/agent/alerts/status

curl https://api.molted.email/v1/agent/alerts/status \
  -H "Authorization: Bearer YOUR_API_KEY"

Portal management

The routes below are for a signed-in human in the portal (cookie session). They are human-only: an agent, including an agent-held cookie session, gets 403 human_required and should use the /v1/agent/alerts/destinations routes above with its API key instead.

Related reading

• Domains -- domain setup and verification
• Rate Limits -- send quota monitoring