{
"id": "evt_9pQ2vX7mKdR4tYb1nZ3sLwCe",
"created_at": "2026-07-28T18:41:03Z",
"type": "store.updated",
"data": {
"id": "st_4bR8kM2wQ7xT1nV5cZ9pLdYe",
"external_id": "pos-store-41",
"name": "<string>",
"phone": "<string>",
"street": "<string>",
"apt_unit": "<string>",
"lat": 123,
"lng": 123,
"pickup_notes": "<string>",
"timezone": "America/Mexico_City",
"default_business_fee_share": 50,
"default_fee_split_amount_cents": 1,
"markup_cents": 1,
"test": true,
"created_at": "2023-11-07T05:31:56Z",
"plan": {
"price_cents": 199000,
"currency": "MXN",
"interval": "month",
"current_period_ends_on": "2023-12-25",
"next_charge_on": "2023-12-25",
"canceled_at": "2023-11-07T05:31:56Z",
"ends_on": "2023-12-25",
"pending_paid_by": "<string>",
"pending_paid_by_on": "2023-12-25",
"courtesy": true
}
},
"test": true
}A store changed
Sent when one of your stores changes, including changes nobody asked
for. The headline case is card readiness flipping once the hosted
onboarding is reviewed. A change to a live store’s Plan Listo sends one
too, carrying the plan: a plan that starts, renews, fails or clears a
charge, is canceled or has that undone, ends, restarts, changes price,
or passes to you from a restaurant that connected. One act sends one
event, carrying the state the plan ended in, and changes that land
close together can arrive as one event carrying the latest state. An
event whose store object would be exactly the one you were last sent
for that store is not sent.
data is the store object, which carries NO readiness field: this event
is the signal, and GET /v1/stores/{id}/stripe_status is the answer.
{
"id": "evt_9pQ2vX7mKdR4tYb1nZ3sLwCe",
"created_at": "2026-07-28T18:41:03Z",
"type": "store.updated",
"data": {
"id": "st_4bR8kM2wQ7xT1nV5cZ9pLdYe",
"external_id": "pos-store-41",
"name": "<string>",
"phone": "<string>",
"street": "<string>",
"apt_unit": "<string>",
"lat": 123,
"lng": 123,
"pickup_notes": "<string>",
"timezone": "America/Mexico_City",
"default_business_fee_share": 50,
"default_fee_split_amount_cents": 1,
"markup_cents": 1,
"test": true,
"created_at": "2023-11-07T05:31:56Z",
"plan": {
"price_cents": 199000,
"currency": "MXN",
"interval": "month",
"current_period_ends_on": "2023-12-25",
"next_charge_on": "2023-12-25",
"canceled_at": "2023-11-07T05:31:56Z",
"ends_on": "2023-12-25",
"pending_paid_by": "<string>",
"pending_paid_by_on": "2023-12-25",
"courtesy": true
}
},
"test": true
}Headers
Proves the event came from us. The value is t=<unix seconds>,v1=<hex>,
where the hex is an HMAC-SHA256, keyed on your signing secret, over the
string "<t>.<raw request body>".
To verify: split the header on the comma, rebuild "<t>.<body>" from
the RAW bytes you received (never a parsed and re-serialized object, or
whitespace and escape sequences will change the digest), compute the
HMAC, and compare it to v1 in constant time. Reject anything that does
not match.
Then check the clock. Reject an event whose t is more than 5 minutes
away from now in EITHER direction: a t far in the past is the replay
this scheme exists to stop, and one far in the future is the same attack
with a clock nobody checked.
Two secrets can be active at once so you can rotate without downtime: add the new one, accept either, promote it, then drop the old one. We always sign with the primary.
"t=1753728063,v1=8d2f4a1b6c7e9f0a1b2c3d4e5f60718293a4b5c6d7e8f90a1b2c3d4e5f607182"
Body
The fields every event shares. Delivery is at-least-once and unordered
by design: dedupe on id, and order by created_at or by the object's
own timestamps rather than by arrival. type and data are added by
each event, because their values depend on which event it is.
The event id, evt_ prefixed. Dedupe on this.
"evt_9pQ2vX7mKdR4tYb1nZ3sLwCe"
When the event was recorded, ISO-8601 in UTC.
"2026-07-28T18:41:03Z"
Which event this is.
store.updated A pickup location. Card readiness is deliberately NOT a field here: it is its own endpoint, with its own outstanding-requirements detail.
Show child attributes
Show child attributes
Present, and true, only on a test event you asked for with
POST /v1/test_webhooks. A real event does not carry the field at
all. A test event's data is a sample whose ids resolve to nothing.
true
Response
Return any 2xx to acknowledge the event.