Workspace-scoped API keys, and HMAC-signed webhooks that fire when a mailbox's health drops, its DNS changes, its authentication fails, or it pauses itself.
The subscribable events are the ones that mean something is wrong with your sending: a health score dropping, a score hitting the floor, a DNS record changing underneath you, SMTP or IMAP authentication failing, OAuth consent disappearing, a mailbox pausing or resuming itself. These are the moments where minutes matter, and where an email to an address nobody reads is not good enough.
Each payload carries an HMAC-SHA256 signature computed with your subscription's secret, so you can verify it came from us and was not altered. Delivery is attempted three times with a short timeout. A subscription that fails ten times consecutively is disabled rather than retried into eternity — a dead endpoint quietly consuming retries is worse than one that visibly stops.
Webhook endpoints are a classic server-side request forgery vector: give a system a URL and it will happily fetch your internal network. Warmerly requires HTTPS and rejects localhost, loopback and private-range literal addresses outright. The check is on the literal hostname and does not resolve DNS, which is stated plainly rather than implied to be more than it is.
Most outreach tools' APIs exist to push leads in. This one exists mainly to push problems out. The failure mode that costs real money is a mailbox that silently stopped working two weeks ago, and the fix for it is not a better dashboard — it is a signal arriving in the place your team already looks.
There is a version of this feature that fires a webhook on every reply, every open and every click, and it is the version most tools ship. It is also the version that produces a firehose nobody consumes, because reply data is already in the inbox and open data is unreliable enough that acting on it is a mistake.
The events worth waking up for are different in kind: your mailbox lost its OAuth consent, your DKIM record changed, your health score fell through the floor, the system paused a sender because it was doing damage. Each of those has a clear owner and a clear action, and each of them is currently costing you sending capacity for as long as it goes unnoticed.
A mailbox that pauses itself and stays paused is invisible in every aggregate number — total sends drop slightly, and everything else looks normal. Warmerly has seen a mailbox sit unreachable for over two weeks in exactly this way. A webhook into Slack turns that into a two-minute problem.
Each delivery carries a signature computed as an HMAC-SHA256 of the raw request body using your subscription secret. Verification is the standard procedure: take the raw body exactly as received — before any JSON parsing, because re-serialising changes the bytes — compute the HMAC with your secret, and compare against the header using a constant-time comparison.
If the comparison fails, discard the request. Do not process it and log a warning; an unsigned or mis-signed payload arriving at your endpoint is either a bug or someone probing it, and neither is a reason to act on the contents.
Keys are scoped to a workspace, not to your user. That is the right boundary for an agency running several clients in separate workspaces: a key leaked from one client's integration cannot read another client's data. Keys are shown once at creation and stored hashed, so a lost key is replaced rather than recovered.
Sessions and keys are separate concerns and are treated separately. Warmerly's own login no longer issues a long-lived API token as a side effect — a pattern that used to be common and that quietly turned every browser session into a year-long credential. Sessions are server-side and revocable; keys are explicit, listed, and individually revocable.
The common thread is that none of these are analytics. They are operational signals about infrastructure you depend on, and their value is entirely in how quickly they reach a human who can act.
Deliveries are batched per sweep with a per-subscription cap, and the sweep runs on a bounded deadline so it cannot overrun into the next one and re-deliver events against a cursor that never advanced. In practice this means bursts are smoothed rather than dropped, and duplicates are avoided by design rather than by hoping.
You should still make your endpoint idempotent. Every event carries an identifier; keying on it costs nothing and protects you from the general truth that at-least-once delivery is the only kind anyone actually ships.
Mailbox and deliverability events: score_drop, score_floor, dns_changed, auth_fail, smtp_fail, imap_fail, oauth_connected, oauth_disconnected, oauth_reconnected, oauth_refresh_fail, auto_paused, auto_resumed, manual_pause, flagged, aged_in and marked_dead.
Compute an HMAC-SHA256 of the raw request body using your subscription secret and compare it to the signature header with a constant-time comparison. Use the raw bytes — parsing and re-serialising the JSON will change them and the signature will not match.
Each event is attempted three times with a short timeout. After ten consecutive failures the subscription is disabled, so a permanently dead endpoint stops consuming retries. Re-enable it once the endpoint is back.
No. HTTPS is required, and localhost, loopback and private-range literal addresses are rejected. The check inspects the hostname in the URL and does not resolve DNS, so it is a guard against the obvious cases rather than a complete defence.
API key access is plan-gated. The keys and webhooks screen tells you where your workspace stands, and the pricing page lists which tiers include it.
Signed events for the mailbox failures that quietly cost you sending capacity — delivered where your team will actually see them.