Quickstart
Create an endpoint, point a provider at it, and watch the first delivery land.
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.
What do I need before starting?
An account, a destination URL that accepts POST requests over HTTPS, and a provider that sends webhooks. Nothing to install, no library, no agent.
How do I create an ingest endpoint?
Create one from the dashboard. You get a URL shaped like this:
https://hooks.shellorbit.com/e/ep_7f3a91
That URL is the address you give your provider. Treat it as a credential: anyone holding it can post events to your endpoint.
How do I send a test event?
Post anything to the endpoint. A JSON body is typical but not required, since the raw bytes are stored either way.
curl -X POST https://hooks.shellorbit.com/e/ep_7f3a91 \
-H 'content-type: application/json' \
-d '{"event":"invoice.paid","id":"evt_test_1"}'
A successful receipt returns 202 with the event id we assigned:
{ "id": "evt_9c41f0", "received_at": "2026-09-03T12:04:01.412Z" }
The 202 means stored, not delivered. Delivery happens on the queue immediately afterwards.
How do I set the destination?
Add a destination URL to the endpoint in the dashboard. From that point every received event is queued and delivered there, with your retry policy applied. Until a destination exists, events are stored and held, which is a useful way to capture traffic before your handler is written.
How do I know it worked?
The event log shows the event with its delivery state and attempt count. Open the event to see the raw headers and body we received, and every attempt with its status code, response time, and response body excerpt.
What should my handler do?
Answer fast and answer with a 2xx. Anything else is treated as a failed attempt and retried.
- Return 2xx as soon as the event is safely stored on your side, then do slow work asynchronously.
- Tolerate duplicates. Delivery is at least once, so use the event id as an idempotency key.
- Do not depend on ordering. Retries mean a later event can arrive before an earlier one that is still failing.
What comes next?
Read delivery and retries before production traffic, then limits and overage so the first busy week holds no surprises.