Version History
This section describes changes made in subsequent releases and the new features in this API:
| Release | Enhancements | API Version |
|---|---|---|
| 2025.2 and Patch in API 2024.2 | Verifactu in Spain refers to the POS software that complies with the Anti-Fraud Law. All Verifactu-compliant invoicing systems (SIF) must be certified through a Declaración Responsable submitted by the system producer. To support this requirement, we have introduced new endpoints: - GET /regionalCertificates/{regionCode} - GET / regionalCertificates/{regionCode}/download These endpoint retrieves required certification records such as, certification standard, authority, version, validity, and certificate URL. | 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 | We improved the POS flow by allowing it to override some basket restriction violations with appropriate approval by the store manager. To support the enhancement, we changed the orchestration for GET /restrictions. This API is now routed to a separate Restrictions Service and receive responses from two different calls: /general and /sales. API is updated to call the below new CPaaS Restrictions Service endpoints: - GET /restrictions/sale/{region} - GET /restrictions/general/{region} Additionally, API is updated to call the following new CPaaS Mapping Service endpoint: - GET /mappings?regionCode={region}&mappedType=productGroup. | v1 |
| 2025.2 | Retail Management has been enhanced to restrict cash transactions for 10,000 or more on certain high-value item category like gold, silver, diamonds etc. for New Zealand region. We have introduced a new string array property called groupIds to the qualifier object inside cashPaymentLimits array from GET /api/v1/cashPaymentLimits/{regionCode} on CPaaS basket service. The property is available on both cloud and edge. paymentLimits[].qualifier.groupIds. | v1 |
| 2024.3 | Retail Management has been enhanced with supporting different numbering schemas for the same document in different regions. To support this feature, we have extended the Fiscal service endpoint GET/documents/{regionCode} with numberingSchemas. The new top-level array fields numberingSchemas and numberingSchemaComponents were added to the response. Array field numberingSchemaRules was deprecated. Currently, Retail Management can manage numbering schemas per region, per CPaaS document type and optionally management node. | v1 |
| 2024.2 | We changed the GET /definitions endpoint name to GET /printforms. The POST /printforms endpoint was moved from CPaaS Configuration API to CPaaS Reports API. | v1 |
| 2024.2 | To improve the system performance and maintain consistency with the backend, we extended the GET /taxes/{regionCode} endpoint with rounding details. The new optional objects: taxes[i].totalRounding and taxes[i].rounding were added to the response. | v1 |
| 2024.2 | To keep consistency of the Configuration API health check with the current implementation, we included health check calls (GET /healthCheck endpoint) to the CPaaS Account Service. | v1 |
| 2024.1 | Local Accounts concern the option of managing individual accounts for customers and assigning their cards thereto. To support Local Accounts implementation for different regions we introduced the following endpoints related to Local Customer Account: - GET /definitions - enables the POS system to retrieve a Local Account invoice definition for the selected region (regionCode) or location (locationId) with a list of fields required to generate the invoice. - POST /printforms - enables the POS system to issue a Local Account print form for the specified region. | v1 |
| 2023.3 | To support integration with Retail Management we created a new endpoint that retrieves details collected in the CPaaS Report Service: GET/reports. It enables the POS system to retrieve a list of available reports in a specific region based on an external location identifier (externalLocationId). To keep consistency with the new endpoint we have modified the existing endpoint: GET /reports/{regionCode} with the following changes: - we deleted the optional response field header.isSubRegion, - we added 3 optional response fields: reports.repository.defaultLanguageCode, reports.repository.supportedLanguageCodes, reports.repository.configuration. | 1.4.4 |
| 2023.3 | To provide an integration of the POS system with CPaaS and support recapitulative invoice implementation we introduced the following endpoint: - GET /derivativeDocuments - accepts ExternalLocationId and enables the POS system to get a list of derivative document configurations. | 1.4.4 |
| 2023.3 | In some countries, such as Thailand, rounding rules are defined per method of payment and document type (for example, one rounding configuration for Cash and Sale and another for Cash and Return). The previous way of managing the rounding configuration did not allow for this level of aggregation by payment media and document type. To optimize this and facilitate communication from the POS side, we created a new endpoint in the Basket service, querying combined methods of payment and roundings: GET /payments/{regionCode} The new endpoint superseded the following endpoints: GET /paymentMedia/{regionCode} and GET /roundings/{regionCode}, deprecated as of Release 2023.3. For backward compatibility, the deprecated endpoints remain functional until further notice (max 12 months), but we recommend that you use the new option instead. | 1.4.4 |
| 2023.3 | The data that should be assigned to each transaction as per the country is defined by its legal regulations. For example, in Norway, if the customer represents a company, the value in the Tax Id field is mandatory, but if it represents an individual customer the value in the Tax Id field is optional. Therefore, in requirements like these, to qualify the types of customers and support validation for different fiscal code types on the POS side, we have added a new array of objects: customerTypes [] to the endpoint: GET /documents/{regionCode} | 1.4.4 |
| 2023.3 | We updated the GET /healthCheck endpoint and added health check calls to all backend services that Configuration API is dependent on: Configuration, Tax, Basket, Fiscal, Report and Invoice services. Previously this endpoint provided health check status of Configuration and Tax Services. | 1.4.4 |
| 2023.2 | To allow POS system to get a list of derivative document types configurations we implemented a new endpoint, which provides details collected in the service of CPaaS: GET /derivativeDocuments/{regionCode} | 1.0.5 |
| 2023.2 | Following endpoints: GET /cashPaymentLimits/{regionCode}, GET /paymentMedia/{regionCode}, GET /restrictions/{regionCode}, GET /roundings/{regionCode} now call the CPaaS's Basket service. Previously, these endpoints called the Configuration service. No changes were required in the contract. | 1.0.5 |
| 2023.2 | Following endpoints: GET /fiscalIntegrations/{regionCode} and GET /documents/{regionCode} now call the CPaaS's Fiscal service. Previously, these endpoints called the Configuration service. No changes were required in the contract. | 1.0.5 |
| 2023.2 | The GET /reports/{regionCode} endpoint now calls the CPaaS's Report service. Previously, this endpoint called the Configuration service. No changes were required in the contract. | 1.0.5 |