@zippendo/sdk 1.1.1 → 1.1.3

package/dist/models/UpdateShipmentRequest.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.  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`.
+ * 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.  List endpoints additionally take a `?brandScope=own|shared|both` parameter to narrow further within whichever brand context already applies. `own` returns only rows assigned to that brand, and requires a brand context — a brand-bound token, a resolved brand session, or the `X-Zippendo-Brand` header above — otherwise `400`. `shared` returns only the organization-wide rows (equivalent to filtering `brandId=none`). The default, `both`, keeps the existing behaviour: a brand context sees its own rows plus the organization-wide ones. Set `X-Zippendo-Brand-Scope` as a client default to apply the same choice to every request instead of repeating the query parameter on each call — an explicit `brandScope` query parameter always wins over the header, and a blank header value is ignored.  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/models/UpdateShipmentRequest.js

@@ -3,7 +3,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.  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`.
+ * 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.  List endpoints additionally take a `?brandScope=own|shared|both` parameter to narrow further within whichever brand context already applies. `own` returns only rows assigned to that brand, and requires a brand context — a brand-bound token, a resolved brand session, or the `X-Zippendo-Brand` header above — otherwise `400`. `shared` returns only the organization-wide rows (equivalent to filtering `brandId=none`). The default, `both`, keeps the existing behaviour: a brand context sees its own rows plus the organization-wide ones. Set `X-Zippendo-Brand-Scope` as a client default to apply the same choice to every request instead of repeating the query parameter on each call — an explicit `brandScope` query parameter always wins over the header, and a blank header value is ignored.  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/models/UpdateShippingRuleRequest.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.  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`.
+ * 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.  List endpoints additionally take a `?brandScope=own|shared|both` parameter to narrow further within whichever brand context already applies. `own` returns only rows assigned to that brand, and requires a brand context — a brand-bound token, a resolved brand session, or the `X-Zippendo-Brand` header above — otherwise `400`. `shared` returns only the organization-wide rows (equivalent to filtering `brandId=none`). The default, `both`, keeps the existing behaviour: a brand context sees its own rows plus the organization-wide ones. Set `X-Zippendo-Brand-Scope` as a client default to apply the same choice to every request instead of repeating the query parameter on each call — an explicit `brandScope` query parameter always wins over the header, and a blank header value is ignored.  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
@@ -169,6 +169,12 @@ export interface UpdateShippingRuleRequest {
      * @memberof UpdateShippingRuleRequest
      */
     autoCreateReturnShipment?: boolean;
+    /**
+     * Brand this record is assigned to; null (or omitted outside a brand session) keeps it organization-wide
+     * @type {string}
+     * @memberof UpdateShippingRuleRequest
+     */
+    brandId?: string | null;
 }
 /**
  * @export

package/dist/models/UpdateShippingRuleRequest.js

@@ -3,7 +3,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.  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`.
+ * 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.  List endpoints additionally take a `?brandScope=own|shared|both` parameter to narrow further within whichever brand context already applies. `own` returns only rows assigned to that brand, and requires a brand context — a brand-bound token, a resolved brand session, or the `X-Zippendo-Brand` header above — otherwise `400`. `shared` returns only the organization-wide rows (equivalent to filtering `brandId=none`). The default, `both`, keeps the existing behaviour: a brand context sees its own rows plus the organization-wide ones. Set `X-Zippendo-Brand-Scope` as a client default to apply the same choice to every request instead of repeating the query parameter on each call — an explicit `brandScope` query parameter always wins over the header, and a blank header value is ignored.  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
@@ -68,6 +68,7 @@ function UpdateShippingRuleRequestFromJSONTyped(json, ignoreDiscriminator) {
         'documentPrinterId': json['documentPrinterId'] === undefined ? undefined : json['documentPrinterId'] === null ? null : json['documentPrinterId'],
         'returnShippingRuleId': json['returnShippingRuleId'] === undefined ? undefined : json['returnShippingRuleId'] === null ? null : json['returnShippingRuleId'],
         'autoCreateReturnShipment': json['autoCreateReturnShipment'] == null ? undefined : json['autoCreateReturnShipment'],
+        'brandId': json['brandId'] === undefined ? undefined : json['brandId'] === null ? null : json['brandId'],
     };
 }
 function UpdateShippingRuleRequestToJSON(json) {
@@ -103,5 +104,6 @@ function UpdateShippingRuleRequestToJSONTyped(value, ignoreDiscriminator = false
         'documentPrinterId': value['documentPrinterId'],
         'returnShippingRuleId': value['returnShippingRuleId'],
         'autoCreateReturnShipment': value['autoCreateReturnShipment'],
+        'brandId': value['brandId'],
     };
 }

