Webhooks (Outbound)

Gett delivers four outbound webhooks to your system — two that drive the order lifecycle and two optional catalog-sync notifications. Each is a POST to a URL on your server (the Webhook Base URL you set during onboarding), signed per the Standard Webhooks spec. They are the partner-implemented side of the contract: Gett calls you, not the other way around.

Direction

These are Gett → your server. They are not endpoints you call on Gett — for the inbound REST API see the Catalog and Store Status operations.

Contract overview

Webhook	Fires	Request body	Your response
Validate Order	Before the customer pays	`ExternalOrder`	`200` + order with `amounts`
Place Order	After successful payment	`StandardOrderWebhook`	`200` + order with `amounts`
Catalog Sync Succeeded	Catalog ingest went live (optional)	`CatalogSyncWebhook`	any `2xx` ack
Catalog Sync Failed	Catalog ingest failed (optional)	`CatalogSyncWebhook`	any `2xx` ack

All four carry the same Standard Webhooks headers and are verified with the same whsec_… signing secret — one verifier covers every webhook. See Security — Standard Webhooks signing for the headers, algorithm, and ready-to-use verification code.

Validate Order

POST {WebhookUrl}/validate — a price-and-availability check before the customer is charged. No side effects: don't reserve inventory or charge here. Respond 200 with the order including your server-computed amounts, and use the inline errors array for business-logic rejections (never 4xx).

Request — ExternalOrder (no paymentToken)
Response — 200 with ExternalOrder
Full contract, examples & verification code → Order Webhooks

Place Order

POST {WebhookUrl}/place — the point of no return, sent after payment. Reserve inventory and charge here. When Gett tokenized the customer's saved card on your behalf, the body carries paymentToken (a single-use Braintree nonce); it is omitted when you tokenize on your side.

Request — StandardOrderWebhook (ExternalOrder + optional paymentToken)
Response — 200 with ExternalOrder
Full contract, examples & verification code → Order Webhooks

Catalog Sync Succeeded

POST {WebhookUrl}/catalog-sync with type catalog.sync.succeeded — fired when a catalog you pushed has been validated and is now live; data.errors is empty. Optional and best-effort: it fires only when your store has a Webhook Base URL configured, and the catalog-ingest status poll remains the authoritative signal.

Request — CatalogSyncWebhook envelope (type / timestamp / data)
Response — any 2xx (no body required)
Full contract & examples → Catalog Integration

Catalog Sync Failed

POST {WebhookUrl}/catalog-sync with type catalog.sync.failed — fired when a catalog you pushed could not go live because a pull, referential-validation, or generation stage failed. data.errors carries the same sanitized, partner-safe reasons as the status poll. Same optional/best-effort caveat as above.