zippendo 1.1.2 → 1.1.3

data/lib/zippendo/api/carriers_api.rb

@@ -1,7 +1,7 @@
 =begin
 #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
@@ -392,6 +392,8 @@ module Zippendo
     # @param [Hash] opts the optional parameters
     # @option opts [Integer] :page Page number (1-based) (default to 1)
     # @option opts [Integer] :limit Items per page (max 100) (default to 20)
+    # @option opts [String] :brand_id Filter by brand. Pass a brand ID, or \"none\" for records not assigned to any brand.
+    # @option opts [String] :brand_scope 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.
     # @return [ListCarriers200Response]
     def list_carriers(org_id, opts = {})
       data, _status_code, _headers = list_carriers_with_http_info(org_id, opts)
@@ -404,6 +406,8 @@ module Zippendo
     # @param [Hash] opts the optional parameters
     # @option opts [Integer] :page Page number (1-based) (default to 1)
     # @option opts [Integer] :limit Items per page (max 100) (default to 20)
+    # @option opts [String] :brand_id Filter by brand. Pass a brand ID, or \"none\" for records not assigned to any brand.
+    # @option opts [String] :brand_scope 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.
     # @return [Array<(ListCarriers200Response, Integer, Hash)>] ListCarriers200Response data, response status code and response headers
     def list_carriers_with_http_info(org_id, opts = {})
       if @api_client.config.debugging
@@ -429,6 +433,10 @@ module Zippendo
         fail ArgumentError, 'invalid value for "opts[:"limit"]" when calling CarriersApi.list_carriers, must be greater than or equal to 1.'
       end
 
+      allowable_values = ["own", "shared", "both"]
+      if @api_client.config.client_side_validation && opts[:'brand_scope'] && !allowable_values.include?(opts[:'brand_scope'])
+        fail ArgumentError, "invalid value for \"brand_scope\", must be one of #{allowable_values}"
+      end
       # resource path
       local_var_path = '/orgs/{orgId}/carriers'.sub('{orgId}', CGI.escape(org_id.to_s))
 
@@ -436,6 +444,8 @@ module Zippendo
       query_params = opts[:query_params] || {}
       query_params[:'page'] = opts[:'page'] if !opts[:'page'].nil?
       query_params[:'limit'] = opts[:'limit'] if !opts[:'limit'].nil?
+      query_params[:'brandId'] = opts[:'brand_id'] if !opts[:'brand_id'].nil?
+      query_params[:'brandScope'] = opts[:'brand_scope'] if !opts[:'brand_scope'].nil?
 
       # header parameters
       header_params = opts[:header_params] || {}

data/lib/zippendo/api/orders_api.rb

@@ -1,7 +1,7 @@
 =begin
 #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
@@ -238,6 +238,7 @@ module Zippendo
     # @option opts [Integer] :page Page number (1-based) (default to 1)
     # @option opts [Integer] :limit Items per page (max 100) (default to 20)
     # @option opts [String] :brand_id Filter by brand. Pass a brand ID, or \"none\" for records not assigned to any brand.
+    # @option opts [String] :brand_scope 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.
     # @option opts [String] :status Order fulfilment status derived from its shipments.
     # @option opts [String] :order_channel_id Filter by order channel ID.
     # @option opts [String] :search Search by order number or customer name/email.
@@ -254,6 +255,7 @@ module Zippendo
     # @option opts [Integer] :page Page number (1-based) (default to 1)
     # @option opts [Integer] :limit Items per page (max 100) (default to 20)
     # @option opts [String] :brand_id Filter by brand. Pass a brand ID, or \"none\" for records not assigned to any brand.
+    # @option opts [String] :brand_scope 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.
     # @option opts [String] :status Order fulfilment status derived from its shipments.
     # @option opts [String] :order_channel_id Filter by order channel ID.
     # @option opts [String] :search Search by order number or customer name/email.
@@ -282,6 +284,10 @@ module Zippendo
         fail ArgumentError, 'invalid value for "opts[:"limit"]" when calling OrdersApi.list_orders, must be greater than or equal to 1.'
       end
 
+      allowable_values = ["own", "shared", "both"]
+      if @api_client.config.client_side_validation && opts[:'brand_scope'] && !allowable_values.include?(opts[:'brand_scope'])
+        fail ArgumentError, "invalid value for \"brand_scope\", must be one of #{allowable_values}"
+      end
       allowable_values = ["pending", "processing", "partially_fulfilled", "fulfilled", "error", "cancelled"]
       if @api_client.config.client_side_validation && opts[:'status'] && !allowable_values.include?(opts[:'status'])
         fail ArgumentError, "invalid value for \"status\", must be one of #{allowable_values}"
@@ -294,6 +300,7 @@ module Zippendo
       query_params[:'page'] = opts[:'page'] if !opts[:'page'].nil?
       query_params[:'limit'] = opts[:'limit'] if !opts[:'limit'].nil?
       query_params[:'brandId'] = opts[:'brand_id'] if !opts[:'brand_id'].nil?
