PAR POS™ | API Release Notes
Build 0.2.148 · PAR POS v5.16r3 · August 2026
API Change Report: v5.16 r2 → v5.16r3
| ✅ No Breaking Changes in this Release. All changes are fully backward compatible. Existing integrations require no code changes. |
|---|
API Portal & Documentation
Full API documentation — including message examples, schema definitions, and field descriptions — is available on the PAR POS Developer Portal:
https://developers.partech.com/
API Best Practices
Request Rate & Batching
Batch requests should be sequential. If end-customer systems allow multi-threaded load, adhere to the recommended Requests Per Minute (RPM) limits below.
Changes should be published and tested on one location first, then cascade to other locations.
If changes are made in parallel at multiple locations, only single-record changes should be executed — bulk/batch operations are not recommended in parallel scenarios.
Changes from one location must not be cascaded to more than 500 locations at once.
Rate Limits (applicable for both EOD and Immediate Publish)
| Endpoint Group | Max Batch Size | Max RPM |
|---|---|---|
| SaveItems, SaveDestinations, SaveTaxes | 100 | 5 |
| DeleteItems, DeleteDestinations, DeleteTaxes | 20 | 5 |
| SavePriceChange / DeletePriceChange | Not recommended (single record only) | — |
API Build 0.2.148 — What’s New
New Features
| ID | Description |
|---|---|
| AS1-3736, AS1-3737 | Deliverect 1PD driver Check-Out / Check-In lifecycle. Completes the first-party delivery (1PD) driver lifecycle by adding the Check-Out and Check-In events alongside the DeliveryDroppedOff event delivered earlier under AS1-3526. Events originate at the Deliverect terminal, are relayed by the customer, and are applied to the order through the delivery-events API surface described below. Check-Out records driver departure: the order moves to In Transit / Out for Delivery, and the departure timestamp and driver employee are stored on the order. A departure covering multiple orders raises one event per order. Check-In settles the trip: a COMPLETED event applies Cash to any outstanding balance, closes the order, and logs the outcome, while an event with any other status is logged without changing order state. Payment on the road is cash-only; card collection on the road is out of scope for this release. A driver POS login session is not required for either event (AS1-3760 / AS1-3761). Requires a Delivery-type destination and an active Cash tender available to the ordering/API path. |
1PD Delivery Events — API Surface
The stories below deliver the endpoints, headers, and schema behind the Check-Out and Check-In lifecycle described above.
| ID | Description |
|---|---|
| AS1-3661 | Check-Out webhook endpoint with HMAC authentication. The customer posts one check-out webhook per order to PAR when a driver departs the store. Requests carry an Authorization: HMAC {hex-signature} header; PAR verifies HMAC-SHA256 over the raw request body using a per-location. A valid event is enqueued to the target store via SQS and an EKS worker, and PAR responds 202 Accepted. An invalid signature returns 401 and is logged. Every event is logged with eventId, orderId, locationNumber, employeeId, timestamp, and the HTTP response code. |
| AS1-3650 | Cloud API delivery-events endpoint. POST /v1/orders/{orderId}/delivery-events on the Cloud API Order Service accepts a driver delivery event and forwards it to the corresponding in-store endpoint. The request carries DriverEmployeeId, EventType (DriverCheckout or DriverCheckin), and Timestamp. Cloud API authenticates the request and routes it to the correct location and stack. This is the above-store half of the delivery-events endpoint pair. |
| AS1-3649 | In-store Order Service delivery-events endpoint. POST /v1/orders/{orderId}/delivery-events on the in-store Order Service receives the Check-Out or Check-In event routed from Cloud API, with the same DriverEmployeeId, EventType, and Timestamp fields. Processing raises an SQS message to the in-store handling added under AS1-3626, so the register can update order state — In Transit, cash application, and close. This is the store-side half of the pair. |
| AS1-3708 | Cash tender accepted on add-payment for delivery orders. POST /v1/orders/add-payment on Order Service previously restricted this path to External tender; TenderType.Cash is now accepted as well, because on-road payment for 1PD is cash-only. The register ApplyPaymentMessageHandler applies the same allowance when the order destination is Delivery. For cash tender the request EmployeeId is set to the order OwnerId, so the payment is attributed to the driver already assigned to the delivery order. Requires an active Cash tender and a Delivery-type destination. |
| AS1-3718 | Idempotency-Key header on add-payment. ApplyPayment is now idempotent, so a retried Check-In following a network timeout or worker retry does not apply cash twice. The caller sends the event ID as an Idempotency-Key header; Cloud API POST /v1/orders/{orderId}/add-payment accepts the header and forwards it to Order Service, which carries it on the SQS message properties. The register checks the key against the order payment additional data under lock: if the key is already present, it returns AlreadyApplied; otherwise it stores the key and applies the payment. Cloud API and Order Service both return 200 when the register reports AlreadyApplied. Clients and workers must send the header; no store configuration is required. |
| AS1-3750 | Cash payments can carry additional data for idempotency. Adds ApplyCashPaymentInfo, derived from ApplyPaymentInfo with an AdditionalData NameValuePairs collection, so cash payments can carry the idempotency key at parity with external payments. Cash is registered in ApplyPayment XML dispatch ApplyPaymentMessageHandler now builds an ApplyCashPaymentInfo carrying the key rather than passing null; validators treat cash additional info as optional but require it to be ApplyCashPaymentInfo when present; and audit helpers handle ApplyPaymentInfoType.Cash. Without this, a retried cash Check-In payment could be applied more than once. Works with the idempotency flow in AS1-3718. |
| AS1-3745 | Check-In cash amount taken from the order balance. On a COMPLETED 1PD Check-In, ApplyPayment uses the order's own outstanding order. Balance for the cash tender amount rather than a paidAmount supplied by the customer or Deliverect, which do not capture the exact cash collected on the road. This is the same balance CloseOrder already computes before close, so an unpaid cash delivery order can settle and close without depending on an external amount field. Follows the pattern used for 3PD under AS1-3598. |
| AS1-3744 | Check-In / Check-Out event schema normalized. Delivery status, Check-In, and Check-Out payloads are mapped into the PAR internal delivery model, so orderId, runId, location, status, timestamp, employee, tip, and the related delivery, trip, and courier fields stay accurate even where PJI field names or shapes differ. Downstream Check-Out and Check-In processing reads the normalized fields. This is a contract and mapping change for integrations with no Settings Editor component; confirm payloads match the agreed schema for your environment. |
| AS1-3764 | Tip and mileage fields on the Check-In schema. The published Check-In event schema now formally carries tip and mileage (distance) data. PAR consumes and forwards those fields with the Check-In event so downstream consumers — Mileage Accumulator and PAR can calculate driver compensation without waiting on a separate contract. The customer and Deliverect send tip and mileage on Check-In where available. |
WSDL Changes (0.2.145 → 0.2.148)
The delivery-events endpoints, the Cash allowance on add-payment, and the Idempotency-Key header are REST additions on the Cloud/External API path and are not represented in the CDN-published WSDL files. AS1-3750 introduces the ApplyCashPaymentInfo type into the ApplyPayment serialization contract used between the API and the register. No changes to the CDN-published WSDL files have been identified for the SOAP services covered by this release: the AS1-3753, AS1-3755 and AS1-3800 fixes change response content and result codes only, so SOAP clients using auto-generated proxies require no regeneration for this build.
Reviewer note: confirm WSDL parity against the CDN-published files before publishing, and set the AS1-3800 fix version once the ticket exits QA. Remove this note prior to release.
API Build 0.2.145 — What’s New
New Features
| ID | Description |
|---|---|
| AS1-3617, AS1-3495, AS1-3638 | DSP modifier group pricing — SOAP support added. The SavePriceChanges and GetPriceChanges SOAP operations (Settings2.svc) now support alternate modifier group pricing per Delivery Service Partner (DSP), matching the REST implementation shipped in 0.2.143. A nested PriceChange → ModifierGroupPriceChanges → ModifierGroupItemPriceChanges model is used. Use negative IDs when creating new records; positive IDs for updates. Note: ModifierGroupPriceChange and ModifierGroupItemPriceChange are part of the runtime contract but are not yet declared in the CDN-published Settings2.xml WSDL — see the WSDL Changes section below. The modifier pricing fields in the SOAP contract follow PascalCase (ModifierGroupId, ModifierGroupItemId, Price); the group Name field is accepted but not persisted. Save semantics are delta-only: send only the changed modifier group items, not the full group. |
WSDL Changes (0.2.143 → 0.2.145)
The CDN-published WSDL files have the following status in this release. SOAP clients relying on auto-generated proxies from the CDN WSDL should review the notes below before implementing modifier pricing.
| WSDL | Change in 0.2.145 | Notes |
|---|---|---|
| Settings2.xml | No change (byte-identical) | ModifierGroupPriceChange and ModifierGroupItemPriceChange types are NOT declared in the CDN-published WSDL. Use the runtime contract shapes documented in this guide. Refer to wsdl-diff/WSDL_DIFF_REPORT.txt and wsdl-diff/MODIFIER_SCHEMA.txt for full diff details. |
| Sales2.xml | Updated | Adds three new fields to the Order type: CustomerMaskedAccountNumber (masked gift card account number, per AS1-3581); FutureDateOrderStatus (FDO status string — Pending, Processed, or Closed — per POG-3254/AS1-3493); and AccountNumber on OrderGiftCard (gift card last 4 digits, per AS1-3581). Integrators using the GetOrders or GetFutureDateOrders SOAP operations should regenerate proxies or manually add these fields to their contracts. |
| HouseAccounts.xml | No change | No API-relevant changes in this release. |
| Kitchen.xml | No change | No API-relevant changes in this release. |
| Labor2.xml | No change | No API-relevant changes in this release. |
| Ordering.xml | No change | No API-relevant changes in this release. |
| Settings.xml (v1) | No change | No API-relevant changes in this release. |
Key Field Rules (SOAP & REST)
| Field | Rule |
|---|---|
| ModifierGroupItemId (SOAP) / modifierGroupItemId (REST) | Maps to ModifierGroupItem.Id (the container/mapping ID), NOT the menu ItemId. |
| Price / price | Required for modifiers with ModifierPriceMethod = ModifierPrice. |
| Group Name (SOAP) | Accepted in XML but not stored. Omit for clarity. |
| Item name / originalPrice | Not stored; not part of the REST schema. |
| Save semantics | Delta-only — send only changed modifier group items, not the full group. |
| Create vs. update | Use negative Id for new records; positive Id for existing records. |
API Build 0.2.143 — What’s New
New Features
| ID | Description |
|---|---|
| AS1-3581 | Gift card last 4 digits now returned by GetOrders. The GetOrders API (REST and SOAP) now returns the last 4 digits of a gift card’s account number in a new AccountNumber field on the OrderGiftCard object. The field is masked for security, consistent with how payment card numbers are handled elsewhere in the API. API portal documentation and the OpenAPI schema have been updated to reflect the new field. Note: AccountNumber is only populated for OrderGiftCard items and does not apply to other order line types. |
| AS1-3318 AS1-3582 |
SavePromotions pricing and availability updates via API (PMP/RSI integration). The SavePromotions API now supports modifying promotion price and availability through external price management integrations such as RSI/PMP. Two new REST endpoints are now available for managing promotions: • POST /settings/v1/promotions – Creates one or more new promotions. Returns HTTP 201 with assigned IDs. • PUT /settings/v1/promotions – Updates existing promotions. Returns HTTP 200. A new SOAP SavePromotions operation is also available, supporting the same create/update workflows. Supported promotion types: BOGO, Gift Card, Coupon, Order Reduction, and Combo. Promotions can include complex configurations such as qualifications, discount items, combo components, destinations, sections, eligible items/groups, and custom fields — all with IDs automatically assigned on creation. Changes can be published immediately or via changesets. Obsolete fields have been clearly marked in the API contract to guide integrators away from deprecated properties. Notes • When creating promotions via the REST API, the request payload must use negative IDs; positive IDs are required when updating existing promotions. • The SavePromotions SOAP operation bypasses certain validation logic by design — integrators should ensure data accuracy before submitting. • The MarketingCampaigns data type must be explicitly requested in the GetSettings call; it is not returned by default. • Several obsolete fields are now marked deprecated in the API schema. Integrators should review and migrate away from these fields in future integrations. |
| AS1-3495, AS1-3546, AS1-3557, AS1-3578 | DSP-specific modifier group pricing added. The SavePriceChange and GetPriceChange APIs now support alternate modifier group pricing per Delivery Service Partner (DSP). A new ModifierGroupPriceChanges array field has been added to the PriceChange data type, along with two new data types: ModifierGroupPriceChange (modifier group identifier, name, and a list of item price changes) and ModifierGroupItemPriceChange (item identifier and updated price). The Ordering Service now applies DSP-specific pricing logic when a modifier group item’s price method is set to ModifierPrice. Full API Portal documentation and code samples (C#, C# Core, Python, XML) are included. This change is fully backward compatible — the ModifierGroupPriceChanges field is optional and only required when DSP-specific modifier pricing is needed. Update Postman collections and SoapUI suites accordingly. |
| AS1-3583 | GetSettings now returns marketing campaign data for SavePromotion. The GetSettings API response now includes marketing campaign data fields, matching the structure and field names exposed by the Settings Editor UI. This data is required input for the SavePromotion API — campaign attributes returned by GetSettings must be supplied back when creating or editing a promotion via API. Without this fix, promotion save operations would fail validation. |
| POG-3254 | FDO status now included in historical order data. FDO status (Pending / Processed / Closed) is now surfaced through the cloud API for back-office integrators. Previously, FDO status was available in the Historical Data Model (Order
|
| MPP-37 | CalculateOrder and SubmitOrder API enhancements. Both APIs now support percentage-based and fixed-amount discounts via discountPercentage and discountAmount fields, applied to the pretax subtotal. SubmitOrder has been extended with three additional capabilities: an employeeId field to associate orders with a specific employee (supporting tip handling, till management, and tip pooling); expanded payment metadata, including CardType, CardNumber (masked to last 4 digits), TransactionNumber, and TransactionIdentifier; and support for auto-added surcharges. Existing CalculateOrder and SubmitOrder functionality is unchanged. |