An order moved into processing

Fires when an order moves from reserved into processing — its outcome was not immediate —
at most once per order, for that first move only. An order delivered at the first attempt goes
straight from reserved to fulfilled and never sends it; a referral for review is announced by
order.under_review, not by this event. data.status is always processing.

Treat it as a progress signal: the wallet reservation is being spent and an outcome event
(order.fulfilled, order.failed or order.refunded) will follow, possibly after
order.under_review. Nothing needs to change in your system yet unless you surface progress to
your own users.

Delivery contract — every Xegora webhook is delivered the same way:

HeaderValue
X-Xegora-Event-IdYour dedupe key — the envelope id without dashes (32 lowercase hex). Identical on every retry.
X-Xegora-TimestampUnix seconds at send time; reject if more than 5 minutes from your clock.
X-Xegora-Signaturev1=<64 lowercase hex> — HMAC-SHA256 over {X-Xegora-Timestamp}.{X-Xegora-Event-Id}.{raw body} keyed with your endpoint's xgwh_… secret.
X-Xegora-Delivery-Contractxegora-webhook-at-least-once-v1

Acknowledge with any 2xx within 5 seconds; redirects are not followed, and endpoints
must be public HTTPS on port 443. Delivery is at-least-once: dedupe durably by
X-Xegora-Event-Id. A non-2xx or timeout is retried with exponential backoff (5 s,
doubling per attempt — up to 8 attempts over roughly 11 minutes), except that a 4xx other
than 401/403/404/408/410/425/429 counts as a permanent rejection and stops retries.
Exhausted or rejected deliveries are parked for operator review — never silently dropped.
Retries can interleave across events, so order by the payload's occurredAtUtc or re-read
the API as the source of truth. Fulfillment artifacts and buyer personal data never appear
in webhook payloads. An endpoint receives only the event types it is subscribed to.

Payload

Envelope for order.processing — emitted at most once per order, the first time it moves from reserved into processing.

uuid
required

Stable event id (UUID), derived from the order and the event type. The X-Xegora-Event-Id header carries the same value without dashes — dedupe on the header form.

const
enum
required
Allowed:
date-time
required
data
object
required

The order snapshot every order event carries.

Headers
string
required
^[0-9a-f]{32}$

The event's stable unique id — your deduplication key, identical on every retry. It is the envelope's id without dashes (32 lowercase hex characters), and it is the exact string signed inside X-Xegora-Signature.

string
required
^[0-9]+$

Unix seconds at signing time — your freshness check. Reject deliveries more than 5 minutes from your clock.

string
required
^v1=[0-9a-f]{64}$

v1= followed by 64 lowercase hex characters: HMAC-SHA256 over the UTF-8 string {X-Xegora-Timestamp}.{X-Xegora-Event-Id}.{raw body}, keyed with your endpoint's xgwh_… signing secret. Verify over the raw request bytes with a constant-time comparison.

const
enum
required

The delivery-contract version — currently always xegora-webhook-at-least-once-v1.

Allowed:
Response
200

Acknowledged — any 2xx accepts the event. Non-2xx responses and timeouts trigger the retry schedule described above.

LoadingLoading…