+      query_params[:'brandScope'] = opts[:'brand_scope'] if !opts[:'brand_scope'].nil?
       query_params[:'status'] = opts[:'status'] if !opts[:'status'].nil?
       query_params[:'orderChannelId'] = opts[:'order_channel_id'] if !opts[:'order_channel_id'].nil?
       query_params[:'search'] = opts[:'search'] if !opts[:'search'].nil?

data/lib/zippendo/api/orgs_api.rb

@@ -1,7 +1,7 @@
 =begin
 #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

data/lib/zippendo/api/quotes_api.rb

@@ -1,7 +1,7 @@
 =begin
 #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

data/lib/zippendo/api/rules_api.rb

@@ -1,7 +1,7 @@
 =begin
 #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
@@ -237,6 +237,8 @@ module Zippendo
     # @param [Hash] opts the optional parameters
     # @option opts [Integer] :page Page number (1-based) (default to 1)
     # @option opts [Integer] :limit Items per page (max 100) (default to 20)
+    # @option opts [String] :brand_id Filter by brand. Pass a brand ID, or \"none\" for records not assigned to any brand.
+    # @option opts [String] :brand_scope 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.
     # @return [ListShippingRules200Response]
     def list_shipping_rules(org_id, opts = {})
       data, _status_code, _headers = list_shipping_rules_with_http_info(org_id, opts)
@@ -249,6 +251,8 @@ module Zippendo
     # @param [Hash] opts the optional parameters
     # @option opts [Integer] :page Page number (1-based) (default to 1)
     # @option opts [Integer] :limit Items per page (max 100) (default to 20)
+    # @option opts [String] :brand_id Filter by brand. Pass a brand ID, or \"none\" for records not assigned to any brand.
+    # @option opts [String] :brand_scope 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.
     # @return [Array<(ListShippingRules200Response, Integer, Hash)>] ListShippingRules200Response data, response status code and response headers
     def list_shipping_rules_with_http_info(org_id, opts = {})
       if @api_client.config.debugging
@@ -274,6 +278,10 @@ module Zippendo
         fail ArgumentError, 'invalid value for "opts[:"limit"]" when calling RulesApi.list_shipping_rules, must be greater than or equal to 1.'
       end
 
+      allowable_values = ["own", "shared", "both"]
+      if @api_client.config.client_side_validation && opts[:'brand_scope'] && !allowable_values.include?(opts[:'brand_scope'])
+        fail ArgumentError, "invalid value for \"brand_scope\", must be one of #{allowable_values}"
+      end
       # resource path
       local_var_path = '/orgs/{orgId}/shipping-rules'.sub('{orgId}', CGI.escape(org_id.to_s))
 
@@ -281,6 +289,8 @@ module Zippendo
       query_params = opts[:query_params] || {}
       query_params[:'page'] = opts[:'page'] if !opts[:'page'].nil?
       query_params[:'limit'] = opts[:'limit'] if !opts[:'limit'].nil?
+      query_params[:'brandId'] = opts[:'brand_id'] if !opts[:'brand_id'].nil?
+      query_params[:'brandScope'] = opts[:'brand_scope'] if !opts[:'brand_scope'].nil?
 
       # header parameters
       header_params = opts[:header_params] || {}

data/lib/zippendo/api/shipments_api.rb

@@ -1,7 +1,7 @@
 =begin
 #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
@@ -544,6 +544,7 @@ module Zippendo
     # @option opts [Integer] :page Page number (1-based) (default to 1)
     # @option opts [Integer] :limit Items per page (max 100) (default to 20)
     # @option opts [String] :brand_id Filter by brand. Pass a brand ID, or \"none\" for records not assigned to any brand.
+    # @option opts [String] :brand_scope 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.
     # @return [ListShipments200Response]
     def list_shipments(org_id, opts = {})
       data, _status_code, _headers = list_shipments_with_http_info(org_id, opts)
@@ -557,6 +558,7 @@ module Zippendo
     # @option opts [Integer] :page Page number (1-based) (default to 1)
     # @option opts [Integer] :limit Items per page (max 100) (default to 20)
     # @option opts [String] :brand_id Filter by brand. Pass a brand ID, or \"none\" for records not assigned to any brand.
+    # @option opts [String] :brand_scope 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.
     # @return [Array<(ListShipments200Response, Integer, Hash)>] ListShipments200Response data, response status code and response headers
     def list_shipments_with_http_info(org_id, opts = {})
       if @api_client.config.debugging
@@ -582,6 +584,10 @@ module Zippendo
         fail ArgumentError, 'invalid value for "opts[:"limit"]" when calling ShipmentsApi.list_shipments, must be greater than or equal to 1.'
       end
 
+      allowable_values = ["own", "shared", "both"]
+      if @api_client.config.client_side_validation && opts[:'brand_scope'] && !allowable_values.include?(opts[:'brand_scope'])
+        fail ArgumentError, "invalid value for \"brand_scope\", must be one of #{allowable_values}"
+      end
       # resource path
       local_var_path = '/orgs/{orgId}/shipments'.sub('{orgId}', CGI.escape(org_id.to_s))
 
