Send every order event to the systems you already run.

Your systems react to every order. Ordering.co runs the operation.

Webhooks turn Ordering.co into a source of live events for the rest of your business: ERP, accounting, CRM, BI, messaging, and your own software. Underneath those events is a complete ordering operation:

• More products and features. More than 20 products and more than 1,500 features across websites, apps, marketplaces, kiosks, call centers, loyalty, and delivery.
• Your own branded channels. Customers order from your website, apps, and kiosks, and every order they place can reach your systems.
• Your design, not a template. Build an ordering experience with your own custom design, with help from our team.
• Built to extend. Combine webhooks with APIs and MCP, with application source code available on eligible plans.

Why use webhooks with Ordering.co

• Keep every system in sync. Send orders to your ERP, accounting, or data warehouse the moment they are placed, instead of exporting and re-entering them.
• React in real time. Your systems are notified as soon as an event happens, so there is no need to poll for changes.
• Alert the right people. Post new orders to a team messaging channel, or tell an operations tool when a pickup or delivery fails.
• Grow your customer data. Send each new sign-up to your CRM so marketing and sales can follow up promptly.
• Automate by store or by project. Route one store’s orders to that store’s own system, or send the whole project’s activity to a central platform.
• Fewer errors. Data moves between systems automatically, without manual transcription.

Events you can subscribe to

The Dashboard offers these events. Each webhook listens to one event, identified by its hook name.

Customers

• New user (users_register): a customer creates an account. Available for project-wide webhooks.

Orders

• New order (orders_register): an order is placed.
• Order status update (orders_status_updated): any change to an order’s status. It fires alongside the more specific status events below.
• Order pending (orders_pending): an order moves to Pending, including when a scheduled preorder becomes active.
• Preorder updated (preorder_updated): a scheduled preorder becomes an active order.
• Order completed (orders_completed): an order is completed.
• Order rejected (orders_rejected): an order is rejected.

Store actions

• Order accepted by business (orders_accepted_business): the store accepts an order.
• Order rejected by business (orders_rejected_business): the store rejects an order.

Driver and delivery

• Order update by driver (orders_update_driver): a driver is assigned to the order or the assigned driver changes.
• Order unassigned driver (orders_unassigned_driver): the order’s driver is removed.
• Order accepted by driver (orders_accepted_driver) and Order rejected by driver (orders_rejected_driver).
• Order pickup completed by driver (orders_pickup_completed_driver) and Order pickup failed by driver (orders_pickup_failed_driver).
• Order delivery completed by driver (orders_delivery_completed_driver) and Order delivery failed by driver (orders_delivery_failed_driver).
• Order driver waiting for customer (orders_driver_waiting_for_customer): the driver is waiting for the customer. Available for project-wide webhooks.
• Driver changes (drivers_changes): a driver’s record changes.

More order events through the API

When you create webhooks through the API, you can also subscribe to other order status events by hook name, including orders_ready, orders_not_ready, orders_driver_in_business, orders_driver_almost_arrived_business, orders_driver_almost_arrived_customer, orders_pickup_completed_customer, orders_not_pickedup_customer, and orders_canceled_customer.

What each webhook sends

Ordering.co sends an HTTP POST request to your URL with a JSON body.

• Order events send the full order record: its ID and status, the store and customer, the assigned driver when there is one, and every product with its options and suboptions. Ordering.co adds fields that make the data easy to use: order_type, status_name in the order’s language, delivery_date, a readable to_string summary for each product, and a calculated block with the order’s totals.
• New user sends the new account’s record, such as the customer’s email.
• Driver changes sends the driver’s id, the changes, the current values, and issued_at.

An abbreviated order payload looks like this:

{
  "id": 1024,
  "status": 0,
  "status_name": "Pending",
  "delivery_type": 1,
  "order_type": "Delivery",
  "delivery_datetime": "2026-09-24 19:30:00",
  "delivery_date": "2026-09-24",
  "business_id": 12,
  "customer_id": 3456,
  "driver_id": null,
  "products": [
    {
      "name": "Margherita pizza",
      "quantity": 2,
      "options": [
        { "name": "Size", "suboptions": [{ "name": "Large" }] }
      ],
      "to_string": "2 x Margherita pizza: $24\n  Size\n    Large  $4\n"
    }
  ],
  "calculated": {
    "subtotal": 24,
    "tax": 1.92,
    "delivery_fee": 3.5,
    "driver_tip": 2,
    "service_fee": 0,
    "discount": 0,
    "total": 31.42
  }
}

