How-to guide
Carry customer context with a GroupKey
When one queue carries events for many of your customers, the GroupKey is the thread that says whose event this is. Queuey extracts it at ingress, keeps it on the event as context, and can forward it to your target — so the customer identity travels end-to-end.
1 — Extract it at ingress
Configure where the GroupKey comes from — a query parameter, a header, or a top-level field in the body. One source per key:
# 1) From a query parameter
POST /events/ten_yourTenant/orders?key=ACME
# 2) From a header
POST /events/ten_yourTenant/orders
X-Customer-Id: ACME
# 3) From a field in the JSON body (envelope)
POST /events/ten_yourTenant/orders
{ "customer": "ACME", "eventType": "order.created", "payload": { ... } }The resolved GroupKey is persisted on the event, so you can filter and observe by customer in the console.
2 — Forward it downstream
Opt in to forward the GroupKey as an outbound header (you choose the name) so your receiver knows which customer an event belongs to:
POST /your/webhook HTTP/1.1
Authorization: Bearer <token>
X-Account-Id: ACME # the GroupKey, forwarded downstream
Content-Type: application/json
{ "eventType": "order.created", "payload": { ... } }Optional: a separate partition key
The lane key can equal the GroupKey, or be extracted separately when you want to order by something finer-grained than the customer (e.g. an account within a customer). Both are derived at ingress from the same header / query / body sources.
Related
- Ordering & per-key lanes — turn the GroupKey into per-customer ordering.
- Core concepts — where context fits in the pipeline.