@voucherify/sdk 3.0.1 → 3.0.2

package/dist/types/ApiClient.d.ts

@@ -1,7 +1,7 @@
 export default ApiClient;
 /**
 * @module ApiClient
-* @version 3.0.1
+* @version 3.0.2
 */
 /**
 * Manages low level client-server communications, parameter marshalling, etc. There should not be any need for an

package/dist/types/api/AsyncActionsApi.d.ts

@@ -1,7 +1,7 @@
 /**
 * AsyncActions service.
 * @module api/AsyncActionsApi
-* @version 3.0.1
+* @version 3.0.2
 */
 export default class AsyncActionsApi {
     /**

package/dist/types/api/BinApi.d.ts

@@ -1,7 +1,7 @@
 /**
 * Bin service.
 * @module api/BinApi
-* @version 3.0.1
+* @version 3.0.2
 */
 export default class BinApi {
     /**

package/dist/types/api/CampaignsApi.d.ts

@@ -1,7 +1,7 @@
 /**
 * Campaigns service.
 * @module api/CampaignsApi
-* @version 3.0.1
+* @version 3.0.2
 */
 export default class CampaignsApi {
     /**

package/dist/types/api/CategoriesApi.d.ts

@@ -1,7 +1,7 @@
 /**
 * Categories service.
 * @module api/CategoriesApi
-* @version 3.0.1
+* @version 3.0.2
 */
 export default class CategoriesApi {
     /**

package/dist/types/api/ClientSideApi.d.ts

@@ -1,7 +1,7 @@
 /**
 * ClientSide service.
 * @module api/ClientSideApi
-* @version 3.0.1
+* @version 3.0.2
 */
 export default class ClientSideApi {
     /**

package/dist/types/api/CustomersApi.d.ts

@@ -1,7 +1,7 @@
 /**
 * Customers service.
 * @module api/CustomersApi
-* @version 3.0.1
+* @version 3.0.2
 */
 export default class CustomersApi {
     /**

package/dist/types/api/EventsApi.d.ts

@@ -1,7 +1,7 @@
 /**
 * Events service.
 * @module api/EventsApi
-* @version 3.0.1
+* @version 3.0.2
 */
 export default class EventsApi {
     /**

package/dist/types/api/ExportsApi.d.ts

@@ -1,7 +1,7 @@
 /**
 * Exports service.
 * @module api/ExportsApi
-* @version 3.0.1
+* @version 3.0.2
 */
 export default class ExportsApi {
     /**

package/dist/types/api/LocationsApi.d.ts

@@ -1,7 +1,7 @@
 /**
 * Locations service.
 * @module api/LocationsApi
-* @version 3.0.1
+* @version 3.0.2
 */
 export default class LocationsApi {
     /**

package/dist/types/api/LoyaltiesApi.d.ts

@@ -1,7 +1,7 @@
 /**
 * Loyalties service.
 * @module api/LoyaltiesApi
-* @version 3.0.1
+* @version 3.0.2
 */
 export default class LoyaltiesApi {
     /**

package/dist/types/api/ManagementApi.d.ts

@@ -1,7 +1,7 @@
 /**
 * Management service.
 * @module api/ManagementApi
-* @version 3.0.1
+* @version 3.0.2
 */
 export default class ManagementApi {
     /**

package/dist/types/api/MetadataSchemasApi.d.ts

@@ -1,7 +1,7 @@
 /**
 * MetadataSchemas service.
 * @module api/MetadataSchemasApi
-* @version 3.0.1
+* @version 3.0.2
 */
 export default class MetadataSchemasApi {
     /**

package/dist/types/api/OAuthApi.d.ts

@@ -1,7 +1,7 @@
 /**
 * OAuth service.
 * @module api/OAuthApi
-* @version 3.0.1
+* @version 3.0.2
 */
 export default class OAuthApi {
     /**

package/dist/types/api/OrdersApi.d.ts

@@ -1,7 +1,7 @@
 /**
 * Orders service.
 * @module api/OrdersApi
-* @version 3.0.1
+* @version 3.0.2
 */
 export default class OrdersApi {
     /**
@@ -70,7 +70,7 @@ export default class OrdersApi {
      */
     /**
      * Import Orders
-     *   🚧 Historical orders  This endpoint should only be used to import historical orders into Voucherify. For on-going synchronization, the [update order](/api-reference/orders/update-order) endpoints should be used. This is critical because this endpoint does not store events or launch distributions. # Limitations ## Import volume There can be only a single on-going order import per tenant per project at a given time. The user can schedule more imports but those extra imports will be scheduled to run in sequence one by one.   ## Maximum count of orders in single import There is a 2000 limit but we might decide to change it to a lower / higher value at any given time depending if we find this value is too high or too low with time. # Notifications There are no notifications on the Dashboard because this import is launched via the API. # Triggered actions    If you import orders with customers, then a logic will be scheduled responsible for placing these customers into segments and refreshing the segments summary. Consequently, this update will trigger  - **customers entering into segments**  - **distributions** based on any rules tied to customer entering segment(s) - **earning rules** based on the customer entering segment(s) # What is not triggered 1. No webhooks are triggered during the import of orders - for both orders and upserted products / SKUs.   2. Distributions based on Order Update, Order Paid, Order Created and Order Cancelled. In other words if you have a distribution based on Order Paid and you import an order with a PAID status, the distribution is not going to be triggered.     3. No events are created during the import of orders - for both orders and upserted products / SKUs. In other words you wont see any events in the Activity tab in the Dashboard such as Order created or Order paid. If you are additionally upserting products / SKUs, then you wont see the Product created events listed, etc.    4. Earning rules based on Order Paid wont be triggered. This API request starts a process that affects Voucherify data in bulk.  In case of small jobs (like bulk update) the request is put into a queue and processed once every other bulk request placed in the queue prior to this request is finished. However, when the job takes a longer time (like vouchers generation) then it is processed in small portions in a round-robin fashion. When there is a list of vouchers generation scheduled, then they will all have the IN_PROGRESS status shortly. This way, small jobs added just after scheduling big jobs of the same type will be processed in a short time window.  The result will return the async ID. You can verify the status of your request with [GET Async Action](/api-reference/async-actions/get-async-action) endpoint.
+     *   🚧 Historical orders  This endpoint should only be used to import historical orders into Voucherify. For on-going synchronization, the [update order](/api-reference/orders/update-order) endpoint should be used. This is critical because this endpoint does not store events or launch distributions. The orders will also have a created_at date thats assigned when theyve been imported to Voucherify. To keep track of the actual order creation date, add an order metadata in ISO 8601 date or date time format to each imported order. # Limitations ## Import volume There can be only a single on-going order import per tenant per project at a given time. The user can schedule more imports but those extra imports will be scheduled to run in sequence one by one.   ## Maximum count of orders in single import There is a 2000 limit of orders per one request. # Notifications There are no notifications on the Dashboard because this import is launched via the API. # Triggered actions    If you import orders with customers, then a logic will be scheduled responsible for placing these customers into segments and refreshing the segments summary. Consequently, this update will trigger  - Customers entering into segments - Distributions based on any rules tied to customer entering segment(s) - Earning rules based on the customer entering segment(s) # What is not triggered 1. No webhooks are triggered during the import of orders - for both orders and upserted products / SKUs.   2. Distributions based on Order Update, Order Paid, Order Created and Order Cancelled. In other words if you have a distribution based on Order Paid and you import an order with a PAID status, the distribution is not going to be triggered.     3. No events are created during the import of orders - for both orders and upserted products / SKUs. In other words you wont see any events in the Activity tab in the Dashboard such as Order created or Order paid. If you are additionally upserting products / SKUs, then you wont see the Product created events listed, etc.    4. Earning rules based on Order Paid wont be triggered. This API request starts a process that affects Voucherify data in bulk.  In case of small jobs (like bulk update) the request is put into a queue and processed once every other bulk request placed in the queue prior to this request is finished. However, when the job takes a longer time (like vouchers generation) then it is processed in small portions in a round-robin fashion. When there is a list of vouchers generation scheduled, then they will all have the IN_PROGRESS status shortly. This way, small jobs added just after scheduling big jobs of the same type will be processed in a short time window.  The result will return the async ID. You can verify the status of your request with [GET Async Action](/api-reference/async-actions/get-async-action) endpoint.
      * @param {Array.<OrdersImportCreateRequestBodyItem>} ordersImportCreateRequestBodyItem The request body is sent in the form of an array of order objects.
      * @param {importOrdersCallback} [callback] The callback function, accepting three arguments: error, data, response
      * data is of type: {@link OrdersImportCreateResponseBody}

package/dist/types/api/ProductCollectionsApi.d.ts

@@ -1,7 +1,7 @@
 /**
 * ProductCollections service.
 * @module api/ProductCollectionsApi
-* @version 3.0.1
+* @version 3.0.2
 */
 export default class ProductCollectionsApi {
     /**

package/dist/types/api/ProductsApi.d.ts

@@ -1,7 +1,7 @@
 /**
 * Products service.
 * @module api/ProductsApi
-* @version 3.0.1
+* @version 3.0.2
 */
 export default class ProductsApi {
     /**

package/dist/types/api/PromotionsApi.d.ts

@@ -1,7 +1,7 @@
 /**
 * Promotions service.
 * @module api/PromotionsApi
-* @version 3.0.1
+* @version 3.0.2
 */
 export default class PromotionsApi {
     /**

package/dist/types/api/PublicationsApi.d.ts

@@ -1,7 +1,7 @@
 /**
 * Publications service.
 * @module api/PublicationsApi
-* @version 3.0.1
+* @version 3.0.2
 */
 export default class PublicationsApi {
     /**

package/dist/types/api/QualificationsApi.d.ts

@@ -1,7 +1,7 @@
 /**
 * Qualifications service.
 * @module api/QualificationsApi
-* @version 3.0.1
+* @version 3.0.2
 */
 export default class QualificationsApi {
     /**

package/dist/types/api/RedemptionsApi.d.ts

@@ -1,7 +1,7 @@
 /**
 * Redemptions service.
 * @module api/RedemptionsApi
-* @version 3.0.1
+* @version 3.0.2
 */
 export default class RedemptionsApi {
     /**
@@ -88,7 +88,7 @@ export default class RedemptionsApi {
      */
     /**
      * Redeem Stackable Discounts
-     * # How API returns calculated discounts and order amounts in the response In the table below, you can see the logic the API follows to calculate discounts and amounts:   API keys with a Merchant role cant use this endpoint.  📘 Rollbacks  You cant roll back a child redemption. When you call rollback on a stacked redemption, all child redemptions will be rolled back. You need to refer to a parent redemption ID in your [rollback request](/api-reference/redemptions/rollback-stackable-redemptions).      📘 Also available on client-side  This method is also accessible through public keys which you can use in client-side​ apps: mobile and web browser apps. Go to the dedicated [endpoint](/api-reference/client-side/redeem-stackable-discounts-client-side) to learn more.  - Use X-Client-Application-Id as the application ID header.  - Use X-Client-Token as the appliction secret key header.  - Use client-side base URL.  - Use an origin header for your custom domain.
+     * # How API returns calculated discounts and order amounts in the response In the table below, you can see the logic the API follows to calculate discounts and amounts:   API keys with a Merchant role cant use this endpoint.  📘 Rollbacks  You cant roll back a child redemption. When you call rollback on a stacked redemption, all child redemptions will be rolled back. You need to refer to a parent redemption ID in your [rollback request](/api-reference/redemptions/rollback-stackable-redemptions).      📘 Also available on client-side  This method is also accessible through public keys which you can use in client-side​ apps: mobile and web browser apps. Go to the dedicated [endpoint](/api-reference/client-side/redeem-stackable-discounts-client-side) to learn more.
      * @param {RedemptionsRedeemRequestBody} redemptionsRedeemRequestBody
      * @param {redeemStackedDiscountsCallback} [callback] The callback function, accepting three arguments: error, data, response
      * data is of type: {@link RedemptionsRedeemResponseBody}

package/dist/types/api/ReferralsApi.d.ts

@@ -1,7 +1,7 @@
 /**
 * Referrals service.
 * @module api/ReferralsApi
-* @version 3.0.1
+* @version 3.0.2
 */
 export default class ReferralsApi {
     /**

package/dist/types/api/RewardsApi.d.ts

@@ -1,7 +1,7 @@
 /**
 * Rewards service.
 * @module api/RewardsApi
-* @version 3.0.1
+* @version 3.0.2
 */
 export default class RewardsApi {
     /**

package/dist/types/api/SegmentsApi.d.ts

@@ -1,7 +1,7 @@
 /**
 * Segments service.
 * @module api/SegmentsApi
-* @version 3.0.1
+* @version 3.0.2
 */
 export default class SegmentsApi {
     /**

package/dist/types/api/TemplatesApi.d.ts

@@ -1,7 +1,7 @@
 /**
 * Templates service.
 * @module api/TemplatesApi
-* @version 3.0.1
+* @version 3.0.2
 */
 export default class TemplatesApi {
     /**

package/dist/types/api/ValidationRulesApi.d.ts

@@ -1,7 +1,7 @@
 /**
 * ValidationRules service.
 * @module api/ValidationRulesApi
-* @version 3.0.1
+* @version 3.0.2
 */
 export default class ValidationRulesApi {
     /**

package/dist/types/api/ValidationsApi.d.ts

@@ -1,7 +1,7 @@
 /**
 * Validations service.
 * @module api/ValidationsApi
-* @version 3.0.1
+* @version 3.0.2
 */
 export default class ValidationsApi {
     /**

package/dist/types/api/VouchersApi.d.ts

@@ -1,7 +1,7 @@
 /**
 * Vouchers service.
 * @module api/VouchersApi
-* @version 3.0.1
+* @version 3.0.2
 */
 export default class VouchersApi {
     /**
@@ -140,7 +140,7 @@ export default class VouchersApi {
      */
     /**
      * Import Vouchers
-     * Import generic (standalone) vouchers and gift cards into the repository.  📘 Important notes  - **Start and expiration dates** need to be provided in compliance with the ISO 8601 norms. For example, 2020-03-11T09:00:00.000Z.  - Custom code attributes (not supported by-default) need to be added as code **metadata**.  - You **cannot import the same codes** to a single Voucherify Project. Any parameters not provided in the payload will be left blank or null. For both **standalone discount vouchers and gift cards**, you can import the following fields:   - code - category - active - type - start_date - expiration_date - redemption.quantity - additional_info - metadata For **gift cards**, you can also import the following field: - gift.amount For **discount vouchers**, you can import the discount object. The object will slightly vary depending on the type of discount. Each discount type **requires** the type to be defined in the import.   Fields other than the ones listed above wont be imported. Even if provided, they will be silently skipped. This API request starts a process that affects Voucherify data in bulk.  In case of small jobs (like bulk update) the request is put into a queue and processed once every other bulk request placed in the queue prior to this request is finished. However, when the job takes a longer time (like vouchers generation) then it is processed in small portions in a round-robin fashion. When there is a list of vouchers generation scheduled, then they will all have the IN_PROGRESS status shortly. This way, small jobs added just after scheduling big jobs of the same type will be processed in a short time window.  The result will return the async ID. You can verify the status of your request via this [API request](/api-reference/async-actions/get-async-action). 🚧 Standalone Vouchers and Campaigns In version [v20241004](https://support.voucherify.io/article/23-whats-new-in-voucherify#v20241004), generic (standalone) vouchers created through the Voucherify dashboard create a campaign for that voucher. However, vouchers imported through the dashboard in the Vouchers section or through the API do not have a campaign attached, so the values for campaign and campaign_id are null.
+     * Import generic (standalone) vouchers and gift cards into the repository. You can upload up to 100,000 codes to a campaign, as a campaign can have up to 100,000 codes by default.   Also, the request can include up to **10 MB** of data.  📘 Important notes  - **Start and expiration dates** need to be provided in compliance with the ISO 8601 norms. For example, 2020-03-11T09:00:00.000Z.  - Custom code attributes (not supported by-default) need to be added as code **metadata**.  - You **cannot import the same codes** to a single Voucherify Project. Any parameters not provided in the payload will be left blank or null. For both **standalone discount vouchers and gift cards**, you can import the following fields:   - code - category - active - type - start_date - expiration_date - redemption.quantity - additional_info - metadata For **gift cards**, you can also import the following field: - gift.amount For **discount vouchers**, you can import the discount object. The object will slightly vary depending on the type of discount. Each discount type **requires** the type to be defined in the import.   Fields other than the ones listed above wont be imported. Even if provided, they will be silently skipped. This API request starts a process that affects Voucherify data in bulk.  In case of small jobs (like bulk update) the request is put into a queue and processed once every other bulk request placed in the queue prior to this request is finished. However, when the job takes a longer time (like vouchers generation) then it is processed in small portions in a round-robin fashion. When there is a list of vouchers generation scheduled, then they will all have the IN_PROGRESS status shortly. This way, small jobs added just after scheduling big jobs of the same type will be processed in a short time window.  The result will return the async ID. You can verify the status of your request via this [API request](/api-reference/async-actions/get-async-action). 🚧 Standalone Vouchers and Campaigns In version [v20241004](https://support.voucherify.io/article/23-whats-new-in-voucherify#v20241004), generic (standalone) vouchers created through the Voucherify dashboard create a campaign for that voucher. However, vouchers imported through the dashboard in the Vouchers section or through the API do not have a campaign attached, so the values for campaign and campaign_id are null.
      * @param {Array.<VouchersImportCreateItemRequestBody>} vouchersImportCreateItemRequestBody The request body is an array of objects. Each object contains details about a specific voucher.
      * @param {importVouchersCallback} [callback] The callback function, accepting three arguments: error, data, response
      * data is of type: {@link VouchersImportCreateResponseBody}
@@ -156,7 +156,7 @@ export default class VouchersApi {
      */
     /**
      * Import Vouchers using CSV
-     * Import generic (standalone) vouchers into the repository using a CSV file. The CSV file has to include headers in the first line. All properties listed in the file headers that cannot be mapped to standard voucher fields will be added to the metadata object.   You can find an example CSV file [here](https://support.voucherify.io/article/45-import-codes-and-share-them-digitally#coupons). ___  📘 Standard voucher fields mapping  - Go to the [import vouchers](/api-reference/vouchers/import-vouchers) endpoint to see all standard CSV fields description (body params section).  - Supported CSV file headers: Code,Voucher Type,Value,Discount Type,Category,Start Date,Expiration Date,Redemption Limit,Redeemed Quantity, Redeemed Amount,Active,Additional Info,Custom Metadata Property Name - **Start and expiration dates** need to be provided in compliance with the ISO 8601 standard. For example, 2020-03-11T09:00:00.000Z.       - YYYY-MM-DD     - YYYY-MM-DDTHH     - YYYY-MM-DDTHH:mm     - YYYY-MM-DDTHH:mm:ss     - YYYY-MM-DDTHH:mm:ssZ     - YYYY-MM-DDTHH:mm:ssZ     - YYYY-MM-DDTHH:mm:ss.SSSZ  - Custom code attributes (not supported by-default) need to be added as code **metadata**.  - You **cannot import the same codes** to a single Voucherify project.  - You can, however, upload the same codes to update them.  📘 Categories  In the structure representing your data, you can define a category that the voucher belongs to. You can later use the category of a voucher to group and search by specific criteria in the Dashboard and using the [List Vouchers](/api-reference/vouchers/list-vouchers) endpoint. This API request starts a process that affects Voucherify data in bulk.  In case of small jobs (like bulk update) the request is put into a queue and processed once every other bulk request placed in the queue prior to this request is finished. However, when the job takes a longer time (like vouchers generation) then it is processed in small portions in a round-robin fashion. When there is a list of vouchers generation scheduled, then they will all have the IN_PROGRESS status shortly. This way, small jobs added just after scheduling big jobs of the same type will be processed in a short time window.  The result will return the async ID. You can verify the status of your request via this [API request](/api-reference/async-actions/get-async-action). You can pass the webhooks_enable true parameter to trigger a webhook sendout for created or updated vouchers. Configure the [respective webhooks](/api-reference/introduction-to-webhooks) in Project settings. For updated webhooks, a webhook is sent even if the voucher hasnt been changed in the CSV file. 🚧 Generic (standalone) vouchers and campaigns In version [v20241004](https://support.voucherify.io/article/23-whats-new-in-voucherify#v20241004), generic (standalone) vouchers created through the Voucherify dashboard create a campaign for that voucher. However, vouchers imported through the dashboard in the Vouchers section or through the API do not have a campaign attached, so the values for campaign and campaign_id are null.
+     * Import generic (standalone) vouchers into the repository using a CSV file. The CSV file has to include headers in the first line. All properties listed in the file headers that cannot be mapped to standard voucher fields will be added to the metadata object. You can upload up to 100,000 codes to a campaign, as a campaign can have up to 100,000 codes by default.   Also, the request can include a max. **10 MB** CSV file. You can find an example CSV file [here](https://support.voucherify.io/article/45-import-codes-and-share-them-digitally#coupons). ___  📘 Standard voucher fields mapping  - Go to the [import vouchers](/api-reference/vouchers/import-vouchers) endpoint to see all standard CSV fields description (body params section).  - Supported CSV file headers: Code,Voucher Type,Value,Discount Type,Category,Start Date,Expiration Date,Redemption Limit,Redeemed Quantity, Redeemed Amount,Active,Additional Info,Custom Metadata Property Name - **Start and expiration dates** need to be provided in compliance with the ISO 8601 standard. For example, 2020-03-11T09:00:00.000Z.       - YYYY-MM-DD     - YYYY-MM-DDTHH     - YYYY-MM-DDTHH:mm     - YYYY-MM-DDTHH:mm:ss     - YYYY-MM-DDTHH:mm:ssZ     - YYYY-MM-DDTHH:mm:ssZ     - YYYY-MM-DDTHH:mm:ss.SSSZ  - Custom code attributes (not supported by-default) need to be added as code **metadata**.  - You **cannot import the same codes** to a single Voucherify project.  - You can, however, upload the same codes to update them.  📘 Categories  In the structure representing your data, you can define a category that the voucher belongs to. You can later use the category of a voucher to group and search by specific criteria in the Dashboard and using the [List Vouchers](/api-reference/vouchers/list-vouchers) endpoint. This API request starts a process that affects Voucherify data in bulk.  In case of small jobs (like bulk update) the request is put into a queue and processed once every other bulk request placed in the queue prior to this request is finished. However, when the job takes a longer time (like vouchers generation) then it is processed in small portions in a round-robin fashion. When there is a list of vouchers generation scheduled, then they will all have the IN_PROGRESS status shortly. This way, small jobs added just after scheduling big jobs of the same type will be processed in a short time window.  The result will return the async ID. You can verify the status of your request via this [API request](/api-reference/async-actions/get-async-action). You can pass the webhooks_enable true parameter to trigger a webhook sendout for created or updated vouchers. Configure the [respective webhooks](/api-reference/introduction-to-webhooks) in Project settings. For updated webhooks, a webhook is sent even if the voucher hasnt been changed in the CSV file. 🚧 Generic (standalone) vouchers and campaigns In version [v20241004](https://support.voucherify.io/article/23-whats-new-in-voucherify#v20241004), generic (standalone) vouchers created through the Voucherify dashboard create a campaign for that voucher. However, vouchers imported through the dashboard in the Vouchers section or through the API do not have a campaign attached, so the values for campaign and campaign_id are null.
      * @param {{
         file?: File,
         webhooksEnable?: Boolean,
@@ -216,6 +216,7 @@ export default class VouchersApi {
         order?: Exclude<keyof typeof ParameterOrderVouchers, "prototype" | "constructFromObject">,
         code?: String,
         ids?: Array.<String>,
+        filters?: Object.<String, Object>,
      }} [opts] Optional parameters
      * @param {listVouchersCallback} [callback] The callback function, accepting three arguments: error, data, response
      * data is of type: {@link VouchersListResponseBody}
@@ -233,6 +234,7 @@ export default class VouchersApi {
         order?: Exclude<keyof typeof ParameterOrderVouchers, "prototype" | "constructFromObject">;
         code?: string;
         ids?: Array<string>;
+        filters?: any;
     }, callback?: (error: Error | null, data?: VouchersListResponseBody, response?: any) => any): Promise<(VouchersListResponseBody | undefined)>;
     /**
      * Callback function to receive the result of the releaseValidationSession operation.

package/dist/types/model/AccessSettings.d.ts

@@ -2,7 +2,7 @@ export default AccessSettings;
 /**
  * The AccessSettings model module.
  * @module model/AccessSettings
- * @version 3.0.1
+ * @version 3.0.2
  */
 declare class AccessSettings {
     /**

package/dist/types/model/AccessSettingsAssign.d.ts

@@ -2,7 +2,7 @@ export default AccessSettingsAssign;
 /**
  * The AccessSettingsAssign model module.
  * @module model/AccessSettingsAssign
- * @version 3.0.1
+ * @version 3.0.2
  */
 declare class AccessSettingsAssign {
     /**

package/dist/types/model/AccessSettingsCampaignAssignmentsList.d.ts

@@ -2,7 +2,7 @@ export default AccessSettingsCampaignAssignmentsList;
 /**
  * The AccessSettingsCampaignAssignmentsList model module.
  * @module model/AccessSettingsCampaignAssignmentsList
- * @version 3.0.1
+ * @version 3.0.2
  */
 declare class AccessSettingsCampaignAssignmentsList {
     /**

package/dist/types/model/AccessSettingsUnassign.d.ts

@@ -2,7 +2,7 @@ export default AccessSettingsUnassign;
 /**
  * The AccessSettingsUnassign model module.
  * @module model/AccessSettingsUnassign
- * @version 3.0.1
+ * @version 3.0.2
  */
 declare class AccessSettingsUnassign {
     /**

package/dist/types/model/ApplicableTo.d.ts

@@ -2,7 +2,7 @@ export default ApplicableTo;
 /**
  * The ApplicableTo model module.
  * @module model/ApplicableTo
- * @version 3.0.1
+ * @version 3.0.2
  */
 declare class ApplicableTo {
     /**

package/dist/types/model/ApplicableToEffect.d.ts

@@ -2,7 +2,7 @@ export default ApplicableToEffect;
 /**
  * Enum class ApplicableToEffect.
  * @module model/ApplicableToEffect
- * @version 3.0.1
+ * @version 3.0.2
  */
 declare class ApplicableToEffect {
     /**

package/dist/types/model/ApplicableToOrderItemUnitsItem.d.ts

@@ -2,7 +2,7 @@ export default ApplicableToOrderItemUnitsItem;
 /**
  * The ApplicableToOrderItemUnitsItem model module.
  * @module model/ApplicableToOrderItemUnitsItem
- * @version 3.0.1
+ * @version 3.0.2
  */
 declare class ApplicableToOrderItemUnitsItem {
     /**

package/dist/types/model/ApplicableToResultList.d.ts

@@ -2,7 +2,7 @@ export default ApplicableToResultList;
 /**
  * The ApplicableToResultList model module.
  * @module model/ApplicableToResultList
- * @version 3.0.1
+ * @version 3.0.2
  */
 declare class ApplicableToResultList {
     /**

package/dist/types/model/ApplicationDetailsItem.d.ts

@@ -2,7 +2,7 @@ export default ApplicationDetailsItem;
 /**
  * The ApplicationDetailsItem model module.
  * @module model/ApplicationDetailsItem
- * @version 3.0.1
+ * @version 3.0.2
  */
 declare class ApplicationDetailsItem {
     /**

package/dist/types/model/AreaStoreCampaignAssignment.d.ts

@@ -2,7 +2,7 @@ export default AreaStoreCampaignAssignment;
 /**
  * The AreaStoreCampaignAssignment model module.
  * @module model/AreaStoreCampaignAssignment
- * @version 3.0.1
+ * @version 3.0.2
  */
 declare class AreaStoreCampaignAssignment {
     /**

package/dist/types/model/AsyncActionBase.d.ts

@@ -2,7 +2,7 @@ export default AsyncActionBase;
 /**
  * The AsyncActionBase model module.
  * @module model/AsyncActionBase
- * @version 3.0.1
+ * @version 3.0.2
  */
 declare class AsyncActionBase {
     /**

package/dist/types/model/AsyncActionGetResponseBody.d.ts

@@ -2,7 +2,7 @@ export default AsyncActionGetResponseBody;
 /**
  * The AsyncActionGetResponseBody model module.
  * @module model/AsyncActionGetResponseBody
- * @version 3.0.1
+ * @version 3.0.2
  */
 declare class AsyncActionGetResponseBody {
     /**

package/dist/types/model/AsyncActionsListResponseBody.d.ts

@@ -2,7 +2,7 @@ export default AsyncActionsListResponseBody;
 /**
  * The AsyncActionsListResponseBody model module.
  * @module model/AsyncActionsListResponseBody
- * @version 3.0.1
+ * @version 3.0.2
  */
 declare class AsyncActionsListResponseBody {
     /**

package/dist/types/model/Bundle.d.ts

@@ -2,7 +2,7 @@ export default Bundle;
 /**
  * The Bundle model module.
  * @module model/Bundle
- * @version 3.0.1
+ * @version 3.0.2
  */
 declare class Bundle {
     /**

package/dist/types/model/BundleIdentifiedItem.d.ts

@@ -2,7 +2,7 @@ export default BundleIdentifiedItem;
 /**
  * The BundleIdentifiedItem model module.
  * @module model/BundleIdentifiedItem
- * @version 3.0.1
+ * @version 3.0.2
  */
 declare class BundleIdentifiedItem {
     /**

package/dist/types/model/BundleMissingItem.d.ts

@@ -2,7 +2,7 @@ export default BundleMissingItem;
 /**
  * The BundleMissingItem model module.
  * @module model/BundleMissingItem
- * @version 3.0.1
+ * @version 3.0.2
  */
 declare class BundleMissingItem {
     /**

package/dist/types/model/BusValRuleAssignment.d.ts

@@ -2,7 +2,7 @@ export default BusValRuleAssignment;
 /**
  * The BusValRuleAssignment model module.
  * @module model/BusValRuleAssignment
- * @version 3.0.1
+ * @version 3.0.2
  */
 declare class BusValRuleAssignment {
     /**

package/dist/types/model/Campaign.d.ts

@@ -2,7 +2,7 @@ export default Campaign;
 /**
  * The Campaign model module.
  * @module model/Campaign
- * @version 3.0.1
+ * @version 3.0.2
  */
 declare class Campaign {
     /**

package/dist/types/model/CampaignBase.d.ts

@@ -2,7 +2,7 @@ export default CampaignBase;
 /**
  * The CampaignBase model module.
  * @module model/CampaignBase
- * @version 3.0.1
+ * @version 3.0.2
  */
 declare class CampaignBase {
     /**

package/dist/types/model/CampaignLoyaltyCard.d.ts

@@ -2,7 +2,7 @@ export default CampaignLoyaltyCard;
 /**
  * The CampaignLoyaltyCard model module.
  * @module model/CampaignLoyaltyCard
- * @version 3.0.1
+ * @version 3.0.2
  */
 declare class CampaignLoyaltyCard {
     /**

package/dist/types/model/CampaignLoyaltyCardExpirationRules.d.ts

@@ -2,7 +2,7 @@ export default CampaignLoyaltyCardExpirationRules;
 /**
  * The CampaignLoyaltyCardExpirationRules model module.
  * @module model/CampaignLoyaltyCardExpirationRules
- * @version 3.0.1
+ * @version 3.0.2
  */
 declare class CampaignLoyaltyCardExpirationRules {
     /**

package/dist/types/model/CampaignLoyaltyVoucher.d.ts

@@ -2,7 +2,7 @@ export default CampaignLoyaltyVoucher;
 /**
  * The CampaignLoyaltyVoucher model module.
  * @module model/CampaignLoyaltyVoucher
- * @version 3.0.1
+ * @version 3.0.2
  */
 declare class CampaignLoyaltyVoucher {
     /**

package/dist/types/model/CampaignLoyaltyVoucherRedemption.d.ts

@@ -2,7 +2,7 @@ export default CampaignLoyaltyVoucherRedemption;
 /**
  * The CampaignLoyaltyVoucherRedemption model module.
  * @module model/CampaignLoyaltyVoucherRedemption
- * @version 3.0.1
+ * @version 3.0.2
  */
 declare class CampaignLoyaltyVoucherRedemption {
     /**

package/dist/types/model/CampaignTemplate.d.ts

@@ -2,7 +2,7 @@ export default CampaignTemplate;
 /**
  * The CampaignTemplate model module.
  * @module model/CampaignTemplate
- * @version 3.0.1
+ * @version 3.0.2
  */
 declare class CampaignTemplate {
     /**

package/dist/types/model/CampaignVoucher.d.ts

@@ -2,7 +2,7 @@ export default CampaignVoucher;
 /**
  * The CampaignVoucher model module.
  * @module model/CampaignVoucher
- * @version 3.0.1
+ * @version 3.0.2
  */
 declare class CampaignVoucher {
     /**

package/dist/types/model/CampaignVoucherRedemption.d.ts

@@ -2,7 +2,7 @@ export default CampaignVoucherRedemption;
 /**
  * The CampaignVoucherRedemption model module.
  * @module model/CampaignVoucherRedemption
- * @version 3.0.1
+ * @version 3.0.2
  */
 declare class CampaignVoucherRedemption {
     /**