What protects your webhooks

Each password gets its own random salt and is stored only as a scrypt hash — never in plain text, never reversibly. Verification is a constant-time comparison, so the time a wrong password takes doesn't leak how much of it was right.

A signed access token is valid for one hour. Refresh tokens are opaque and stateful — only their hash is stored, and they rotate on every silent refresh, so a captured refresh token stops working once the real client uses its successor.

The one-time code that hands a browser session to the app is valid for two minutes and is consumed on first use. It is bound to the client with PKCE (S256), so intercepting the code alone is not enough to redeem it.

Every authenticated route derives the caller from a cryptographically verified Bearer token. An earlier header-based fallback that let a caller assert an identity to the public API was removed — asserting is no longer a thing the API accepts.

Signing up with an address that already exists returns exactly the same response as a fresh signup. Instead of telling the stranger, we email the real owner that someone tried. The HTTP response cannot be used as an account-existence oracle.

Email-verification and password-reset codes are kept only as hashes with short lifetimes — a day for verification, an hour for a reset. Reading the database does not yield a usable code.

A new key is displayed exactly once, at creation. Only its hash is persisted, so it cannot be recovered from our side — if it is lost, you revoke it and mint another. Keys are capped per account and each can be revoked independently.

Creating a key requires an interactive session, not a key. That closes the path where one leaked credential quietly becomes permanent access that survives revoking the original.

The token-signing secret is per-environment and validated at deploy time: production will not build with the development placeholder or with anything short. This is enforced by the deployment itself, not by a checklist.

Callers present a secret alongside the request. It is verified with a constant-time comparison so the check cannot be turned into a guessing oracle, and it is verified before anything is counted, stored or delivered.

A short-window burst guard blunts floods within seconds regardless of plan; a daily quota tied to your live plan bounds sustained volume; and a webhook that keeps hammering well past its quota is disabled automatically rather than being allowed to bleed cost. Edge throttling sits in front of all of it — the application-level limits are the backstop, not the only line.

Unknown or disabled webhooks are rejected on a single lookup, and a bad secret is rejected before any counter is written. An attacker cannot make rejected traffic expensive.

Callbacks carry an HMAC-SHA256 signature over the timestamp and the raw body, the same way major webhook providers sign their own deliveries. Your receiver can verify the request came from us and not from someone who guessed your URL.

The timestamp is inside the signed string, not merely alongside it, so a recorded delivery cannot be re-sent later with a fresh timestamp — the signature would no longer match. Receivers are told to reject anything outside a five-minute window.

Outbound calls are bounded by a short timeout, so an endpoint that stops responding degrades that one callback instead of holding a request open.

Replying to a message is a conditional write: the first tap wins and a second is refused. A question that has been answered cannot be quietly answered again.

Any request that writes must arrive as application/json. This blocks form-based cross-site request forgery and content-type confusion outright — a hostile page cannot make your browser submit a form that changes your account. (Ingestion is a separate service and intentionally accepts arbitrary webhook bodies.)

The contact and feedback forms send real email, which makes them a target for email-bombing and cost abuse. They are rate-limited per origin, and addresses are validated and length-bounded before anything is sent.

Deleting your account purges the stored request payloads in object storage as well as the database rows. Expiry alone would have left payload objects behind — deletion is explicit about them.

Every message carries a retention window from your plan and expires automatically once it passes. Keeping something longer is a deliberate act — archive it in the app.

You can download everything we hold as JSON, and you can delete the account and all of its data yourself, from Settings, without contacting us first.

Each webhook is pinned to a processing region, so traffic is ingested in the zone you picked rather than wherever it happens to land.