Documentation
How Leak Alarm finds leaked keys in your app, repos, and logs, and how the webhook pipeline under it receives, stores, delivers, and replays events.
These pages describe ShellOrbit as it runs today. Breaking changes to the HTTP API are announced before they ship, and existing request and response shapes stay supported.
Start Leak Alarm with verified domains, then scans and tripwires. For webhooks, start with the quickstart if you want an endpoint receiving traffic in the next five minutes. Read the delivery page before you go to production, because retry behaviour is the part that decides what happens on your worst day.
Two ideas run through everything here. First, receipt and delivery are separate: a request is stored before any delivery is attempted, so a failing destination never causes data loss. Second, delivery is at least once, so your handler must tolerate the same event arriving twice.
Leak Alarm
Verified domains
Prove you control a hostname once, then use it for leak scans, custom ingest URLs, or both.
Domain scans
What Leak Alarm checks on your live site, how often, and what it never does.
Tripwires
Fake keys, links, emails, and database rows that tell you the moment something leaked.
GitHub repos
Scan the repos you connect for keys in their full history and in every push, and hear within seconds when one is made public.
Log drains
Stream your platform's logs to ShellOrbit, and keys that reach a log become findings.
JavaScript SDK and DSN
Mask keys in your logs before they are written, and flag responses that carry a secret.
MCP server
Let Claude, Cursor, and other AI agents read findings, fix them in your code, and drive your webhooks.
Revoke and undo
Shut a leaked key at the provider, with ten minutes for you to cancel.
Webhooks
Quickstart
Create an endpoint, point a provider at it, and watch the first delivery land.
Forward events to localhost
Send the real events an endpoint receives to a server on your machine while you build.
Ingest endpoints
What an endpoint is, what it accepts, and how to organise endpoints across providers and environments.
Delivery and retries
How delivery attempts are made, when they are retried, how backoff is calculated, and what your handler must guarantee.
Replay and the dead letter queue
Resend a single event, a filtered range, or everything that failed, using the original bytes.
Alerts and usage warnings
Hear about a failing destination by email, Slack, or Discord, about your allowance before it runs out, and about your week every Monday.
Signature verification
Verify the provider's signature on the way in, and verify ours on the way out.
Payload transformation
Preview a declarative reshape before forwarding.
Custom ingest domain
Receive on your own hostname instead of a shared ShellOrbit URL.
Processing, deduplication, and privacy
Separate HTTP delivery from business completion and build reviewed regression fixtures.
GitHub provider reconciliation
Compare repository webhook history, then approve missing-event redelivery.
Limits, quotas, and overage
What each plan includes, what happens when you pass it, and the technical limits that apply to every plan.
Team, seats, sign-ins, and the audit log
Who can do what in an organization, how seats are counted and charged, and what the audit log and sign-in history record.
HTTP API
Manage endpoints, read events, and trigger replays from your own code.
Send events through the API
Send your own application's webhooks through ShellOrbit and get the same storage, signing, retries, and replay.
Status codes and troubleshooting
What each failure means, which side it comes from, and the first thing to check.