Getting started
Core concepts
The Queuey mental model in seven pieces. Producers POST events to a queue on a tenant; Queuey applies the policy cascade, forwards to your delivery target, and gives you the operational tooling to handle whatever fails.
- Tenant
- The isolation boundary. Each tenant has its own data and its own queues. Producers address a tenant by its tenantPublicId in the ingress URL.
- Queue
- The unit of configuration and delivery. A queue has a mode (Paused, LogOnly, or Deliver), a delivery target, and a full set of policies. Events flow through a queue on their way to your target.
- Ingress
- Where producers POST events: /events/{tenantPublicId}/{queueName}. Ingress enforces auth (API key or HMAC signed-request), an optional source-IP allowlist, idempotency, and loop prevention before an event is accepted.
- Policy cascade
- Every knob — retries, ordering, payload handling, retention, security — resolves system → tenant → queue, field by field. A queue overrides just the fields it cares about; everything else inherits.
- Delivery target
- The HTTP endpoint a queue forwards to, plus how Queuey authenticates to it: Bearer, API key, Basic, HMAC signing, or OAuth2 client credentials (including private_key_jwt with a P12 certificate).
- Event lifecycle
- An accepted event is Received, then InProgress as the worker attempts delivery, then Delivered on success. Failures retry under the queue's policy and, when exhausted, land in the dead-letter queue (DLQ).
- Issues & operations
- When a target stops responding, Queuey surfaces it as an issue with target-health state, lets you clear and resume a stuck queue, and lets you replay events — so delivery is something you operate, not just attempt.
Next
- Quickstart — send your first event.
- Reliable delivery — retries, idempotency, and the dead-letter queue.