What is POS integration?
August 13, 2026
POS integration is the work of connecting your product to the point-of-sale platforms your customers run their stores and restaurants on, such as Clover, Square, or Toast, so your application can read their sales, tenders, tips, inventory, and staff time-clock data.
A point-of-sale platform is not one data category. At Unified, POS includes the Accounting, E-Commerce, and Payment APIs, and POS platforms that run the time clock, such as Clover, also serve the HR & Directory API: one authorized connection carries every category the platform supports, across 142+ POS integrations as of August 2026.
Why does POS data span four categories?
A point-of-sale platform sits at the intersection of the sale, the money, the catalog, and the staff, so its data belongs to four categories at once. Treating "POS" as one flat category forces a receipt, a card tender, a stock count, and a clock-in through a single generic schema, and the schema can only be as deep as its shallowest member.
Unified models it the other way around: the POS is one integration, and each kind of data it records is served through the category API built for that data.
| What the POS records | Unified category API | What the objects carry |
|---|---|---|
| The sale | Accounting | Sales orders with the receipt number, the serving employee, the register device, dine-in through curbside fulfillment types, guest count, and subtotal, tax, discount, tip, and service-charge amounts |
| The tender | Payments | Payments with a normalized tender type across ten categories from card and cash to buy-now-pay-later, the card brand and last four, the tip, the processing fee, and a reference to the sales order the payment settled |
| Catalog and stock | E-Commerce | Items, variants, inventory, and store locations |
| Staff and the time clock | HR & Directory | Employees, and attendance records carrying the job worked, the hourly rate, and declared and non-cash tips |
| The table describes the data models; whether a given field returns data depends on what each platform's own API provides and how far its mapping has been built, and the per-integration capability page documents it field by field. The same trade the composition approach makes everywhere applies here: a flat POS schema gives you one model to learn, and four category APIs give you deeper models and a discovery cost. The capability pages exist to pay that cost down before you build. |
Why is the time clock part of POS integration?
Retail and restaurant staff clock in and out on the register, which makes the POS the source of record for hourly attendance. That data is served through the HR & Directory API, where attendance records carry hours, tips, and, where the platform provides them, the job worked and the hourly rate, next to the same employee objects your HRIS integrations return. A scheduling or payroll product reads clock and tip data from a POS the same way it reads employee records from an HRIS, on the same connection that carries the sales.
How does POS integration work through a unified API?
One authorized connection to the customer's POS carries every category that integration supports, and your application calls each category-scoped API with the same connection ID. When a customer authorizes Clover once, your sales reads, your tender reads, your inventory reads, and your attendance reads all run through that single authorization.
Requests are routed directly to the source API. Unified is a real-time pass-through system rather than a fetch-and-store system: there is no copy of your customer's sales or staff records sitting in a vendor database between your application and the POS. For store data, that matters continuously, because a sale closes, stock moves, and a shift starts every few minutes of a trading day.
The models keep the source's own labels next to the normalized values. A payment's tender is normalized into one of ten categories, and the platform's original label stays in payment_method; a sales order's charges are normalized into typed fees, and the platform's original fee label travels with each one. Normalization never costs you the native detail, and the original provider fields are always in raw, with the Passthrough API reaching any endpoint of the POS platform's own API on the same connection.
How do you get events from a POS without building polling infrastructure?
Where a POS platform's API offers webhooks, Unified delivers them as native events. Where it doesn't, virtual webhooks detect changes and deliver events on an interval you set, down to one minute on paid plans, and they only bill when data is found: a one-minute check that finds nothing costs nothing, which is what makes a one-minute interval usable as a default in a store that's quiet between lunch and dinner. Event support per integration is documented in each capability matrix. More on the pattern in receiving updates from APIs without webhooks.
What can you build with POS integration?
- Sales and revenue analytics. Read sales orders across every location a customer connects, with tips and service charges broken out rather than buried in totals, so POS and back-office records stay aligned.
- Books that match the register. Each payment references the sales order it settled, so reconciling the day's tenders against the day's tickets is a join, not an export, alongside the customer's payment platforms.
- Store staff in sync. Employee records on POS platforms support reads and writes, so staff profiles flow between the systems HR owns and the register the store runs on.
- Scheduling and workforce products. Read clock-ins, hours, and tip declarations from the store floor through the HR & Directory API, and write scheduled shifts back where the platform supports it.
- Inventory that agrees across channels. Keep items and stock aligned between the register and an e-commerce storefront through one commerce model.
Which POS platforms does Unified support?
The live integration directory is the current source, and as of August 2026 it includes Clover, SquareUp, Toast, PAR Brink POS, Revel Systems, Restaurant365, Rosnet, and the Lightspeed family as four distinct integrations: Lightspeed POS (X-Series), Lightspeed Restaurant (K-Series), Lightspeed Retail R-Series, and Lightspeed eCom (C-Series). Which categories each platform spans differs by integration; Clover, for example, serves the accounting, payments, e-commerce, and HR & Directory APIs, and the Lightspeed variants each carry their own category set, so check the integration page for the platforms your customers run. Toast is live in the accounting, payments, e-commerce, and HR & Directory categories as of August 13, 2026, and there's a guide to configuring webhooks in Toast for Unified.
→ Start your 30-day free trial → Book a demo
FAQ
Is POS a category in the Unified API? No, and that's deliberate. POS at Unified is the Accounting, Payments, E-Commerce, and HR & Directory APIs together on one connection, so a receipt gets an accounting-grade model, a tender gets a payments-grade one, and a clock-in gets an HR-grade one, instead of all three flattening into a generic POS schema.
How are tenders normalized across platforms?
Every payment carries a normalized tender type across ten categories, from card and cash through gift card, bank transfer, wallet, check, store credit, and buy-now-pay-later, and the platform's original label stays in payment_method beside it. Your reporting groups by the normalized value; your reconciliation keeps the native one.
Do I have to use all four categories? No. You call only the category APIs your build needs; the connection carries whichever categories the integration supports. A pure analytics product reads accounting and payments and ignores the rest.
What if the data I need isn't in the unified models?
Every object returns the original provider fields in raw, and the Passthrough API reaches any endpoint of the POS platform's own API on the same connection.
Author
Written for Unified.to by Mallory Greene
About the author: Mallory Greene is a writer specializing in generative engine optimization (GEO) and content, through her practice Search Everywhere. She covers integration infrastructure and technical content across Unified.to's technical content library. Based in Toronto.