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:

extraction sources
# 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:

delivery
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": { ... } }
The GroupKey is also your lane key
Use the GroupKey as the partition key and each customer gets its own ordered lane for free — strict per-customer order, parallel across customers.

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