UCP order webhooks must now sign two more headers. A commit to the Universal Commerce Protocol repository dated October 16, 2026 adds Webhook-Id and Webhook-Timestamp to the signed components. Its message is marked as a breaking change: a signature covering only the baseline components is no longer valid for these deliveries.

This note reads the commit and the spec files it changed. We did not read any platform’s implementation, so nothing here says who has shipped the change.

What changed

An order webhook is how a business tells a platform that an order moved: confirmed, shipped, updated. The commit message explains the gap it closes. Event identity and event time had moved into headers, but those headers sat outside the signed digest, so “the identity and the freshness of an order event travelled unsigned.”

After the commit, per the signatures spec:

  • webhook-id and webhook-timestamp join the list of headers a signature must cover when they are present.
  • A signature that leaves out a header the request carries is treated as unsigned.
  • The commit’s own example now signs ucp-agent, content-digest, content-type, webhook-id and webhook-timestamp together.

What businesses must do

The order specification now says:

  • Both headers are required on the delivery, and platforms reject a delivery whose signature omits either.
  • Businesses MUST send retries with the original Webhook-Id and Webhook-Timestamp, so a retry is the same event, not a new one.
  • Platforms SHOULD deduplicate on Webhook-Id. Because an order webhook carries the full current state of the order, a platform that applies deliveries in timestamp order, or re-reads the order, converges on the right state.

The commit message says the blast radius is “the order event webhook alone”. Checkout and cart requests are not affected.

Why a merchant should care

Most merchants never sign a webhook by hand. Their commerce platform does, and the risk sits with whoever operates the signing code: a platform, an agency integration or a custom headless build.

For those, the failure can be quiet. By the commit’s own terms, an order update signed under the old rule is no longer valid, so a verifier on the new rule rejects it. That is our reading of the spec, not an observed incident: the platform would then miss the update, and the shopper’s agent could not report it.

What we could not verify

The commit is on the repository’s main branch. Our check of the repository tags found no dated release that contains it, so we cannot say which spec version will carry it or when platforms will enforce it.

FAQ

What is Webhook-Id in a UCP order webhook?

It is the identifier of an order event. Per the UCP order spec it stays the same across retries, which is what lets a platform deduplicate repeated deliveries of one event.

Does the UCP signing change apply to checkout and cart requests?

The commit message says the blast radius is the order event webhook alone. The two new headers appear on no other operation in the four service documents, so other requests are unaffected.

What happens to an order webhook signed the old way?

The commit states that a signature covering only the baseline REST components is no longer valid for a delivery carrying Webhook-Id or Webhook-Timestamp. Businesses must add both to the signature input, and platforms must reject deliveries that omit them.

Sources

An agent that buys for a shopper also has to report what happened to the order, and a signed, replay-safe status update is part of the transaction AgentReady audits, not just discovery. See also our note on UCP’s return policy extension.