Core concepts
The nouns Outemit uses everywhere: dashboard, API, portal, and docs. Learn Retry vs Replay before you wire support runbooks.
Domain model
| Concept | Meaning | ID |
|---|---|---|
| Organization | Billing + members workspace | org_ |
| Environment | test or live (hard segregated) | - |
| Application | One of your tenants who receives webhooks | app_ |
| Endpoint | HTTPS URL owned by an application | ep_ |
| Event type | Catalog entry like invoice.paid | - |
| Message / Event | Immutable payload you emit once | evt_ |
| Delivery | One HTTP try path to one endpoint | dlv_ |
| Attempt | One HTTP request inside a delivery | att_ |
| Signing secret | Per-endpoint HMAC secret | whsec_ |
| API key | Server key for ingest / management | sk_test_ / sk_live_ |
An organization owns many applications. Each application owns endpoints subscribed to event types. When you emit a message, Outemit creates one delivery per matching endpoint, and each HTTP try is an attempt.
Environments
Test and Live are hard segregated: separate applications, endpoints, messages, deliveries, and API keys. The dashboard switcher flips the entire workspace view. Keys are never interchangeable across environments.
Retry vs Replay
Retry
Re-attempt the same message to the same endpoint. Adds a new attempt on the existing dlv_. API: POST /api/v1/deliveries/:id/retry
Use when the receiver was briefly down, returned 5xx, or you fixed the receiver and want another try of the same delivery path.
Replay
Re-run the message through the pipeline for currently subscribed endpoints. Creates new delivery rows (can fan out to endpoints added after the original ingest). API: POST /api/v1/messages/:id/replay
The customer portal exposes Replay only. Use when you need a fresh fan-out, not another attempt on one delivery.
Loading diagram...
See also the retry and replay glossary entries.
Idempotency
- Emit: send
Idempotency-Key(header or body). Retried HTTP calls with the same key return the original message instead of creating duplicates. - Queue consumers: at-least-once delivery is safe because attempt processing is idempotent on delivery/attempt keys.
- Receivers: treat
webhook-idas the dedupe key for your side effects.
Delivery pipeline
- API accepts the message, stores payload in object storage, metadata in D1.
- Queue message carries the storage key only (keeps queue payloads small).
- Worker signs the body (Standard Webhooks), POSTs to the endpoint, records attempt + response.
- On retryable failure: exponential backoff. Non-429 4xx stops infinite retries.
- After N consecutive failures the endpoint can auto-disable and raise an Issue.