Skip to main content

Orders

2026-09-18 — Promotions — create, read, update and delete a promotion; apply a coupon to an order​

🆕 New

  • POST /v1/orders/{id}/coupon — Redeems a coupon code on an order and returns it with the totals recalculated. Only orders created through the API can be changed here (422 order_not_modifiable otherwise). A coupon that exists but is not eligible for this order — service type, usage limit reached, once per customer, or new customers only — answers 422 coupon_not_applicable; a coupon already applied to the order answers 422 validation_failed. To remove a coupon, use the existing DELETE /v1/orders/{id}/discounts/{discountId} with the discount id the coupon created.

Scopes​

  • orders:write — also required by POST /v1/orders/{id}/coupon (existing scope, no new grant needed for keys that already write orders).

2026-09-16 — Orders — payments on storefront and POS orders​

✨ Changed

  • POST /v1/orders/:id/payments and DELETE /v1/orders/:id/payments/:paymentId now also work on orders placed by the customer on the storefront (INBOUND) or taken by the merchant on the POS (OUTBOUND), not only on orders created through the API. Orders from food apps still answer 422 order_not_modifiable. Every other write endpoint keeps accepting only orders created through the API.

2026-09-12 — Orders — create and update orders​

🆕 New

  • POST /v1/orders — Creates an order. Send service_type and, optionally, client_id (an existing client of your company). table_id is only accepted for TABLE orders; address_id and delivery_price only for DELIVERY orders. source, country_code, timezone and currency are always taken from your credential. By default the order starts as INITIATED, a draft the merchant does not see: add its items, payments and discounts, then confirm it with PATCH /v1/orders/{id}/status and status: PENDING (or PREPARING), which assigns its daily number and shows it to the merchant. Send status: PENDING on creation to skip the draft. Drafts are never returned by GET /v1/orders: keep the id from the create response and read them with GET /v1/orders/{id}. Requires an Idempotency-Key header, which is stored as the order's reference and must be unique per order.
  • PATCH /v1/orders/{id} — Edits an order you created through the API. Send at least one of comment, order_title, delivery_comment, delivery_price, packaging_price or scheduled_delivery_date; delivery_comment and delivery_price are only accepted on DELIVERY orders. comment is appended to what the order already has rather than replacing it; currency is always taken from your credential. Orders from other channels cannot be edited here.

2026-09-04 — Order management — items, payments, discounts, status and cancellation​

🆕 New

  • PATCH /v1/orders/:id/status — Move an order along its lifecycle.
  • POST /v1/orders/:id/cancel — Cancel an order, with a reason.
  • POST /v1/orders/:id/combos — Add items to an existing order.
  • DELETE /v1/orders/:id/combos/:comboId — Remove one item from an order.
  • POST /v1/orders/:id/payments — Register a payment against an order.
  • DELETE /v1/orders/:id/payments/:paymentId — Cancel one payment.
  • POST /v1/orders/:id/discounts — Apply a manual discount.
  • DELETE /v1/orders/:id/discounts/:discountId — Remove a discount.

All eight return the order in its new state, the same shape as GET /v1/orders/:id.

Scopes​

  • orders:write — required by all eight endpoints. Existing API keys need it granted before calling them. The rider endpoints keep using logistics:write.

Notes

  • Only orders created through the API can be edited.
  • Changing the status is the exception: it works for orders from any channel. Advancing an order the merchant is already fulfilling is an operational action, whoever took it.
  • Statuses only move forward through PENDING, PREPARING, READY, DELIVERED and FINALIZED. Sending a status earlier than the current one leaves the order unchanged and returns it as-is; skipping ahead applies the statuses in between. CANCELLED is not accepted here — use the cancel endpoint.
  • An order with active payments cannot be cancelled. Cancel its payments first with DELETE /v1/orders/:id/payments/:paymentId.
  • Removing an item or a payment cancels it: the row stays on the order with canceled_at set, so the change remains auditable and keeps showing in the merchant reports. Removing a discount deletes it.
  • Items do not have to exist in your menu. Sent without product_id they are added as free-form lines; a sku that matches a product in your menu links the line to it automatically.
  • Payments can be several per order, one per method the customer used. The order is marked as paid once they add up to its total, and amounts above the total are accepted and reported as an overpayment.
  • Discounts are manual, by AMOUNT or PERCENTAGE, and they add up. A percentage above 100 is rejected; an amount above 100 is not.
  • The currency and the timezone are taken from the company that owns your API key, so you never send them.

Prices: you send unit prices, you read back line totals

The item fields carry the same names in the request and in the response, but they do not mean the same thing. You send what one unit costs; the order stores what the whole line adds up to:

variant_price          = unit price x item quantity
variant_original_price = unit list price x item quantity

per modifier:
  price    = unit price x modifier quantity x item quantity
  quantity = modifier quantity x item quantity

modifiers_price      = sum of the modifier prices
combo_price          = variant_price + modifiers_price
combo_original_price = variant_original_price + sum of original prices

A modifier's quantity is per unit of the item. Asking for one large side on an item with quantity: 2 records two large sides.

For example, sending an item with quantity: 2 at variant_price: 25 and variant_original_price: 30, plus one modifier at price: 4 and another at price: 6, stores variant_price: 50, the modifiers at 8 and 12, modifiers_price: 20 and combo_price: 70.

variant_original_price and a modifier's original_price are optional: they default to the price you charge, so send them only when you want the order to show the discount you granted.

2026-08-14 — Logistics API — External delivery providers​

🆕 New

  • PUT /v1/orders/:id/rider — Assign or update a delivery rider (name, phone number).
  • DELETE /v1/orders/:id/rider — Unassign the rider from an order.
  • PATCH /v1/orders/:id/delivery-status — Update the delivery status. Automatically sets delivered_by to API.

Scopes​

  • logistics:write — required by all three new endpoints.

Notes

  • These endpoints allow external delivery providers (e.g. PickNGo) to report rider assignment and delivery progress on existing orders.
  • They do NOT create orders — they only operate on orders already created in OlaClick.
  • delivered_by is set to API automatically so reports can distinguish provider-driven deliveries.
  • Existing API keys need the logistics:write scope granted before calling these endpoints.

2026-06-20 — Public API — Initial Release​

🆕 New

First version of the OlaClick Public API is live.

  • GET /v1/orders — Paginated order list with filters
  • GET /v1/orders/:id — Single order by UUID or public ID
  • GET /v1/orders/by-payment-methods — Orders aggregated by payment method
  • GET /v1/orders/by-tips — Orders aggregated by tips
  • GET /v1/orders/products-sold — Products sold statistics