@zippendo/sdk 1.0.3 → 1.1.1

package/dist/esm/models/ListShippingRules200ResponseDataInner.d.ts

@@ -1,6 +1,6 @@
 /**
  * Zippendo Public API
- * Public API documentation for Zippendo. Authenticate using your API token (Bearer token prefixed with zipp_).  **Brands (sub-accounts).** An organization can be split into brands, each keeping its own orders, shipments and configuration separate. There are two ways to scope requests to one brand, and NEITHER changes any request body:  1. **Bind the token.** Create an API token with a `brandId` and every request it makes is confined    to that brand — reads filtered, writes stamped. This is the recommended way to give a single    brand\'s team its own credential. 2. **Send the `X-Zippendo-Brand` header.** An organization-wide token can scope an individual    request by sending the brand\'s id or slug in this header. Most SDKs let you set it once on the    client so every call inherits it.  A brand-bound token that receives an `X-Zippendo-Brand` header naming a different brand is rejected with `403 BRAND_ACCESS_DENIED` — the binding is never widened. Omit both and requests cover the whole organization, which is the behaviour of every existing token.  Records that belong to no brand carry `brandId: null`. Configuration (carriers, shipping rules, addresses) with a null brand is organization-wide and remains visible inside every brand; orders and shipments with a null brand are only visible organization-wide.
+ * Public API documentation for Zippendo. Authenticate using your API token (Bearer token prefixed with zipp_).  **Brands (sub-accounts).** An organization can be split into brands, each keeping its own orders, shipments and configuration separate. There are two ways to scope requests to one brand, and NEITHER changes any request body:  1. **Bind the token.** Create an API token with a `brandId` and every request it makes is confined    to that brand — reads filtered, writes stamped. This is the recommended way to give a single    brand\'s team its own credential. 2. **Send the `X-Zippendo-Brand` header.** An organization-wide token can scope an individual    request by sending the brand\'s id or slug in this header. Most SDKs let you set it once on the    client so every call inherits it.  A brand-bound token that receives an `X-Zippendo-Brand` header naming a different brand is rejected with `403 BRAND_ACCESS_DENIED` — the binding is never widened. Omit both and requests cover the whole organization, which is the behaviour of every existing token.  Records that belong to no brand carry `brandId: null`. Configuration (carriers, shipping rules, addresses) with a null brand is organization-wide and remains visible inside every brand; orders and shipments with a null brand are only visible organization-wide.  Brands themselves are managed under the **Brands** tag. Retiring a brand is done with `POST /orgs/{orgId}/brands/{brandId}/archive` — permanent deletion is a dashboard-only action, since it is refused while any order, shipment, member or token still references the brand. Brands require a plan that includes them; creating one beyond your plan\'s limit returns `403`.
  *
  * The version of the OpenAPI document: 1.0.0
  * Contact: support@zippendo.com
@@ -13,7 +13,7 @@ import type { ListShippingRules200ResponseDataInnerCarrier } from './ListShippin
 import type { ListAddresses200ResponseDataInner } from './ListAddresses200ResponseDataInner';
 import type { ListShippingRules200ResponseDataInnerConditionsInner } from './ListShippingRules200ResponseDataInnerConditionsInner';
 import type { ListShippingRules200ResponseDataInnerLabelPrinter } from './ListShippingRules200ResponseDataInnerLabelPrinter';
-import type { ListShippingRules200ResponseDataInnerAdditionalParametersInner } from './ListShippingRules200ResponseDataInnerAdditionalParametersInner';
+import type { ListShippingRules200ResponseDataInnerAdditionalParametersValue } from './ListShippingRules200ResponseDataInnerAdditionalParametersValue';
 import type { ListShippingRules200ResponseDataInnerReturnShippingRule } from './ListShippingRules200ResponseDataInnerReturnShippingRule';
 /**
  *
@@ -64,11 +64,13 @@ export interface ListShippingRules200ResponseDataInner {
      */
     services: Array<string>;
     /**
-     * Carrier-specific extra parameters. DEPRECATED array form `[{ name, val }]` where `name` is the carrier parameter `key` (from the product's `additionalParameters[].key`, e.g. `returnFunctionality`) and `val` is the stringified value. This will change to a `{ key: value }` object in a future version — writes already accept either shape.
-     * @type {Array<ListShippingRules200ResponseDataInnerAdditionalParametersInner>}
+     * Carrier-specific extra parameters, keyed by the carrier parameter `key` from the product's `additionalParameters[].key`.
+     * @type {{ [key: string]: ListShippingRules200ResponseDataInnerAdditionalParametersValue; }}
      * @memberof ListShippingRules200ResponseDataInner
      */
-    additionalParameters: Array<ListShippingRules200ResponseDataInnerAdditionalParametersInner>;
+    additionalParameters: {
+        [key: string]: ListShippingRules200ResponseDataInnerAdditionalParametersValue;
+    };
     /**
      * Sender address ID
      * @type {string}

package/dist/esm/models/ListShippingRules200ResponseDataInner.js

@@ -2,7 +2,7 @@
 /* eslint-disable */
 /**
  * Zippendo Public API
- * Public API documentation for Zippendo. Authenticate using your API token (Bearer token prefixed with zipp_).  **Brands (sub-accounts).** An organization can be split into brands, each keeping its own orders, shipments and configuration separate. There are two ways to scope requests to one brand, and NEITHER changes any request body:  1. **Bind the token.** Create an API token with a `brandId` and every request it makes is confined    to that brand — reads filtered, writes stamped. This is the recommended way to give a single    brand\'s team its own credential. 2. **Send the `X-Zippendo-Brand` header.** An organization-wide token can scope an individual    request by sending the brand\'s id or slug in this header. Most SDKs let you set it once on the    client so every call inherits it.  A brand-bound token that receives an `X-Zippendo-Brand` header naming a different brand is rejected with `403 BRAND_ACCESS_DENIED` — the binding is never widened. Omit both and requests cover the whole organization, which is the behaviour of every existing token.  Records that belong to no brand carry `brandId: null`. Configuration (carriers, shipping rules, addresses) with a null brand is organization-wide and remains visible inside every brand; orders and shipments with a null brand are only visible organization-wide.
+ * Public API documentation for Zippendo. Authenticate using your API token (Bearer token prefixed with zipp_).  **Brands (sub-accounts).** An organization can be split into brands, each keeping its own orders, shipments and configuration separate. There are two ways to scope requests to one brand, and NEITHER changes any request body:  1. **Bind the token.** Create an API token with a `brandId` and every request it makes is confined    to that brand — reads filtered, writes stamped. This is the recommended way to give a single    brand\'s team its own credential. 2. **Send the `X-Zippendo-Brand` header.** An organization-wide token can scope an individual    request by sending the brand\'s id or slug in this header. Most SDKs let you set it once on the    client so every call inherits it.  A brand-bound token that receives an `X-Zippendo-Brand` header naming a different brand is rejected with `403 BRAND_ACCESS_DENIED` — the binding is never widened. Omit both and requests cover the whole organization, which is the behaviour of every existing token.  Records that belong to no brand carry `brandId: null`. Configuration (carriers, shipping rules, addresses) with a null brand is organization-wide and remains visible inside every brand; orders and shipments with a null brand are only visible organization-wide.  Brands themselves are managed under the **Brands** tag. Retiring a brand is done with `POST /orgs/{orgId}/brands/{brandId}/archive` — permanent deletion is a dashboard-only action, since it is refused while any order, shipment, member or token still references the brand. Brands require a plan that includes them; creating one beyond your plan\'s limit returns `403`.
  *
  * The version of the OpenAPI document: 1.0.0
  * Contact: support@zippendo.com
@@ -11,11 +11,12 @@
  * https://openapi-generator.tech
  * Do not edit the class manually.
  */
+import { mapValues } from '../runtime';
 import { ListShippingRules200ResponseDataInnerCarrierFromJSON, ListShippingRules200ResponseDataInnerCarrierToJSON, } from './ListShippingRules200ResponseDataInnerCarrier';
 import { ListAddresses200ResponseDataInnerFromJSON, ListAddresses200ResponseDataInnerToJSON, } from './ListAddresses200ResponseDataInner';
 import { ListShippingRules200ResponseDataInnerConditionsInnerFromJSON, ListShippingRules200ResponseDataInnerConditionsInnerToJSON, } from './ListShippingRules200ResponseDataInnerConditionsInner';
 import { ListShippingRules200ResponseDataInnerLabelPrinterFromJSON, ListShippingRules200ResponseDataInnerLabelPrinterToJSON, } from './ListShippingRules200ResponseDataInnerLabelPrinter';
