PAR Brink API
PAR Brink POS (PAR POS) is a cloud point-of-sale platform for quick-service, fast-casual, table-service, convenience, and cinema operators. An unofficial API lets you pull orders, checks, payments, menu items, modifiers, discounts, taxes, tills, sales totals, employees, and labor schedules—and push updates like order submission, item 86s, and availability changes back into Brink.
What is PAR Brink?
PAR Brink (now marketed as PAR POS) is a cloud point-of-sale platform from PAR Technology used by quick-service, fast-casual, table-service, convenience and fuel, cinema, and hospitality operators. Restaurants run Brink to ring up orders and checks, process payments, manage menus and modifiers, drive online and kitchen ordering, schedule labor, and report sales across single sites and multi-unit brands.
Core service areas include:
- Ordering (submit, calculate, and retrieve orders; manage item availability and payments)
- Sales2 (sales data including deposits, orders, tills, and business dates)
- Settings and Settings2 (items, employees, taxes, discounts, and location configuration)
- Kitchen (kitchen queues and order bump times)
- Labor2 (labor schedules and shift data)
- HouseAccounts (account charges and payments)
Common data entities:
- Orders, Checks, Order Lines, Payments, Deposits
- Menu Items, Modifiers, Item Availability, Destinations
- Taxes, Discounts, Tills, Business Dates
- Employees, Labor Schedules, Shifts, Jobs
- House Accounts, Account Charges, Kitchen Queues
The PAR Brink Integration Challenge
Operators run Brink as their system of record at the register, but turning it into clean API-driven automation is non-trivial:
- SOAP/XML surface: The core API is SOAP-based with per-service WSDLs (Ordering, Sales2, Settings, Kitchen, Labor2, HouseAccounts), requiring SOAPAction headers and XML payloads rather than simple JSON
- Per-location access tokens: Each store carries its own access token and endpoint environment (production Admin2 vs. development APIINT), so multi-unit brands must manage credentials and routing per site
- Mixed SOAP and REST: Newer Order, Data, and Settings REST services coexist with the legacy SOAP services, so coverage and shapes differ depending on which surface you hit
- Partner approval gates: API portal access and production credentials are provisioned through PAR and the operator, gating headless automation behind onboarding
- Master terminal dependencies: Calls like submitting orders depend on the Primary Register being online, so integrations must handle terminal-status checks and retries
- Per-brand configuration: Items, modifiers, taxes, discounts, and destinations are configured per location, so generic mappings break across franchisees and concepts
How Supergood Creates PAR Brink APIs
Supergood wraps Brink's SOAP and REST services—Ordering, Sales2, Settings, Kitchen, Labor2, and HouseAccounts—behind a single normalized, JSON API for your locations, so you integrate once instead of generating WSDL clients per service.
- Manages per-location access tokens, endpoint environments, and SOAPAction routing securely
- Normalizes orders, checks, payments, menu, and labor objects into consistent JSON across SOAP and REST surfaces
- Handles master-terminal status checks, retries, and idempotency when submitting orders and availability changes
- Adapts to per-location item, modifier, tax, and discount configuration so mappings stay correct across brands
Use PAR Brink with AI agents: PAR Brink MCP Server →
Getting Started
- Schedule Integration Assessment
Book a 30-minute session to confirm your Brink services, locations, and access-token model.
- Supergood Generates and Validates Your API
We deliver a production-ready Brink adapter tailored to your locations and configuration.
- Deploy with Monitoring
Go live with continuous monitoring and automatic adjustments as Brink evolves.
API Endpoints
Authentication
/authenticateAuthenticate to a Brink location using its access token and obtain a session for downstream service calls.
Ordering
/ordersRetrieve orders and checks with filters for business date, destination, and status across the Ordering and Sales2 services.
Ordering
/submit_orderCalculate and submit an order with items, modifiers, and payments, honoring master-terminal status checks.
Menu
/menu_itemsPull menu items, modifiers, taxes, and discounts from the Settings and Settings2 services for a location.
Menu
/item_availabilityUpdate or retrieve item availability to 86 or re-enable products in the Ordering service.
Sales
/salesRetrieve sales totals, deposits, tills, and business-date summaries from the Sales2 service.
Labor
/laborPull employees, labor schedules, and shift data from the Labor2 service.
Use Cases
Sync orders and sales into your data stack
- Pull orders, checks, and payments by business date from Ordering and Sales2 into a single warehouse - Stream sales totals, deposits, and tills to BI and reconciliation tools - Unify multi-location order data across franchisees into one normalized schema
Automate online and third-party ordering
- Submit calculated orders with items, modifiers, and payments into the Ordering service - Check master-terminal status and retry so orders land reliably at the register - Push delivery and pickup orders from online and marketplace channels into Brink
Keep menu and availability in sync
- Pull menu items, modifiers, taxes, and discounts from Settings and Settings2 - 86 or re-enable items by updating availability without touching each terminal - Reconcile per-location menu configuration across brands and concepts
Surface labor and kitchen operations
- Pull employees, schedules, and shift data from Labor2 for workforce tools - Monitor kitchen queues and bump times to track throughput - Feed labor and sales data into scheduling and forecasting systems
Technical Specifications
Authentication
Per-location Brink access tokens and SOAPAction headers handled in a managed session
Connectivity
Brink SOAP services (Ordering, Sales2, Settings, Kitchen, Labor2, HouseAccounts) plus newer Order, Data, and Settings REST services
Response format
Normalized JSON across orders, checks, menu, sales, and labor objects regardless of SOAP or REST source
Rate limits
Adaptive throttling tuned per location and environment to avoid register-side impact
Session management
Automatic token handling, environment routing, and credential rotation per location
Data freshness
Near real-time reads for orders and sales with optional scheduled batch syncs by business date
Security
Encrypted credential vault, scoped access tokens, SOC 2-aligned controls, and audit logging
Webhooks
Event-style callbacks for new orders, payments, item availability, and business-date close
Latency
Sub-second reads on cached menu and sales data; multi-second writes when submitting orders through the register
Throughput
Horizontally scaled workers sized to multi-unit order and transaction volume
Reliability
Retry, backoff, master-terminal status checks, and idempotency keys for order submission
Adaptation
Continuous monitoring of Brink service releases, REST rollouts, and per-location configuration drift
Frequently asked questions
Yes. Supergood wraps both the SOAP services (Ordering, Sales2, Settings, Kitchen, Labor2, HouseAccounts) and the newer Order, Data, and Settings REST services behind a single normalized JSON API, so you integrate once regardless of which surface a call comes from.
Each Brink location has its own access token and endpoint environment. Supergood stores and routes those credentials securely per site, so multi-unit brands get one API instead of managing tokens and environments themselves.
Yes. Supergood calculates and submits orders with items, modifiers, and payments through the Ordering service, including master-terminal status checks and retries so orders land reliably at the register.
Production access tokens are provisioned through PAR and the operator. Supergood works against your existing authorized Brink credentials and does not require you to build WSDL clients or manage the SOAP plumbing yourself.
Yes. You can 86 or re-enable items by updating availability in the Ordering service through the API, without touching each terminal, and reconcile menu configuration across locations.