Send orders into any Online eMenu restaurant from your own software.
The Partner API lets your software read a restaurant's live menu, place orders that land in the same queue as every other channel, and read back orders from POS, WhatsApp, QR and aggregators. Accept, reject and move orders through to completion, all over one JSON API secured with a per-restaurant key.
What can I do with the Partner API?
One key, one restaurant, six things your software can do against its live order flow.
Read the live menu
Categories, items, prices and add-ons, with stock and meal-window flags so you only ever offer what the kitchen can actually serve right now.
Place an order
A new order from your system lands in the restaurant's live queue and rings the alarm exactly like an order from any other channel.
Read every channel's orders
One feed covering POS, the QR diner menu, WhatsApp, Zomato, Swiggy and your own API orders — filter by channel or status.
Accept or reject, with a prep time
Confirm an order to the kitchen and the customer with an optional prep-time estimate, or turn it down with a reason for the audit trail.
Move an order through its stages
Preparing, ready, dispatched, completed — post the status change your system already knows about and it reflects on every screen.
Aggregator decisions, passed through
Decide on a Zomato or Swiggy order through the same call, and the decision is queued for that platform until it confirms (awaitingPortal).
How does the API keep money safe?
The restaurant prices every order, not your integration. You send item ids and quantities; the restaurant's own menu and tax settings compute the subtotal, add-ons, service charge, packaging and tax, and return the total to you. No integration can book an order at a price the restaurant never agreed to.
You send ids and quantities
Never a price. The restaurant's menu and settings decide what everything costs.
expectedTotalMinor is checked
Send the total your system showed the customer. A mismatch refuses the order with TOTAL_MISMATCH rather than creating it at the wrong price.
Integer minor units, always
Paise, cents, fils — never decimals, so nothing is lost to floating-point rounding.
Per-restaurant keys
Revocable instantly from the restaurant's panel, and meant to be called from your server only, never from a browser or app.
Who builds on it?
Anyone whose software needs to read a restaurant's menu or put an order into its kitchen.
Delivery and aggregator platforms
Sync your own ordering flow into the restaurant's live queue alongside its other channels.
Kiosk and tablet vendors
Read the live menu for display and send the order straight into the kitchen queue.
Loyalty and CRM apps
Read completed orders to build spend history, segments and win-back campaigns.
Agencies building a branded app
Put your client's own website or app in front of customers while orders still land in their queue.
Hotel PMS and ERP teams
Pull completed orders for accounting, reconciliation and reporting outside the restaurant panel.
A minimal integration in four calls
Prove the connection, then build the loop. This is the same shape as the four-part loop in the API docs.
curl https://api.onlineemenu.com/api/v1/outlet \
-H "Authorization: Bearer emk_live_YOUR_KEY"POST /api/v1/orders
Authorization: Bearer emk_live_...
Content-Type: application/json
{
"externalRef": "INV-2026-0912",
"type": "DELIVERY",
"customer": { "name": "Vinod", "phone": "9876500123" },
"deliveryAddress": {
"addressLine1": "12 MG Road",
"city": "Indore"
},
"items": [
{ "menuItemId": "cmtwzpw6b000wvnai89aldj73", "qty": 2 }
],
"note": "less spicy"
}Outlet and menu, on start-up
Call GET /outlet for currency and minorPerUnit, call GET /menu and cache it, then refresh the menu every few minutes so sold-out items and price changes reach you.
POST /orders with your own externalRef
Store the order id we return against your record. If the call fails or times out, retry the identical payload — the reference makes that safe.
Poll ?status=NEW every 5-10 seconds
Catch orders that need a decision, show them to your staff, then post the answer back to /accept or /reject.
Cursor sync with ?since=
Keep a cursor, ask for what has changed since it, apply the results oldest-first, then move the cursor to the last updatedAt you saw.
How do I get an API key?
The restaurant creates your key inside its own eMenu panel, under Settings → API access. It is named at creation and shown once, so it needs to be pasted to you over something private — it is a password for that restaurant's orders. A restaurant can run up to 10 active keys at a time, one per integration, and revoke any of them instantly without disturbing the others.
If you are a developer or platform without a restaurant client yet, ask us on WhatsApp about getting a test restaurant to build against before you go live with a real one.
Limits, versioning and support
| Limit | Value |
|---|---|
| Requests per key | 600 per minute |
| Lines per order | 200 |
| Quantity per line | 999 |
| Add-on choices per line | 40 |
| Kitchen note | 500 characters |
| Orders per page | 200 |
| Active keys per restaurant | 10 |
Going over the request ceiling returns 429 RATE_LIMITED. Back off for a few seconds and retry — nothing is lost, and a polling loop simply catches up on its next pass.
The version sits in the path. Within v1, fields get added to responses and optional fields get added to requests, but nothing existing is removed, renamed or changed in meaning — ignore fields you do not recognise and your integration keeps working. A breaking change gets its own version path, and v1 keeps running.
For support, quote the order's code and timestamp — both are visible in the restaurant's panel and make a single order traceable end to end.
Partner API questions.
Is the API free? +
The API is part of the restaurant's Ordering Suite subscription — ₹199/month in India, $9/month elsewhere. There is no separate API fee listed. If you are integrating for a partner platform across many restaurants, ask us on WhatsApp and we will confirm volume terms.
Can I read Zomato and Swiggy orders? +
Yes. GET /orders returns orders from every channel, including ZOMATO and SWIGGY, and you can filter with ?channel=ZOMATO,SWIGGY. If you accept or reject one of those orders through the API, the decision is queued for that platform and the order's status only changes once the platform itself confirms.
Does it work with the Desktop POS? +
Yes. Orders placed through this API land in the same live queue as orders rung up on the Desktop POS, and POS-channel orders are visible back to you through GET /orders with ?channel=POS. There is one queue behind both.
Can I set my own prices? +
No. The restaurant prices every order from its own menu and tax settings. You send item ids and quantities; the subtotal, add-ons, service charge, packaging and tax come back computed. You can send expectedTotalMinor to confirm your total agrees before the order is created.
What happens if my request times out? +
Retry the identical payload using the same externalRef. The API recognises the repeated reference and returns the original order with "duplicate": true instead of creating a second one. Accept, reject and status calls are also safe to repeat and return "unchanged": true on a repeat.
Is there a webhook? +
No webhook is documented. The API is built around polling: GET /orders?status=NEW every 5 to 10 seconds to catch orders needing a decision, and a cursor sync with ?since= to keep everything else in step.
Which currencies? +
Whichever currency the restaurant's outlet is configured in. GET /outlet returns the ISO currency code and minorPerUnit, so you can convert the integer minor-unit amounts to a display price without hard-coding a multiplier.
Can one key see multiple restaurants? +
No. One key belongs to one restaurant and can never see or touch another restaurant's menu or orders. An integration covering several restaurants holds one key per restaurant.
Get your restaurant's first order into your system.
Read the full docs for every endpoint and error code, or message us on WhatsApp and we will point you at the right starting call.