Re-Ordering

Re-ordering lets a customer repeat something they have ordered before in as few taps as possible. You take a past order, ask us to rebuild it as a cart, and drop the customer straight into checkout.

The complication is that time has passed. Items get removed from menus, prices change, discounts end, and stores stop offering order types. So re-ordering is two calls rather than one: first you ask what has changed, then you build the cart.

Re-ordering requires a signed-in customer, since it reads their order history.

Use the order-scoped endpoints

Re-ordering moved onto the order in 4.78: POST /orders/{order_uuid}/reorder/validate and POST /orders/{order_uuid}/reorder, which is what this guide uses.

The older cart-scoped POST /cart/reorder/validate and POST /cart/reorder still work and are unchanged, so existing integrations keep running — but they are deprecated and new work should use the paths below.

Step 1 — Find out what changed

Call Reorder Validate with the past order's UUID in the path. Nothing is modified; you are just asking whether the order can be repeated as-is.

Request

{
  "method": "post",
  "url": "https://api-public-demo.menu.app/api/orders/6f2a1c74-8b19-4a55-9d0e-1f2c3b4a5d6e/reorder/validate",
  "headers": {
    "X-Request-ID": "69da3547-204b-4093-a225-54e084c24215",
    "Application": "f3a90488ffee32c3acb6fcd0ca417cf6",
    "Api-Version": "4.78.0",
    "Authorization": "Bearer {customer_token}",
    "Content-Type": "application/json"
  },
  "body": {}
}

The assessment comes back under data.cart_reorder and carries a validation_check_code. If it is null, nothing has changed and you can rebuild the order exactly. Any other value tells you what is different:

Code	What changed
2000	An item, combo meal or modifier is no longer available
2001	More than one of the checks below failed, so several things changed at once
2002	The discount used on the original order is no longer available
2003	Some prices have changed
2004	The delivery fee has changed
2005	The store no longer offers that order type

See Reordering: Validation Check Codes for the reference version of this table.

Use the code to decide how much to tell the customer. A price change is usually worth a quiet note; an unavailable item needs a clear prompt, because their reordered basket will not be what they expected. If the order type has gone, re-ordering into the same store is not possible and you should send them through normal store selection instead.

You can also pass an optional venue_id in the body to validate the order against a different store — useful when the customer has moved, or when their original store is closed.

Step 2 — Build the cart

Call Reorder on the same order. This creates a cart containing everything from the original order that is still available, priced at today's prices.

Request

{
  "method": "post",
  "url": "https://api-public-demo.menu.app/api/orders/6f2a1c74-8b19-4a55-9d0e-1f2c3b4a5d6e/reorder",
  "headers": {
    "X-Request-ID": "69da3547-204b-4093-a225-54e084c24215",
    "Application": "f3a90488ffee32c3acb6fcd0ca417cf6",
    "Api-Version": "4.78.0",
    "Authorization": "Bearer {customer_token}",
    "Content-Type": "application/json"
  },
  "body": {}
}

You get back a normal cart under data.cart, with the same shape as any other cart response. From here the flow is exactly as in Server Side Cart — set a fresh pickup or delivery time on metadata.order_type, check out, take payment and place the order.

Always set a new time. The time from the original order is in the past, so carrying it over will fail at checkout with code 2001.

Repeating a group order

A group order cannot be repeated with these endpoints. Calling either of them on one returns 1216, because rebuilding a group order means recreating a whole session rather than a single cart.

Use Group Reorder instead — it creates a new group session seeded with the previous participants' items, which the host then adjusts and pays for. Group Ordering covers it. You can tell the two apart from is_group on the order.

Where to find past orders

GET Receipts returns the customer's order history, which is where the order UUID for these calls comes from. A good pattern is to show an "Order again" action on each receipt, run the validate call when it is tapped, and only then decide what to show.

What can go wrong

The order was not found — HTTP 404. Either the UUID is wrong, or the order does not belong to this customer.

The customer is not signed in — HTTP 401. Both calls require a customer token.

It is a group order — 1216. Use the group reorder endpoints described above.

The rebuilt cart fails at checkout. Treat the reordered cart like any other from that point on, including the checkout failures described in Server Side Cart — an item can become unavailable between validating and checking out.

Group Ordering

Scheduled Ordering