package/dist/models/VerifyApiToken200Response.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.  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`.
+ * 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.  List endpoints additionally take a `?brandScope=own|shared|both` parameter to narrow further within whichever brand context already applies. `own` returns only rows assigned to that brand, and requires a brand context — a brand-bound token, a resolved brand session, or the `X-Zippendo-Brand` header above — otherwise `400`. `shared` returns only the organization-wide rows (equivalent to filtering `brandId=none`). The default, `both`, keeps the existing behaviour: a brand context sees its own rows plus the organization-wide ones. Set `X-Zippendo-Brand-Scope` as a client default to apply the same choice to every request instead of repeating the query parameter on each call — an explicit `brandScope` query parameter always wins over the header, and a blank header value is ignored.  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/models/VerifyApiToken200Response.js

@@ -3,7 +3,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.  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`.
+ * 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.  List endpoints additionally take a `?brandScope=own|shared|both` parameter to narrow further within whichever brand context already applies. `own` returns only rows assigned to that brand, and requires a brand context — a brand-bound token, a resolved brand session, or the `X-Zippendo-Brand` header above — otherwise `400`. `shared` returns only the organization-wide rows (equivalent to filtering `brandId=none`). The default, `both`, keeps the existing behaviour: a brand context sees its own rows plus the organization-wide ones. Set `X-Zippendo-Brand-Scope` as a client default to apply the same choice to every request instead of repeating the query parameter on each call — an explicit `brandScope` query parameter always wins over the header, and a blank header value is ignored.  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/models/VerifyApiTokenRequest.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.  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`.
+ * 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.  List endpoints additionally take a `?brandScope=own|shared|both` parameter to narrow further within whichever brand context already applies. `own` returns only rows assigned to that brand, and requires a brand context — a brand-bound token, a resolved brand session, or the `X-Zippendo-Brand` header above — otherwise `400`. `shared` returns only the organization-wide rows (equivalent to filtering `brandId=none`). The default, `both`, keeps the existing behaviour: a brand context sees its own rows plus the organization-wide ones. Set `X-Zippendo-Brand-Scope` as a client default to apply the same choice to every request instead of repeating the query parameter on each call — an explicit `brandScope` query parameter always wins over the header, and a blank header value is ignored.  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/models/VerifyApiTokenRequest.js

@@ -3,7 +3,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.  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`.
+ * 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.  List endpoints additionally take a `?brandScope=own|shared|both` parameter to narrow further within whichever brand context already applies. `own` returns only rows assigned to that brand, and requires a brand context — a brand-bound token, a resolved brand session, or the `X-Zippendo-Brand` header above — otherwise `400`. `shared` returns only the organization-wide rows (equivalent to filtering `brandId=none`). The default, `both`, keeps the existing behaviour: a brand context sees its own rows plus the organization-wide ones. Set `X-Zippendo-Brand-Scope` as a client default to apply the same choice to every request instead of repeating the query parameter on each call — an explicit `brandScope` query parameter always wins over the header, and a blank header value is ignored.  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/models/index.d.ts

@@ -66,6 +66,7 @@ export * from './GetBillingUsage200ResponseCurrentPeriod';
 export * from './GetBillingUsage200ResponseLimits';
 export * from './GetBillingUsage200ResponseLimitsTeamMembers';
 export * from './GetBillingUsage200ResponseShipments';
