Version History


This section describes changes made in subsequent releases and the new features in this API:

ReleaseEnhancementsAPI Version
2025.2 and Patch in API 2024.2Attribute is a user-defined item property that can be configured within an offer definition as an item qualifier. We enhanced the item attribute feature, which allows defining retailer-specific attributes that can be used as item qualifiers when defining offers.
To support this enhancement in the Public API, we introduced the following new endpoints:
- GET /Attributes/Type - retrieve a collection of types of attributes.
- GET /Attributes - retrieve a collection of attributes.
- GET /Attributes/{id} - retrieve the list of attributes filtered by their ID.
- POST /Attributes - enable the POS system to create attributes.
- PUT /Attributes/{id} - update attributes by their ID.
- DELETE /Attributes/{id} - delete attributes by their ID.
v2
2025.2 and Patch in API 2024.2In Vynamic Engage, we have enhanced the targeting feature for Offers. Currently, you can specify "all targets" and "exclude" particular customer segments when defining the target condition. To support this extension in Public API, we have added the following optional fields:
- CustomerSegmentExcludedIds
- CustomerSegmentAllIds
to the endpoints: POST /offers, PUT /offers/external/{offerExternalId}, PUT /offers/{offerId} (in request) and GET /offers/{offerId}, GET /offers/external/{offerExternalId} (in response).
v2
2025.2 and Patch in API 2024.2In Vynamic Engage, we have extended the Offers view with displaying the Campaign (campaignName) associated to the specific Offer. Currently, you can display all offers associated with the particular Campaign and use the Campaign Name as a search filter. To support this enhancement in Public API, we have extended the GET /offers endpoint:
- we have added the optional URL query parameter campaignName. It restricts the results to records that contain the filtering term in the campaignName field.
- we have extended the Offers collection in the response body with a new optional field CampaignName. It depicts the name of the campaign to which the offer is attached.
v2
2025.2 and Patch in API 2024.2To maintain consistency with private Vynamic Engage API and support the creation of offers for different time zones, we added the following optional request fields to the POST /offers, PUT /offers/external/{offerExternalId}, PUT /api/offers/{offerId}:
- startTime - start time of the offer validity period.
- endTime - end time of the offer validity period.
- isLocalDateTime - depicts if the validity period is defined in a local time.
- timeZone - default time zone (for example, Europe/Berlin, Australia/Sydney).
We also extended the GET /offers endpoint with optional response fields: startTime, endTime, and timeZone.
v2
2025.2 and Patch in API 2024.2To support improvements and maintain consistency with the private Vynamic Engage API, we added a new request array: LocalizedDisplayText [] to the POST /offers/, PUT /offers/external/{offerExternalId} and PUT /offers/{offerId} endpoints. The new fields handle translations for the messages that should be printed on the sales receipt:
- localizedDisplayText.languageCode - depicts an ISO code of the language.
- localizedDisplayText.value - represents the "Receipt Message" for an offer which can be defined in multiple languages.
v2
2025.2 and Patch in API 2024.2To enable a service-level health check, we introduced a new endpoint:
- GET /healthCheck.
It allows the API client to check the status of the dependent backend service. On the 200 response, the client receives the overall status information: healthy, degraded, unhealthy.
v2
2024.3, 2024.2, 2024.1, 2023.3-SP2We extended the GET /offers endpoint with an additional request field: includeLocations. If this attribute is marked as "true", the response array: offers.locationsIds [] is returned for each offer. It depicts the locations (a fuel station, store, or a physical site) where the offer can be executed.v1, v2
2024.3Local Accounts feature was enhanced with Rebates handling. The rebate is a kind of discount provided by station operators to their Local Account customers at the end of invoicing period, based on an amount of purchased goods and fuel. This feature ensures that rebates are accurately calculated, recorded, and reflected on the printed invoices. To support this enhancement we extended the following endpoints: POST /offers/, PUT /offers/external/{offerExternalId}, PUT /offers/{offerId}, GET /offers/{offerId} with a new response field: CustomerAccountIds [].v1, v2
2024.3To enhance the integration of an API client with the Marketing Service of Vynamic Engage, we extended the public API with the following new endpoints:
- GET /offers/{offerId} - retrieves an offer details, based on the specified internal offer Id.
- GET /offers/external/{offerExternalId} - retrieves an offer details, based on the specified external offer Id.
v2
2024.3To support enhancements pertained to the relationship between offer definitions, we introduced the following fields in the POST /offers, PUT /offers/external/{offerExternalId} and PUT /offers/{offerId} endpoints:
- calculationDefinition.quantityActions.ruleExclusive
- calculationDefinition.turnoverActions.ruleExclusive
- calculationDefinitions.quantityActions.ruleExclusive
- calculationDefinitions.turnoverActions.ruleExclusive
The ruleExclusive flag determines whether item can be discounted more than once.
v2
2024.2We enhanced capabilites for an offer definition and discount calculation, which enables a user to expand the offer eligibility criteria. We extended Action and Trigger elements within an offer definition, and currently they can be linked via an "OR" operator. We also enhanced the Item qualifiers definition by introducing the "AND" operator, to link offer elements via an "AND" operation. To support this enhancements we implemented the following changes in the POST /offers/, PUT /offers/external/{offerExternalId} and PUT /offers/{offerId} endpoints:

