zippendo 1.3.12 → 1.3.13

checksums.yaml

@@ -1,7 +1,7 @@
 ---
 SHA256:
-  metadata.gz: 4b5c2a39a1de9a6184910cd2c3a3262f40df3b49de8480f4f8038501f9472fb1
-  data.tar.gz: ff572945f629b7dd7446357e5295ee72f12ab24f72659a357ee603ab686e3b82
+  metadata.gz: 327ac86fc7c9ee283583e7b70ebd1f0bb813d72d8a183a74f18ec0f73ba1e2d9
+  data.tar.gz: c595218b5c9192467876c5695915a61dd86a3e6df90153f2eba4b2fff3076643
 SHA512:
-  metadata.gz: c73f1e7e63f9171951e6c7c7d11ce1c5261380405a95d3244a245081dff18d271b46c5f2fa65fa59dd297e54f4dc6ee5fa772fa6a580206decd4e93ca9ef35f5
-  data.tar.gz: 89d5e38846c755005b8f896266158d9cd9297186943a7af73019317862a401e0615809b06d58965a2c033595c93c5d625fa34ac6787209a0195541a64d93defe
+  metadata.gz: e7da97582dc30b838575640d7aa1966cd29e9a6937560c47800d2d872c9982d8bdd9d8a239cc7e178dc0e38d93c3ed192ba2f6a7ce751822081ad04aded7fff6
+  data.tar.gz: 580f2c0d23329c90bb4172150e2dd8f849d31bdf785831fc5cdfe4aef4b48341585a7789edd848c8b44d63277e4980e0b11bc6ab2cc3b3ec03ed92ab66ab3559

data/README.md

