Skip to main content
You build a reporting product. Your end-users connect their point-of-sale systems and expect to see their sales performance in your tool: turnover by location, revenue per product category, busiest periods, payment method breakdown. This article covers what data the POS API exposes and how to use it for reporting.

​
Core concepts

​
Orders

An order records what a customer selected at the till, with line items, products, payment methods, and customer links. Use orders for transaction-level detail.

​
Closures

A closure is the end-of-day summary for one location. It bundles all finalized sales since the last closure into one record. For daily or period-based reporting, closures provide a ready-to-use aggregation. For transaction-level detail, use individual orders.

​
Locations

A POS connection covers one or more locations. If an end-user operates several stores, each location has its own sales, closures, and products. Filter by location to report per store, or aggregate across locations for a group view.

​
Products and categories

A product carries a category. Categories are how revenue naturally groups: food versus drinks, services versus goods. For reporting, they let your end-users see which parts of their business drive turnover.

​
Reporting scenarios

The POS API supports the following reporting use cases. Period performance. Closures give daily totals per location, already aggregated. For transaction-level detail, use individual orders filtered by date range. Revenue by category. Order lines reference products, which belong to product categories. Join them to show which parts of the business drive turnover: food versus drinks, services versus goods. Payment breakdown. Each order records how the customer paid. Aggregate by payment method to show the split across cash, card, and digital wallets. This is useful for cash management and reconciliation. Location comparison. Filter or group orders and closures by location to benchmark stores against each other, or roll up across all locations for a group view. Customer analysis. When the POS stores buyer records, orders link to customers. Use that link for loyalty tracking or spend analysis per customer.

​
What you build

With the POS API, you pull the data your reporting product needs. No configuration choices belong to the end-user beyond connecting their POS system. You build the data pipeline (fetching, scheduling, storing) and the reporting views (charts, tables, exports). Chift handles the connector differences: the same API calls work across all connected POS systems.