v4.3.0: Multiple personal coupons creation endpoint, Loyalty and Referrals counters and Export Endpoints #22
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Summary
createCouponsForMultipleRecipients
EndpointdestroySession
EndpointManagement API
Introduce
createCouponsForMultipleRecipients
EndpointAn endpoint to allow creation of multiple coupons of the same configuration for up to 1,000 recipients at once.
☝️ Back to Table of Contents
Expose export endpoints as integral part of the SDK
All of our CSV export endpoints are accessible via the Web Application from the corresponding entity pages (refer to our Help Center for an example regarding Coupons).
Now these are also available endpoints as part of the SDK (links to our developer docs):
Example code snippet demonstrating consuming and printing the lines of a Customer Loyalty Balance Export using the
csv-parse
package:☝️ Back to Table of Contents
Expose
destroySession
EndpointExpose an existing endpoint to allow destroying a bearer token used in the context of the management-api.
This endpoint imitates a "logout" function and will make the attached token invalid for consequent requests.
☝️ Back to Table of Contents
Introduce loyalty effects related and referrals creation counters on Campaign entities
As part of the newly added budgets to campaigns (see relevant Help Center Section), we have added new counters on campaigns with regard to loyalty and referrals:
createdLoyaltyPointsCount
: Total number of loyalty points created by rules in this campaigncreatedLoyaltyPointsEffectCount
: Total number of loyalty point creation effects triggered by rules in this campaignredeemedLoyaltyPointsCount
: Total number of loyalty points redeemed by rules in this campaignredeemedLoyaltyPointsEffectCount
: Total number of loyalty point redemption effects triggered by rules in this campaignreferralCreationCount
: Total number of referrals created by rules in this campaign☝️ Back to Table of Contents
Integration API
Improve Responses Transparency
We are constantly extending and improving our integration API to provide our consumers with the best transparency regarding what exactly has happened within their requests.
We have added new data points to our v2 endpoints effects in order to improve the transparency we aspire for:
Effect.md
RejectCouponEffectProps
:ConditionIndex
- The index of the condition that caused the rejection of the couponEffectIndex
- The index of the effect that caused the rejection of the couponDetails
- More details about the failure (if available)RejectReferralEffectProps
:ConditionIndex
- The index of the condition that caused the rejection of the referralEffectIndex
- The index of the effect that caused the rejection of the referralDetails
- More details about the failure (if available)Moreover, we have introduced a new response content,
ruleFailureReasons
, which when requested will attach to the response a collection containing all failed rules, with details (see theruleFailureReason
model to help narrowing down failures and further debugging efforts to a specific single condition or effect that caused the failure.One "gotcha" to keep in mind: in order to maximize transparency, and due to the fact that we do not know in advance which campaign in the application the request targets, the list contains a collection of all failure reasons.
Meaning that, it might have "white noise" with data about failures that could be considered as "obvious" to the consumer. Therefore, we suggest always filtering the list by the campaign id that was expected to trigger and did not.
☝️ Back to Table of Contents
Attach Loyalty Program ID in responses
When the consumer requires that the response will contain the details of loyalty programs involved in processing the requests, we now attach the identifier of the loyalty program to the returned
loyaltyProgramLedgers
models.The idea behind attaching the identifier is to help streamline further potential requests to our Management API with regard to details about a Loyalty Program, for example getLoyaltyStatistics or getLoyaltyPoints, that require the program identifier as part of the URI of the endpoint.
☝️ Back to Table of Contents
The deprecation was introduced already in the last release of the SDK, here is a kind reminder of the deprecation notices for Integration API@v1 endpoints:
These endpoints will be flagged deprecated on 15.07.2021, meaning support for requests to these endpoints will end on that date. We will not remove the endpoints, and they will still be accessible for you to use.
We highly encourage migrating to the correspondent v2 endpoints for easier and more granular integration, as well as new features support (See our developer docs section about API V2.0).
☝️ Back to Table of Contents
Improve Typescript definitions for optional request parameters
Thanks to @emadgit and their reported issue regarding the topic, we have conducted some ground work to improve the JSDoc definitions the OpenAPI Generator produces.
This allows us to emit optional parameters type definitions correctly and flag them as optional arguments to the different API functions.
However, there is a bug in the current Generator functionality, which doesn't infer types of enum-typed parameters correctly in optional bags, which unfortunately results in not fully correct emitted type definitions for those bags.
For example, one can see that the the
campaignState
parameter of thegetCampaigns
request is wrongly inferred asmodule:model/String
instead of simplyString
or the correct Enum definition.talon_one.js/src/api/ManagementApi.js
Lines 2424 to 2439 in 58deea2
That in turn leads to their emitted typescript definition inference as
any
, and ignoring the fact that they are optional.We are investigating the issue and will hopefully be able to open a bug report and suggest a patch to the OpenAPI Generator team.
In the meantime, a workaround could be to type the optional bags as
any
before passing them to the requests to avoid the TS compiler from complaining:resolves #21
☝️ Back to Table of Contents
Misc: OpenAPI Generator version upgrade
We have upgraded the OpenAPI Generator used to release this SDK from v4.2.3 to v4.3.1 which includes a few subtle improvements in the generated code, for full list of changes, please consult the release logs' under the Javascript section.
☝️ Back to Table of Contents