Version History
This section describes changes made in subsequent releases and the new features in this API. If not otherwise stated, changes are implemented in the Public API Cloud and Public API Edge.
| Release | Enhancements | API Version |
|---|---|---|
| 2026.1 | Some orchestration calls to the CPaaS are being simplified to enhance maintenance and performance. To support these updates, the request contract has been extended with an additional attribute for the following endpoint: - POST /transactions/basket/abort The following optional field has been added to the request contract: - fiscalSessionId (string) - Unique identifier of the fiscal session. - Additionally, the optional field type under info has been modified to change its string enumeration to a standard string type. | v2 |
| 2026.1 | To address and improve rounding functionality on the POS, from 2026.1 onwards, calculations related to total rounding are performed only by the CPaaS. The CPaaS is responsible for applying total rounding to ensure country-specific legal requirements are met. The CPaaS returns calculated net values to avoid rounding problems on the POS and VRx consumes CPaaS rounding definitions. To support the change, the request and response contract are extended with the additional attributes for the following endpoint: - POST /transactions/basket/payment The following fields are added to request and response contract: AdjustmentDto: - taxAmount - Adjustment tax amount ItemDto: - netDiscountedTotal - Net Total value of item object (Price x QTY) - all discounts. - netDiscountedTotalRounded - Rounded Net Total value of item object (Price x QTY) - all discounts. - netTotal - Net Total value of item object (Price x QTY). - netTotalRounded - Rounded Net Total value of item object (Price x QTY). - netPerUnit - Net Total value of item object (Price x QTY) per Unit. - netDiscountedPerUnit - Net Total value of item object (Price x QTY) - all discounts per Unit. TaxesDto: - baseUnitMeasureRounded - Rounded BaseUnitMeasure Value. - netBaseUnitMeasure - Net BaseUnitMeasure Value. - netBaseUnitMeasureRounded - Rounded Net BaseUnitMeasure Value. | v1 |
| 2026.1 | To address and improve rounding functionality on the POS, from 2026.1 onwards, calculations related to total rounding are performed only by the CPaaS. The CPaaS is responsible for applying total rounding to ensure country-specific legal requirements are met. The CPaaS returns calculated net values to avoid rounding problems on the POS and VRx consumes CPaaS rounding definitions. To support the change, the request and response contract are extended with the additional attributes for the following endpoint: - POST /transactions/basket/total The following fields are added to request and response contract: AdjustmentDto: - taxAmount - Adjustment tax amount ItemDto: - netDiscountedTotal - Net Total value of item object (Price x QTY) - all discounts. - netDiscountedTotalRounded - Rounded Net Total value of item object (Price x QTY) - all discounts. - netTotal - Net Total value of item object (Price x QTY). - netTotalRounded - Rounded Net Total value of item object (Price x QTY). - netPerUnit - Net Total value of item object (Price x QTY) per Unit. - netDiscountedPerUnit - Net Total value of item object (Price x QTY) - all discounts per Unit. TaxesDto: - baseUnitMeasureRounded - Rounded BaseUnitMeasure Value. - netBaseUnitMeasure - Net BaseUnitMeasure Value. - netBaseUnitMeasureRounded - Rounded Net BaseUnitMeasure Value. | v1 & v2 |
| 2026.1 | To allow the POS to have cashflow transactions without a fiscal session, we have updated Public API Cahsflow Management Service. The following endpoints are extended with new parameters in request contract: - POST /transactions/cashflow/finish - POST /transactions/cashflow/abort The following fields are added: - fiscal.externalClientId (string) - Unique identifier of the client configured in an external system. - fiscal.externalLocationId (string) - Unique identifier of the location configured in an external system. | v2 |
| 2025.2 | To improve resiliency and maintainability along with the performance ; internal orchestration changed to point new CPaaS services. The orchestration logic doesn't involve contract change, making it non-breaking change ideally. But it does constitute a breaking change with respect to Multiversion. Hence a new version is introduced to public API, v2. For backward compatibility, the deprecated version (v1) remains functional until further notice (max 12 months), but we recommend that you use the new option instead. | v2 |
| 2025.2 | API client is enabled to verify the Health Check status for the newly added backend services: Mapping Service and Restrictions Service along with the other dependent backend services. | v1 |
| 2025.2 and Patch in API 2024.2 | We improved the POS flow by allowing it to override some basket restriction violations with appropriate approval by the store manager. This ensures that the transaction will not be terminated with an exception when a sale restriction validation returns false. CPaaS now returns information on what restriction failed, why it failed, and if it is allowed to bypass. To support this implementation, request and response contracts are extended for the following endpoints: - POST /transactions/basket/total - POST /transactions/basket/payment - POST /transactions/basket/item The optional string field below has been added to the request contract. - info.TransactionType The array properties below have been added to the response contract. - failedGeneralRestrictios - failedSaleRestrictions The below string field is deprecated from the request contract. - info.type Orchestration changed for a few endpoints. POST /transactions/basket/total - To validate sales restrictions and collect required customer data during sales validation failure with a bypass condition, the endpoint now calls the new CPaaS Restriction Service endpoint. - To populate missing tax and product groups, PAG is calling the CPaaS Mapping Service. Orchestration change for POST /transactions/basket/payment - Added the additional call to the Restriction Service. - The backend call to /calculatetaxesWithPayments is removed. Orchestration change for POST /transactions/basket/item - Additional calls to Restriction Service and Mapping Service were added. | v1 |
| 2024.2 | Depending on regional requirements, a fiscal session for a miscellaneous transaction (for instance, Store Receipt, Archive Receipt, Reprint Receipt, No Sale, Sign Off) can be optional. To support regions that do not require fiscal session for miscellaneous transactions, we extended the following endpoints: POST /transactions/miscellaneous/start and POST /transactions/miscellaneous/finish with the optional request field: fiscal.externalLocationId, indicating business unit Id. For regions that do not require fiscal session for miscellaneous transactions (fiscalSessionId is not present), required data can be retrieved using externalLocationId. | v1 |
| 2024.2 | To enhance the customer corrections handling, we extended the POST /transactions/basket/finish endpoint with the following optional request fields, representing a document chain: info.documentChain [] - info.documentChain.documentCode - info.documentChain.documentType - info.documentChain.additionalInfo - info.documentChain.additionalInfo - info.documentChain.additionalInfo.attribute - info.documentChain.additionalInfo.value - info.documentChain.linkedDocuments [] - info.documentChain.linkedDocuments.linkedTypeId - info.documentChain.linkedDocuments.linkedDocumentCode This extension enables CPaaS to apply region-specific validation rules on a structure of the full document chain without calling CTR. The POS system stores the customer correction data in the Electronic Journal. Only after successful validation, VRx saves the document in CTR. | v1 |
| 2024.2 | To improve the system performance and resiliency we changed System APIs and backend calls sequence, reflecting changes in Backend services: - new backend calls sequence in the POST /transactions/basket/payment endpoint: POST /api/v1/restrictions/validate (Basket Service) > POST /api/v1/restrictions/validate (new endpoint in the Basket Service, combining the payments/validate and payment-rounding/calculate logic) > POST /api/v1/taxes/recalculateWithPayment (new endpoint in the Tax Service) - new backend calls sequence in the POST /transactions/basket/total endpoint: POST /api/restrictions/validate (Basket Service) > POST /api/transactions/basket/validate (Fiscal Service) > POST /api/taxes/calculate (Tax Service, logic extended to include rounding) > POST /api/payments/suggestedPayments (new endpoint in the Basket Service) | v1 |
| 2023.3 | In particular countries (like Norway or Portugal), to prevent manipulations in cash register systems, all sales transactions must be digitally signed sequentially, using an encrypted hash of the previous transaction. The use of signatures from the previous receipt ensures a chain of signed data that should not be broken. To directly support the implementation of signing process we have added the new optional request array info.previousFiscalData [] to the following endpoints: POST /transactions/basket/start, POST /transactions/cashflow/start, POST /transactions/miscellaneous/start, and POST /transactions/basket/finish. This allows the POS to load fiscal data from previous response and apply it to the next sequential request to CPaaS finish transaction. To maintain consistency with private CPaaS API: - we deleted optional request objects: header.* and details.* from the endpoint POST /transactions/basket/start - we deleted optional request object header.* from endpoints: POST /transactions/cashflow/start and POST /transactions/miscellaneous/start | 1.5.0 |
| 2023.3 | In some countries, such as Norway, there is requirement to include additional information for each tax calculation (on item level) in SAF-T report. To enable holding additional tax related metadata, we have added additional fields to the following endpoints: POST /transactions/basket/total (in response) and POST /transactions/basket/finish (in request): details.items[i].taxes[ii].attributes, details.items[i].taxes[ii].attributes[iii].id, details.items[i].taxes[ii].attributes[iii].description, details.items[i].taxes[ii].attributes[iii].value | 1.5.0 |
| 2023.3 | To support primary document numbering by the POS when integrating with CPaaS, we extended request for endpoint POST /transactions/basket/finish with the following new fields: info.attributes [], info.attributes.key, info.attributes.value, info.attributes.order. The POS system uses the new Info.attributes property to send all parts of the document number (key-value pair with order property) to CPaaS. | 1.5.0 |
| 2023.2 | To POST /transactions/basket/total, POST /transactions/basket/payment, and POST /transactions/basket/finish endpoints we have added the following new fields, in requests and responses: - details.items[i].taxes[ii].isReturn, details.items[i].originalTaxes[ii].isReturn, details.taxes[i].isReturn, details.originalTaxes[i].isReturn, details.total.isReturn. | 1.3.16 |
| 2023.2 | To the following endpoints: - Basket APIs: POST /transactions/basket/finish; POST /transactions/basket/abort - Cash Flow APIs: POST /transactions/cashflow/finish; POST /transactions/cashflow/abort - Miscellaneous APIs: POST /transactions/miscellaneous/finish; POST /transactions/miscellaneous/abort we have added events array to request and response. New fields added in request: details.events, details.events[i].id, details.events[i].eventType, details.events[i].externalEventType, details.events[i].timestamp New fields added in response: basketSummary.events, basketSummary.event[i].id, basketSummary.event[i].fiscalData, basketSummary.event[i].fiscalData[ii].key, basketSummary.event[i].fiscalData[ii].value, basketSummary.event[i].fiscalData[ii].mustArchive. | 1.3.16 |