Know the moment something happens in the business,an order placed, a payment confirmed, a delivery on the move.
Webhooks would push real events out of Queek OS to your systems the instant they happen, so you stop polling and start reacting. The events are real and run today; the delivery surface that pushes them to you is building toward. Talk to us about early access.
Happening in Queek OS
- order.createda customer just checked out
- payment.confirmedthe transaction cleared
- delivery.updateda rider is on the move
Pushed to your endpoint
POSTyour receiving service
- event:"order.created"
- merchant:"a Queek OS business"
- occurred_at:"the moment it happened"
Polling asks the same question over and over and mostly hears nothing. A webhook tells you the instant the answer changes.
The moments worth reacting to, each from a real Queek OS operation.
Every event below maps to something that already happens for live businesses on Queek OS. Webhooks are the surface that would push them to you, building toward. The names are the intended shape, not a documented contract.
order.created
An order is placed on any channel, web, WhatsApp, POS, or an AI agent.
payment.confirmed
A transaction clears, so you can fulfil, invoice, or reconcile.
order.status_changed
Accepted, preparing, ready, or cancelled, the lifecycle moves.
delivery.updated
A rider is assigned, picks up, or arrives, tracking in motion.
catalog.updated
A product, price, or stock level changes at the source of truth.
support.requested
A customer needs a human, so you can route it without polling.
What an event would look like, in spirit.
This is illustrative of the intent, a single order event arriving at your endpoint, not a documented live payload. Real field names, the signing scheme, and delivery behaviour land as webhooks move from roadmap to early access.
- event:"order.created"
- merchant:"a Queek OS business"
- order:{ id, items, fulfillment }
- occurred_at:"the moment it happened"
Illustrative of the direction. Names, fields, and the verification scheme will change before anything is documented.
Delivered to you, conceptually
Sent to a URL you control
Your service receives the event, not us calling into your database.
Carries enough to act
What changed, for which business, and when, so you can respond.
Verifiable, by design
A way to confirm an event genuinely came from Queek. The scheme is not finalised.
Real events, from the operating layer that already runs live businesses.
Webhooks invent nothing. Every event is something Queek OS already does, a checkout completing, a payment clearing, a rider being dispatched. The webhook surface is simply the notification layer over that real activity, and it is what we are building toward.
Something happens
An order, payment, or delivery moves on live Queek OS.
Queek records it
The operating layer is the single source of truth for the change.
An event is shaped
That change becomes a clean, conceptual event payload.
It reaches your endpoint
Building toward: the event is pushed to a URL you control.
Real today, building toward, and what we will not claim yet.
We would rather be clear than impressive. This is the real state of webhooks, with the events that genuinely happen kept separate from the delivery surface that is still being built.
- Orders, payments, status & delivery changes on Queek OS
- One source of truth for every change
- These are the events webhooks will surface
- The webhook delivery surface that pushes events to you
- Early-access setup with our team
- Documented endpoints & self-serve subscriptions
- Signing secrets, retry & delivery SLAs
- Stable, versioned event names & payloads
Need events pushed to your systems? Tell us what matters.
Early partners decide which events ship first and what their payloads carry. Tell us what you want to react to and we will work with you directly, rather than point you at docs that are not public yet.
Straight answers about webhooks.
What is real today, what is building toward, and what we will not pretend exists yet.
Can I subscribe to webhooks today?
Not self-serve. The events are real and run on Queek OS today, but the delivery surface that pushes them to your endpoint is building toward. Tell us what you need and we will work with you directly as part of early access, rather than point you at a subscription flow that is not live yet.
Are these event names final?
No. Names like order.created and payment.confirmed are the intended shape, shown so you can picture what events would carry. The real names, fields, and structure can still change before anything is documented, and we will not present them as a stable contract.
What about signing secrets, retries, and delivery guarantees?
Not published yet, and we will not invent them. Signing schemes, retry behaviour, and delivery SLAs land as webhooks move from roadmap to early access to general availability. For now the honest answer is: talk to us about what you are building and we will tell you exactly what is possible today.
If webhooks are not ready, how do I react to events now?
The operations behind the events run today on Queek OS, and the Queek API in early access can read orders, catalog, and payments. If push events are critical to what you are building, tell us. Early partners shape the order we build delivery in.
Real events, building toward a clean way to receive them.
Start with the operating layer that is live today, and help shape the webhook surface as it moves from roadmap to early access.