Skip to main content

Changelog

All notable changes to the OlaClick Public API.

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

🆕 New

Orders​

  • 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; the order starts as PENDING. 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-08] Company — list configured payment methods​

🆕 New

Company​

  • GET /v1/company/payment-methods — Lists the active payment methods configured for your company: id, code, description, and the order service types that accept it (ONSITE, TABLE, DELIVERY, TAKEAWAY). Only methods enabled for at least one of those service types are returned.

Scopes​

  • payment-methods:read — required by the new endpoint. Existing API keys need it granted before calling it.

[2026-09-07] Logistics — assign your OlaClick riders​

✨ Changed

Logistics​

  • PUT /v1/orders/{id}/rider — New optional provider field: api (default, unchanged behaviour) registers an external rider managed by your system; olaclick assigns one of your OlaClick users with the rider role.

Notes

  • user_id was documented as an OlaClick user id. With provider: api it is the id of the rider in your own system, stored as-is. With provider: olaclick it is required and must be the id of an active user of your company with the rider role (see GET /v1/users?filter[role]=rider&filter[active]=true).
  • With provider: olaclick the order must be a delivery and must not be in PENDING status; otherwise the endpoint answers 422 validation_failed with the failing field under errors[].
  • Existing integrations are unaffected: omitting provider behaves exactly as before.

[2026-09-04] Users — list your company staff​

🆕 New

Users​

  • GET /v1/users — Paginated list of the users of your company (staff such as admins, managers, waiters, riders, cooks, sales and cashiers).

Scopes​

  • users:read — required by the endpoint. Existing API keys need it granted before calling it.

Notes

  • Filter by role with filter[role], one role or several separated by commas (filter[role]=waiter,rider). Allowed roles: admin, manager, waiter, rider, cook, sales, cashier.
  • Filter by account status with filter[active]=true|false. Without it the list includes deactivated users; check the active field on each item.
  • Page through results with page and per_page (default 20, max 100). The pagination object tells you whether there are more pages.
  • Each user carries a single role.

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

🆕 New

Orders​

  • 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-09-01] Company profile — language and currency​

🆕 New

Company​

  • GET /v1/company now also returns language and currency.

Notes

  • language is the company's configured 2-letter ISO 639-1 code (e.g. es, en) — not a full locale like es-PE. null when the company has no language set.
  • currency is the company's ISO 4217 currency code (e.g. PEN, USD). Always present — defaults to USD when the company never configured one.
  • Both fields are additive; no existing field changed.

[2026-08-27] Menu write endpoints — product & variant create/update​

🆕 New

  • POST /v1/menu/products — Create a product, optionally with its variants, in one call.
  • POST /v1/menu/products/:id/variants — Create a variant for an existing product.
  • PATCH /v1/menu/products/:id/variants/:variantId — Update a variant.
  • PATCH /v1/menu/products/:id now also accepts visible, stock_enabled, and messages_for_customers.
  • GET product responses now include stock_enabled and messages_for_customers.

[2026-08-19] Company profile​

🆕 New

Company​

  • GET /v1/company — profile of the company behind the credential: name, description, logo, public URL, location and weekly business hours, plus currently_open computed in the company timezone.

Scopes​

  • companies:read — required by GET /v1/company (scope already exists since the initial release; existing keys must have it granted).

Notes

  • description comes from the connected Google Business Profile and is null for companies that never synced one.
  • currently_open is derived from business_hours in the company timezone and supports multiple blocks per day and overnight ranges.
  • Existing API keys need the companies:read scope granted before calling this endpoint.

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

🆕 New

Orders​

  • 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-08-07] Food-app store status​

🆕 New

Stores​

  • GET /v1/stores/status — live open/closed state for every food app supported in your country (Rappi, Rappi Turbo, iFood, Didi, PedidosYa, Uber Eats, 99Food). Accepts an optional provider_names filter (comma-separated); narrowing it reduces the number of live provider lookups and therefore the response time.

Scopes​

  • stores:read — required by GET /v1/stores/status

Notes

  • store_status is resolved live against each food app, so this endpoint is slower than a plain read. A provider that has no credentials configured, is not yet supported, or fails to answer is reported as UNKNOWN rather than failing the whole request.
  • Existing API keys need the new scope granted before they can call this endpoint.

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

🆕 New

First version of the OlaClick Public API is live.

Authentication​

  • API Key authentication via Authorization: Bearer olk_live_... or X-API-Key header
  • Scopes: menu:read, menu:write, orders:read, clients:read, reports:read, webhooks:read, webhooks:write, companies:read
  • GET /v1/menu — Full catalog with categories and products
  • GET /v1/menu/categories/:id — Single category by id
  • GET /v1/menu/products/:id — Single product with variants and modifiers
  • PUT /v1/menu/products — Bulk upsert up to 500 products (idempotent)
  • PATCH /v1/menu/products/:id — Partial update of a product

Orders​

  • 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

Webhooks​

  • POST /v1/webhooks — Create webhook subscription
  • GET /v1/webhooks — List webhook subscriptions
  • GET /v1/webhooks/:id — Get webhook details
  • PATCH /v1/webhooks/:id — Update webhook configuration
  • DELETE /v1/webhooks/:id — Delete webhook subscription

Clients​

  • GET /v1/clients — Paginated client list with filters
  • GET /v1/clients/:id — Get a single client by UUID

Infrastructure​

  • Rate limiting per API key (tier-based)
  • RFC 7807 Problem Details for all errors
  • Idempotency support via Idempotency-Key header on write endpoints
  • Sandbox environment (olk_test_* keys on api-sandbox)