+export * from './GetBillingUsage200ResponseZippyMessages';
 export * from './GetOrder200Response';
 export * from './GetOrder200ResponseShipmentsInner';
 export * from './GetOrder200ResponseShippingRule';

package/dist/models/index.js

@@ -84,6 +84,7 @@ __exportStar(require("./GetBillingUsage200ResponseCurrentPeriod"), exports);
 __exportStar(require("./GetBillingUsage200ResponseLimits"), exports);
 __exportStar(require("./GetBillingUsage200ResponseLimitsTeamMembers"), exports);
 __exportStar(require("./GetBillingUsage200ResponseShipments"), exports);
+__exportStar(require("./GetBillingUsage200ResponseZippyMessages"), exports);
 __exportStar(require("./GetOrder200Response"), exports);
 __exportStar(require("./GetOrder200ResponseShipmentsInner"), exports);
 __exportStar(require("./GetOrder200ResponseShippingRule"), exports);

package/dist/runtime.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.  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`.
+ * 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.  List endpoints additionally take a `?brandScope=own|shared|both` parameter to narrow further within whichever brand context already applies. `own` returns only rows assigned to that brand, and requires a brand context — a brand-bound token, a resolved brand session, or the `X-Zippendo-Brand` header above — otherwise `400`. `shared` returns only the organization-wide rows (equivalent to filtering `brandId=none`). The default, `both`, keeps the existing behaviour: a brand context sees its own rows plus the organization-wide ones. Set `X-Zippendo-Brand-Scope` as a client default to apply the same choice to every request instead of repeating the query parameter on each call — an explicit `brandScope` query parameter always wins over the header, and a blank header value is ignored.  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/runtime.js

@@ -3,7 +3,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.  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`.
+ * 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.  List endpoints additionally take a `?brandScope=own|shared|both` parameter to narrow further within whichever brand context already applies. `own` returns only rows assigned to that brand, and requires a brand context — a brand-bound token, a resolved brand session, or the `X-Zippendo-Brand` header above — otherwise `400`. `shared` returns only the organization-wide rows (equivalent to filtering `brandId=none`). The default, `both`, keeps the existing behaviour: a brand context sees its own rows plus the organization-wide ones. Set `X-Zippendo-Brand-Scope` as a client default to apply the same choice to every request instead of repeating the query parameter on each call — an explicit `brandScope` query parameter always wins over the header, and a blank header value is ignored.  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/docs/AddressesApi.md

@@ -84,6 +84,7 @@ example().catch(console.error);
 | **201** | Default Response |  -  |
 | **400** | Default Response |  -  |
 | **403** | Default Response |  -  |