- we added the new request field: calculationDefinition.couponTriggers.creationOrder

- we changed the following request fields to optional: calculationDefinition, calculationDefinition.quantityActions.itemsQualifier.qualifierElements, calculationDefinition.quantityTriggers.itemsQualifier.qualifierElements calculationDefinition.turnoverActions.itemsQualifier.qualifierElements, calculationDefinition.turnoverTriggers.itemQualifier.qualifierElements, calculationDefinition.combinedActions.quantityQualifiers.itemsQualifier.qualifierElements, calculationDefinition.combinedActions.turnoverQualifiers.itemsQualifier.qualifierElements

- we added the following new fields to the request body:
calculationDefinitions [] - contains a collection of fields 'CalculationDefinition'.
calculationDefinition.quantityActions.itemsQualifier.qualifierSets []
calculationDefinition.quantityTriggers.itemsQualifier.qualifierSets []
calculationDefinition.turnoverActions.itemsQualifier.qualifierSets []
calculationDefinition.turnoverTriggers.itemsQualifier.qualifierSets []
calculationDefinition.combinedActions.quantityQualifiers.itemsQualifier.qualifierSets []
calculationDefinition.combinedActions.turnoverQualifiers.itemsQualifier.qualifierSets []

The new field 'QualifierSets' is used to group the existing 'QualifierElements'. This field contains a collection of 'QualifierElements', each linked via an AND operator.

- we added the following enum value: DepartmentGroupsExclusion to the below listed request fields: calculationDefinition.quantityActions.itemsQualifier.qualifierElements.qualifierType , calculationDefinition.quantityTriggers.itemsQualifier.qualifierElements.qualifierType , calculationDefinition.turnoverActions.itemsQualifier.qualifierElements.qualifierType , calculationDefinition.combinedActions.quantityQualifiers.itemsQualifier.qualifierElements.qualifierType , calculationDefinition.combinedActions.turnoverQualifiers.itemsQualifier.qualifierElements.qualifierType

- we added enum value: AboveOrEqual to the request field: calculationDefinition.turnoverActions.operator

- we changed description to the following request fields: calculationDefinition.combinedActions.quantityQualifiers.itemsQualifier.qualifierElements.selectionValue and calculationDefinition.couponTriggers []
v2
2024.1Vynamic 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. Rewards for Loyalty Points enrich the customer journey and positively impact the retailers' business. To support this enhancement, we introduced the following request fields in the POST /offers, PUT /offers/external/{offerExternalId}, PUT /offers/{offerId} endpoints:
- calculationDefinition.loyaltyPointTriggers []
- calculationDefinition.loyaltyPointTriggers.loyaltyProgramId
- calculationDefinition.loyaltyPointTriggers.pointsToUse
- calculationDefinition.loyaltyPointTriggers.calculationValue
- calculationDefinition.loyaltyPointTriggers.isAutomatic
- calculationDefinition.loyaltyPointTriggers.messages []
- calculationDefinition.loyaltyPointTriggers.messages.languageIsoCode
- calculationDefinition.loyaltyPointTriggers.messages.messageTranslation
- calculationDefinition.loyaltyPointTriggers.creationOrder
To ensure that a promotion cannot be added outside of its campaign validity period, more restricted validations were implemented on the backend side. Since it was a breaking change, we changed the backend version for the following endpoints: POST /offers, PUT /offers/external/{offerExternalId}, PUT /offers, POST /campaigns/{offerId}, PUT /campaigns/{campaignId}, GET /offers. We raised Marketing API version to v2. For backward compatibility, the deprecated version v1 remain functional until further notice (max 12 months), but we recommend that you use the new option instead.
To keep consistency with the backend specification, we changed the following request fields from optional to mandatory in the POST /offers endpoint: displayText, description, distributeDiscount, grantOnDiscountedItems, presentationType (in v1 and v2)
v2
2023.3We have added the following response fields: offers.campaignId and offers.promotionId to GET /offers endpoint. This change makes it possible to check which Campaign and Promotion the offers are assigned to (using the Campaign and Promotion's unique IDs).1.2.12
2023.3To allow customers manage and maintain the Sales Channels more efficiently via API Platform, we introduced the following endpoints:
- GET /salesChannels - enables to search and sort list of sales channels by properties (Id, externalId, externalName, Description) in Vynamic Engage.
- PUT /salesChannels/{salesChannelId} - allows to update a sales channel with an unique Id in Vynamic Engage.
- DELETE /salesChannels - enables to delete a Sales Channel with an unique Id from the system.
1.2.12
2023.3We have extended the randomization options for lottery promotions by enabling the offer to be triggered in time intervals (seconds, minutes, days). To enable for these new features to be consumed through the API Platform, we have added the new request fields: randomizedDiscount.* to the following endpoints: POST /offers, PUT /offers/external/{offerId} and PUT /offers/{offerId}
To solve the problem with missing target system External ID we also included the new request field: locationsIds.externalLocationsId to these endpoints.
1.2.12
2023.2We updated the GET /offers endpoint. As of this Release offerType field is optional and default to "AllOffers" when not provided in the request.1.0.25