-import { ListShippingRules200ResponseDataInnerAdditionalParametersInnerFromJSON, ListShippingRules200ResponseDataInnerAdditionalParametersInnerToJSON, } from './ListShippingRules200ResponseDataInnerAdditionalParametersInner';
+import { ListShippingRules200ResponseDataInnerAdditionalParametersValueFromJSON, ListShippingRules200ResponseDataInnerAdditionalParametersValueToJSON, } from './ListShippingRules200ResponseDataInnerAdditionalParametersValue';
 import { ListShippingRules200ResponseDataInnerReturnShippingRuleFromJSON, ListShippingRules200ResponseDataInnerReturnShippingRuleToJSON, } from './ListShippingRules200ResponseDataInnerReturnShippingRule';
 /**
  * @export
@@ -107,7 +108,7 @@ export function ListShippingRules200ResponseDataInnerFromJSONTyped(json, ignoreD
         'carrierId': json['carrierId'],
         'productId': json['productId'],
         'services': json['services'],
-        'additionalParameters': (json['additionalParameters'].map(ListShippingRules200ResponseDataInnerAdditionalParametersInnerFromJSON)),
+        'additionalParameters': (mapValues(json['additionalParameters'], ListShippingRules200ResponseDataInnerAdditionalParametersValueFromJSON)),
         'addressId': json['addressId'],
         'receivingCountries': json['receivingCountries'],
         'emailNotification': json['emailNotification'],
@@ -151,7 +152,7 @@ export function ListShippingRules200ResponseDataInnerToJSONTyped(value, ignoreDi
         'carrierId': value['carrierId'],
         'productId': value['productId'],
         'services': value['services'],
-        'additionalParameters': (value['additionalParameters'].map(ListShippingRules200ResponseDataInnerAdditionalParametersInnerToJSON)),
+        'additionalParameters': (mapValues(value['additionalParameters'], ListShippingRules200ResponseDataInnerAdditionalParametersValueToJSON)),
         'addressId': value['addressId'],
         'receivingCountries': value['receivingCountries'],
         'emailNotification': value['emailNotification'],

package/dist/esm/models/ListShippingRules200ResponseDataInnerAdditionalParametersValue.d.ts

@@ -0,0 +1,51 @@
+/**
+ * Zippendo Public API
+ * Public API documentation for Zippendo. Authenticate using your API token (Bearer token prefixed with zipp_).  **Brands (sub-accounts).** An organization can be split into brands, each keeping its own orders, shipments and configuration separate. There are two ways to scope requests to one brand, and NEITHER changes any request body:  1. **Bind the token.** Create an API token with a `brandId` and every request it makes is confined    to that brand — reads filtered, writes stamped. This is the recommended way to give a single    brand\'s team its own credential. 2. **Send the `X-Zippendo-Brand` header.** An organization-wide token can scope an individual    request by sending the brand\'s id or slug in this header. Most SDKs let you set it once on the    client so every call inherits it.  A brand-bound token that receives an `X-Zippendo-Brand` header naming a different brand is rejected with `403 BRAND_ACCESS_DENIED` — the binding is never widened. Omit both and requests cover the whole organization, which is the behaviour of every existing token.  Records that belong to no brand carry `brandId: null`. Configuration (carriers, shipping rules, addresses) with a null brand is organization-wide and remains visible inside every brand; orders and shipments with a null brand are only visible organization-wide.  Brands themselves are managed under the **Brands** tag. Retiring a brand is done with `POST /orgs/{orgId}/brands/{brandId}/archive` — permanent deletion is a dashboard-only action, since it is refused while any order, shipment, member or token still references the brand. Brands require a plan that includes them; creating one beyond your plan\'s limit returns `403`.
+ *
+ * The version of the OpenAPI document: 1.0.0
+ * Contact: support@zippendo.com
+ *
+ * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech).
+ * https://openapi-generator.tech
+ * Do not edit the class manually.
+ */
+import type { ListShippingRules200ResponseDataInnerAdditionalParametersValueAnyOfCoordinatesInner } from './ListShippingRules200ResponseDataInnerAdditionalParametersValueAnyOfCoordinatesInner';
+/**
+ *
+ * @export
+ * @interface ListShippingRules200ResponseDataInnerAdditionalParametersValue
+ */
+export interface ListShippingRules200ResponseDataInnerAdditionalParametersValue {
+    /**
+     * Identifier of the selected service point.
+     * @type {string}
+     * @memberof ListShippingRules200ResponseDataInnerAdditionalParametersValue
+     */
+    id: string;
+    /**
+     * Display name of the service point.
+     * @type {string}
+     * @memberof ListShippingRules200ResponseDataInnerAdditionalParametersValue
+     */
+    name: string;
+    /**
+     * Formatted address of the service point.
+     * @type {string}
+     * @memberof ListShippingRules200ResponseDataInnerAdditionalParametersValue
+     */
+    address: string;
+    /**
+     * Latitude/longitude of the service point.
+     * @type {Array<ListShippingRules200ResponseDataInnerAdditionalParametersValueAnyOfCoordinatesInner>}
+     * @memberof ListShippingRules200ResponseDataInnerAdditionalParametersValue
+     */
+    coordinates?: Array<ListShippingRules200ResponseDataInnerAdditionalParametersValueAnyOfCoordinatesInner>;
+}
+/**
+ * Check if a given object implements the ListShippingRules200ResponseDataInnerAdditionalParametersValue interface.
+ */
+export declare function instanceOfListShippingRules200ResponseDataInnerAdditionalParametersValue(value: object): value is ListShippingRules200ResponseDataInnerAdditionalParametersValue;
+export declare function ListShippingRules200ResponseDataInnerAdditionalParametersValueFromJSON(json: any): ListShippingRules200ResponseDataInnerAdditionalParametersValue;
+export declare function ListShippingRules200ResponseDataInnerAdditionalParametersValueFromJSONTyped(json: any, ignoreDiscriminator: boolean): ListShippingRules200ResponseDataInnerAdditionalParametersValue;
+export declare function ListShippingRules200ResponseDataInnerAdditionalParametersValueToJSON(json: any): ListShippingRules200ResponseDataInnerAdditionalParametersValue;
+export declare function ListShippingRules200ResponseDataInnerAdditionalParametersValueToJSONTyped(value?: ListShippingRules200ResponseDataInnerAdditionalParametersValue | null, ignoreDiscriminator?: boolean): any;

package/dist/esm/models/{ListShipments200ResponseDataInnerCarrierSettingsAdditionalParametersValueAnyOf.js → ListShippingRules200ResponseDataInnerAdditionalParametersValue.js}

@@ -2,7 +2,7 @@
 /* eslint-disable */
 /**
  * Zippendo Public API
- * Public API documentation for Zippendo. Authenticate using your API token (Bearer token prefixed with zipp_).  **Brands (sub-accounts).** An organization can be split into brands, each keeping its own orders, shipments and configuration separate. There are two ways to scope requests to one brand, and NEITHER changes any request body:  1. **Bind the token.** Create an API token with a `brandId` and every request it makes is confined    to that brand — reads filtered, writes stamped. This is the recommended way to give a single    brand\'s team its own credential. 2. **Send the `X-Zippendo-Brand` header.** An organization-wide token can scope an individual    request by sending the brand\'s id or slug in this header. Most SDKs let you set it once on the    client so every call inherits it.  A brand-bound token that receives an `X-Zippendo-Brand` header naming a different brand is rejected with `403 BRAND_ACCESS_DENIED` — the binding is never widened. Omit both and requests cover the whole organization, which is the behaviour of every existing token.  Records that belong to no brand carry `brandId: null`. Configuration (carriers, shipping rules, addresses) with a null brand is organization-wide and remains visible inside every brand; orders and shipments with a null brand are only visible organization-wide.
+ * Public API documentation for Zippendo. Authenticate using your API token (Bearer token prefixed with zipp_).  **Brands (sub-accounts).** An organization can be split into brands, each keeping its own orders, shipments and configuration separate. There are two ways to scope requests to one brand, and NEITHER changes any request body:  1. **Bind the token.** Create an API token with a `brandId` and every request it makes is confined    to that brand — reads filtered, writes stamped. This is the recommended way to give a single    brand\'s team its own credential. 2. **Send the `X-Zippendo-Brand` header.** An organization-wide token can scope an individual    request by sending the brand\'s id or slug in this header. Most SDKs let you set it once on the    client so every call inherits it.  A brand-bound token that receives an `X-Zippendo-Brand` header naming a different brand is rejected with `403 BRAND_ACCESS_DENIED` — the binding is never widened. Omit both and requests cover the whole organization, which is the behaviour of every existing token.  Records that belong to no brand carry `brandId: null`. Configuration (carriers, shipping rules, addresses) with a null brand is organization-wide and remains visible inside every brand; orders and shipments with a null brand are only visible organization-wide.  Brands themselves are managed under the **Brands** tag. Retiring a brand is done with `POST /orgs/{orgId}/brands/{brandId}/archive` — permanent deletion is a dashboard-only action, since it is refused while any order, shipment, member or token still references the brand. Brands require a plan that includes them; creating one beyond your plan\'s limit returns `403`.
  *
  * The version of the OpenAPI document: 1.0.0
  * Contact: support@zippendo.com
@@ -11,11 +11,11 @@
  * https://openapi-generator.tech
  * Do not edit the class manually.
  */
