{
"id": "evt_9pQ2vX7mKdR4tYb1nZ3sLwCe",
"created_at": "2026-07-28T18:41:03Z",
"type": "store.connected",
"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 restaurant connected its existing account to you
Sent when the owner of an existing Listo account approves your connect
request. data is the whole store object, so this is everything
POST /v1/connections would have told you.
It is a distinct event from store.updated on purpose. That one means “a
store you already hold changed”, and this store is one you have never
seen: it may well arrive BEFORE you exchange your code, so a
store.updated carrying an unfamiliar id would be a payload you would
have to drop.
It is also your recovery path. The redirect that carries the code runs
through the owner’s browser, and browsers get closed; this event does
not depend on one. Treat the store as connected when either arrives,
whichever comes first, and dedupe on the event id.
Its plan is the store’s Plan Listo as it stood when the owner
approved, which is the restaurant’s own. If your account pays for its
stores’ plans, Listo then hands the plan to
you, and a store.updated follows within moments carrying the result: a
restaurant that already pays its own plan reads paid_by: "store" with
pending_paid_by: "partner" and the date its plan passes to you, and
one with no live plan starts yours, charged that day. Listo emits a
connected store’s store.connected before any store.updated for it,
but webhooks are unordered in delivery, so order them by the event’s
created_at rather than by arrival.
{
"id": "evt_9pQ2vX7mKdR4tYb1nZ3sLwCe",
"created_at": "2026-07-28T18:41:03Z",
"type": "store.connected",
"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.connected 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.