@@ -590,6 +596,7 @@ module Zippendo
       query_params[:'page'] = opts[:'page'] if !opts[:'page'].nil?
       query_params[:'limit'] = opts[:'limit'] if !opts[:'limit'].nil?
       query_params[:'brandId'] = opts[:'brand_id'] if !opts[:'brand_id'].nil?
+      query_params[:'brandScope'] = opts[:'brand_scope'] if !opts[:'brand_scope'].nil?
 
       # header parameters
       header_params = opts[:header_params] || {}

data/lib/zippendo/api/system_api.rb

@@ -1,7 +1,7 @@
 =begin
 #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

data/lib/zippendo/api/tokens_api.rb

@@ -1,7 +1,7 @@
 =begin
 #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

data/lib/zippendo/api/webhooks_api.rb

@@ -1,7 +1,7 @@
 =begin
 #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
@@ -328,6 +328,8 @@ module Zippendo
     # @param [Hash] opts the optional parameters
     # @option opts [Integer] :page Page number (1-based) (default to 1)
     # @option opts [Integer] :limit Items per page (max 100) (default to 20)
+    # @option opts [String] :brand_id Filter by brand. Pass a brand ID, or \"none\" for records not assigned to any brand.
+    # @option opts [String] :brand_scope 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.
     # @return [ListOrgWebhooks200Response]
     def list_org_webhooks(org_id, opts = {})
       data, _status_code, _headers = list_org_webhooks_with_http_info(org_id, opts)
@@ -340,6 +342,8 @@ module Zippendo
     # @param [Hash] opts the optional parameters
     # @option opts [Integer] :page Page number (1-based) (default to 1)
     # @option opts [Integer] :limit Items per page (max 100) (default to 20)
+    # @option opts [String] :brand_id Filter by brand. Pass a brand ID, or \"none\" for records not assigned to any brand.
+    # @option opts [String] :brand_scope 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.
     # @return [Array<(ListOrgWebhooks200Response, Integer, Hash)>] ListOrgWebhooks200Response data, response status code and response headers
     def list_org_webhooks_with_http_info(org_id, opts = {})
       if @api_client.config.debugging
@@ -365,6 +369,10 @@ module Zippendo
         fail ArgumentError, 'invalid value for "opts[:"limit"]" when calling WebhooksApi.list_org_webhooks, must be greater than or equal to 1.'
       end
 
+      allowable_values = ["own", "shared", "both"]
+      if @api_client.config.client_side_validation && opts[:'brand_scope'] && !allowable_values.include?(opts[:'brand_scope'])
+        fail ArgumentError, "invalid value for \"brand_scope\", must be one of #{allowable_values}"
+      end
       # resource path
       local_var_path = '/orgs/{orgId}/webhooks'.sub('{orgId}', CGI.escape(org_id.to_s))
 
@@ -372,6 +380,8 @@ module Zippendo
       query_params = opts[:query_params] || {}
       query_params[:'page'] = opts[:'page'] if !opts[:'page'].nil?
       query_params[:'limit'] = opts[:'limit'] if !opts[:'limit'].nil?
+      query_params[:'brandId'] = opts[:'brand_id'] if !opts[:'brand_id'].nil?
+      query_params[:'brandScope'] = opts[:'brand_scope'] if !opts[:'brand_scope'].nil?
 
       # header parameters
       header_params = opts[:header_params] || {}

data/lib/zippendo/api_client.rb

@@ -1,7 +1,7 @@
 =begin
 #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

data/lib/zippendo/api_error.rb

@@ -1,7 +1,7 @@
 =begin
 #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

data/lib/zippendo/api_model_base.rb

@@ -1,7 +1,7 @@
 =begin
 #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

data/lib/zippendo/configuration.rb

@@ -1,7 +1,7 @@
 =begin
 #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

data/lib/zippendo/models/batch_send_shipments200_response.rb

@@ -1,7 +1,7 @@
 =begin
 #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

data/lib/zippendo/models/batch_send_shipments200_response_results_inner.rb

@@ -1,7 +1,7 @@
 =begin
 #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
@@ -157,7 +157,7 @@ module Zippendo
       return false if @status.nil?
       status_validator = EnumAttributeValidator.new('String', ["sent", "failed"])
       return false unless status_validator.valid?(@status)
