Η δική σας σελίδα παραγγελιών, οι τιμές σας, η περιοχή παράδοσής σας

Every restaurant on Angie Eats gets its own ordering page at a stable address, and it is yours to look at: your name, your logo, your colour, one of three typefaces, your photograph and your phone number. There is no Angie Eats header, no Angie Eats footer and nothing advertising another restaurant on it — one discreet “powered by” line at the bottom, and that is the whole of our presence.

Put a QR code on the tables and the link on your receipts, and the people already walking through your door order from you directly. That works the day you are set up, before anybody has ever searched a marketplace for you.

• It goes on your own website

  A snippet you paste into Squarespace, WordPress, Wix or a hand-built page, and the ordering page appears inside it taking real orders. Your console generates it, and only the domains you register can embed it — a per-restaurant allowlist rather than a blanket permission for anyone on the internet to frame your menu.

• Your colour, still readable

  Whatever brand colour you pick, the platform derives the button fill, the text on it and the edge, each measured against the surface behind it until it passes the accessibility contrast standard. A pale yellow keeps its colour and gains an outline rather than being quietly darkened into mustard.

• Nothing arrives late

  The typefaces are system stacks, so no font downloads and the page cannot reflow half a second after it appears. It is a page a customer opens on a phone in your car park, on the worst connection in the building.

• Closed is a page, not a dead end

  When you are shut, paused or not taking orders, the page still loads in full with an honest banner and the time you reopen — because the reader is standing at your table holding a phone.

• The menu

  Sections, dishes, sizes, and option groups with their own rules — a required choice, a limited number of extras, a free option in a paid group. Photos, descriptions and dietary tags are yours. Bulk import is there for a menu that already exists in a spreadsheet.

• Prices, including online prices

  Your counter price stays the counter price. An online price is derived from it by a rule you set, with the rounding you chose — so an uplift on $8.50 lands on the price you meant rather than on whatever a decimal did. Any single dish can be pinned to an exact online price, and the rule leaves that one alone.

• One menu, not two

  Because online prices are derived rather than copied, a price change at the till flows through to every channel you have not deliberately overridden — so nothing to maintain twice and nothing to go stale. Today this is set through the API; the screen for it in the merchant console is not built yet.

• Hours, and a pause button

  Opening hours per day, and a pause for the night a fryer dies or the tickets stack up. A paused kitchen stops taking orders immediately rather than collecting ones you cannot cook.

• Delivery zones

  Draw the area you will deliver to on a map, and give each zone its own fee and its own minimum order. Customers outside it are told why, which is better for you than a cancelled order.

• Coupons and promotions

  Your own codes, validated by the platform when the customer applies them, so a discount is never larger than the one you set. Every discount records who funded it, so a promotion we ran and a promotion you ran are never confused at settlement.

• Your reviews

  Read what customers wrote and reply. A restaurant nobody has reviewed yet is shown as exactly that, never as a one-star venue.

The order rail is built for a tablet on a wall, read from two metres by somebody holding a pan: 18px base type, 56px touch targets, states that are distinguishable without relying on colour, and a chime that is synthesised in the browser so it cannot go quiet because a file failed to load.

It only ever offers transitions the platform will actually accept — the buttons are drawn from what the order can do next, so a cook is never told “no” after tapping. If the network drops, the last orders stay on screen behind a banner instead of the rail going blank mid-service.

It runs in any browser today, on the tablet you already own.

ORA — the same rail as a dedicated Android app for kitchen tablets — is being built in this same codebase. It is not finished and it is not on Google Play, so there is nothing to download from this page yet. When there is, the button will be here.

Angie Eats does not ask you to run your online orders in a system that cannot talk to your till. There is a documented partner API — scoped keys, versioned endpoints, integer minor units for money, an error contract that names the obstacle — and it carries the two flows that matter: your menu inward, and orders outward.

• Your till stays the system of record for the menu

  Your POS pushes the whole menu — sections, dishes, sizes, option groups, base prices — and Angie Eats layers online prices over it rather than copying it. A push never overwrites the online prices you set.

• Matched by your own reference, never by name

  Rename a dish and it is still the same dish, with its price overrides intact. A row that arrives with no reference is reported back to you and skipped rather than guessed at.

• A push cannot destroy anything

  One transaction, so a push that fails half way leaves the previous menu exactly as it was. A dish missing from the document is deactivated rather than deleted, because orders point at it. Sending the same document twice writes nothing the second time.

• Orders reach the till, and a dead POS cannot stop service

  Orders are delivered with an idempotency key and retried, so a till that was offline for ten minutes does not lose them. And the kitchen never depends on that succeeding: the order is already on the rail and already on the customer’s tracking page.

It is the same API our own integrations use, not a reduced public version of a private one.

Oracle Simphony. For enterprise venues, a bidirectional Simphony integration is specified — orders posted as checks, the menu and the 86 list kept in step both ways, and printing left to the routing your revenue centres already do. It is written up against Oracle’s published API and no code for it exists yet, so nobody should buy on the strength of it today.

One thing worth knowing before anyone spends time on it: it depends on Simphony Transaction Services Gen 2, which Oracle provides only on Simphony Cloud hosted in their own hosting centre. If your venue runs an older on-premise Simphony, that route is not open, and we would rather tell you that in the first conversation than in the fourth.

The division of responsibility is settled either way: your POS stays the system of record for the restaurant, and Angie Eats stays the system of record for the order it took the money for.

Your own drivers, Angie Eats couriers, or a third-party delivery network — it is a per-restaurant setting rather than a platform-wide policy. What a delivery costs the customer comes from your zones; what the courier leg costs is recorded against the order at the time it happens, so the two can be reconciled afterwards rather than argued about.

While a courier is carrying an order, their position is reported every fifteen seconds and your customer can see how far away the food is. If the phone goes quiet for two minutes the position is withheld and the customer is told when we last heard — rather than being shown a pin that has stopped moving and phoning you about it.

Collection-only is a perfectly good configuration, and plenty of kitchens should choose it.

Every order produces a settlement record with its parts kept separate: item sales, discounts and who funded them, the platform’s commission, service fees, the delivery charge and what the delivery leg cost, tax withheld or passed through, and the tip — which goes to you in full.

Commission terms are agreed per restaurant and stored per restaurant. “We take no commission from this venue” and “nobody has configured this venue yet” are different states in the database and are never flattened into a silent zero — a bug the legacy system had, and an expensive one.

Your reports screen shows sales, orders and what you are owed, and it is derived from the same ledger the platform reconciles against. There is no second set of books.

1. 1

   Tell us about the restaurant

   Where you are, what you cook, whether you want delivery, collection or both, and whether you have a POS you want connected.
2. 2

   We set up the venue and your staff accounts

   Your market, currency, tax rate and payout account. A venue cannot go live until each of those is actually set — the platform lists what is missing rather than letting a restaurant open with an unconfigured tax rate.
3. 3

   Your menu goes in

   Typed in, imported from a file, or pushed through the partner API from your existing system.
4. 4

   You dress your page and print the QR code

   Logo, colour and typeface in the console, with a live preview driven by the same code the real page runs — so a preview can never disagree with what your customers see. Then the snippet, if you want the page on your own website too.
5. 5

   You go live and take the first order

   On the kitchen tablet, in a browser. Pause it whenever you need to.

Already on Angie Eats? Sign in to the merchant console.