-import { CreateShippingRuleRequestAdditionalParametersAnyOfValueAnyOfCoordinatesInnerFromJSON, CreateShippingRuleRequestAdditionalParametersAnyOfValueAnyOfCoordinatesInnerToJSON, } from './CreateShippingRuleRequestAdditionalParametersAnyOfValueAnyOfCoordinatesInner';
+import { ListShippingRules200ResponseDataInnerAdditionalParametersValueAnyOfCoordinatesInnerFromJSON, ListShippingRules200ResponseDataInnerAdditionalParametersValueAnyOfCoordinatesInnerToJSON, } from './ListShippingRules200ResponseDataInnerAdditionalParametersValueAnyOfCoordinatesInner';
 /**
- * Check if a given object implements the ListShipments200ResponseDataInnerCarrierSettingsAdditionalParametersValueAnyOf interface.
+ * Check if a given object implements the ListShippingRules200ResponseDataInnerAdditionalParametersValue interface.
  */
-export function instanceOfListShipments200ResponseDataInnerCarrierSettingsAdditionalParametersValueAnyOf(value) {
+export function instanceOfListShippingRules200ResponseDataInnerAdditionalParametersValue(value) {
     if (!('id' in value) || value['id'] === undefined)
         return false;
     if (!('name' in value) || value['name'] === undefined)
@@ -24,10 +24,10 @@ export function instanceOfListShipments200ResponseDataInnerCarrierSettingsAdditi
         return false;
     return true;
 }
-export function ListShipments200ResponseDataInnerCarrierSettingsAdditionalParametersValueAnyOfFromJSON(json) {
-    return ListShipments200ResponseDataInnerCarrierSettingsAdditionalParametersValueAnyOfFromJSONTyped(json, false);
+export function ListShippingRules200ResponseDataInnerAdditionalParametersValueFromJSON(json) {
+    return ListShippingRules200ResponseDataInnerAdditionalParametersValueFromJSONTyped(json, false);
 }
-export function ListShipments200ResponseDataInnerCarrierSettingsAdditionalParametersValueAnyOfFromJSONTyped(json, ignoreDiscriminator) {
+export function ListShippingRules200ResponseDataInnerAdditionalParametersValueFromJSONTyped(json, ignoreDiscriminator) {
     if (json == null) {
         return json;
     }
@@ -35,13 +35,13 @@ export function ListShipments200ResponseDataInnerCarrierSettingsAdditionalParame
         'id': json['id'],
         'name': json['name'],
         'address': json['address'],
-        'coordinates': json['coordinates'] == null ? undefined : (json['coordinates'].map(CreateShippingRuleRequestAdditionalParametersAnyOfValueAnyOfCoordinatesInnerFromJSON)),
+        'coordinates': json['coordinates'] == null ? undefined : (json['coordinates'].map(ListShippingRules200ResponseDataInnerAdditionalParametersValueAnyOfCoordinatesInnerFromJSON)),
     };
 }
-export function ListShipments200ResponseDataInnerCarrierSettingsAdditionalParametersValueAnyOfToJSON(json) {
-    return ListShipments200ResponseDataInnerCarrierSettingsAdditionalParametersValueAnyOfToJSONTyped(json, false);
+export function ListShippingRules200ResponseDataInnerAdditionalParametersValueToJSON(json) {
+    return ListShippingRules200ResponseDataInnerAdditionalParametersValueToJSONTyped(json, false);
 }
-export function ListShipments200ResponseDataInnerCarrierSettingsAdditionalParametersValueAnyOfToJSONTyped(value, ignoreDiscriminator = false) {
+export function ListShippingRules200ResponseDataInnerAdditionalParametersValueToJSONTyped(value, ignoreDiscriminator = false) {
     if (value == null) {
         return value;
     }
@@ -49,6 +49,6 @@ export function ListShipments200ResponseDataInnerCarrierSettingsAdditionalParame
         'id': value['id'],
         'name': value['name'],
         'address': value['address'],
-        'coordinates': value['coordinates'] == null ? undefined : (value['coordinates'].map(CreateShippingRuleRequestAdditionalParametersAnyOfValueAnyOfCoordinatesInnerToJSON)),
+        'coordinates': value['coordinates'] == null ? undefined : (value['coordinates'].map(ListShippingRules200ResponseDataInnerAdditionalParametersValueAnyOfCoordinatesInnerToJSON)),
     };
 }

package/dist/esm/models/ListShippingRules200ResponseDataInnerAdditionalParametersValueAnyOf.d.ts

@@ -0,0 +1,51 @@
+/**
+ * Zippendo Public API
+ * Public API documentation for Zippendo. Authenticate using your API token (Bearer token prefixed with zipp_).  **Brands (sub-accounts).** An organization can be split into brands, each keeping its own orders, shipments and configuration separate. There are two ways to scope requests to one brand, and NEITHER changes any request body:  1. **Bind the token.** Create an API token with a `brandId` and every request it makes is confined    to that brand — reads filtered, writes stamped. This is the recommended way to give a single    brand\'s team its own credential. 2. **Send the `X-Zippendo-Brand` header.** An organization-wide token can scope an individual    request by sending the brand\'s id or slug in this header. Most SDKs let you set it once on the    client so every call inherits it.  A brand-bound token that receives an `X-Zippendo-Brand` header naming a different brand is rejected with `403 BRAND_ACCESS_DENIED` — the binding is never widened. Omit both and requests cover the whole organization, which is the behaviour of every existing token.  Records that belong to no brand carry `brandId: null`. Configuration (carriers, shipping rules, addresses) with a null brand is organization-wide and remains visible inside every brand; orders and shipments with a null brand are only visible organization-wide.  Brands themselves are managed under the **Brands** tag. Retiring a brand is done with `POST /orgs/{orgId}/brands/{brandId}/archive` — permanent deletion is a dashboard-only action, since it is refused while any order, shipment, member or token still references the brand. Brands require a plan that includes them; creating one beyond your plan\'s limit returns `403`.
+ *
+ * The version of the OpenAPI document: 1.0.0
+ * Contact: support@zippendo.com
+ *
+ * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech).
+ * https://openapi-generator.tech
+ * Do not edit the class manually.
+ */
+import type { ListShippingRules200ResponseDataInnerAdditionalParametersValueAnyOfCoordinatesInner } from './ListShippingRules200ResponseDataInnerAdditionalParametersValueAnyOfCoordinatesInner';
+/**
+ *
+ * @export
+ * @interface ListShippingRules200ResponseDataInnerAdditionalParametersValueAnyOf
+ */
+export interface ListShippingRules200ResponseDataInnerAdditionalParametersValueAnyOf {
+    /**
+     * Identifier of the selected service point.
+     * @type {string}
+     * @memberof ListShippingRules200ResponseDataInnerAdditionalParametersValueAnyOf
+     */
+    id: string;
+    /**
+     * Display name of the service point.
+     * @type {string}
+     * @memberof ListShippingRules200ResponseDataInnerAdditionalParametersValueAnyOf
+     */
+    name: string;
+    /**
+     * Formatted address of the service point.
+     * @type {string}
+     * @memberof ListShippingRules200ResponseDataInnerAdditionalParametersValueAnyOf
+     */
+    address: string;
+    /**
+     * Latitude/longitude of the service point.
+     * @type {Array<ListShippingRules200ResponseDataInnerAdditionalParametersValueAnyOfCoordinatesInner>}
+     * @memberof ListShippingRules200ResponseDataInnerAdditionalParametersValueAnyOf
+     */
+    coordinates?: Array<ListShippingRules200ResponseDataInnerAdditionalParametersValueAnyOfCoordinatesInner>;
+}
+/**
+ * Check if a given object implements the ListShippingRules200ResponseDataInnerAdditionalParametersValueAnyOf interface.
+ */
+export declare function instanceOfListShippingRules200ResponseDataInnerAdditionalParametersValueAnyOf(value: object): value is ListShippingRules200ResponseDataInnerAdditionalParametersValueAnyOf;
+export declare function ListShippingRules200ResponseDataInnerAdditionalParametersValueAnyOfFromJSON(json: any): ListShippingRules200ResponseDataInnerAdditionalParametersValueAnyOf;
+export declare function ListShippingRules200ResponseDataInnerAdditionalParametersValueAnyOfFromJSONTyped(json: any, ignoreDiscriminator: boolean): ListShippingRules200ResponseDataInnerAdditionalParametersValueAnyOf;
+export declare function ListShippingRules200ResponseDataInnerAdditionalParametersValueAnyOfToJSON(json: any): ListShippingRules200ResponseDataInnerAdditionalParametersValueAnyOf;
+export declare function ListShippingRules200ResponseDataInnerAdditionalParametersValueAnyOfToJSONTyped(value?: ListShippingRules200ResponseDataInnerAdditionalParametersValueAnyOf | null, ignoreDiscriminator?: boolean): any;

package/dist/esm/models/ListShippingRules200ResponseDataInnerAdditionalParametersValueAnyOf.js

@@ -0,0 +1,54 @@
+/* tslint:disable */
+/* eslint-disable */
+/**
+ * Zippendo Public API
+ * Public API documentation for Zippendo. Authenticate using your API token (Bearer token prefixed with zipp_).  **Brands (sub-accounts).** An organization can be split into brands, each keeping its own orders, shipments and configuration separate. There are two ways to scope requests to one brand, and NEITHER changes any request body:  1. **Bind the token.** Create an API token with a `brandId` and every request it makes is confined    to that brand — reads filtered, writes stamped. This is the recommended way to give a single    brand\'s team its own credential. 2. **Send the `X-Zippendo-Brand` header.** An organization-wide token can scope an individual    request by sending the brand\'s id or slug in this header. Most SDKs let you set it once on the    client so every call inherits it.  A brand-bound token that receives an `X-Zippendo-Brand` header naming a different brand is rejected with `403 BRAND_ACCESS_DENIED` — the binding is never widened. Omit both and requests cover the whole organization, which is the behaviour of every existing token.  Records that belong to no brand carry `brandId: null`. Configuration (carriers, shipping rules, addresses) with a null brand is organization-wide and remains visible inside every brand; orders and shipments with a null brand are only visible organization-wide.  Brands themselves are managed under the **Brands** tag. Retiring a brand is done with `POST /orgs/{orgId}/brands/{brandId}/archive` — permanent deletion is a dashboard-only action, since it is refused while any order, shipment, member or token still references the brand. Brands require a plan that includes them; creating one beyond your plan\'s limit returns `403`.
+ *
+ * The version of the OpenAPI document: 1.0.0
+ * Contact: support@zippendo.com
+ *
+ * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech).
+ * https://openapi-generator.tech
+ * Do not edit the class manually.
+ */
+import { ListShippingRules200ResponseDataInnerAdditionalParametersValueAnyOfCoordinatesInnerFromJSON, ListShippingRules200ResponseDataInnerAdditionalParametersValueAnyOfCoordinatesInnerToJSON, } from './ListShippingRules200ResponseDataInnerAdditionalParametersValueAnyOfCoordinatesInner';
+/**
+ * Check if a given object implements the ListShippingRules200ResponseDataInnerAdditionalParametersValueAnyOf interface.
+ */
+export function instanceOfListShippingRules200ResponseDataInnerAdditionalParametersValueAnyOf(value) {
+    if (!('id' in value) || value['id'] === undefined)
+        return false;
+    if (!('name' in value) || value['name'] === undefined)
+        return false;
+    if (!('address' in value) || value['address'] === undefined)
+        return false;
+    return true;
+}
+export function ListShippingRules200ResponseDataInnerAdditionalParametersValueAnyOfFromJSON(json) {
+    return ListShippingRules200ResponseDataInnerAdditionalParametersValueAnyOfFromJSONTyped(json, false);
+}
+export function ListShippingRules200ResponseDataInnerAdditionalParametersValueAnyOfFromJSONTyped(json, ignoreDiscriminator) {
+    if (json == null) {
+        return json;
+    }
+    return {
+        'id': json['id'],
+        'name': json['name'],
+        'address': json['address'],
+        'coordinates': json['coordinates'] == null ? undefined : (json['coordinates'].map(ListShippingRules200ResponseDataInnerAdditionalParametersValueAnyOfCoordinatesInnerFromJSON)),
+    };
+}
+export function ListShippingRules200ResponseDataInnerAdditionalParametersValueAnyOfToJSON(json) {
+    return ListShippingRules200ResponseDataInnerAdditionalParametersValueAnyOfToJSONTyped(json, false);
+}
+export function ListShippingRules200ResponseDataInnerAdditionalParametersValueAnyOfToJSONTyped(value, ignoreDiscriminator = false) {
+    if (value == null) {
+        return value;
+    }
+    return {
+        'id': value['id'],
+        'name': value['name'],
+        'address': value['address'],
+        'coordinates': value['coordinates'] == null ? undefined : (value['coordinates'].map(ListShippingRules200ResponseDataInnerAdditionalParametersValueAnyOfCoordinatesInnerToJSON)),
+    };
+}

package/dist/{models/ListShippingRules200ResponseDataInnerAdditionalParametersInner.d.ts → esm/models/ListShippingRules200ResponseDataInnerAdditionalParametersValueAnyOfCoordinatesInner.d.ts}

@@ -1,6 +1,6 @@
 /**
  * Zippendo Public API
- * Public API documentation for Zippendo. Authenticate using your API token (Bearer token prefixed with zipp_).  **Brands (sub-accounts).** An organization can be split into brands, each keeping its own orders, shipments and configuration separate. There are two ways to scope requests to one brand, and NEITHER changes any request body:  1. **Bind the token.** Create an API token with a `brandId` and every request it makes is confined    to that brand — reads filtered, writes stamped. This is the recommended way to give a single    brand\'s team its own credential. 2. **Send the `X-Zippendo-Brand` header.** An organization-wide token can scope an individual    request by sending the brand\'s id or slug in this header. Most SDKs let you set it once on the    client so every call inherits it.  A brand-bound token that receives an `X-Zippendo-Brand` header naming a different brand is rejected with `403 BRAND_ACCESS_DENIED` — the binding is never widened. Omit both and requests cover the whole organization, which is the behaviour of every existing token.  Records that belong to no brand carry `brandId: null`. Configuration (carriers, shipping rules, addresses) with a null brand is organization-wide and remains visible inside every brand; orders and shipments with a null brand are only visible organization-wide.
+ * Public API documentation for Zippendo. Authenticate using your API token (Bearer token prefixed with zipp_).  **Brands (sub-accounts).** An organization can be split into brands, each keeping its own orders, shipments and configuration separate. There are two ways to scope requests to one brand, and NEITHER changes any request body:  1. **Bind the token.** Create an API token with a `brandId` and every request it makes is confined    to that brand — reads filtered, writes stamped. This is the recommended way to give a single    brand\'s team its own credential. 2. **Send the `X-Zippendo-Brand` header.** An organization-wide token can scope an individual    request by sending the brand\'s id or slug in this header. Most SDKs let you set it once on the    client so every call inherits it.  A brand-bound token that receives an `X-Zippendo-Brand` header naming a different brand is rejected with `403 BRAND_ACCESS_DENIED` — the binding is never widened. Omit both and requests cover the whole organization, which is the behaviour of every existing token.  Records that belong to no brand carry `brandId: null`. Configuration (carriers, shipping rules, addresses) with a null brand is organization-wide and remains visible inside every brand; orders and shipments with a null brand are only visible organization-wide.  Brands themselves are managed under the **Brands** tag. Retiring a brand is done with `POST /orgs/{orgId}/brands/{brandId}/archive` — permanent deletion is a dashboard-only action, since it is refused while any order, shipment, member or token still references the brand. Brands require a plan that includes them; creating one beyond your plan\'s limit returns `403`.
  *
  * The version of the OpenAPI document: 1.0.0
  * Contact: support@zippendo.com
@@ -12,27 +12,15 @@
 /**
  *
  * @export
- * @interface ListShippingRules200ResponseDataInnerAdditionalParametersInner
+ * @interface ListShippingRules200ResponseDataInnerAdditionalParametersValueAnyOfCoordinatesInner
  */
-export interface ListShippingRules200ResponseDataInnerAdditionalParametersInner {
-    /**
-     * Carrier parameter key
-     * @type {string}
-     * @memberof ListShippingRules200ResponseDataInnerAdditionalParametersInner
-     */
-    name: string;
-    /**
-     * Parameter value (stringified)
-     * @type {string}
-     * @memberof ListShippingRules200ResponseDataInnerAdditionalParametersInner
-     */
-    val: string;
+export interface ListShippingRules200ResponseDataInnerAdditionalParametersValueAnyOfCoordinatesInner {
 }
 /**
- * Check if a given object implements the ListShippingRules200ResponseDataInnerAdditionalParametersInner interface.
+ * Check if a given object implements the ListShippingRules200ResponseDataInnerAdditionalParametersValueAnyOfCoordinatesInner interface.
  */
-export declare function instanceOfListShippingRules200ResponseDataInnerAdditionalParametersInner(value: object): value is ListShippingRules200ResponseDataInnerAdditionalParametersInner;
-export declare function ListShippingRules200ResponseDataInnerAdditionalParametersInnerFromJSON(json: any): ListShippingRules200ResponseDataInnerAdditionalParametersInner;
-export declare function ListShippingRules200ResponseDataInnerAdditionalParametersInnerFromJSONTyped(json: any, ignoreDiscriminator: boolean): ListShippingRules200ResponseDataInnerAdditionalParametersInner;
-export declare function ListShippingRules200ResponseDataInnerAdditionalParametersInnerToJSON(json: any): ListShippingRules200ResponseDataInnerAdditionalParametersInner;
-export declare function ListShippingRules200ResponseDataInnerAdditionalParametersInnerToJSONTyped(value?: ListShippingRules200ResponseDataInnerAdditionalParametersInner | null, ignoreDiscriminator?: boolean): any;
+export declare function instanceOfListShippingRules200ResponseDataInnerAdditionalParametersValueAnyOfCoordinatesInner(value: object): value is ListShippingRules200ResponseDataInnerAdditionalParametersValueAnyOfCoordinatesInner;
+export declare function ListShippingRules200ResponseDataInnerAdditionalParametersValueAnyOfCoordinatesInnerFromJSON(json: any): ListShippingRules200ResponseDataInnerAdditionalParametersValueAnyOfCoordinatesInner;
+export declare function ListShippingRules200ResponseDataInnerAdditionalParametersValueAnyOfCoordinatesInnerFromJSONTyped(json: any, ignoreDiscriminator: boolean): ListShippingRules200ResponseDataInnerAdditionalParametersValueAnyOfCoordinatesInner;
+export declare function ListShippingRules200ResponseDataInnerAdditionalParametersValueAnyOfCoordinatesInnerToJSON(json: any): ListShippingRules200ResponseDataInnerAdditionalParametersValueAnyOfCoordinatesInner;
+export declare function ListShippingRules200ResponseDataInnerAdditionalParametersValueAnyOfCoordinatesInnerToJSONTyped(value?: ListShippingRules200ResponseDataInnerAdditionalParametersValueAnyOfCoordinatesInner | null, ignoreDiscriminator?: boolean): any;

package/dist/esm/models/{ListShippingRules200ResponseDataInnerAdditionalParametersInner.js → ListShippingRules200ResponseDataInnerAdditionalParametersValueAnyOfCoordinatesInner.js}

@@ -2,7 +2,7 @@
 /* eslint-disable */
 /**
  * Zippendo Public API
- * Public API documentation for Zippendo. Authenticate using your API token (Bearer token prefixed with zipp_).  **Brands (sub-accounts).** An organization can be split into brands, each keeping its own orders, shipments and configuration separate. There are two ways to scope requests to one brand, and NEITHER changes any request body:  1. **Bind the token.** Create an API token with a `brandId` and every request it makes is confined    to that brand — reads filtered, writes stamped. This is the recommended way to give a single    brand\'s team its own credential. 2. **Send the `X-Zippendo-Brand` header.** An organization-wide token can scope an individual    request by sending the brand\'s id or slug in this header. Most SDKs let you set it once on the    client so every call inherits it.  A brand-bound token that receives an `X-Zippendo-Brand` header naming a different brand is rejected with `403 BRAND_ACCESS_DENIED` — the binding is never widened. Omit both and requests cover the whole organization, which is the behaviour of every existing token.  Records that belong to no brand carry `brandId: null`. Configuration (carriers, shipping rules, addresses) with a null brand is organization-wide and remains visible inside every brand; orders and shipments with a null brand are only visible organization-wide.
+ * Public API documentation for Zippendo. Authenticate using your API token (Bearer token prefixed with zipp_).  **Brands (sub-accounts).** An organization can be split into brands, each keeping its own orders, shipments and configuration separate. There are two ways to scope requests to one brand, and NEITHER changes any request body:  1. **Bind the token.** Create an API token with a `brandId` and every request it makes is confined    to that brand — reads filtered, writes stamped. This is the recommended way to give a single    brand\'s team its own credential. 2. **Send the `X-Zippendo-Brand` header.** An organization-wide token can scope an individual    request by sending the brand\'s id or slug in this header. Most SDKs let you set it once on the    client so every call inherits it.  A brand-bound token that receives an `X-Zippendo-Brand` header naming a different brand is rejected with `403 BRAND_ACCESS_DENIED` — the binding is never widened. Omit both and requests cover the whole organization, which is the behaviour of every existing token.  Records that belong to no brand carry `brandId: null`. Configuration (carriers, shipping rules, addresses) with a null brand is organization-wide and remains visible inside every brand; orders and shipments with a null brand are only visible organization-wide.  Brands themselves are managed under the **Brands** tag. Retiring a brand is done with `POST /orgs/{orgId}/brands/{brandId}/archive` — permanent deletion is a dashboard-only action, since it is refused while any order, shipment, member or token still references the brand. Brands require a plan that includes them; creating one beyond your plan\'s limit returns `403`.
  *
  * The version of the OpenAPI document: 1.0.0
  * Contact: support@zippendo.com
@@ -12,36 +12,20 @@
  * Do not edit the class manually.
  */
 /**
- * Check if a given object implements the ListShippingRules200ResponseDataInnerAdditionalParametersInner interface.
+ * Check if a given object implements the ListShippingRules200ResponseDataInnerAdditionalParametersValueAnyOfCoordinatesInner interface.
  */
-export function instanceOfListShippingRules200ResponseDataInnerAdditionalParametersInner(value) {
-    if (!('name' in value) || value['name'] === undefined)
-        return false;
-    if (!('val' in value) || value['val'] === undefined)
-        return false;
+export function instanceOfListShippingRules200ResponseDataInnerAdditionalParametersValueAnyOfCoordinatesInner(value) {
     return true;
 }
-export function ListShippingRules200ResponseDataInnerAdditionalParametersInnerFromJSON(json) {
-    return ListShippingRules200ResponseDataInnerAdditionalParametersInnerFromJSONTyped(json, false);
+export function ListShippingRules200ResponseDataInnerAdditionalParametersValueAnyOfCoordinatesInnerFromJSON(json) {
+    return ListShippingRules200ResponseDataInnerAdditionalParametersValueAnyOfCoordinatesInnerFromJSONTyped(json, false);
 }
-export function ListShippingRules200ResponseDataInnerAdditionalParametersInnerFromJSONTyped(json, ignoreDiscriminator) {
-    if (json == null) {
-        return json;
-    }
-    return {
-        'name': json['name'],
-        'val': json['val'],
-    };
+export function ListShippingRules200ResponseDataInnerAdditionalParametersValueAnyOfCoordinatesInnerFromJSONTyped(json, ignoreDiscriminator) {
+    return json;
 }
-export function ListShippingRules200ResponseDataInnerAdditionalParametersInnerToJSON(json) {
-    return ListShippingRules200ResponseDataInnerAdditionalParametersInnerToJSONTyped(json, false);
+export function ListShippingRules200ResponseDataInnerAdditionalParametersValueAnyOfCoordinatesInnerToJSON(json) {
+    return ListShippingRules200ResponseDataInnerAdditionalParametersValueAnyOfCoordinatesInnerToJSONTyped(json, false);
 }
-export function ListShippingRules200ResponseDataInnerAdditionalParametersInnerToJSONTyped(value, ignoreDiscriminator = false) {
-    if (value == null) {
-        return value;
-    }
-    return {
-        'name': value['name'],
-        'val': value['val'],
-    };
+export function ListShippingRules200ResponseDataInnerAdditionalParametersValueAnyOfCoordinatesInnerToJSONTyped(value, ignoreDiscriminator = false) {
+    return value;
 }

package/dist/esm/models/ListShippingRules200ResponseDataInnerCarrier.d.ts

@@ -1,6 +1,6 @@
 /**
  * Zippendo Public API
- * Public API documentation for Zippendo. Authenticate using your API token (Bearer token prefixed with zipp_).  **Brands (sub-accounts).** An organization can be split into brands, each keeping its own orders, shipments and configuration separate. There are two ways to scope requests to one brand, and NEITHER changes any request body:  1. **Bind the token.** Create an API token with a `brandId` and every request it makes is confined    to that brand — reads filtered, writes stamped. This is the recommended way to give a single    brand\'s team its own credential. 2. **Send the `X-Zippendo-Brand` header.** An organization-wide token can scope an individual    request by sending the brand\'s id or slug in this header. Most SDKs let you set it once on the    client so every call inherits it.  A brand-bound token that receives an `X-Zippendo-Brand` header naming a different brand is rejected with `403 BRAND_ACCESS_DENIED` — the binding is never widened. Omit both and requests cover the whole organization, which is the behaviour of every existing token.  Records that belong to no brand carry `brandId: null`. Configuration (carriers, shipping rules, addresses) with a null brand is organization-wide and remains visible inside every brand; orders and shipments with a null brand are only visible organization-wide.
+ * Public API documentation for Zippendo. Authenticate using your API token (Bearer token prefixed with zipp_).  **Brands (sub-accounts).** An organization can be split into brands, each keeping its own orders, shipments and configuration separate. There are two ways to scope requests to one brand, and NEITHER changes any request body:  1. **Bind the token.** Create an API token with a `brandId` and every request it makes is confined    to that brand — reads filtered, writes stamped. This is the recommended way to give a single    brand\'s team its own credential. 2. **Send the `X-Zippendo-Brand` header.** An organization-wide token can scope an individual    request by sending the brand\'s id or slug in this header. Most SDKs let you set it once on the    client so every call inherits it.  A brand-bound token that receives an `X-Zippendo-Brand` header naming a different brand is rejected with `403 BRAND_ACCESS_DENIED` — the binding is never widened. Omit both and requests cover the whole organization, which is the behaviour of every existing token.  Records that belong to no brand carry `brandId: null`. Configuration (carriers, shipping rules, addresses) with a null brand is organization-wide and remains visible inside every brand; orders and shipments with a null brand are only visible organization-wide.  Brands themselves are managed under the **Brands** tag. Retiring a brand is done with `POST /orgs/{orgId}/brands/{brandId}/archive` — permanent deletion is a dashboard-only action, since it is refused while any order, shipment, member or token still references the brand. Brands require a plan that includes them; creating one beyond your plan\'s limit returns `403`.
  *
  * The version of the OpenAPI document: 1.0.0
  * Contact: support@zippendo.com

package/dist/esm/models/ListShippingRules200ResponseDataInnerCarrier.js

@@ -2,7 +2,7 @@
 /* eslint-disable */
 /**
  * Zippendo Public API
- * Public API documentation for Zippendo. Authenticate using your API token (Bearer token prefixed with zipp_).  **Brands (sub-accounts).** An organization can be split into brands, each keeping its own orders, shipments and configuration separate. There are two ways to scope requests to one brand, and NEITHER changes any request body:  1. **Bind the token.** Create an API token with a `brandId` and every request it makes is confined    to that brand — reads filtered, writes stamped. This is the recommended way to give a single    brand\'s team its own credential. 2. **Send the `X-Zippendo-Brand` header.** An organization-wide token can scope an individual    request by sending the brand\'s id or slug in this header. Most SDKs let you set it once on the    client so every call inherits it.  A brand-bound token that receives an `X-Zippendo-Brand` header naming a different brand is rejected with `403 BRAND_ACCESS_DENIED` — the binding is never widened. Omit both and requests cover the whole organization, which is the behaviour of every existing token.  Records that belong to no brand carry `brandId: null`. Configuration (carriers, shipping rules, addresses) with a null brand is organization-wide and remains visible inside every brand; orders and shipments with a null brand are only visible organization-wide.
+ * Public API documentation for Zippendo. Authenticate using your API token (Bearer token prefixed with zipp_).  **Brands (sub-accounts).** An organization can be split into brands, each keeping its own orders, shipments and configuration separate. There are two ways to scope requests to one brand, and NEITHER changes any request body:  1. **Bind the token.** Create an API token with a `brandId` and every request it makes is confined    to that brand — reads filtered, writes stamped. This is the recommended way to give a single    brand\'s team its own credential. 2. **Send the `X-Zippendo-Brand` header.** An organization-wide token can scope an individual    request by sending the brand\'s id or slug in this header. Most SDKs let you set it once on the    client so every call inherits it.  A brand-bound token that receives an `X-Zippendo-Brand` header naming a different brand is rejected with `403 BRAND_ACCESS_DENIED` — the binding is never widened. Omit both and requests cover the whole organization, which is the behaviour of every existing token.  Records that belong to no brand carry `brandId: null`. Configuration (carriers, shipping rules, addresses) with a null brand is organization-wide and remains visible inside every brand; orders and shipments with a null brand are only visible organization-wide.  Brands themselves are managed under the **Brands** tag. Retiring a brand is done with `POST /orgs/{orgId}/brands/{brandId}/archive` — permanent deletion is a dashboard-only action, since it is refused while any order, shipment, member or token still references the brand. Brands require a plan that includes them; creating one beyond your plan\'s limit returns `403`.
  *
  * The version of the OpenAPI document: 1.0.0
  * Contact: support@zippendo.com

package/dist/esm/models/ListShippingRules200ResponseDataInnerConditionsInner.d.ts

@@ -1,6 +1,6 @@
 /**
  * Zippendo Public API
- * Public API documentation for Zippendo. Authenticate using your API token (Bearer token prefixed with zipp_).  **Brands (sub-accounts).** An organization can be split into brands, each keeping its own orders, shipments and configuration separate. There are two ways to scope requests to one brand, and NEITHER changes any request body:  1. **Bind the token.** Create an API token with a `brandId` and every request it makes is confined    to that brand — reads filtered, writes stamped. This is the recommended way to give a single    brand\'s team its own credential. 2. **Send the `X-Zippendo-Brand` header.** An organization-wide token can scope an individual    request by sending the brand\'s id or slug in this header. Most SDKs let you set it once on the    client so every call inherits it.  A brand-bound token that receives an `X-Zippendo-Brand` header naming a different brand is rejected with `403 BRAND_ACCESS_DENIED` — the binding is never widened. Omit both and requests cover the whole organization, which is the behaviour of every existing token.  Records that belong to no brand carry `brandId: null`. Configuration (carriers, shipping rules, addresses) with a null brand is organization-wide and remains visible inside every brand; orders and shipments with a null brand are only visible organization-wide.
+ * Public API documentation for Zippendo. Authenticate using your API token (Bearer token prefixed with zipp_).  **Brands (sub-accounts).** An organization can be split into brands, each keeping its own orders, shipments and configuration separate. There are two ways to scope requests to one brand, and NEITHER changes any request body:  1. **Bind the token.** Create an API token with a `brandId` and every request it makes is confined    to that brand — reads filtered, writes stamped. This is the recommended way to give a single    brand\'s team its own credential. 2. **Send the `X-Zippendo-Brand` header.** An organization-wide token can scope an individual    request by sending the brand\'s id or slug in this header. Most SDKs let you set it once on the    client so every call inherits it.  A brand-bound token that receives an `X-Zippendo-Brand` header naming a different brand is rejected with `403 BRAND_ACCESS_DENIED` — the binding is never widened. Omit both and requests cover the whole organization, which is the behaviour of every existing token.  Records that belong to no brand carry `brandId: null`. Configuration (carriers, shipping rules, addresses) with a null brand is organization-wide and remains visible inside every brand; orders and shipments with a null brand are only visible organization-wide.  Brands themselves are managed under the **Brands** tag. Retiring a brand is done with `POST /orgs/{orgId}/brands/{brandId}/archive` — permanent deletion is a dashboard-only action, since it is refused while any order, shipment, member or token still references the brand. Brands require a plan that includes them; creating one beyond your plan\'s limit returns `403`.
  *
  * The version of the OpenAPI document: 1.0.0
  * Contact: support@zippendo.com

package/dist/esm/models/ListShippingRules200ResponseDataInnerConditionsInner.js

@@ -2,7 +2,7 @@
 /* eslint-disable */
 /**
  * Zippendo Public API
- * Public API documentation for Zippendo. Authenticate using your API token (Bearer token prefixed with zipp_).  **Brands (sub-accounts).** An organization can be split into brands, each keeping its own orders, shipments and configuration separate. There are two ways to scope requests to one brand, and NEITHER changes any request body:  1. **Bind the token.** Create an API token with a `brandId` and every request it makes is confined    to that brand — reads filtered, writes stamped. This is the recommended way to give a single    brand\'s team its own credential. 2. **Send the `X-Zippendo-Brand` header.** An organization-wide token can scope an individual    request by sending the brand\'s id or slug in this header. Most SDKs let you set it once on the    client so every call inherits it.  A brand-bound token that receives an `X-Zippendo-Brand` header naming a different brand is rejected with `403 BRAND_ACCESS_DENIED` — the binding is never widened. Omit both and requests cover the whole organization, which is the behaviour of every existing token.  Records that belong to no brand carry `brandId: null`. Configuration (carriers, shipping rules, addresses) with a null brand is organization-wide and remains visible inside every brand; orders and shipments with a null brand are only visible organization-wide.
+ * Public API documentation for Zippendo. Authenticate using your API token (Bearer token prefixed with zipp_).  **Brands (sub-accounts).** An organization can be split into brands, each keeping its own orders, shipments and configuration separate. There are two ways to scope requests to one brand, and NEITHER changes any request body:  1. **Bind the token.** Create an API token with a `brandId` and every request it makes is confined    to that brand — reads filtered, writes stamped. This is the recommended way to give a single    brand\'s team its own credential. 2. **Send the `X-Zippendo-Brand` header.** An organization-wide token can scope an individual    request by sending the brand\'s id or slug in this header. Most SDKs let you set it once on the    client so every call inherits it.  A brand-bound token that receives an `X-Zippendo-Brand` header naming a different brand is rejected with `403 BRAND_ACCESS_DENIED` — the binding is never widened. Omit both and requests cover the whole organization, which is the behaviour of every existing token.  Records that belong to no brand carry `brandId: null`. Configuration (carriers, shipping rules, addresses) with a null brand is organization-wide and remains visible inside every brand; orders and shipments with a null brand are only visible organization-wide.  Brands themselves are managed under the **Brands** tag. Retiring a brand is done with `POST /orgs/{orgId}/brands/{brandId}/archive` — permanent deletion is a dashboard-only action, since it is refused while any order, shipment, member or token still references the brand. Brands require a plan that includes them; creating one beyond your plan\'s limit returns `403`.
  *
  * The version of the OpenAPI document: 1.0.0
  * Contact: support@zippendo.com

package/dist/esm/models/ListShippingRules200ResponseDataInnerConditionsInnerOneOf.d.ts

@@ -1,6 +1,6 @@
 /**
  * Zippendo Public API
- * Public API documentation for Zippendo. Authenticate using your API token (Bearer token prefixed with zipp_).  **Brands (sub-accounts).** An organization can be split into brands, each keeping its own orders, shipments and configuration separate. There are two ways to scope requests to one brand, and NEITHER changes any request body:  1. **Bind the token.** Create an API token with a `brandId` and every request it makes is confined    to that brand — reads filtered, writes stamped. This is the recommended way to give a single    brand\'s team its own credential. 2. **Send the `X-Zippendo-Brand` header.** An organization-wide token can scope an individual    request by sending the brand\'s id or slug in this header. Most SDKs let you set it once on the    client so every call inherits it.  A brand-bound token that receives an `X-Zippendo-Brand` header naming a different brand is rejected with `403 BRAND_ACCESS_DENIED` — the binding is never widened. Omit both and requests cover the whole organization, which is the behaviour of every existing token.  Records that belong to no brand carry `brandId: null`. Configuration (carriers, shipping rules, addresses) with a null brand is organization-wide and remains visible inside every brand; orders and shipments with a null brand are only visible organization-wide.
+ * Public API documentation for Zippendo. Authenticate using your API token (Bearer token prefixed with zipp_).  **Brands (sub-accounts).** An organization can be split into brands, each keeping its own orders, shipments and configuration separate. There are two ways to scope requests to one brand, and NEITHER changes any request body:  1. **Bind the token.** Create an API token with a `brandId` and every request it makes is confined    to that brand — reads filtered, writes stamped. This is the recommended way to give a single    brand\'s team its own credential. 2. **Send the `X-Zippendo-Brand` header.** An organization-wide token can scope an individual    request by sending the brand\'s id or slug in this header. Most SDKs let you set it once on the    client so every call inherits it.  A brand-bound token that receives an `X-Zippendo-Brand` header naming a different brand is rejected with `403 BRAND_ACCESS_DENIED` — the binding is never widened. Omit both and requests cover the whole organization, which is the behaviour of every existing token.  Records that belong to no brand carry `brandId: null`. Configuration (carriers, shipping rules, addresses) with a null brand is organization-wide and remains visible inside every brand; orders and shipments with a null brand are only visible organization-wide.  Brands themselves are managed under the **Brands** tag. Retiring a brand is done with `POST /orgs/{orgId}/brands/{brandId}/archive` — permanent deletion is a dashboard-only action, since it is refused while any order, shipment, member or token still references the brand. Brands require a plan that includes them; creating one beyond your plan\'s limit returns `403`.
  *
  * The version of the OpenAPI document: 1.0.0
  * Contact: support@zippendo.com

package/dist/esm/models/ListShippingRules200ResponseDataInnerConditionsInnerOneOf.js

@@ -2,7 +2,7 @@
 /* eslint-disable */
 /**
  * Zippendo Public API
- * Public API documentation for Zippendo. Authenticate using your API token (Bearer token prefixed with zipp_).  **Brands (sub-accounts).** An organization can be split into brands, each keeping its own orders, shipments and configuration separate. There are two ways to scope requests to one brand, and NEITHER changes any request body:  1. **Bind the token.** Create an API token with a `brandId` and every request it makes is confined    to that brand — reads filtered, writes stamped. This is the recommended way to give a single    brand\'s team its own credential. 2. **Send the `X-Zippendo-Brand` header.** An organization-wide token can scope an individual    request by sending the brand\'s id or slug in this header. Most SDKs let you set it once on the    client so every call inherits it.  A brand-bound token that receives an `X-Zippendo-Brand` header naming a different brand is rejected with `403 BRAND_ACCESS_DENIED` — the binding is never widened. Omit both and requests cover the whole organization, which is the behaviour of every existing token.  Records that belong to no brand carry `brandId: null`. Configuration (carriers, shipping rules, addresses) with a null brand is organization-wide and remains visible inside every brand; orders and shipments with a null brand are only visible organization-wide.
+ * Public API documentation for Zippendo. Authenticate using your API token (Bearer token prefixed with zipp_).  **Brands (sub-accounts).** An organization can be split into brands, each keeping its own orders, shipments and configuration separate. There are two ways to scope requests to one brand, and NEITHER changes any request body:  1. **Bind the token.** Create an API token with a `brandId` and every request it makes is confined    to that brand — reads filtered, writes stamped. This is the recommended way to give a single    brand\'s team its own credential. 2. **Send the `X-Zippendo-Brand` header.** An organization-wide token can scope an individual    request by sending the brand\'s id or slug in this header. Most SDKs let you set it once on the    client so every call inherits it.  A brand-bound token that receives an `X-Zippendo-Brand` header naming a different brand is rejected with `403 BRAND_ACCESS_DENIED` — the binding is never widened. Omit both and requests cover the whole organization, which is the behaviour of every existing token.  Records that belong to no brand carry `brandId: null`. Configuration (carriers, shipping rules, addresses) with a null brand is organization-wide and remains visible inside every brand; orders and shipments with a null brand are only visible organization-wide.  Brands themselves are managed under the **Brands** tag. Retiring a brand is done with `POST /orgs/{orgId}/brands/{brandId}/archive` — permanent deletion is a dashboard-only action, since it is refused while any order, shipment, member or token still references the brand. Brands require a plan that includes them; creating one beyond your plan\'s limit returns `403`.
  *
  * The version of the OpenAPI document: 1.0.0
  * Contact: support@zippendo.com

package/dist/esm/models/ListShippingRules200ResponseDataInnerConditionsInnerOneOf1.d.ts

@@ -1,6 +1,6 @@
 /**
  * Zippendo Public API
- * Public API documentation for Zippendo. Authenticate using your API token (Bearer token prefixed with zipp_).  **Brands (sub-accounts).** An organization can be split into brands, each keeping its own orders, shipments and configuration separate. There are two ways to scope requests to one brand, and NEITHER changes any request body:  1. **Bind the token.** Create an API token with a `brandId` and every request it makes is confined    to that brand — reads filtered, writes stamped. This is the recommended way to give a single    brand\'s team its own credential. 2. **Send the `X-Zippendo-Brand` header.** An organization-wide token can scope an individual    request by sending the brand\'s id or slug in this header. Most SDKs let you set it once on the    client so every call inherits it.  A brand-bound token that receives an `X-Zippendo-Brand` header naming a different brand is rejected with `403 BRAND_ACCESS_DENIED` — the binding is never widened. Omit both and requests cover the whole organization, which is the behaviour of every existing token.  Records that belong to no brand carry `brandId: null`. Configuration (carriers, shipping rules, addresses) with a null brand is organization-wide and remains visible inside every brand; orders and shipments with a null brand are only visible organization-wide.
+ * Public API documentation for Zippendo. Authenticate using your API token (Bearer token prefixed with zipp_).  **Brands (sub-accounts).** An organization can be split into brands, each keeping its own orders, shipments and configuration separate. There are two ways to scope requests to one brand, and NEITHER changes any request body:  1. **Bind the token.** Create an API token with a `brandId` and every request it makes is confined    to that brand — reads filtered, writes stamped. This is the recommended way to give a single    brand\'s team its own credential. 2. **Send the `X-Zippendo-Brand` header.** An organization-wide token can scope an individual    request by sending the brand\'s id or slug in this header. Most SDKs let you set it once on the    client so every call inherits it.  A brand-bound token that receives an `X-Zippendo-Brand` header naming a different brand is rejected with `403 BRAND_ACCESS_DENIED` — the binding is never widened. Omit both and requests cover the whole organization, which is the behaviour of every existing token.  Records that belong to no brand carry `brandId: null`. Configuration (carriers, shipping rules, addresses) with a null brand is organization-wide and remains visible inside every brand; orders and shipments with a null brand are only visible organization-wide.  Brands themselves are managed under the **Brands** tag. Retiring a brand is done with `POST /orgs/{orgId}/brands/{brandId}/archive` — permanent deletion is a dashboard-only action, since it is refused while any order, shipment, member or token still references the brand. Brands require a plan that includes them; creating one beyond your plan\'s limit returns `403`.
  *
  * The version of the OpenAPI document: 1.0.0
  * Contact: support@zippendo.com

package/dist/esm/models/ListShippingRules200ResponseDataInnerConditionsInnerOneOf1.js

@@ -2,7 +2,7 @@
 /* eslint-disable */
 /**
  * Zippendo Public API
- * Public API documentation for Zippendo. Authenticate using your API token (Bearer token prefixed with zipp_).  **Brands (sub-accounts).** An organization can be split into brands, each keeping its own orders, shipments and configuration separate. There are two ways to scope requests to one brand, and NEITHER changes any request body:  1. **Bind the token.** Create an API token with a `brandId` and every request it makes is confined    to that brand — reads filtered, writes stamped. This is the recommended way to give a single    brand\'s team its own credential. 2. **Send the `X-Zippendo-Brand` header.** An organization-wide token can scope an individual    request by sending the brand\'s id or slug in this header. Most SDKs let you set it once on the    client so every call inherits it.  A brand-bound token that receives an `X-Zippendo-Brand` header naming a different brand is rejected with `403 BRAND_ACCESS_DENIED` — the binding is never widened. Omit both and requests cover the whole organization, which is the behaviour of every existing token.  Records that belong to no brand carry `brandId: null`. Configuration (carriers, shipping rules, addresses) with a null brand is organization-wide and remains visible inside every brand; orders and shipments with a null brand are only visible organization-wide.
+ * Public API documentation for Zippendo. Authenticate using your API token (Bearer token prefixed with zipp_).  **Brands (sub-accounts).** An organization can be split into brands, each keeping its own orders, shipments and configuration separate. There are two ways to scope requests to one brand, and NEITHER changes any request body:  1. **Bind the token.** Create an API token with a `brandId` and every request it makes is confined    to that brand — reads filtered, writes stamped. This is the recommended way to give a single    brand\'s team its own credential. 2. **Send the `X-Zippendo-Brand` header.** An organization-wide token can scope an individual    request by sending the brand\'s id or slug in this header. Most SDKs let you set it once on the    client so every call inherits it.  A brand-bound token that receives an `X-Zippendo-Brand` header naming a different brand is rejected with `403 BRAND_ACCESS_DENIED` — the binding is never widened. Omit both and requests cover the whole organization, which is the behaviour of every existing token.  Records that belong to no brand carry `brandId: null`. Configuration (carriers, shipping rules, addresses) with a null brand is organization-wide and remains visible inside every brand; orders and shipments with a null brand are only visible organization-wide.  Brands themselves are managed under the **Brands** tag. Retiring a brand is done with `POST /orgs/{orgId}/brands/{brandId}/archive` — permanent deletion is a dashboard-only action, since it is refused while any order, shipment, member or token still references the brand. Brands require a plan that includes them; creating one beyond your plan\'s limit returns `403`.
  *
  * The version of the OpenAPI document: 1.0.0
  * Contact: support@zippendo.com

package/dist/esm/models/ListShippingRules200ResponseDataInnerConditionsInnerOneOf2.d.ts

@@ -1,6 +1,6 @@
 /**
  * Zippendo Public API
- * Public API documentation for Zippendo. Authenticate using your API token (Bearer token prefixed with zipp_).  **Brands (sub-accounts).** An organization can be split into brands, each keeping its own orders, shipments and configuration separate. There are two ways to scope requests to one brand, and NEITHER changes any request body:  1. **Bind the token.** Create an API token with a `brandId` and every request it makes is confined    to that brand — reads filtered, writes stamped. This is the recommended way to give a single    brand\'s team its own credential. 2. **Send the `X-Zippendo-Brand` header.** An organization-wide token can scope an individual    request by sending the brand\'s id or slug in this header. Most SDKs let you set it once on the    client so every call inherits it.  A brand-bound token that receives an `X-Zippendo-Brand` header naming a different brand is rejected with `403 BRAND_ACCESS_DENIED` — the binding is never widened. Omit both and requests cover the whole organization, which is the behaviour of every existing token.  Records that belong to no brand carry `brandId: null`. Configuration (carriers, shipping rules, addresses) with a null brand is organization-wide and remains visible inside every brand; orders and shipments with a null brand are only visible organization-wide.
+ * Public API documentation for Zippendo. Authenticate using your API token (Bearer token prefixed with zipp_).  **Brands (sub-accounts).** An organization can be split into brands, each keeping its own orders, shipments and configuration separate. There are two ways to scope requests to one brand, and NEITHER changes any request body:  1. **Bind the token.** Create an API token with a `brandId` and every request it makes is confined    to that brand — reads filtered, writes stamped. This is the recommended way to give a single    brand\'s team its own credential. 2. **Send the `X-Zippendo-Brand` header.** An organization-wide token can scope an individual    request by sending the brand\'s id or slug in this header. Most SDKs let you set it once on the    client so every call inherits it.  A brand-bound token that receives an `X-Zippendo-Brand` header naming a different brand is rejected with `403 BRAND_ACCESS_DENIED` — the binding is never widened. Omit both and requests cover the whole organization, which is the behaviour of every existing token.  Records that belong to no brand carry `brandId: null`. Configuration (carriers, shipping rules, addresses) with a null brand is organization-wide and remains visible inside every brand; orders and shipments with a null brand are only visible organization-wide.  Brands themselves are managed under the **Brands** tag. Retiring a brand is done with `POST /orgs/{orgId}/brands/{brandId}/archive` — permanent deletion is a dashboard-only action, since it is refused while any order, shipment, member or token still references the brand. Brands require a plan that includes them; creating one beyond your plan\'s limit returns `403`.
  *
  * The version of the OpenAPI document: 1.0.0
  * Contact: support@zippendo.com

package/dist/esm/models/ListShippingRules200ResponseDataInnerConditionsInnerOneOf2.js

@@ -2,7 +2,7 @@
 /* eslint-disable */
 /**
  * Zippendo Public API
- * Public API documentation for Zippendo. Authenticate using your API token (Bearer token prefixed with zipp_).  **Brands (sub-accounts).** An organization can be split into brands, each keeping its own orders, shipments and configuration separate. There are two ways to scope requests to one brand, and NEITHER changes any request body:  1. **Bind the token.** Create an API token with a `brandId` and every request it makes is confined    to that brand — reads filtered, writes stamped. This is the recommended way to give a single    brand\'s team its own credential. 2. **Send the `X-Zippendo-Brand` header.** An organization-wide token can scope an individual    request by sending the brand\'s id or slug in this header. Most SDKs let you set it once on the    client so every call inherits it.  A brand-bound token that receives an `X-Zippendo-Brand` header naming a different brand is rejected with `403 BRAND_ACCESS_DENIED` — the binding is never widened. Omit both and requests cover the whole organization, which is the behaviour of every existing token.  Records that belong to no brand carry `brandId: null`. Configuration (carriers, shipping rules, addresses) with a null brand is organization-wide and remains visible inside every brand; orders and shipments with a null brand are only visible organization-wide.
+ * Public API documentation for Zippendo. Authenticate using your API token (Bearer token prefixed with zipp_).  **Brands (sub-accounts).** An organization can be split into brands, each keeping its own orders, shipments and configuration separate. There are two ways to scope requests to one brand, and NEITHER changes any request body:  1. **Bind the token.** Create an API token with a `brandId` and every request it makes is confined    to that brand — reads filtered, writes stamped. This is the recommended way to give a single    brand\'s team its own credential. 2. **Send the `X-Zippendo-Brand` header.** An organization-wide token can scope an individual    request by sending the brand\'s id or slug in this header. Most SDKs let you set it once on the    client so every call inherits it.  A brand-bound token that receives an `X-Zippendo-Brand` header naming a different brand is rejected with `403 BRAND_ACCESS_DENIED` — the binding is never widened. Omit both and requests cover the whole organization, which is the behaviour of every existing token.  Records that belong to no brand carry `brandId: null`. Configuration (carriers, shipping rules, addresses) with a null brand is organization-wide and remains visible inside every brand; orders and shipments with a null brand are only visible organization-wide.  Brands themselves are managed under the **Brands** tag. Retiring a brand is done with `POST /orgs/{orgId}/brands/{brandId}/archive` — permanent deletion is a dashboard-only action, since it is refused while any order, shipment, member or token still references the brand. Brands require a plan that includes them; creating one beyond your plan\'s limit returns `403`.
  *
  * The version of the OpenAPI document: 1.0.0
  * Contact: support@zippendo.com

package/dist/esm/models/ListShippingRules200ResponseDataInnerConditionsInnerOneOf3.d.ts

@@ -1,6 +1,6 @@
 /**
  * Zippendo Public API
- * Public API documentation for Zippendo. Authenticate using your API token (Bearer token prefixed with zipp_).  **Brands (sub-accounts).** An organization can be split into brands, each keeping its own orders, shipments and configuration separate. There are two ways to scope requests to one brand, and NEITHER changes any request body:  1. **Bind the token.** Create an API token with a `brandId` and every request it makes is confined    to that brand — reads filtered, writes stamped. This is the recommended way to give a single    brand\'s team its own credential. 2. **Send the `X-Zippendo-Brand` header.** An organization-wide token can scope an individual    request by sending the brand\'s id or slug in this header. Most SDKs let you set it once on the    client so every call inherits it.  A brand-bound token that receives an `X-Zippendo-Brand` header naming a different brand is rejected with `403 BRAND_ACCESS_DENIED` — the binding is never widened. Omit both and requests cover the whole organization, which is the behaviour of every existing token.  Records that belong to no brand carry `brandId: null`. Configuration (carriers, shipping rules, addresses) with a null brand is organization-wide and remains visible inside every brand; orders and shipments with a null brand are only visible organization-wide.
+ * Public API documentation for Zippendo. Authenticate using your API token (Bearer token prefixed with zipp_).  **Brands (sub-accounts).** An organization can be split into brands, each keeping its own orders, shipments and configuration separate. There are two ways to scope requests to one brand, and NEITHER changes any request body:  1. **Bind the token.** Create an API token with a `brandId` and every request it makes is confined    to that brand — reads filtered, writes stamped. This is the recommended way to give a single    brand\'s team its own credential. 2. **Send the `X-Zippendo-Brand` header.** An organization-wide token can scope an individual    request by sending the brand\'s id or slug in this header. Most SDKs let you set it once on the    client so every call inherits it.  A brand-bound token that receives an `X-Zippendo-Brand` header naming a different brand is rejected with `403 BRAND_ACCESS_DENIED` — the binding is never widened. Omit both and requests cover the whole organization, which is the behaviour of every existing token.  Records that belong to no brand carry `brandId: null`. Configuration (carriers, shipping rules, addresses) with a null brand is organization-wide and remains visible inside every brand; orders and shipments with a null brand are only visible organization-wide.  Brands themselves are managed under the **Brands** tag. Retiring a brand is done with `POST /orgs/{orgId}/brands/{brandId}/archive` — permanent deletion is a dashboard-only action, since it is refused while any order, shipment, member or token still references the brand. Brands require a plan that includes them; creating one beyond your plan\'s limit returns `403`.
  *
  * The version of the OpenAPI document: 1.0.0
  * Contact: support@zippendo.com