The body does not repeat the event name, because each webhook listens to one event. Give each event its own URL, or add a query parameter through the API, so your endpoint knows which event arrived.

How an event reaches your system

1. Something happens in your operation: a customer signs up, an order is placed, a store accepts it, or a driver completes the delivery.
2. Ordering.co finds every active webhook for that event, both project-wide and, for order events, the webhooks of the order’s store.
3. Each webhook is queued and sent immediately, or after the delay you chose for it.
4. Ordering.co posts the JSON payload to your URL, with any headers and query parameters you configured.
5. Your system takes action: it creates the order in your ERP, updates a dashboard, alerts your team, or starts a workflow.

Set up and go live

For the whole project

The Ordering.co Configure webhooks guide walks through each step:

1. In the Dashboard, open Settings > Pro > Developers and select the Webhooks card.
2. Select Add new webhook.
3. Enter the destination URL, choose the event, and choose the delay.
4. Save the webhook. It now appears in the list, where you can review or delete it.

Project-wide webhooks are managed by project administrators.

For a single store

Open Stores, select the store, and choose Webhooks in the store panel. Add the event, the URL, and the delay. These webhooks only fire for that store’s orders, so each location or franchisee can connect its own system.

Choose when it fires

Each webhook can fire immediately, after 5, 10, or 15 minutes, or after the store’s delivery time, the store’s pickup time, or the order’s preparation time.

Through the API

Your developers can manage webhooks with the webhook operations in the API Reference, authenticated with a project API key in the X-Api-Key header:

• Project webhooks: list, create, update, and delete them at /webhooks, with a hook, a url, and an optional delay.
• Store webhooks: the same operations at /business/{business}/webhooks.
• Custom headers and query parameters: add headers and query_params to a webhook, up to 10 of each.
• Subscriptions from other platforms: an integration platform can subscribe and unsubscribe a webhook with /webhooks/services/subscribe and /webhooks/services/unsubscribe, using its own platform name and subscription id.

Delivery, timing, and retries

• Queued and sent in the background. Deliveries run in a queue, separately from the order itself, and each webhook fires at its chosen delay.
• Retries on failure. A webhook with retry_on_fail enabled retries a failed delivery a few seconds later, up to five attempts in total.
• Paused endpoints. If an endpoint keeps failing, the webhook can be paused. Its disabled_until and disabled_reason fields show when it resumes and why it was paused.
• More than one delivery per change. Order status update fires on every status change, alongside the specific event for that change. Subscribe only to the events you need, and handle a repeated delivery of the same event safely, for example by using the order id and status.

Secure your endpoint

• Use HTTPS for every destination URL.
• Authenticate each request. Add a secret header or query parameter through the API and reject requests that do not include it. Header values are stored encrypted.
• Validate the payload before you act on it, and respond promptly.
• Protect customer data. Payloads carry customer and order details, so do not log credentials or sensitive customer data, and share them only with approved systems.
• Limit access. Only project administrators manage project-wide webhooks. Keep API keys private and replace any key you suspect is exposed.

Test before you rely on it

1. Test in a staging environment before you enable a webhook on a live project.
2. Create a matching event, such as a test order or a test sign-up, and check that your endpoint received the payload.
3. Confirm your system processed it, not just that the request arrived.
4. To exercise your endpoint without a real event, your developers can send a JSON body of up to 20,000 characters to any URL with /webhooks/dispatch, now or after a delay of up to 10 days, with optional headers and query parameters.

Webhooks, plugins, or the API

• Webhooks push Ordering.co events to a URL you run. Use them when your own system should react the moment something happens.
• The Ordering API lets your system read and update Ordering.co data on demand, for example to fetch more details after a webhook arrives.
• Plugins run inside the platform and receive events there, without a separate server of yours.
• Zapier receives the same events through a webhook URL and connects them to thousands of apps without code.

More ways to automate Ordering.co

• Zapier sends Ordering.co events to thousands of apps without writing code.
• Ordering API reads and updates your Ordering.co data from your own applications.
• APIs and MCP show everything developers and AI agents can build on Ordering.co.