FAQ

Do PLUs have to be unique across locations on a multi-site account?

Yes, for shared/global product catalogs. Deliverect keys products by PLU within the account; the same PLU must not identify different items at different sites, or menus, overrides, and snooze will collide. If the POS reuses short numeric PLUs per store, use distinct PLUs per logical item (prefixes, SKUs, or stable cross-store codes)

Which ID do we use for order status updates and for cancellations?

Use Deliverect’s order _id from the original order webhook in the Update Order Status call. Channel cancels arrive on the same order webhook URL with "status": 100; void in the POS, then confirm with 110 (Canceled) on the initial order’s _id, see How to handle cancellations.

Can the POS trigger product sync automatically (e.g. every few hours)?

Yes. The POS may call Insert/Update products whenever you want, so you can schedule daily syncs. Deliverect can also request a sync via Store API in some setups; the POS still pushes product data to Deliverect, not the other way around.

Why does Deliverect fail an order with “invalid PLU” before our webhook runs?

That is usually Deliverect-side validation against the synced catalog (wrong location’s products, or menu not republished after sync), not your HTTP handler rejecting the call. Align location ↔ product catalog, re-sync, republish the menu, and ensure order line PLUs exist for that location; check operation reports for the failing PLU.

Do we poll for orders?

No, POS order notification is webhook-driven.

Why is our product sync stuck in "Await"?

"Await" means Deliverect has called your product sync endpoint and is waiting for you to send the products to POST /productAndCategories for that location. If that POST never arrives, or Deliverect can't process it, the operation stays in "Await". The usual causes are:

  • your endpoint returned 200 but never sent the products;
  • the payload was sent for a different locationId;
  • the payload doesn't follow the schema.
How should we interpret modifier quantities in an order? Should we multiply them by the item quantity?

A modifier's quantity is per unit of its parent item. The total number of modifiers is the modifier quantity x the parent item quantity. For example, 2 x Potato Wedges with 1 x Melted Cheese means 2 cheeses in total, and the cheese price is charged twice. Identical item and modifier combinations are grouped into one line; different combinations come as separate lines. Deliverect sends quantities this way for all channels (Uber Eats, Deliveroo, Just Eat, etc.) and doesn't pre-multiply them for the POS, so the POS has to apply the multiplication when it displays and prices the order. See how to interpret order quantity.

Why do our modifiers show up as separate modifier groups instead of nested ones, or why do we get "link ignored" warnings?

Deliverect builds the product tree only from the subProducts references in your product sync. To nest a modifier group under a modifier, list that group's PLU in the modifier's subProducts. If the modifier's subProducts is empty, the groups sync as separate, flat groups. The warning 'linked product with plu X exists 0 times (link ignored)' means a subProducts entry points to a PLU that isn't in the same payload, so the link is dropped. Every referenced PLU (products, modifier groups and modifiers) has to be included in the same sync.

Why do some orders stay in "Received by POS" instead of moving to Finalized?

"Received by POS" means your webhook accepted the order, but no status update has come back from the POS since then. Orders only move forward (e.g. 20 Accepted --> 90 Finalized) when you send Update Order Status with Deliverect's order _id. Until then, the channel can't tell whether the store is actually preparing the order. The usual causes are:

  • the POS never sends status updates;
  • the POS couldn't process part of the order internally (for example an unmapped discount), so the check never progressed.

Did this page help you?