@@ -3,6 +3,12 @@
 Official Ruby client for the [Zippendo](https://zippendo.com) shipping & logistics API. Requires
 Ruby 2.7+.
 
+Book shipments and print labels with PostNord, GLS, DAO, Bring, DHL, DPD, UPS and more, track
+parcels, and manage orders, shipping rules and webhooks from your own code. New to the API? Start with
+the [SDK guide](https://www.zippendo.com/docs/sdks/overview) or browse the
+[API reference](https://www.zippendo.com/docs/api-reference/overview). To work from an AI assistant
+instead, connect the [Zippendo MCP server](https://www.zippendo.com/docs/mcp/overview).
+
 ## Install
 
 ```sh

data/SECURITY.md

@@ -0,0 +1,19 @@
+# Security policy
+
+## Reporting a vulnerability
+
+Please report a security issue privately by email to **support@zippendo.com** with "Security" in the
+subject, not in a public issue. Include the SDK, its version and the steps to reproduce. This covers
+this SDK and the Zippendo API it calls.
+
+## Supported versions
+
+Fixes ship in a new release; earlier versions are not patched. Every Zippendo SDK is released under
+the same version number, so a fix reaches all of them at once.
+
+## Where this code comes from
+
+This repository is generated from the Zippendo public API specification
+(<https://api.zippendo.com/public/json>) with [OpenAPI Generator](https://openapi-generator.tech) and
+published by Zippendo's release pipeline. A change made here directly is replaced by the next release,
+so report problems in an issue or by email rather than a pull request.

data/lib/zippendo/version.rb

@@ -11,5 +11,5 @@ Generator version: 7.24.0
 =end
 
 module Zippendo
-  VERSION = '1.3.12'
+  VERSION = '1.3.13'
 end

data/zippendo.gemspec

@@ -19,11 +19,11 @@ Gem::Specification.new do |s|
   s.name        = "zippendo"
   s.version     = Zippendo::VERSION
   s.platform    = Gem::Platform::RUBY
-  s.authors     = ["OpenAPI-Generator"]
+  s.authors     = ["Zippendo"]
   s.email       = ["support@zippendo.com"]
-  s.homepage    = "https://www.zippendo.com"
-  s.summary     = "Zippendo Public API Ruby Gem"
-  s.description = "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`."
+  s.homepage    = "https://www.zippendo.com/docs/sdks/overview"
+  s.summary     = "Official Ruby SDK for the Zippendo shipping API: book shipments, print labels and track parcels with PostNord, GLS, DAO, Bring, DHL, DPD, UPS and more."
+  s.description = "Official Ruby SDK for the Zippendo shipping API: book shipments, print labels and track parcels with PostNord, GLS, DAO, Bring, DHL, DPD, UPS and more."
   s.license     = "MIT"
   s.required_ruby_version = ">= 2.7"
   s.metadata    = {}

metadata

@@ -1,10 +1,10 @@
 --- !ruby/object:Gem::Specification
 name: zippendo
 version: !ruby/object:Gem::Version
-  version: 1.3.12
+  version: 1.3.13
 platform: ruby
 authors:
-- OpenAPI-Generator
+- Zippendo
 bindir: bin
 cert_chain: []
 date: 1980-01-02 00:00:00.000000000 Z
@@ -49,36 +49,8 @@ dependencies:
     - - ">="
       - !ruby/object:Gem::Version
         version: 3.6.0
-description: '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`.'
+description: 'Official Ruby SDK for the Zippendo shipping API: book shipments, print
+  labels and track parcels with PostNord, GLS, DAO, Bring, DHL, DPD, UPS and more.'
 email:
 - support@zippendo.com
 executables: []
@@ -89,6 +61,7 @@ files:
 - LICENSE.md
 - README.md
 - Rakefile
+- SECURITY.md
 - docs/AddressesApi.md
 - docs/BatchSendShipments200Response.md
 - docs/BatchSendShipments200ResponseResultsInner.md
@@ -268,7 +241,6 @@ files:
 - docs/VerifyApiToken200Response.md
 - docs/VerifyApiTokenRequest.md
 - docs/WebhooksApi.md
-- git_push.sh
 - lib/zippendo.rb
 - lib/zippendo/api/addresses_api.rb
 - lib/zippendo/api/billing_api.rb
@@ -456,7 +428,7 @@ files:
 - lib/zippendo/version.rb
 - spec/spec_helper.rb
 - zippendo.gemspec
-homepage: https://www.zippendo.com
+homepage: https://www.zippendo.com/docs/sdks/overview
 licenses:
 - MIT
 metadata: {}
@@ -476,6 +448,7 @@ required_rubygems_version: !ruby/object:Gem::Requirement
 requirements: []
 rubygems_version: 3.6.9
 specification_version: 4
-summary: Zippendo Public API Ruby Gem
+summary: 'Official Ruby SDK for the Zippendo shipping API: book shipments, print labels
+  and track parcels with PostNord, GLS, DAO, Bring, DHL, DPD, UPS and more.'
 test_files:
 - spec/spec_helper.rb

data/git_push.sh

@@ -1,57 +0,0 @@
-#!/bin/sh
-# ref: https://help.github.com/articles/adding-an-existing-project-to-github-using-the-command-line/
-#
-# Usage example: /bin/sh ./git_push.sh wing328 openapi-petstore-perl "minor update" "gitlab.com"
-
-git_user_id=$1
-git_repo_id=$2
-release_note=$3
-git_host=$4
-
-if [ "$git_host" = "" ]; then
-    git_host="github.com"
-    echo "[INFO] No command line input provided. Set \$git_host to $git_host"
-fi
-
-if [ "$git_user_id" = "" ]; then
-    git_user_id="zippendo"
-    echo "[INFO] No command line input provided. Set \$git_user_id to $git_user_id"
-fi
-
-if [ "$git_repo_id" = "" ]; then
-    git_repo_id="zippendo-ruby"
-    echo "[INFO] No command line input provided. Set \$git_repo_id to $git_repo_id"
-fi
-
-if [ "$release_note" = "" ]; then
-    release_note="Minor update"
-    echo "[INFO] No command line input provided. Set \$release_note to $release_note"
-fi
-
-# Initialize the local directory as a Git repository
-git init
-
-# Adds the files in the local repository and stages them for commit.
-git add .
-
-# Commits the tracked changes and prepares them to be pushed to a remote repository.
-git commit -m "$release_note"
-
-# Sets the new remote
-git_remote=$(git remote)
-if [ "$git_remote" = "" ]; then # git remote not defined
-
-    if [ "$GIT_TOKEN" = "" ]; then
-        echo "[INFO] \$GIT_TOKEN (environment variable) is not set. Using the git credential in your environment."
-        git remote add origin https://${git_host}/${git_user_id}/${git_repo_id}.git
-    else
-        git remote add origin https://${git_user_id}:"${GIT_TOKEN}"@${git_host}/${git_user_id}/${git_repo_id}.git
-    fi
-
-fi
-
-git pull origin master
-
-# Pushes (Forces) the changes in the local repository up to the remote repository
-echo "Git pushing to https://${git_host}/${git_user_id}/${git_repo_id}.git"
-git push origin master 2>&1 | grep -v 'To https'