Payload

Topic and body type

All four topics support payload versions v1 and v3; the selected registration version controls the body shape. The registration topic is not always the body type: a receiver that switches on type must handle tracking_order_updated for tracking_updated and order_cancelled for order_canceled, or it will drop its own events.

HTTP delivery

Gearment sends a POST request to the registered delivery URL with Content-Type: application/json. Only active store-level webhooks matching the event team, store, and topic receive a request; delivery is skipped when the team has no default credentials.

See Signature construction logic and Verifying a payload for the authentication details.

Retries, timeout, and success

Each HTTP attempt has a 10 second timeout, subject to earlier context cancellation. Gearment makes at most four attempts: the initial attempt and three retries, fixed 2 seconds apart. It retries transport errors, including timeouts, and HTTP 5xx responses only; every HTTP 2xx response is success. HTTP 4xx responses, including 429, and terminal 3xx responses are not retried. After the fourth failure, the event is dropped with no replay, so receivers must be idempotent and must not wait for a later retry. The timestamp, nonce, body, and signature are reused across retries.

Serialization

Every map key shown in the topic contracts is emitted, including keys whose value is "". tracking_list is always an array; absent input is [], not null. JSON object member order is not contractual.