For POS companies
POS Connect: one standard API to bring your venues’ sales into Restaurant AI Manager.
POS Connect is Open Pantry’s published API for point-of-sale companies. Your POS pushes each venue’s sales, menu items, refunds, voids and day close as signed JSON events, and the venue’s Restaurant AI Manager matches them to its recipes for food cost and GP. You build to the public docs, prove it in a sandbox, and Open Pantry lists you for every venue.
- One API for every venue you serve, documented in public
- A sandbox that validates exactly like live, and touches no venue
- Signed requests and a separate key for every venue
- Self-certify against a 10-item checklist, then get listed
POST /api/v1/pos-connect/events
Authorization: Bearer opc_live_…
webhook-id: evt_1001_r1
webhook-timestamp: 1793000530
webhook-signature: v1,…
{
"id": "evt_1001_r1",
"type": "check.closed",
"spec_version": "0.1",
"occurred_at": "2026-10-25T19:42:10+11:00",
"location_id": "store_12",
"data": {
"id": "chk_1001",
"revision": 1,
"status": "closed",
"business_date": "2026-10-25",
"tax_mode": "inclusive",
"lines": [ … ],
"tenders": [ … ]
}
}- 1 token
- per venue, with its own signing secret and scopes
- 5 minutes
- signature timestamp tolerance, so captured requests can’t be replayed
- 500 events
- per live batch, each answered in order
- 10 items
- on the self-certification checklist
How POS Connect works, in four steps
Build to the published spec, prove it in the sandbox, and get listed.
- Read
Read the public docs
Authentication and signatures, the event envelope, every event type, idempotency, batches, size and rate limits, error codes and sample payloads — one page, no login. Ask us for the POS Connect docs.
- Build
Build against the sandbox
Register with one request for a sandbox key and signing secret. Once Open Pantry approves the registration, the sandbox runs the live receiver’s checks — same signatures, limits, validation and error codes. It only validates: nothing reaches a venue.
- Prove
Self-certify against 10 items
Each event the sandbox accepts ticks what it proves. Read your checklist any time:
- A sale
- The menu
- A refund
- A void
- A modifier
- A split payment
- A tip
- A discount
- A day’s close
- A safe retry
- Go live
Open Pantry approves and lists you
With the checklist complete, Open Pantry reviews your outcomes and lists you in every venue’s Connect a POS screen as “POS Connect: your name”, for the countries you serve. Each venue that picks you gets its own live token.
The data your POS sends
Events in one envelope — an id, a type, the time with its UTC offset, your location id and the data. Money and quantities are decimal strings, and every sale line balances to the cent.
- Sales
check.closed - Each paid check with its lines, modifiers, discounts and comps, and its payments — split tenders and tips included. A changed check is resent with a higher revision.
- Menu items
menu.updated - Items and their variations, with modifiers, combos and categories — the full menu, or only what changed.
- Refunds
refund.created - What was given back, linked to the original check and line where you have them, and whether it really went back on the shelf.
- Voids
check.voided · line.voided - A whole check or one line, with whether the kitchen had already made it — so the venue sees waste, not just a reversed sale.
- The day’s close
day.closed - The trading day’s total, which Open Pantry reconciles against the sales you sent.
- Location and heartbeat
location.updated · location.heartbeat - Optional: the location’s name, time zone, tax mode and trading day, and a heartbeat that keeps a quiet feed showing live.
Never sent: card data or customer details. An event with a card number, CVV or expiry is discarded whole — not stored, not logged — and refused.
Security: signed requests and a key for every venue
A stolen token alone cannot write, and a captured request cannot be replayed.
- Every write is signed
- Writes carry a Standard Webhooks signature — HMAC-SHA256 over the request id, timestamp and exact body — on top of the bearer key. A timestamp more than five minutes off is refused.
- One connection token per venue
- Each venue gets its own token and signing secret, shown once. A token covers one venue and only the event types its scopes allow — menu, sales and adjustments.
- Secrets are never stored in the clear
- Open Pantry keeps only a keyed digest of each token and an encrypted copy of each signing secret.
- Rotate or revoke at any time
- Rotate a signing secret through the API; the old one keeps working for 24 hours. When a venue disconnects, its token stops working at once and your POS is told so.
- Sandbox and live never mix
- Your sandbox key works only on the sandbox and never reaches a venue; a venue’s token never works on the sandbox.
- Safe retries and fair limits
- The event id makes every retry safe. Rate limits are per token and per IP address, and every error is an RFC 9457 problem response that points at the field to fix.
Questions POS companies ask
- What is Open Pantry POS Connect and who is it for?
- POS Connect is a standard, published API for point-of-sale companies. Your POS pushes each connected venue’s sales, menu, refunds, voids and day close to Open Pantry, and the venue’s Restaurant AI Manager uses them for food cost, GP and stock. You build to the public docs yourself — there is no one-off integration to negotiate.
- Does Open Pantry pull data from our POS, or does our POS push it?
- Your POS pushes. Open Pantry never pulls from your system. You send signed JSON events to the receiver as they happen, singly or in batches of up to 500, and the receiver answers 202 once each event is stored. If a venue asks for a day again, it appears as a backfill request your POS can read and resend.
- What data does a POS send through POS Connect?
- Closed checks with their lines, modifiers, discounts and payments (including tips); refunds; whole-check and single-line voids, with whether the kitchen had already made the item; the menu, in full or as changes; and the day’s close with its total. Location details and a heartbeat for quiet hours are optional. Money and quantities are sent as decimal strings.
- How are POS Connect requests authenticated and signed?
- Every request carries a bearer key. Every write must also carry a Standard Webhooks signature: an HMAC-SHA256 of the request id, a timestamp and the exact body, using the signing secret. The timestamp must be within five minutes of Open Pantry’s clock, so a stolen token alone cannot write and a captured request cannot be replayed later.
- What is a per-venue connection token, and what happens when a venue disconnects?
- Each venue that connects your POS gets its own connection token and signing secret, shown once, which the venue enters in your POS. One token covers one venue, and only the event types its scopes allow. Open Pantry keeps only a keyed digest of the token. If the venue disconnects, the token stops working at once and your POS is told the connection was revoked.
- How does the POS Connect sandbox work, and can test data reach a real venue?
- You register with one request and get a sandbox key and signing secret. Once Open Pantry approves the registration, the sandbox runs the same signature, size and validation checks and returns the same error codes as live. It only validates: nothing you send reaches a venue, and it keeps each event’s id, type and outcome, not your payloads.
- What is on the POS Connect self-certification checklist?
- Ten items: a sale, the menu, a refund, a void, a modifier, a split payment, a tip, a discount, a day’s close and a safe retry (the same event id sent twice, answered as a duplicate). Each item is ticked automatically by the first sandbox event that proves it, and you can read your checklist and recent outcomes at any time.
- How does our POS get listed for Restaurant AI Manager venues?
- When your checklist is complete, Open Pantry reviews your sandbox outcomes and lists you in every venue’s Connect a POS screen as “POS Connect: your name”, for the countries you serve. A venue that picks you gets its own live token. Your sandbox key never reaches a venue, and a venue token never works on the sandbox.
- What happens if our POS resends an event or a check changes after it closes?
- The event id is the idempotency key, so resending the same event is answered as a duplicate and nothing is counted twice — always retry with the same id. A changed check is sent as a new event with the same check id and a higher revision; the highest revision wins, whatever order the events arrive in.
- Can we send card numbers or customer details through POS Connect?
- No. Card data is never accepted: an event with a card-number field, a CVV or expiry field, or text that looks like a card number is discarded whole — not stored, not logged — and answered with an error. Payments carry only a fixed set of fields. Never send customer names, emails, phone numbers or addresses.
Building a POS integration? Start with the docs.
Everything you need to build and self-certify is public. Questions about POS Connect or your listing — talk to the team.
Or email info@theopenpantry.com