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 | To suppport integration with third party system for obtaining prices and promotions for items in the basket and help calculate duty-free prices for eligible passengers, we extended the endpoint POST /basket/calculation with the following new request fields: transaction.currency, transaction.transactionType, transaction.extensionFields, transaction.basket.items.measurementType,transaction.basket.items.extensionFields, transaction.identifiedCustomer.IsEligibleForDiscount, transaction.identifiedCustomer.ExternalGroupId and transaction.identifiedCustomer.ExtensionFields. | v5 |
| 2025.2 and Patch in API 2024.2 | To maintain consistency with the private Vynamic Engage API, we extended the endpoint POST /basket/calculation by adding the new response fields attribute, name and value. | v5 |
| 2025.2 and Patch in API 2024.2 | To maintain consistency with private Vynamic Engage API, we extended the endpoint POST /basket/calculation with the following new response fields which provides discount details: toBeFinalizeStoredActions.grantPointsActions.discountDetail.discountItems [] (v4,v5), toBeFinalizeStoredActions.grantPointsActions.discountDetail.discountItems.lineNumber (v4,v5) and toBeFinalizeStoredActions.grantPointsActions.discountDetail.discountItems.amount (v4,v5). | v4,v5 |
| 2025.2 and Patch in API 2024.2 | To ensure proper rounding of discounts and maintain consistency with private Vynamic Engage API, we have added the following optional request field: transaction.exactnessInDigits to the POST /basket/calculation endpoint. This represents the number of decimal places used to calculate the total discount value. | v5 |
| 2025.2 and Patch in API 2024.2 | We introduced the following new endpoint used to search offers based on item identifiers: - POST /offers - retrieves a list of promotions with basic details: offer's identifier, name, description, validity period, location, and priority. To elevate our customer engagement strategies, we extended the Electronic Shelf Labels (ESL) interface to incorporate promotional details, in addition to standard product and pricing information. To support these enhancements and ensure seamless integration with external ESL systems, we also extended the ESL PAPI to retrieve promotion details for items from specific external customer ESL systems: - orchestration: we added the additional call to the POST /offer endpoint (Promotion Engine) - we added a join logic to combine ESL message (ESL_Export) and Promotion Engine response. - we extended the SAPI contract with the following arrays: articles[].offers[] | v5 |
| 2025.2 | To add improvements and maintain consistency with the private Vynamic Engage API, we extended the POST /basket/calculation endpoint with a new response collection: discountTranslations []. It contains translations of the some offer's messages (with the language ISO code), for instance the messages that should be printed on the sales receipt. | v5 |
| 2024.3 | Local Account feature was enhanced with Rebates handling. This feature ensures that rebates are accurately calculated, recorded, and reflected on the printed invoices. To support this enhancement we extended the POST /basket/calculation endpoint with a new request field: transaction.customerAccountId, depicting the Id of the customer Local Account | v5 |
| 2024.2 | We verified the Promotions API orchestration flow and aligned it with the Vynamic Engage Promotion Engine. The following changes were introduced in the transformation logic: To reedem points using the Promotion Engine: - we added new mapping in the backend services request for the transaction.pointsToBeRedeemed object in the POST /basket/finalization endpoint and the transaction.redeemedPointsToBeVoided object in the POST /basket/void endpoint - we added the following condition: customizationFlow=true for calling Loyalty Service API (applicable to Public API Cloud only) To allow coupon issuance by the Promotion Engine, the isSyncOperationIncluded header in the POST /basket/finalization endpoint should be passed to the Promotion Engine (backend service). If settled to false, the Promotion Engine issues required coupons. In this case no coupon details will be returned in the API response (applicable to Public API Cloud only). | v5 |
| 2024.2 | The Eligible offers feature enables the POS application to display available offers for upselling. We have enhanced the handling Eligible offers by providing a full offer description on the POS as per the offer description in Vynamic Engage. To support this feature we extended the POST /basket/calculation endpoint with the new optional response field: eligibleOffers.discountName | v5 |
| 2024.1 | To fix the discrepancy in data type we have modified the POST /basket/calculation endpoint. We have changed the data type from integer to string in the following response fields: - toBeFinalizeStoredActions.grantVoucherActions.grantedVoucher.voucherTemplateId - vouchersAsBenefitToBeGranted.voucherType - storedActions.voucherTemplateGettingActions.voucherType | v5 |
| 2024.1 | We enhanced the POST /basket/calculation endpoint to include the additional values in the Promotion Engine response for discounts. DiscountDetail object was extended in response with the new properties: DiscValueType and DiscValue | v5 |
| 2024.1 | Vynamic Engage is extending its offer capabilities with the Loyalty Points Exchange feature. The Customer can exchange loyalty points for rewards, such as discounts, coupons, stamps, and vouchers. To support this enhancement, we extended the POST /basket/calculation endpoint with the following fields: In request: - transaction.identifiedCustomer.loyaltyAccounts.loyaltyProgramId - transaction.identifiedCustomer.loyaltyAccounts.points - transaction.languages [] - transaction.manualDiscountsConfirmationResponse [] - transaction.manualDiscountsConfirmationResponse.messageId - transaction.manualDiscountsConfirmationResponse.isConfirmed In response: - manualDiscountsToBeConfirmed [] - manualDiscountsToBeConfirmed.messageId - manualDiscountsToBeConfirmed.messages [] - manualDiscountsToBeConfirmed.messages.languageCode - manualDiscountsToBeConfirmed.messages.text | v5 |
| 2024.1 | To solve the problem of identifying Actions, such as granting and issuing coupons and vouchers, we extended the POST /basket/calculation and POST /basket/finalization endpoints by adding the "sourceActionId" field - the identifier of an action which returns a given coupon/voucher. In the POST /basket/calculation endpoint we added the following fields in response: - couponsAsBenefitToBeGranted.sourceActionId - vouchersAsBenefitToBeGranted.sourceActionId In the POST /basket/finalization endpoint we added the following fields in response: - issuedCoupons.sourceActionId - issuedVouchers.sourceActionId | v5 |
| 2023.3-SP2 | Public API Edge only: To be consistent with the current implementation, we changed the Coupon type enum value and example from NonSerialized to Non-serialized for the following endpoints: - POST /api/basket/calculation in the subsequent fields in the request: transaction.scannedCoupons.couponsToBeReserved.couponType (v2, v4, v5), transaction.scannedCoupons.couponsToBeRedeemed.couponType (v2, v4), transaction.scannedCoupons.couponsToBeReleased.couponType (v2, v4), transaction.couponsAsBenefitToBeGranted.couponType (v2, v4) and in the response fields: storedActions.couponGettingActions.couponType (v2, v4, v5), storedActions.couponTemplateGettingActions.couponType (v2, v4, v5), scannedCoupons.couponsToBeReserved.couponType (v2, v4, v5), scannedCoupons.couponsToBeRedeemed.couponType (v2, v4, v5), scannedCoupons.couponsToBeReleased.couponType (v2, v4, v5), couponsAsBenefitToBeGranted.couponType (v2, v4, v5) - POST /api/basket/finalization in the subsequent fields in request: transaction.scannedCoupons.couponsToBeRedeemed.couponType (v2, v4), transaction.scannedCoupons.couponsToBeReleased.couponType (v2, v4), transaction.couponsAsBenefitToBeGranted.couponType (v2, v4) and in the response fields: redeemedCoupons.couponType (v5), redeemingCouponFailures.couponType (v5), releasedCoupons.couponType (v5), releasingCouponFailures.couponType (v5), alreadyIssuedCoupons.preprintedCoupons.type (v5), alreadyIssuedCoupons.nonserializedCoupons.type (v5) | v2, v4, v5 |
| 2023.3-SP1 | To enable Basket finalization with all the new features and offers available in Vynamic Engage, for example different types of Coupons, Vouchers, Loyalty Points, Stamps, Promotion Messages, randomized and limited offers, we introduced the following new fields to POST /basket/finalization endpoint response: - redeemedCoupons [], redeemingCouponFailures [], releasedCoupons [], releasingCouponFailures [], issuingCouponFailures [], alreadyIssuedCoupons., alreadyIssuedCouponFailures., grantedPoints [], grantingPointsFailures [], redeemedPoints [], redeemedPointsFailures [], grantedStamps [], grantingStampsFailures [], redeemedStampcards [], redeemingStampcardFailures [], releasedStampcards [], releasingStampcardFailures [], confirmedCounters [], confirmingCountersFailures [], servicesConnectivityCheck [], issuedVouchers [], issuingVoucherFailures [], grantedMessages [], grantingMessageFailures []. We also introduced the following changes: - We changed data type from integer to number(double) in the following fields: toBeFinalizeStoredActions.grantPointsActions.pointsCount and pointsToBeGranted.pointsCount in POST /basket/calculation endpoint (in response); transaction.pointsToBeRedeemed.pointsCount in POST /basket/finalization endpoint (in request); transaction.identifiedCustomer.grantedPointsToBeVoided.pointsCount and transaction.redeemedPointsToBeVoided.pointsCount in POST /basket/void endpoint (in request). With the implementation of these changes, the Promotion Engine supports decimal numbers. - To simplify API usage and structure, we removed the following unused properties from the POST /basket/calculation and POST /basket/finalization endpoints (in requests): transaction.identifiedCustomer.stampcards.stampcardsToBeRedeemed.*, transaction.identifiedCustomer.stampcards.stampcardsToBeReleased.*, transaction.identifiedCustomer.pointsToBeGranted.*, transaction.scannedCoupons.couponsToBeRedeemed.*, transaction.scannedCoupons.couponsToBeReleased.*, transaction.couponsAsBenefitToBeGranted.*, transaction.identifiedCustomer.stampsToBeGranted.* (only in POST /basket/finalization endpoint) - The following backend endpoint versions have changed: PUT/api/v5/Basket/Calculate (for POST /basket/calculation), PUT /api/v4/Basket/Finalize (for POST /basket/finalization), PUT /api/v3/Basket/Void (for POST /api/basket/void). We changed the public Promotions API version to v5. | v5 |
| 2023.3-SP1 | Eligible offers feature enables the POS application to display available offers for upselling. With a quick access to available offers description on the operator screen, the Cashier can notify the customer about all potential offers that could be triggered in their basket by adding additional items. For example, when adding additional bottles of Coca-Cola, the customer can receive one for free or at a discounted price. Using this strategy, retailers can boost sales and increase the value of a customer's purchase. To support the eligible offers feature we have extended the POST /basket/calculation endpoint with a new request field: checkEligibleOffers and the following new response fields: - eligibleOffers [] - eligibleOffers.discountId - eligibleOffers.discountDescription - eligibleOffers.itemsInvolved [] - eligibleOffers.itemsInvolved.itemType - eligibleOffers.itemsInvolved.id - eligibleOffers.isOfferAlreadyApplied | v5 |
| 2023.3 | To enable Basket finalization with all the new features and offers available in Vynamic Engage, for example different types of Coupons, Vouchers, Loyalty Points, Stamps, Promotion Messages, randomized and limited offers, we introduced the following new fields to POST /basket/finalization endpoint response: - redeemedCoupons [], redeemingCouponFailures [], releasedCoupons [], releasingCouponFailures [], issuingCouponFailures [], alreadyIssuedCoupons., alreadyIssuedCouponFailures., grantedPoints [], grantingPointsFailures [], redeemedPoints [], redeemedPointsFailures [], grantedStamps [], grantingStampsFailures [], redeemedStampcards [], redeemingStampcardFailures [], releasedStampcards [], releasingStampcardFailures [], confirmedCounters [], confirmingCountersFailures [], servicesConnectivityCheck [], issuedVouchers [], issuingVoucherFailures [], grantedMessages [], grantingMessageFailures []. We also introduced the following changes: - We changed data type from integer to number(double) in the following fields: 1. toBeFinalizeStoredActions.grantPointsActions.pointsCount and pointsToBeGranted.pointsCount in POST /basket/calculation endpoint (in response) 2. transaction.pointsToBeRedeemed.pointsCount in POST /basket/finalization endpoint (in request) 3. transaction.identifiedCustomer.grantedPointsToBeVoided.pointsCount and transaction.redeemedPointsToBeVoided.pointsCount in POST /basket/void endpoint (in request) With the implementation of these changes, the Promotion Engine supports decimal numbers. - To simplify API usage and structure, we removed the following unused properties from the POST /basket/calculation and POST /basket/finalization endpoints (in requests): transaction.identifiedCustomer.stampcards.stampcardsToBeRedeemed., transaction.identifiedCustomer.stampcards.stampcardsToBeReleased., transaction.identifiedCustomer.pointsToBeGranted., transaction.scannedCoupons.couponsToBeRedeemed., transaction.scannedCoupons.couponsToBeReleased., transaction.couponsAsBenefitToBeGranted., transaction.identifiedCustomer.stampsToBeGranted. (only in POST /basket/finalization endpoint). - The following backend endpoint versions have changed: PUT/api/v5/Basket/Calculate (for POST /basket/calculation), PUT /api/v4/Basket/Finalize (for POST /basket/finalization), PUT /api/v3/Basket/Void (for POST /basket/void). | 4.0.4 |
| 2023.3 | We have extended the randomization options for lottery promotions by enabling the offer to be triggered in time intervals (seconds, minutes, days). Previously, offers could only be triggered for every X transactions. To enable for these new features to be consumed through the API Platform, we have added the new request fields: randomizedDiscount.' to the POST /basket/calculation endpoint. | 4.0.4 |
| 2023.2 | To enable configuring coupons with dynamic values and enhance Vynamic Engage promotion engine flexibility, we modified the POST /basket/finalization endpoint. - we added new response fields for objects: issuedCoupons.redemption, issuedCoupons.template, issuedCoupons.design, issuedCoupons.validity, new response fields: issuedCoupons.couponType, issuedCoupons.activationDate, issuedCoupons.obtainDate, issuedCoupons.value, issuedCoupons.currency, issuedCoupons.rowVersion, - we introduced new value for Coupon status description (response field issuedCoupons.status): Voided. | 4.0.0 |
| 2023.2 | To fix discrepancy in datatype we have modified POST /basket/calculation endpoint and changed its backend version to v4. We have changed datatype, example and description to following response fields: storedActions.voucherTemplateGettingActions.discountDetail.discountActionType, storedActions.couponValidityDatesCheckingActions.discountDetail.discountActionType, toBeFinalizeStoredActions.grantVoucherActions.discountDetail.discountActionType, toBeFinalizeStoredActions.grantMessageActions.discountDetail.discountActionType | 4.0.0 |