Skip to main content

Changelog

API and documentation changes relevant to integrated partners, most recent first. Additions are backward-compatible unless a row explicitly says otherwise.

2026-08-10 - Create venues for standalone restaurants​

Additive - no breaking change.

  • New endpoint: GET /v1/pat/pos-types - discover which POS systems are available for venue creation (use its code values as posType).
  • New endpoint: POST /v1/pat/venues - create a venue for a restaurant that runs a supported POS (LIGHTSPEED_K_SERIES, SIMPHONY, SAAPAD) but is not yet in Mozrest. The venue is automatically added to your partner scope and the response includes the onboarding link where the restaurant connects its POS account, poll /features to know when the POS connection goes live.
  • Duplicate protection: if the restaurant's POS location is already connected to an existing Mozrest venue, the POS connection is rejected during onboarding ("location already connected"). Contact Mozrest support to request access to the existing venue instead.

2026-08-10 - Lightspeed K-Series live + synchronous grace window on deferred payments​

Additive - no breaking change.

  • The first deferred-confirmation POS is live: venues on Lightspeed K-Series can now be provisioned with payAtTable.paymentForwarding = true and paymentConfirmation = "deferred".
  • On deferred venues Mozrest now holds the payment POST for a few seconds while the POS confirms. Most payments answer a synchronous 200 OK with a terminal status; 202 Accepted + polling remains the contract for the slower tail. Keep the polling loop - nothing changes for integrations that already handle 202, and nothing changes on immediate-confirmation venues.
  • Documentation clarified: the payment amount is tip-inclusive, so a settle-up with a tip is amount = totalDue + tip. See Get bill - totalDue and Submit payment.

2026-07-13 - Payment lifecycle and status polling​

Additive - no breaking change. All currently provisioned venues keep answering 200 OK with status: "confirmed" on the payment endpoint; existing integrations work unchanged.

  • Every payment object now carries three new fields: status (pending / confirmed / failed), failureCode (stable slug, set only on failure), and confirmedAt. See Submit payment - payment lifecycle.
  • New endpoint: GET /v1/pat/venue/{venueId}/order/{orderId}/payment/{externalReference} - read back a payment's current state, keyed on your own externalReference.
  • Venues on deferred-confirmation POSs (none provisioned yet; the first will be Lightspeed K-Series) answer 202 Accepted with status: "pending" on the payment POST; you then poll the payment to a terminal state. Guaranteed terminal within 120 seconds. See the integration loop.
  • /features gains payAtTable.paymentConfirmation ("immediate" or "deferred").
  • New 409 cause on the payment POST: submitting a new externalReference while another payment on the same order is still pending. See Errors.
  • The bill's totals.paid and the auto-close rule now count confirmed payments only - pending and failed payments never settle the bill.
  • Idempotent replays now return the payment's current state (previously documented as the original snapshot), with the HTTP code matching that state.

2026-07-03 - Venue listing pagination and canonical bill items​

  • GET /v1/pat/venues gained pagination and filtering: offset (default 0), limit (default 10, max 100), filters[name], filters[city], filters[countryCode], plus total and per-venue city in the response. Behaviour change: the endpoint previously returned your full venue scope unpaginated; the default page size is now 10 - pass limit/offset if you expect more than 10 venues.
  • Bill line items are now normalised to one canonical shape for every POS: { id, name, quantity, unitPrice, price, total }. Previously the fields present per item could vary with the venue's POS.
  • Documentation corrected to match actual API behaviour: the error envelope is nested ({"error": {code, message, details}}), a missing Authorization header returns 403 (an invalid token returns 401 with an OAuth-style body), and validation errors return the field map in error.details.

2026-06-17 - Outstanding balance and partial-payment maturity​

  • The bill response gained totals.prepayment, totals.paid, and totals.totalDue - always charge totalDue, not total, so deposits and earlier partial payments are accounted for.
  • Cumulative partial payments now auto-close the order once they cover the bill - no need to flip the last call to type: "full".
  • Bill items gained unitPrice and total per line.
  • Payment forwarding failures (502) return a controlled, partner-displayable error.message.

2026-05-11 - Initial sandbox availability​

  • Pay-at-Table API live on sandbox (https://api-sandbox.mozrest.com): venue discovery, table listing, bill retrieval, payment submission (full and partial with tip), and per-venue feature discovery.