+| **404** | Default Response |  -  |
 
 [[Back to top]](#) [[Back to API list]](../README.md#api-endpoints) [[Back to Model list]](../README.md#models) [[Back to README]](../README.md)
 
@@ -242,7 +243,7 @@ example().catch(console.error);
 
 ## listAddresses
 
-> ListAddresses200Response listAddresses(orgId, page, limit, type)
+> ListAddresses200Response listAddresses(orgId, page, limit, type, brandId, brandScope)
 
 List addresses
 
@@ -274,6 +275,10 @@ async function example() {
     limit: 20,
     // 'sender' | 'pickup' | 'return' | Filter by address type (sender, pickup, return) (optional)
     type: sender,
+    // string | Filter by brand. Pass a brand ID, or \"none\" for records not assigned to any brand. (optional)
+    brandId: brnd_8f3kd92ld0,
+    // 'own' | 'shared' | 'both' | How the brand context narrows this list: \"own\" returns only rows assigned to the current brand (requires a brand session, a brand-bound token, or the X-Zippendo-Brand header), \"shared\" returns only unassigned organization-wide rows, \"both\" (default) returns both. The X-Zippendo-Brand-Scope header supplies a default when the parameter is omitted. For strictly brand-owned records (orders, shipments), a brand-scoped request combined with \"shared\" returns no rows, since those records are never visible organization-wide from within a brand context. (optional)
+    brandScope: own,
   } satisfies ListAddressesRequest;
 
   try {
@@ -297,6 +302,8 @@ example().catch(console.error);
 | **page** | `number` | Page number (1-based) | [Optional] [Defaults to `1`] |
 | **limit** | `number` | Items per page (max 100) | [Optional] [Defaults to `20`] |
 | **type** | `sender`, `pickup`, `return` | Filter by address type (sender, pickup, return) | [Optional] [Defaults to `undefined`] [Enum: sender, pickup, return] |
+| **brandId** | `string` | Filter by brand. Pass a brand ID, or \"none\" for records not assigned to any brand. | [Optional] [Defaults to `undefined`] |
+| **brandScope** | `own`, `shared`, `both` | How the brand context narrows this list: \"own\" returns only rows assigned to the current brand (requires a brand session, a brand-bound token, or the X-Zippendo-Brand header), \"shared\" returns only unassigned organization-wide rows, \"both\" (default) returns both. The X-Zippendo-Brand-Scope header supplies a default when the parameter is omitted. For strictly brand-owned records (orders, shipments), a brand-scoped request combined with \"shared\" returns no rows, since those records are never visible organization-wide from within a brand context. | [Optional] [Defaults to `undefined`] [Enum: own, shared, both] |
 
 ### Return type
 

package/docs/CarriersApi.md

@@ -403,7 +403,7 @@ example().catch(console.error);
 
 ## listCarriers
 
-> ListCarriers200Response listCarriers(orgId, page, limit)
+> ListCarriers200Response listCarriers(orgId, page, limit, brandId, brandScope)
 
 List carriers
 
@@ -433,6 +433,10 @@ async function example() {
     page: 1,
     // number | Items per page (max 100) (optional)
     limit: 20,
+    // string | Filter by brand. Pass a brand ID, or \"none\" for records not assigned to any brand. (optional)
+    brandId: brnd_8f3kd92ld0,
+    // 'own' | 'shared' | 'both' | How the brand context narrows this list: \"own\" returns only rows assigned to the current brand (requires a brand session, a brand-bound token, or the X-Zippendo-Brand header), \"shared\" returns only unassigned organization-wide rows, \"both\" (default) returns both. The X-Zippendo-Brand-Scope header supplies a default when the parameter is omitted. For strictly brand-owned records (orders, shipments), a brand-scoped request combined with \"shared\" returns no rows, since those records are never visible organization-wide from within a brand context. (optional)
+    brandScope: own,
   } satisfies ListCarriersRequest;
 
   try {
@@ -455,6 +459,8 @@ example().catch(console.error);
 | **orgId** | `string` | Organization ID | [Defaults to `undefined`] |
 | **page** | `number` | Page number (1-based) | [Optional] [Defaults to `1`] |
 | **limit** | `number` | Items per page (max 100) | [Optional] [Defaults to `20`] |
+| **brandId** | `string` | Filter by brand. Pass a brand ID, or \"none\" for records not assigned to any brand. | [Optional] [Defaults to `undefined`] |
+| **brandScope** | `own`, `shared`, `both` | How the brand context narrows this list: \"own\" returns only rows assigned to the current brand (requires a brand session, a brand-bound token, or the X-Zippendo-Brand header), \"shared\" returns only unassigned organization-wide rows, \"both\" (default) returns both. The X-Zippendo-Brand-Scope header supplies a default when the parameter is omitted. For strictly brand-owned records (orders, shipments), a brand-scoped request combined with \"shared\" returns no rows, since those records are never visible organization-wide from within a brand context. | [Optional] [Defaults to `undefined`] [Enum: own, shared, both] |
 
 ### Return type
 

package/docs/ConnectCarrierRequest.md

@@ -9,6 +9,7 @@ Name | Type
 `name` | string
 `carrierSlug` | string
 `config` | [{ [key: string]: ListCarriers200ResponseDataInnerConfigValue; }](ListCarriers200ResponseDataInnerConfigValue.md)
+`brandId` | string
 
 ## Example
 
@@ -20,6 +21,7 @@ const example = {
   "name": PostNord,
   "carrierSlug": postnord,
   "config": {"customerNumber":"123456"},
+  "brandId": brnd_8f3kd92ld0,
 } satisfies ConnectCarrierRequest
 
 console.log(example)

package/docs/CreateAddressRequest.md

@@ -18,6 +18,7 @@ Name | Type
 `email` | string
 `customs` | { [key: string]: string; }
 `addressTypes` | Array<string>
+`brandId` | string
 
 ## Example
 
@@ -38,6 +39,7 @@ const example = {
   "email": lager@example.dk,
   "customs": {"eori":"DK12345678"},
   "addressTypes": ["sender"],
+  "brandId": brnd_8f3kd92ld0,
 } satisfies CreateAddressRequest
 
 console.log(example)

package/docs/CreateOrgWebhook201Response.md

@@ -12,6 +12,7 @@ Name | Type
 `secret` | string
 `events` | Array<string>
 `isActive` | boolean
+`brandId` | string
 `createdAt` | string
 `updatedAt` | string
 
@@ -28,6 +29,7 @@ const example = {
   "secret": whsec_8f3a1c2b9d4e5f6a,
   "events": ["shipment.created"],
   "isActive": true,
+  "brandId": brnd_8f3kd92ld0,
   "createdAt": 2026-06-01T09:30:00.000Z,
   "updatedAt": 2026-06-10T11:15:00.000Z,
 } satisfies CreateOrgWebhook201Response

package/docs/CreateOrgWebhookRequest.md

@@ -10,6 +10,7 @@ Name | Type
 `url` | string
 `events` | Array<string>
 `isActive` | boolean
+`brandId` | string
 
 ## Example
 
@@ -22,6 +23,7 @@ const example = {
   "url": https://hooks.example.dk/zippendo,
   "events": ["shipment.created","tracking.updated"],
   "isActive": true,
+  "brandId": brnd_8f3kd92ld0,
 } satisfies CreateOrgWebhookRequest
 
 console.log(example)

package/docs/CreateShippingRule201Response.md

@@ -33,6 +33,7 @@ Name | Type
 `returnShippingRuleId` | string
 `autoCreateReturnShipment` | boolean
 `orgId` | string
+`brandId` | string
 `createdAt` | string
 `updatedAt` | string
 
@@ -70,6 +71,7 @@ const example = {
   "returnShippingRuleId": null,
   "autoCreateReturnShipment": false,
   "orgId": org_01HZX9K2QF,
+  "brandId": brnd_8f3kd92ld0,
   "createdAt": 2026-06-22T09:00:00.000Z,
   "updatedAt": 2026-06-22T09:00:00.000Z,
 } satisfies CreateShippingRule201Response

package/docs/CreateShippingRuleRequest.md

@@ -31,6 +31,7 @@ Name | Type
 `documentPrinterId` | string
 `returnShippingRuleId` | string
 `autoCreateReturnShipment` | boolean
+`brandId` | string
 
 ## Example
 
@@ -64,6 +65,7 @@ const example = {
   "documentPrinterId": null,
   "returnShippingRuleId": null,
   "autoCreateReturnShipment": false,
+  "brandId": brnd_8f3kd92ld0,
 } satisfies CreateShippingRuleRequest
 
 console.log(example)

package/docs/GetBillingUsage200Response.md

@@ -10,6 +10,7 @@ Name | Type
 `shipments` | [GetBillingUsage200ResponseShipments](GetBillingUsage200ResponseShipments.md)
 `limits` | [GetBillingUsage200ResponseLimits](GetBillingUsage200ResponseLimits.md)
 `addOns` | [Array<GetBillingUsage200ResponseAddOnsInner>](GetBillingUsage200ResponseAddOnsInner.md)
+`zippyMessages` | [GetBillingUsage200ResponseZippyMessages](GetBillingUsage200ResponseZippyMessages.md)
 
 ## Example
 
@@ -22,6 +23,7 @@ const example = {
   "shipments": null,
   "limits": null,
   "addOns": [],
+  "zippyMessages": null,
 } satisfies GetBillingUsage200Response
 
 console.log(example)

package/docs/GetBillingUsage200ResponseZippyMessages.md

@@ -0,0 +1,37 @@
+
+# GetBillingUsage200ResponseZippyMessages
+
+Zippy AI message usage this period (present when Zippy access is enabled)
+
+## Properties
+
+Name | Type
+------------ | -------------
+`used` | number
+`charges` | number
+
+## Example
+
+```typescript
+import type { GetBillingUsage200ResponseZippyMessages } from '@zippendo/sdk'
+
+// TODO: Update the object below with actual values
+const example = {
+  "used": 42,
+  "charges": 4158,
+} satisfies GetBillingUsage200ResponseZippyMessages
+
+console.log(example)
+
+// Convert the instance to a JSON string
+const exampleJSON: string = JSON.stringify(example)
+console.log(exampleJSON)
+
+// Parse the JSON string back to an object
+const exampleParsed = JSON.parse(exampleJSON) as GetBillingUsage200ResponseZippyMessages
+console.log(exampleParsed)
+```
+
+[[Back to top]](#) [[Back to API list]](../README.md#api-endpoints) [[Back to Model list]](../README.md#models) [[Back to README]](../README.md)
+
+

package/docs/ListAddresses200ResponseDataInner.md

@@ -20,6 +20,7 @@ Name | Type
 `customs` | { [key: string]: string; }
 `addressTypes` | Array<string>
 `orgId` | string
+`brandId` | string
 `createdAt` | string
 `updatedAt` | string
 
@@ -44,6 +45,7 @@ const example = {
   "customs": {"eori":"DK12345678"},
   "addressTypes": ["sender"],
   "orgId": org_01HZX9K2QF,
+  "brandId": brnd_8f3kd92ld0,
   "createdAt": 2026-06-22T09:00:00.000Z,
   "updatedAt": 2026-06-22T09:00:00.000Z,
 } satisfies ListAddresses200ResponseDataInner

package/docs/ListCarriers200ResponseDataInner.md

@@ -11,6 +11,7 @@ Name | Type
 `carrierSlug` | string
 `config` | [{ [key: string]: ListCarriers200ResponseDataInnerConfigValue; }](ListCarriers200ResponseDataInnerConfigValue.md)
 `orgId` | string
+`brandId` | string
 `createdAt` | string
 `updatedAt` | string
 `logo` | string
@@ -30,6 +31,7 @@ const example = {
   "carrierSlug": postnord,
   "config": {"customerNumber":"123456"},
   "orgId": org_01HZX9K2QF,
+  "brandId": brnd_8f3kd92ld0,
   "createdAt": 2026-06-22T09:00:00.000Z,
   "updatedAt": 2026-06-22T09:00:00.000Z,
   "logo": https://cdn.zippendo.com/logos/postnord.svg,

package/docs/ListOrgWebhooks200ResponseDataInner.md

@@ -11,6 +11,7 @@ Name | Type
 `url` | string
 `events` | Array<string>
 `isActive` | boolean
+`brandId` | string
 `createdAt` | string
 `updatedAt` | string
 
@@ -26,6 +27,7 @@ const example = {
   "url": https://hooks.example.dk/zippendo,
   "events": ["shipment.created"],
   "isActive": true,
+  "brandId": brnd_8f3kd92ld0,
   "createdAt": 2026-06-01T09:30:00.000Z,
   "updatedAt": 2026-06-10T11:15:00.000Z,
 } satisfies ListOrgWebhooks200ResponseDataInner

package/docs/ListShipments200ResponseDataInnerAddress.md

@@ -20,6 +20,7 @@ Name | Type
 `customs` | { [key: string]: string; }
 `addressTypes` | Array<string>
 `orgId` | string
+`brandId` | string
 `createdAt` | string
 `updatedAt` | string
 
@@ -44,6 +45,7 @@ const example = {
   "customs": {"eori":"DK12345678"},
   "addressTypes": ["sender"],
   "orgId": org_01HZX9K2QF,
+  "brandId": brnd_8f3kd92ld0,
   "createdAt": 2026-06-22T09:00:00.000Z,
   "updatedAt": 2026-06-22T09:00:00.000Z,
 } satisfies ListShipments200ResponseDataInnerAddress

package/docs/ListShippingRules200ResponseDataInner.md

@@ -33,6 +33,7 @@ Name | Type
 `returnShippingRuleId` | string
 `autoCreateReturnShipment` | boolean
 `orgId` | string
+`brandId` | string
 `createdAt` | string
 `updatedAt` | string
 `carrier` | [ListShippingRules200ResponseDataInnerCarrier](ListShippingRules200ResponseDataInnerCarrier.md)
@@ -75,6 +76,7 @@ const example = {
   "returnShippingRuleId": null,
   "autoCreateReturnShipment": false,
   "orgId": org_01HZX9K2QF,
+  "brandId": brnd_8f3kd92ld0,
   "createdAt": 2026-06-22T09:00:00.000Z,
   "updatedAt": 2026-06-22T09:00:00.000Z,
   "carrier": null,

package/docs/ListShippingRules200ResponseDataInnerCarrier.md

@@ -11,6 +11,7 @@ Name | Type
 `carrierSlug` | string
 `config` | [{ [key: string]: ListCarriers200ResponseDataInnerConfigValue; }](ListCarriers200ResponseDataInnerConfigValue.md)
 `orgId` | string
+`brandId` | string
 `createdAt` | string
 `updatedAt` | string
 
@@ -26,6 +27,7 @@ const example = {
   "carrierSlug": postnord,
   "config": {"customerNumber":"123456"},
   "orgId": org_01HZX9K2QF,
+  "brandId": brnd_8f3kd92ld0,
   "createdAt": 2026-06-22T09:00:00.000Z,
   "updatedAt": 2026-06-22T09:00:00.000Z,
 } satisfies ListShippingRules200ResponseDataInnerCarrier

package/docs/OrdersApi.md

@@ -244,7 +244,7 @@ example().catch(console.error);
 
 ## listOrders
 
-> ListOrders200Response listOrders(orgId, page, limit, brandId, status, orderChannelId, search)
+> ListOrders200Response listOrders(orgId, page, limit, brandId, brandScope, status, orderChannelId, search)
 
 List orders
 
@@ -276,6 +276,8 @@ async function example() {
     limit: 20,
     // string | Filter by brand. Pass a brand ID, or \"none\" for records not assigned to any brand. (optional)
     brandId: brnd_8f3kd92ld0,
+    // 'own' | 'shared' | 'both' | How the brand context narrows this list: \"own\" returns only rows assigned to the current brand (requires a brand session, a brand-bound token, or the X-Zippendo-Brand header), \"shared\" returns only unassigned organization-wide rows, \"both\" (default) returns both. The X-Zippendo-Brand-Scope header supplies a default when the parameter is omitted. For strictly brand-owned records (orders, shipments), a brand-scoped request combined with \"shared\" returns no rows, since those records are never visible organization-wide from within a brand context. (optional)
+    brandScope: own,
     // 'pending' | 'processing' | 'partially_fulfilled' | 'fulfilled' | 'error' | 'cancelled' | Order fulfilment status derived from its shipments. (optional)
     status: processing,
     // string | Filter by order channel ID. (optional)
@@ -305,6 +307,7 @@ example().catch(console.error);
 | **page** | `number` | Page number (1-based) | [Optional] [Defaults to `1`] |
 | **limit** | `number` | Items per page (max 100) | [Optional] [Defaults to `20`] |
 | **brandId** | `string` | Filter by brand. Pass a brand ID, or \"none\" for records not assigned to any brand. | [Optional] [Defaults to `undefined`] |
+| **brandScope** | `own`, `shared`, `both` | How the brand context narrows this list: \"own\" returns only rows assigned to the current brand (requires a brand session, a brand-bound token, or the X-Zippendo-Brand header), \"shared\" returns only unassigned organization-wide rows, \"both\" (default) returns both. The X-Zippendo-Brand-Scope header supplies a default when the parameter is omitted. For strictly brand-owned records (orders, shipments), a brand-scoped request combined with \"shared\" returns no rows, since those records are never visible organization-wide from within a brand context. | [Optional] [Defaults to `undefined`] [Enum: own, shared, both] |
 | **status** | `pending`, `processing`, `partially_fulfilled`, `fulfilled`, `error`, `cancelled` | Order fulfilment status derived from its shipments. | [Optional] [Defaults to `undefined`] [Enum: pending, processing, partially_fulfilled, fulfilled, error, cancelled] |
 | **orderChannelId** | `string` | Filter by order channel ID. | [Optional] [Defaults to `undefined`] |
 | **search** | `string` | Search by order number or customer name/email. | [Optional] [Defaults to `undefined`] |

package/docs/RulesApi.md

@@ -84,6 +84,7 @@ example().catch(console.error);
 | **201** | Default Response |  -  |
 | **400** | Default Response |  -  |
 | **403** | Default Response |  -  |
+| **404** | Default Response |  -  |
 
 [[Back to top]](#) [[Back to API list]](../README.md#api-endpoints) [[Back to Model list]](../README.md#models) [[Back to README]](../README.md)
 
@@ -242,7 +243,7 @@ example().catch(console.error);
 
 ## listShippingRules
 
-> ListShippingRules200Response listShippingRules(orgId, page, limit)
+> ListShippingRules200Response listShippingRules(orgId, page, limit, brandId, brandScope)
 
 List shipping rules
 
@@ -272,6 +273,10 @@ async function example() {
     page: 1,
     // number | Items per page (max 100) (optional)
     limit: 20,
+    // string | Filter by brand. Pass a brand ID, or \"none\" for records not assigned to any brand. (optional)
+    brandId: brnd_8f3kd92ld0,
+    // 'own' | 'shared' | 'both' | How the brand context narrows this list: \"own\" returns only rows assigned to the current brand (requires a brand session, a brand-bound token, or the X-Zippendo-Brand header), \"shared\" returns only unassigned organization-wide rows, \"both\" (default) returns both. The X-Zippendo-Brand-Scope header supplies a default when the parameter is omitted. For strictly brand-owned records (orders, shipments), a brand-scoped request combined with \"shared\" returns no rows, since those records are never visible organization-wide from within a brand context. (optional)
+    brandScope: own,
   } satisfies ListShippingRulesRequest;
 
   try {
@@ -294,6 +299,8 @@ example().catch(console.error);
 | **orgId** | `string` | Organization ID | [Defaults to `undefined`] |
 | **page** | `number` | Page number (1-based) | [Optional] [Defaults to `1`] |
 | **limit** | `number` | Items per page (max 100) | [Optional] [Defaults to `20`] |
+| **brandId** | `string` | Filter by brand. Pass a brand ID, or \"none\" for records not assigned to any brand. | [Optional] [Defaults to `undefined`] |
+| **brandScope** | `own`, `shared`, `both` | How the brand context narrows this list: \"own\" returns only rows assigned to the current brand (requires a brand session, a brand-bound token, or the X-Zippendo-Brand header), \"shared\" returns only unassigned organization-wide rows, \"both\" (default) returns both. The X-Zippendo-Brand-Scope header supplies a default when the parameter is omitted. For strictly brand-owned records (orders, shipments), a brand-scoped request combined with \"shared\" returns no rows, since those records are never visible organization-wide from within a brand context. | [Optional] [Defaults to `undefined`] [Enum: own, shared, both] |
 
 ### Return type