-      code_validator = EnumAttributeValidator.new('String', ["INTERNAL_ERROR", "BAD_REQUEST", "VALIDATION_FAILED", "UNAUTHORIZED", "FORBIDDEN", "NOT_FOUND", "CONFLICT", "RATE_LIMITED", "PAYLOAD_TOO_LARGE", "IMAGE_DIMENSIONS_EXCEEDED", "NOT_IMPLEMENTED", "AUTH_INVALID_CREDENTIALS", "AUTH_TOKEN_INVALID", "AUTH_TOKEN_EXPIRED", "AUTH_EMAIL_NOT_VERIFIED", "AUTH_EMAIL_EXISTS", "AUTH_OAUTH_FAILED", "AUTH_SIGNUP_NOT_ALLOWED", "AUTH_VERIFICATION_FAILED", "AUTH_RESET_TOKEN_INVALID", "AUTH_MFA_REQUIRED", "AUTH_MFA_INVALID_CODE", "AUTH_MFA_ALREADY_ENABLED", "AUTH_MFA_NOT_ENABLED", "SESSION_REQUIRED", "ORG_NOT_FOUND", "ORG_ACCESS_DENIED", "ORG_DISABLED", "ORG_SLUG_EXISTS", "BRAND_NOT_FOUND", "BRAND_ACCESS_DENIED", "BRAND_SLUG_EXISTS", "BRAND_HAS_RECORDS", "USER_NOT_FOUND", "USER_EXISTS", "MEMBER_NOT_FOUND", "MEMBER_SELF_BRAND_RESTRICTION", "ROLE_NOT_FOUND", "ROLE_NAME_EXISTS", "ROLE_IN_USE", "MEMBER_EXISTS", "INVITATION_NOT_FOUND", "INVITATION_EXPIRED", "INVITATION_ALREADY_SENT", "INVITATION_EMAIL_FAILED", "TOKEN_NOT_FOUND", "BILLING_PAYMENT_FAILED", "BILLING_NO_SUBSCRIPTION", "BILLING_TAX_ID_INVALID", "BILLING_PLAN_INVALID", "BILLING_OPERATION_FAILED", "FEATURE_NOT_AVAILABLE", "RESOURCE_LIMIT_REACHED", "PLAN_LIMITS_EXCEEDED", "NO_SUBSCRIPTION", "SUBSCRIPTION_INACTIVE", "BILLING_MANAGED_BY_SHOPIFY", "BILLING_CHECKOUT_REQUIRED", "SHIPMENT_NOT_FOUND", "SHIPMENT_DOCUMENT_NOT_FOUND", "SHIPMENT_ALREADY_SENT", "SHIPMENT_INVALID_STATE", "PARCEL_NOT_FOUND", "PARCEL_INVALID_SPLIT", "PICKUP_NOT_FOUND", "PICKUP_FAILED", "CARRIER_ERROR", "CARRIER_AUTH_FAILED", "CARRIER_NOT_FOUND", "CARRIER_PRODUCT_NOT_FOUND", "CARRIER_CONFIG_INVALID", "CARRIER_PARAMETER_INVALID", "CARRIER_SERVER_UNAVAILABLE", "CARRIER_GLS_WRONG_ADDRESS", "CARRIER_DAO_INVALID_POSTAL_CODE", "CARRIER_POSTNORD_BOOKING_FAILED", "CARRIER_FEDEX_BOOKING_FAILED", "CARRIER_DHL_EXPRESS_BOOKING_FAILED", "CARRIER_UPS_BOOKING_FAILED", "CARRIER_MATKAHUOLTO_BOOKING_FAILED", "CARRIER_TRACKING_WEBHOOK_REGISTRATION_FAILED", "CARRIER_CUSTOMS_UNSUPPORTED_PRODUCT", "CARRIER_CUSTOMS_INCOMPLETE", "CARRIER_REQUEST_NOT_FOUND", "CARRIER_REQUEST_LOCKED", "CARRIER_REQUEST_DISPATCH_FAILED", "SHIPPING_RULE_NOT_FOUND", "SHIPPING_RULE_INVALID", "ADDRESS_NOT_FOUND", "ORDER_NOT_FOUND", "ORDER_CHANNEL_NOT_FOUND", "ORDER_CHANNEL_CONFIG_INVALID", "INTEGRATION_NOT_CONFIGURED", "INSTALLATION_NOT_FOUND", "WEBHOOK_SIGNATURE_INVALID", "WEBHOOK_PAYLOAD_INVALID", "SHOPIFY_PENDING_INSTALL_NOT_FOUND", "SHOPIFY_PENDING_INSTALL_EXPIRED", "SHOP_ALREADY_CONNECTED", "SHOP_CLAIMED_BY_ANOTHER_ORG", "WOOCOMMERCE_CONNECT_FAILED", "WOOCOMMERCE_AUTH_STATE_INVALID", "CHECKOUT_TOKEN_INVALID", "ORDER_CHANNEL_TYPE_UNSUPPORTED", "PRINTER_NOT_FOUND", "PRINTER_OFFLINE", "PRINTER_AUTH_TIMEOUT", "PRINTER_JOB_NOT_FOUND", "ORG_INTEGRATION_NOT_FOUND", "ORG_WEBHOOK_NOT_FOUND", "AUTOMATION_NOT_FOUND", "AUTOMATION_INVALID", "ZIPPY_DISABLED", "CONVERSATION_NOT_FOUND", "ADMIN_FORBIDDEN", "JOB_HANDLER_NOT_REGISTERED", "JOB_QUEUE_NOT_CONFIGURED", "JOB_ENQUEUE_FAILED", "JOB_PAYLOAD_INVALID", "EMAIL_SEND_FAILED", "INTEGRATION_DELIVERY_FAILED", "WEBHOOK_DELIVERY_FAILED", "DOCUMENT_GENERATION_FAILED", "AI_UNAVAILABLE", "MIGRATION_PROVIDER_UNKNOWN", "MIGRATION_SOURCE_TOKEN_INVALID", "MIGRATION_SOURCE_UNREACHABLE", "MIGRATION_NOT_FOUND", "MIGRATION_IN_PROGRESS"])
+      code_validator = EnumAttributeValidator.new('String', ["INTERNAL_ERROR", "BAD_REQUEST", "VALIDATION_FAILED", "UNAUTHORIZED", "FORBIDDEN", "NOT_FOUND", "CONFLICT", "RATE_LIMITED", "PAYLOAD_TOO_LARGE", "IMAGE_DIMENSIONS_EXCEEDED", "NOT_IMPLEMENTED", "AUTH_INVALID_CREDENTIALS", "AUTH_TOKEN_INVALID", "AUTH_TOKEN_EXPIRED", "AUTH_EMAIL_NOT_VERIFIED", "AUTH_EMAIL_EXISTS", "AUTH_OAUTH_FAILED", "AUTH_SIGNUP_NOT_ALLOWED", "AUTH_VERIFICATION_FAILED", "AUTH_RESET_TOKEN_INVALID", "AUTH_MFA_REQUIRED", "AUTH_MFA_INVALID_CODE", "AUTH_MFA_ALREADY_ENABLED", "AUTH_MFA_NOT_ENABLED", "SESSION_REQUIRED", "ORG_NOT_FOUND", "ORG_ACCESS_DENIED", "ORG_DISABLED", "ORG_SLUG_EXISTS", "BRAND_NOT_FOUND", "BRAND_ACCESS_DENIED", "BRAND_SLUG_EXISTS", "BRAND_HAS_RECORDS", "USER_NOT_FOUND", "USER_EXISTS", "MEMBER_NOT_FOUND", "MEMBER_SELF_BRAND_RESTRICTION", "ROLE_NOT_FOUND", "ROLE_NAME_EXISTS", "ROLE_IN_USE", "MEMBER_EXISTS", "INVITATION_NOT_FOUND", "INVITATION_EXPIRED", "INVITATION_ALREADY_SENT", "INVITATION_EMAIL_FAILED", "TOKEN_NOT_FOUND", "BILLING_PAYMENT_FAILED", "BILLING_NO_SUBSCRIPTION", "BILLING_TAX_ID_INVALID", "BILLING_PLAN_INVALID", "BILLING_OPERATION_FAILED", "FEATURE_NOT_AVAILABLE", "RESOURCE_LIMIT_REACHED", "PLAN_LIMITS_EXCEEDED", "NO_SUBSCRIPTION", "SUBSCRIPTION_INACTIVE", "BILLING_MANAGED_BY_SHOPIFY", "BILLING_CHECKOUT_REQUIRED", "ZIPPY_ADDON_REQUIRED", "SHIPMENT_NOT_FOUND", "SHIPMENT_DOCUMENT_NOT_FOUND", "SHIPMENT_ALREADY_SENT", "SHIPMENT_INVALID_STATE", "PARCEL_NOT_FOUND", "PARCEL_INVALID_SPLIT", "PICKUP_NOT_FOUND", "PICKUP_FAILED", "CARRIER_ERROR", "CARRIER_AUTH_FAILED", "CARRIER_NOT_FOUND", "CARRIER_PRODUCT_NOT_FOUND", "CARRIER_CONFIG_INVALID", "CARRIER_PARAMETER_INVALID", "CARRIER_SERVER_UNAVAILABLE", "CARRIER_GLS_WRONG_ADDRESS", "CARRIER_DAO_INVALID_POSTAL_CODE", "CARRIER_POSTNORD_BOOKING_FAILED", "CARRIER_FEDEX_BOOKING_FAILED", "CARRIER_DHL_EXPRESS_BOOKING_FAILED", "CARRIER_UPS_BOOKING_FAILED", "CARRIER_MATKAHUOLTO_BOOKING_FAILED", "CARRIER_TRACKING_WEBHOOK_REGISTRATION_FAILED", "CARRIER_CUSTOMS_UNSUPPORTED_PRODUCT", "CARRIER_CUSTOMS_INCOMPLETE", "CARRIER_REQUEST_NOT_FOUND", "CARRIER_REQUEST_LOCKED", "CARRIER_REQUEST_DISPATCH_FAILED", "SHIPPING_RULE_NOT_FOUND", "SHIPPING_RULE_INVALID", "ADDRESS_NOT_FOUND", "ORDER_NOT_FOUND", "ORDER_CHANNEL_NOT_FOUND", "ORDER_CHANNEL_CONFIG_INVALID", "INTEGRATION_NOT_CONFIGURED", "INSTALLATION_NOT_FOUND", "WEBHOOK_SIGNATURE_INVALID", "WEBHOOK_PAYLOAD_INVALID", "SHOPIFY_PENDING_INSTALL_NOT_FOUND", "SHOPIFY_PENDING_INSTALL_EXPIRED", "SHOP_ALREADY_CONNECTED", "SHOP_CLAIMED_BY_ANOTHER_ORG", "WOOCOMMERCE_CONNECT_FAILED", "WOOCOMMERCE_AUTH_STATE_INVALID", "CHECKOUT_TOKEN_INVALID", "ORDER_CHANNEL_TYPE_UNSUPPORTED", "PRINTER_NOT_FOUND", "PRINTER_OFFLINE", "PRINTER_AUTH_TIMEOUT", "PRINTER_JOB_NOT_FOUND", "ORG_INTEGRATION_NOT_FOUND", "ORG_WEBHOOK_NOT_FOUND", "AUTOMATION_NOT_FOUND", "AUTOMATION_INVALID", "ZIPPY_DISABLED", "CONVERSATION_NOT_FOUND", "ADMIN_FORBIDDEN", "JOB_HANDLER_NOT_REGISTERED", "JOB_QUEUE_NOT_CONFIGURED", "JOB_ENQUEUE_FAILED", "JOB_PAYLOAD_INVALID", "EMAIL_SEND_FAILED", "INTEGRATION_DELIVERY_FAILED", "WEBHOOK_DELIVERY_FAILED", "DOCUMENT_GENERATION_FAILED", "AI_UNAVAILABLE", "MIGRATION_PROVIDER_UNKNOWN", "MIGRATION_SOURCE_TOKEN_INVALID", "MIGRATION_SOURCE_UNREACHABLE", "MIGRATION_NOT_FOUND", "MIGRATION_IN_PROGRESS", "DATA_EXPORT_NOT_FOUND", "DATA_EXPORT_IN_PROGRESS", "DATA_EXPORT_NOT_READY", "DATA_EXPORT_EXPIRED", "DATA_EXPORT_FAILED"])
       return false unless code_validator.valid?(@code)
       true
     end
