POS Software Sync
POS Software Sync is the integration that brings a venue's products and sales transactions from a POS software into Cheers. It is what makes the venue's real catalogue -- with real prices, real VAT rates and real stock -- appear in the Cheers app, and what feeds the sales reports the partner sees in the Cheers CMS.
In every other Cheers integration, Cheers provides the API and your system calls it. In POS Software Sync it is the opposite: you provide the API and Cheers calls you.
- Cheers is the client. It polls your endpoints on a schedule (daily by default, configurable) and on demand when the partner triggers a manual sync from the Cheers CMS.
- Your POS is the server. It only has to answer requests. There is no webhook, no push, no callback URL, nothing to send to us.
Compare with Hybrid RevoUnion, Cheers Loyalty and Counter Order -- in all three, Cheers exposes the API and your POS is the client.
How It Works
The Two APIs
| API | Required | Purpose |
|---|---|---|
| Product API | Yes | Returns the venue's complete, current product list. Drives product matching, price sync and stock sync. |
| Transaction API | No, but strongly recommended | Returns closed payment transactions. Drives the partner's sales reports. |
Without the Product API there is no integration. Without the Transaction API the integration still works -- the partner simply gets no turnover reporting from the POS.
The Format Is Flexible, the Content Is Not
Cheers writes a dedicated adapter for every POS software it integrates with. That is the key thing to understand before reading the rest of this section:
- We adapt to your response shape. Field names, language, wrapper objects, pagination style, HTTP method -- these are yours to choose. Several live integrations use entirely different shapes, including one with Hungarian field names.
- We cannot invent data you do not send. The required fields listed in the following pages are required because the sync cannot function without them.
So the question to answer while implementing is never "is my JSON in the right format?" but "does my response carry all the required information?"
Key Concepts
| Concept | Description |
|---|---|
| Sync run | One scheduled or manual execution of the sync. A run either succeeds or is marked failed, and the partner sees the result -- including the error message -- in the Cheers CMS. |
| Product matching | Linking a product returned by your API to a product in Cheers. The link is made on your product identifier, so that identifier must be stable forever. |
| Price sync | Optional per-partner setting. When enabled, the price from your POS overwrites the price on the Cheers product. |
| Stock sync | Optional per-partner setting. When enabled, the availability flag from your POS controls whether the product can be ordered in Cheers. Stays off if you send no stock information. |
| Missing product | A product that was present in an earlier sync but is absent from the current response. It is flagged in the CMS as "disappeared from the POS" rather than silently deleted. |
What to Prepare
To go live, the partner needs to enter your connection details in the Cheers CMS, and your API needs to satisfy a handful of transport-level requirements:
- Authentication -- accepted auth schemes and the values the partner must provide.
- Product API -- required and optional data, accepted response shapes, variants and modifiers.
- Transaction API -- the two required fields, time filtering and deduplication.
- Requirements -- HTTPS, status codes, identifier stability, response times.