Filing as requested by @damaz91 in ucp#570: "The sample … does not comply with how the webhook should be implemented. The canonical shape is the one documented in source/services/shopping/rest.openapi.json. Would appreciate you opening an issue in …/samples to track this."
What happens
Per the spec, the orderEvent webhook's request body is the order object itself — rest.openapi.json defines webhooks.orderEvent.post.requestBody as {"$ref": "#/components/schemas/order"} (verified on current ucp main).
The Python server instead posts a custom envelope (services/checkout_service.py, _notify_webhook):
payload = {
"event_type": event_type,
"checkout_id": checkout.id,
"order": order_data,
}So a platform implementing a spec-conformant webhook receiver gets a shape that doesn't validate: the order fields it expects at the top level are nested under order, alongside two fields the spec doesn't define.
Impact
Platforms building receivers against the sample learn the wrong contract, and receivers built against the spec reject the sample's deliveries — the same class of divergence as the profile/transport mismatches in #133.
Fix sketch
_notify_webhook should post the order object as the body (the event_type/correlation concerns belong to headers or future spec work — cf. ucp#413 on correlation references). Happy to send the PR — it's a small change to _notify_webhook plus updating webhook_test-style coverage on the receiving side.
Filing as requested by @damaz91 in ucp#570: "The sample … does not comply with how the webhook should be implemented. The canonical shape is the one documented in source/services/shopping/rest.openapi.json. Would appreciate you opening an issue in …/samples to track this."
What happens
Per the spec, the
orderEventwebhook's request body is the order object itself —rest.openapi.jsondefineswebhooks.orderEvent.post.requestBodyas{"$ref": "#/components/schemas/order"}(verified on currentucpmain).The Python server instead posts a custom envelope (
services/checkout_service.py,_notify_webhook):So a platform implementing a spec-conformant webhook receiver gets a shape that doesn't validate: the order fields it expects at the top level are nested under
order, alongside two fields the spec doesn't define.Impact
Platforms building receivers against the sample learn the wrong contract, and receivers built against the spec reject the sample's deliveries — the same class of divergence as the profile/transport mismatches in #133.
Fix sketch
_notify_webhookshould post the order object as the body (theevent_type/correlation concerns belong to headers or future spec work — cf. ucp#413 on correlation references). Happy to send the PR — it's a small change to_notify_webhookplus updatingwebhook_test-style coverage on the receiving side.