Documentation
How ShellOrbit receives, stores, delivers, and replays webhooks, and how to drive it from your own code.
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 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.
Quickstart
Create an endpoint, point a provider at it, and watch the first delivery land.
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.
Signature verification
Verify the provider's signature on the way in, and verify ours on the way out.
Payload transformation
Reshape, trim, or enrich the body before it reaches your handler.
Custom ingest domain
Receive on your own hostname instead of a shared ShellOrbit URL.
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, and the audit log
Who can do what in an organization, how seats are counted and charged, and what the audit log records.
HTTP API
Manage endpoints, read events, and trigger replays from your own code.
Status codes and troubleshooting
What each failure means, which side it comes from, and the first thing to check.