@@ -185,7 +185,7 @@ module Zippendo
     # Custom attribute writer method checking allowed values (enum).
     # @param [Object] code Object to be assigned
     def code=(code)
-      validator = EnumAttributeValidator.new('String', ["INTERNAL_ERROR", "BAD_REQUEST", "VALIDATION_FAILED", "UNAUTHORIZED", "FORBIDDEN", "NOT_FOUND", "CONFLICT", "RATE_LIMITED", "PAYLOAD_TOO_LARGE", "IMAGE_DIMENSIONS_EXCEEDED", "NOT_IMPLEMENTED", "AUTH_INVALID_CREDENTIALS", "AUTH_TOKEN_INVALID", "AUTH_TOKEN_EXPIRED", "AUTH_EMAIL_NOT_VERIFIED", "AUTH_EMAIL_EXISTS", "AUTH_OAUTH_FAILED", "AUTH_SIGNUP_NOT_ALLOWED", "AUTH_VERIFICATION_FAILED", "AUTH_RESET_TOKEN_INVALID", "AUTH_MFA_REQUIRED", "AUTH_MFA_INVALID_CODE", "AUTH_MFA_ALREADY_ENABLED", "AUTH_MFA_NOT_ENABLED", "SESSION_REQUIRED", "ORG_NOT_FOUND", "ORG_ACCESS_DENIED", "ORG_DISABLED", "ORG_SLUG_EXISTS", "BRAND_NOT_FOUND", "BRAND_ACCESS_DENIED", "BRAND_SLUG_EXISTS", "BRAND_HAS_RECORDS", "USER_NOT_FOUND", "USER_EXISTS", "MEMBER_NOT_FOUND", "MEMBER_SELF_BRAND_RESTRICTION", "ROLE_NOT_FOUND", "ROLE_NAME_EXISTS", "ROLE_IN_USE", "MEMBER_EXISTS", "INVITATION_NOT_FOUND", "INVITATION_EXPIRED", "INVITATION_ALREADY_SENT", "INVITATION_EMAIL_FAILED", "TOKEN_NOT_FOUND", "BILLING_PAYMENT_FAILED", "BILLING_NO_SUBSCRIPTION", "BILLING_TAX_ID_INVALID", "BILLING_PLAN_INVALID", "BILLING_OPERATION_FAILED", "FEATURE_NOT_AVAILABLE", "RESOURCE_LIMIT_REACHED", "PLAN_LIMITS_EXCEEDED", "NO_SUBSCRIPTION", "SUBSCRIPTION_INACTIVE", "BILLING_MANAGED_BY_SHOPIFY", "BILLING_CHECKOUT_REQUIRED", "SHIPMENT_NOT_FOUND", "SHIPMENT_DOCUMENT_NOT_FOUND", "SHIPMENT_ALREADY_SENT", "SHIPMENT_INVALID_STATE", "PARCEL_NOT_FOUND", "PARCEL_INVALID_SPLIT", "PICKUP_NOT_FOUND", "PICKUP_FAILED", "CARRIER_ERROR", "CARRIER_AUTH_FAILED", "CARRIER_NOT_FOUND", "CARRIER_PRODUCT_NOT_FOUND", "CARRIER_CONFIG_INVALID", "CARRIER_PARAMETER_INVALID", "CARRIER_SERVER_UNAVAILABLE", "CARRIER_GLS_WRONG_ADDRESS", "CARRIER_DAO_INVALID_POSTAL_CODE", "CARRIER_POSTNORD_BOOKING_FAILED", "CARRIER_FEDEX_BOOKING_FAILED", "CARRIER_DHL_EXPRESS_BOOKING_FAILED", "CARRIER_UPS_BOOKING_FAILED", "CARRIER_MATKAHUOLTO_BOOKING_FAILED", "CARRIER_TRACKING_WEBHOOK_REGISTRATION_FAILED", "CARRIER_CUSTOMS_UNSUPPORTED_PRODUCT", "CARRIER_CUSTOMS_INCOMPLETE", "CARRIER_REQUEST_NOT_FOUND", "CARRIER_REQUEST_LOCKED", "CARRIER_REQUEST_DISPATCH_FAILED", "SHIPPING_RULE_NOT_FOUND", "SHIPPING_RULE_INVALID", "ADDRESS_NOT_FOUND", "ORDER_NOT_FOUND", "ORDER_CHANNEL_NOT_FOUND", "ORDER_CHANNEL_CONFIG_INVALID", "INTEGRATION_NOT_CONFIGURED", "INSTALLATION_NOT_FOUND", "WEBHOOK_SIGNATURE_INVALID", "WEBHOOK_PAYLOAD_INVALID", "SHOPIFY_PENDING_INSTALL_NOT_FOUND", "SHOPIFY_PENDING_INSTALL_EXPIRED", "SHOP_ALREADY_CONNECTED", "SHOP_CLAIMED_BY_ANOTHER_ORG", "WOOCOMMERCE_CONNECT_FAILED", "WOOCOMMERCE_AUTH_STATE_INVALID", "CHECKOUT_TOKEN_INVALID", "ORDER_CHANNEL_TYPE_UNSUPPORTED", "PRINTER_NOT_FOUND", "PRINTER_OFFLINE", "PRINTER_AUTH_TIMEOUT", "PRINTER_JOB_NOT_FOUND", "ORG_INTEGRATION_NOT_FOUND", "ORG_WEBHOOK_NOT_FOUND", "AUTOMATION_NOT_FOUND", "AUTOMATION_INVALID", "ZIPPY_DISABLED", "CONVERSATION_NOT_FOUND", "ADMIN_FORBIDDEN", "JOB_HANDLER_NOT_REGISTERED", "JOB_QUEUE_NOT_CONFIGURED", "JOB_ENQUEUE_FAILED", "JOB_PAYLOAD_INVALID", "EMAIL_SEND_FAILED", "INTEGRATION_DELIVERY_FAILED", "WEBHOOK_DELIVERY_FAILED", "DOCUMENT_GENERATION_FAILED", "AI_UNAVAILABLE", "MIGRATION_PROVIDER_UNKNOWN", "MIGRATION_SOURCE_TOKEN_INVALID", "MIGRATION_SOURCE_UNREACHABLE", "MIGRATION_NOT_FOUND", "MIGRATION_IN_PROGRESS"])
+      validator = EnumAttributeValidator.new('String', ["INTERNAL_ERROR", "BAD_REQUEST", "VALIDATION_FAILED", "UNAUTHORIZED", "FORBIDDEN", "NOT_FOUND", "CONFLICT", "RATE_LIMITED", "PAYLOAD_TOO_LARGE", "IMAGE_DIMENSIONS_EXCEEDED", "NOT_IMPLEMENTED", "AUTH_INVALID_CREDENTIALS", "AUTH_TOKEN_INVALID", "AUTH_TOKEN_EXPIRED", "AUTH_EMAIL_NOT_VERIFIED", "AUTH_EMAIL_EXISTS", "AUTH_OAUTH_FAILED", "AUTH_SIGNUP_NOT_ALLOWED", "AUTH_VERIFICATION_FAILED", "AUTH_RESET_TOKEN_INVALID", "AUTH_MFA_REQUIRED", "AUTH_MFA_INVALID_CODE", "AUTH_MFA_ALREADY_ENABLED", "AUTH_MFA_NOT_ENABLED", "SESSION_REQUIRED", "ORG_NOT_FOUND", "ORG_ACCESS_DENIED", "ORG_DISABLED", "ORG_SLUG_EXISTS", "BRAND_NOT_FOUND", "BRAND_ACCESS_DENIED", "BRAND_SLUG_EXISTS", "BRAND_HAS_RECORDS", "USER_NOT_FOUND", "USER_EXISTS", "MEMBER_NOT_FOUND", "MEMBER_SELF_BRAND_RESTRICTION", "ROLE_NOT_FOUND", "ROLE_NAME_EXISTS", "ROLE_IN_USE", "MEMBER_EXISTS", "INVITATION_NOT_FOUND", "INVITATION_EXPIRED", "INVITATION_ALREADY_SENT", "INVITATION_EMAIL_FAILED", "TOKEN_NOT_FOUND", "BILLING_PAYMENT_FAILED", "BILLING_NO_SUBSCRIPTION", "BILLING_TAX_ID_INVALID", "BILLING_PLAN_INVALID", "BILLING_OPERATION_FAILED", "FEATURE_NOT_AVAILABLE", "RESOURCE_LIMIT_REACHED", "PLAN_LIMITS_EXCEEDED", "NO_SUBSCRIPTION", "SUBSCRIPTION_INACTIVE", "BILLING_MANAGED_BY_SHOPIFY", "BILLING_CHECKOUT_REQUIRED", "ZIPPY_ADDON_REQUIRED", "SHIPMENT_NOT_FOUND", "SHIPMENT_DOCUMENT_NOT_FOUND", "SHIPMENT_ALREADY_SENT", "SHIPMENT_INVALID_STATE", "PARCEL_NOT_FOUND", "PARCEL_INVALID_SPLIT", "PICKUP_NOT_FOUND", "PICKUP_FAILED", "CARRIER_ERROR", "CARRIER_AUTH_FAILED", "CARRIER_NOT_FOUND", "CARRIER_PRODUCT_NOT_FOUND", "CARRIER_CONFIG_INVALID", "CARRIER_PARAMETER_INVALID", "CARRIER_SERVER_UNAVAILABLE", "CARRIER_GLS_WRONG_ADDRESS", "CARRIER_DAO_INVALID_POSTAL_CODE", "CARRIER_POSTNORD_BOOKING_FAILED", "CARRIER_FEDEX_BOOKING_FAILED", "CARRIER_DHL_EXPRESS_BOOKING_FAILED", "CARRIER_UPS_BOOKING_FAILED", "CARRIER_MATKAHUOLTO_BOOKING_FAILED", "CARRIER_TRACKING_WEBHOOK_REGISTRATION_FAILED", "CARRIER_CUSTOMS_UNSUPPORTED_PRODUCT", "CARRIER_CUSTOMS_INCOMPLETE", "CARRIER_REQUEST_NOT_FOUND", "CARRIER_REQUEST_LOCKED", "CARRIER_REQUEST_DISPATCH_FAILED", "SHIPPING_RULE_NOT_FOUND", "SHIPPING_RULE_INVALID", "ADDRESS_NOT_FOUND", "ORDER_NOT_FOUND", "ORDER_CHANNEL_NOT_FOUND", "ORDER_CHANNEL_CONFIG_INVALID", "INTEGRATION_NOT_CONFIGURED", "INSTALLATION_NOT_FOUND", "WEBHOOK_SIGNATURE_INVALID", "WEBHOOK_PAYLOAD_INVALID", "SHOPIFY_PENDING_INSTALL_NOT_FOUND", "SHOPIFY_PENDING_INSTALL_EXPIRED", "SHOP_ALREADY_CONNECTED", "SHOP_CLAIMED_BY_ANOTHER_ORG", "WOOCOMMERCE_CONNECT_FAILED", "WOOCOMMERCE_AUTH_STATE_INVALID", "CHECKOUT_TOKEN_INVALID", "ORDER_CHANNEL_TYPE_UNSUPPORTED", "PRINTER_NOT_FOUND", "PRINTER_OFFLINE", "PRINTER_AUTH_TIMEOUT", "PRINTER_JOB_NOT_FOUND", "ORG_INTEGRATION_NOT_FOUND", "ORG_WEBHOOK_NOT_FOUND", "AUTOMATION_NOT_FOUND", "AUTOMATION_INVALID", "ZIPPY_DISABLED", "CONVERSATION_NOT_FOUND", "ADMIN_FORBIDDEN", "JOB_HANDLER_NOT_REGISTERED", "JOB_QUEUE_NOT_CONFIGURED", "JOB_ENQUEUE_FAILED", "JOB_PAYLOAD_INVALID", "EMAIL_SEND_FAILED", "INTEGRATION_DELIVERY_FAILED", "WEBHOOK_DELIVERY_FAILED", "DOCUMENT_GENERATION_FAILED", "AI_UNAVAILABLE", "MIGRATION_PROVIDER_UNKNOWN", "MIGRATION_SOURCE_TOKEN_INVALID", "MIGRATION_SOURCE_UNREACHABLE", "MIGRATION_NOT_FOUND", "MIGRATION_IN_PROGRESS", "DATA_EXPORT_NOT_FOUND", "DATA_EXPORT_IN_PROGRESS", "DATA_EXPORT_NOT_READY", "DATA_EXPORT_EXPIRED", "DATA_EXPORT_FAILED"])
       unless validator.valid?(code)
         fail ArgumentError, "invalid value for \"code\", must be one of #{validator.allowable_values}."
       end

data/lib/zippendo/models/batch_send_shipments200_response_summary.rb

@@ -1,7 +1,7 @@
 =begin
 #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

data/lib/zippendo/models/batch_send_shipments_request.rb

@@ -1,7 +1,7 @@
 =begin
 #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

data/lib/zippendo/models/batch_split_shipment201_response.rb

@@ -1,7 +1,7 @@
 =begin
 #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

data/lib/zippendo/models/batch_split_shipment_request.rb

@@ -1,7 +1,7 @@
 =begin
 #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