Core concepts

For exact, term-by-term definitions and the object hierarchy, see the Glossary & data model. This page is the prose tour.

Endpoints

An endpoint is an inbound entry you configure and hand to a provider — a slug under the dedicated ingest domain (<ingest-domain>/<slug>), a queue source you write to, or an email alias. Endpoints carry the provider preset (signature verification — applied in the processing plane as a verdict, not at the edge — plus the synchronous handshake the provider expects, answered at the edge) and the routes that fan an incoming request out to one or more destinations.

Destinations & the central registry

A destination is where a delivered event goes: an HTTPS URL, a queue (SQS, SNS, Pub/Sub, Azure Service Bus, RabbitMQ/AMQP, Kafka, NATS, Redis Streams), or the Pull API. Destinations live in a central registry — defined once, referenced by id from many endpoints. Editing a destination updates every reference.

Every destination is validated before it can receive traffic:

1. Schema — the config matches the adapter's JSON schema.
2. Credentials — the secret resolves and authenticates.
3. Connectivity — a live test publish succeeds.

For queue/stream destinations, Emithook publishes using its own managed identity — you grant access with a copy-paste snippet (an SQS queue policy, IAM binding, Kafka ACL, etc.) and never share long-lived keys.

Delivery semantics

• Retries — exponential backoff with full jitter — 8 attempts over ~28 h (immediate, 5s, 5m, 30m, 2h, 5h, 10h, 10h, per-endpoint configurable), then a replayable dead-letter queue. Success = a 2xx within 15 s. See API conventions → delivery semantics.
• Circuit breaker — repeated failures pause a dead endpoint, park events, then probe and recover.
• Idempotency — send with an Idempotency-Key; duplicates within the window collapse to one delivery.
• SSRF protection — outbound HTTP resolves DNS, validates the resolved IP against a private/metadata denylist, pins the connection to that IP (defeating DNS-rebinding), and follows no redirects (3xx = failure).

Signing

Outbound webhooks use the Standard Webhooks spec. The signed content is {id}.{timestamp}.{body}, HMAC-SHA256 with a whsec_ secret, sent as webhook-id, webhook-timestamp, and webhook-signature. Secrets rotate with an overlap window so in-flight messages keep verifying.

Organizations & roles

A user can belong to multiple organizations with a different role in each (Admin, Developer, Viewer). You pick one at sign-in and switch anytime from the console. Endpoints, destinations, domains, members, billing and region are all scoped per organization.

Logs, archive & replay

Every attempt is logged with full request/response detail. Logs are written to an hourly gzipped archive per URL for backup and export, and any event can be replayed — singly, in bulk, or from the archive.