@spree/docs 0.1.229 → 0.1.231

package/dist/developer/core-concepts/catalogs.md

@@ -21,6 +21,8 @@ erDiagram
     Catalog ||--o{ CatalogProduct : "assortment"
     Catalog ||--o{ CatalogAssignment : "audiences"
     Catalog ||--o| PriceList : "owns (optional)"
+    Catalog ||--o{ CatalogQuantityRule : "per-SKU terms"
+    Catalog ||--o{ CatalogOrderMinimum : "cart minimum"
     CatalogAssignment }o--|| CustomerGroup : "one of"
     CatalogAssignment }o--|| Company : "one of"
 
@@ -28,6 +30,8 @@ erDiagram
         string name
         boolean active
         integer position
+        integer minimum_order_quantity
+        integer order_multiple
     }
 ```
 
@@ -48,14 +52,29 @@ That's worth pausing on, because it's the one behaviour that surprises people: a
 
 ## Creating one
 
+
 ```typescript Admin SDK
 const catalog = await adminClient.catalogs.create({
   name: 'Wholesale',
-  price_list_id: 'plist_xxx',
-  active: true,
+  price_list: { name: 'Wholesale pricing' },
 })
+
+await adminClient.catalogs.activate(catalog.id)
+```
+
+```bash cURL
+# Create the agreement with its pricing inline
+curl -X POST 'https://api.mystore.com/api/v3/admin/catalogs' \
+  -H 'X-Spree-API-Key: sk_xxx' \
+  -H 'Content-Type: application/json' \
+  -d '{ "name": "Wholesale", "price_list": { "name": "Wholesale pricing" } }'
+
+# Catalogs are born inactive — going live is its own act
+curl -X PATCH 'https://api.mystore.com/api/v3/admin/catalogs/cat_xxx/activate' \
+  -H 'X-Spree-API-Key: sk_xxx'
 ```
 
+
 The price list is optional. A catalog with an assortment and no price list restricts the range at normal prices; a catalog with a price list and no assortment adjusts prices without hiding anything.
 
 A price list is either **standalone** (matched by its own rules) or **owned by exactly one catalog**. A catalog creates the list it prices through, so the two are configured together on the catalog page — an owned list never appears in the price-lists index, since it has no rules or audience of its own.
@@ -64,6 +83,7 @@ Removing a catalog's pricing (`price_list: null`), or deleting the catalog itsel
 
 ### Filling the assortment
 
+
 ```typescript Admin SDK
 // Add products (a bare array of IDs)
 await adminClient.catalogs.products.create(catalog.id, ['prod_xxx', 'prod_yyy'])
@@ -73,14 +93,34 @@ const { data: products } = await adminClient.catalogs.products.list(catalog.id)
 await adminClient.catalogs.products.delete(catalog.id, 'prod_xxx')
 ```
 
+```bash cURL
+# Add products to the assortment
+curl -X POST 'https://api.mystore.com/api/v3/admin/catalogs/cat_xxx/products' \
+  -H 'X-Spree-API-Key: sk_xxx' \
+  -H 'Content-Type: application/json' \
+  -d '{ "product_ids": ["prod_xxx", "prod_yyy"] }'
+
+# List them
+curl 'https://api.mystore.com/api/v3/admin/catalogs/cat_xxx/products' \
+  -H 'X-Spree-API-Key: sk_xxx'
+```
+
+
 Membership is all a catalog holds — it decides *what* a buyer sees, never the order they see it in. Presentation order stays with categories and collections.
 
 When a catalog should restrict to exactly what its price list covers, there's a shortcut that copies those products in rather than making someone add them by hand:
 
+
 ```typescript Admin SDK
 const { added_count } = await adminClient.catalogs.importProducts(catalog.id)
 ```
 
+```bash cURL
+curl -X POST 'https://api.mystore.com/api/v3/admin/catalogs/cat_xxx/import_products' \
+  -H 'X-Spree-API-Key: sk_xxx'
+```
+
+
 ## Choosing the audience
 
 A catalog is assigned to a buyer audience:
@@ -92,6 +132,7 @@ A catalog is assigned to a buyer audience:
 
 A [Channel](channels.md) is not assigned — it names its catalog directly via `default_catalog_id`, which applies to everyone buying through it when nothing narrower does.
 
+
 ```typescript Admin SDK
 await adminClient.catalogs.assign(catalog.id, {
   assignable_type: 'customer_group',
@@ -99,6 +140,14 @@ await adminClient.catalogs.assign(catalog.id, {
 })
 ```
 
+```bash cURL
+curl -X POST 'https://api.mystore.com/api/v3/admin/catalogs/cat_xxx/assign' \
+  -H 'X-Spree-API-Key: sk_xxx' \
+  -H 'Content-Type: application/json' \
+  -d '{ "assignable_type": "customer_group", "assignable_id": "cgrp_xxx" }'
+```
+
+
 > **NOTE:** **A company assignment covers the whole subtree.** Assign the group-wide catalog once at the root of a [company tree](companies.md) and every division below inherits it — no re-assigning per branch. A branch can still add its own catalog on top.
 
 ## What a shopper ends up seeing

package/dist/developer/core-concepts/channels.md

@@ -9,6 +9,25 @@ Channels segment a single [Store](stores.md) into distinct selling surfaces. A c
 
 Every store ships with one default channel named *Online Store*. You can add more from **Settings → Sales channels** in the admin dashboard.
 
+```mermaid
+erDiagram
+    Store ||--o{ Channel : "has many"
+    Channel ||--o{ ProductPublication : "publishes"
+    ProductPublication }o--|| Product : "lists"
+    Channel ||--o{ Order : "attributes"
+    Channel ||--o{ OrderRoutingRule : "routes by"
+    Channel ||--o{ ChannelStockLocation : "serves from"
+    Channel }o--o| Catalog : "default assortment"
+    Channel ||--o{ ApiKey : "authenticates"
+
+    Channel {
+        string name
+        string code
+        boolean active
+        boolean default
+    }
+```
+
 ## Channel Attributes
 
 | Attribute | Description | Example |
@@ -206,7 +225,7 @@ The write contract is **full-set**: the array represents the complete desired st
 
 - **Dashboard** — new products are auto-published on the store's default channel. The merchant can untick channels via the Publishing card post-create.
 - **Admin API** — new products are **not** auto-published. The caller supplies `product_publications: [{ channel_id }]` on create, or calls `POST /admin/channels/:id/add_products` afterwards.
-- **Sample data** (`bin/rake spree:load_sample_data`) — all loaded products are explicitly published on the default channel.
+- **Sample data** (`spree sample-data`) — all loaded products are explicitly published on the default channel.
 
 ## Related Documentation
 

package/dist/developer/core-concepts/commissions.md

@@ -31,6 +31,7 @@ flowchart LR
 
 A rate says what to charge. It's either a percentage of the sale or a flat amount.
 
+
 ```typescript Admin SDK
 await adminClient.commissionRates.create({
   name: 'Electronics',
@@ -41,6 +42,20 @@ await adminClient.commissionRates.create({
 })
 ```
 
+```bash cURL
+curl -X POST 'https://api.mystore.com/api/v3/admin/commission_rates' \
+  -H 'X-Spree-API-Key: sk_xxx' \
+  -H 'Content-Type: application/json' \
+  -d '{
+    "name": "Electronics",
+    "code": "electronics",
+    "kind": "percentage",
+    "value": "12.5",
+    "enabled": true
+  }'
+```
+
+
 | Attribute | Description |
 |---|---|
 | `name` | What operators call it |
@@ -84,6 +99,7 @@ Rules narrow when a rate applies. A rate can hold several, and **all of them mus
 
 So "electronics **and** these three sellers" is two rules on one rate.
 
+
 ```typescript Admin SDK
 // Every rule kind, with the schema describing its settings — so an editor
 // is built from what this marketplace actually has, not a hardcoded list
@@ -97,6 +113,23 @@ await adminClient.commissionRates.update('crate_xxx', {
 })
 ```
 
+```bash cURL
+# Discover the rule kinds this marketplace has
+curl 'https://api.mystore.com/api/v3/admin/commission_rates/rule_types' \
+  -H 'X-Spree-API-Key: sk_xxx'
+
+# Attach rules to a rate
+curl -X PATCH 'https://api.mystore.com/api/v3/admin/commission_rates/crate_xxx' \
+  -H 'X-Spree-API-Key: sk_xxx' \
+  -H 'Content-Type: application/json' \
+  -d '{
+    "rules": [
+      { "type": "category_rule", "preferences": { "category_ids": ["ctg_xxx"] } }
+    ]
+  }'
+```
+
+
 Rules are replaced wholesale on update — send the full set you want.
 
 ### The four rule types
@@ -164,6 +197,7 @@ Discounts come off either way. Commission is charged on what the customer actual
 
 Money is stated per currency, never converted:
 
+
 ```typescript Admin SDK
 // A percentage, with a floor and a cap in each currency
 await adminClient.commissionRates.create({
@@ -185,6 +219,34 @@ await adminClient.commissionRates.create({
 })
 ```
 
+```bash cURL
+# A percentage, with a floor and a cap in each currency
+curl -X POST 'https://api.mystore.com/api/v3/admin/commission_rates' \
+  -H 'X-Spree-API-Key: sk_xxx' \
+  -H 'Content-Type: application/json' \
+  -d '{
+    "name": "Standard",
+    "kind": "percentage",
+    "value": 10,
+    "bounds": {
+      "USD": { "min_amount": 1, "max_amount": 50 },
+      "EUR": { "min_amount": 1, "max_amount": 45 }
+    }
+  }'
+
+# A flat fee, stated per currency
+curl -X POST 'https://api.mystore.com/api/v3/admin/commission_rates' \
+  -H 'X-Spree-API-Key: sk_xxx' \
+  -H 'Content-Type: application/json' \
+  -d '{
+    "name": "Listing fee",
+    "kind": "fixed",
+    "value": 0,
+    "amounts": { "USD": "5.00", "GBP": "4.00" }
+  }'
+```
+
+
 - **`amounts`** — what a flat fee charges, per currency
 - **`bounds`** — the floor and cap a percentage charges within, per currency
 
@@ -229,12 +291,19 @@ When an order is placed, the resolved rate is applied and the result frozen as a
 | `line_item_id` / `fulfillment_id` | What was commissioned — exactly one |
 | `commission_rate_id` | The rate, if it still exists |
 
+
 ```typescript Admin SDK
 const { data: lines } = await adminClient.commissionLines.list({
-  filter: { seller_id_eq: 'sel_xxx' },
+  seller_id_eq: 'sel_xxx',
 })
 ```
 
+```bash cURL
+curl 'https://api.mystore.com/api/v3/admin/commission_lines?q[seller_id_eq]=sel_xxx' \
+  -H 'X-Spree-API-Key: sk_xxx'
+```
+
+
 **Every field is a snapshot.** Editing the rate afterwards changes nothing here, and neither does deleting it — a retired rate is soft-deleted precisely so "which rate charged this" stays answerable.
 
 There is **no write path**. Lines are read-only in the API, and correcting a charge means recording a reversal rather than editing history — the discipline any ledger needs.

package/dist/developer/core-concepts/companies.md

@@ -59,6 +59,7 @@ So a buyer attached to "Acme Europe" can act for Sales and Operations beneath it
 
 This is why authorization always asks "does this person have standing on this node *or any of its ancestors*", never "is this person a member of exactly this node".
 
+
 ```typescript Store SDK
 // Which companies can this customer act for?
 const { data: memberships } = await client.account.companies()
@@ -69,6 +70,13 @@ memberships.forEach((m) => {
 })
 ```
 
+```bash cURL
+curl 'https://api.mystore.com/api/v3/store/account/companies' \
+  -H 'X-Spree-API-Key: pk_xxx' \
+  -H 'Authorization: Bearer $CUSTOMER_JWT'
+```
+
+
 > **NOTE:** **In open source, every member can do everything within their standing** — buy, see the subtree's orders, and manage addresses and members. There are no company roles; the `role` label on a membership is cosmetic.
 > 
 > To restrict what individual people may do, see [company governance](#company-governance) below.
@@ -77,12 +85,22 @@ memberships.forEach((m) => {
 
 Both the dashboard and the storefront add members the same way — by email:
 
+
 ```typescript Store SDK
 const result = await client.companies.members.create('comp_xxx', {
   customer_email: 'buyer@acme.com',
 })
 ```
 
+```bash cURL
+curl -X POST 'https://api.mystore.com/api/v3/store/companies/comp_xxx/members' \
+  -H 'X-Spree-API-Key: pk_xxx' \
+  -H 'Authorization: Bearer $CUSTOMER_JWT' \
+  -H 'Content-Type: application/json' \
+  -d '{ "customer_email": "buyer@acme.com" }'
+```
+
+
 What comes back depends on whether that email is already a customer:
 
 - **An existing customer** becomes a member straight away.
@@ -92,6 +110,7 @@ You can tell which by the ID prefix — `cmem_` for a membership, `cinv_` for an
 
 Accepting an invitation either signs an existing customer in, or registers a new account with the invited email. Either way it ends as a membership:
 
+
 ```typescript Store SDK
 // The token comes from the invitation email — no sign-in needed to read it
 const invitation = await client.companyInvitations.lookup(token)
@@ -104,31 +123,60 @@ await client.companyInvitations.accept(token, {
 })
 ```
 
+```bash cURL
+# Reading an invitation needs no sign-in — just the emailed token
+curl 'https://api.mystore.com/api/v3/store/company_invitations/TOKEN' \
+  -H 'X-Spree-API-Key: pk_xxx'
+
+curl -X POST 'https://api.mystore.com/api/v3/store/company_invitations/TOKEN/accept' \
+  -H 'X-Spree-API-Key: pk_xxx'
+```
+
+
 Memberships are always active and always backed by a real customer. Anything still waiting lives on the invitation, so there's no such thing as a half-active member.
 
 ## Buying for a company
 
 A cart and an order can name a company. That's what turns a personal purchase into a company one — it decides which addresses are on offer, whose tax registration applies, and who else will see the order.
 
+
 ```typescript Store SDK
 await client.carts.update(cartId, { company_id: 'comp_xxx' })
 ```
 
+```bash cURL
+curl -X PATCH 'https://api.mystore.com/api/v3/store/carts/cart_xxx' \
+  -H 'X-Spree-API-Key: pk_xxx' \
+  -H 'Authorization: Bearer $CUSTOMER_JWT' \
+  -H 'Content-Type: application/json' \
+  -d '{ "company_id": "comp_xxx" }'
+```
+
+
 A buyer with exactly one membership doesn't need to choose; it resolves on its own. A buyer who belongs to several names the node — and it must be one they have standing on.
 
 The company is **frozen onto the order** at completion, like the addresses and prices. Reorganize the tree next year and last year's order still explains itself.
 
+
 ```typescript Store SDK
 // Everything anyone in the subtree has bought
 const { data: orders } = await client.companies.orders.list('comp_xxx')
 ```
 
+```bash cURL
+curl 'https://api.mystore.com/api/v3/store/companies/comp_xxx/orders' \
+  -H 'X-Spree-API-Key: pk_xxx' \
+  -H 'Authorization: Bearer $CUSTOMER_JWT'
+```
+
+
 That subtree rollup is the feature a finance team actually asks for: one place showing what the whole organization spent, without chasing individual accounts.
 
 ## The shared address book
 
 A company keeps its own addresses — ship-to sites, a billing address — separate from any individual's. They're labelled, and one of each kind can be the default.
 
+
 ```typescript Store SDK
 await client.companies.addresses.create('comp_xxx', {
   label: 'Northern Warehouse',
@@ -142,12 +190,22 @@ await client.companies.addresses.create('comp_xxx', {
 })
 ```
 
+```bash cURL
+curl -X POST 'https://api.mystore.com/api/v3/store/companies/comp_xxx/addresses' \
+  -H 'X-Spree-API-Key: pk_xxx' \
+  -H 'Authorization: Bearer $CUSTOMER_JWT' \
+  -H 'Content-Type: application/json' \
+  -d '{ "label": "Northern Warehouse", "first_name": "Goods", "last_name": "Inwards" }'
+```
+
+
 Note that a delivery site is just an address. Ten warehouses do not mean ten company nodes — nodes exist for organizational and legal structure, addresses for where things go.
 
 ## Tax
 
 Tax registrations and exemption certificates live **only on legal entities**, and a purchase resolves tax through the node's nearest `company` ancestor.
 
+
 ```typescript Admin SDK
 await adminClient.companies.taxIdentifiers.create('comp_xxx', {
   kind: 'eu_vat',
@@ -158,6 +216,14 @@ await adminClient.companies.taxIdentifiers.create('comp_xxx', {
 await adminClient.companies.taxIdentifiers.validate('comp_xxx', 'txid_xxx')
 ```
 
+```bash cURL
+curl -X POST 'https://api.mystore.com/api/v3/admin/companies/comp_xxx/tax_identifiers' \
+  -H 'X-Spree-API-Key: sk_xxx' \
+  -H 'Content-Type: application/json' \
+  -d '{ "kind": "eu_vat", "value": "NL123456789B01" }'
+```
+
+
 > **WARNING:** The walk stops at the first `company` node, **whether or not it holds a registration**. A subsidiary with no VAT number of its own therefore has none — it never quietly borrows its parent's, because in most jurisdictions that would be a false declaration.
 
 Exemption certificates hang off a legal entity and are scoped to the country or state that issued them. Check whether a certificate is `active` rather than reading its status — a verified certificate stops exempting once it expires, and `active` accounts for that.
@@ -216,6 +282,7 @@ Payment terms and net invoicing, quotes, and a packaged buyer portal are on the
 
 ## Managing companies as staff
 
+
 ```typescript Admin SDK
 // Roots only
 const { data: roots } = await adminClient.companies.list({ parent_id_null: 1 })
@@ -230,6 +297,13 @@ const division = await adminClient.companies.create({
 })
 ```
 
+```bash cURL
+# Roots only
+curl 'https://api.mystore.com/api/v3/admin/companies?q[parent_id_null]=1' \
+  -H 'X-Spree-API-Key: sk_xxx'
+```
+
+
 Moving a branch is an update with a new `parent_id`. Deleting a node removes its whole subtree, and is refused outright once any order exists beneath it — history doesn't get deleted to tidy up an org chart.
 
 Each row carries `children_count` and `members_count`. `children_count` is the node's direct sub-units. `members_count` is the number of distinct customers holding a membership on the node or on any node below it, so somebody who is a member of both a parent and one of its sub-units is counted once rather than twice.

package/dist/developer/core-concepts/customers.md

@@ -10,28 +10,40 @@ Customers interact with your store through the Store API. They can register, log
 ```mermaid
 erDiagram
     Customer ||--o{ Order : "places"
-    Customer ||--o{ Address : "has many"
+    Customer ||--o{ Address : "address book"
+    Customer ||--o| Address : "default ship/bill"
     Customer ||--o{ Wishlist : "has many"
     Customer ||--o{ StoreCredit : "has many"
-    Customer ||--o{ PaymentSource : "has many"
+    Customer ||--o{ GiftCard : "holds"
+    Customer ||--o{ CompanyMembership : "buys for"
+    CompanyMembership }o--|| Company : "belongs to"
+    Customer }o--o{ CustomerGroup : "segmented by"
 
     Customer {
-        string id
         string email
         string first_name
         string last_name
+        string phone
     }
 
     Order {
         string number
-        string state
+        string payment_status
+        string fulfillment_status
     }
 
     Address {
+        string label
         string first_name
         string last_name
+        string company
         string address1
+        string address2
         string city
+        string postal_code
+        string state_code
+        string country_code
+        string phone
     }
 
     Wishlist {
@@ -71,7 +83,7 @@ curl -X POST 'https://api.mystore.com/api/v3/store/customers' \
 
 > **NOTE:** The Store API flow above is **customer self-registration** — the customer sets a password and gets a JWT back. To [create a customer record from the back office](../sdk/admin/resources.md) (importers, CRM sync, phone orders), use the [Admin SDK](../sdk/admin/quickstart.md) instead. No password is set, so it's a managed record rather than a sign-up:
 > 
-> ```typescript
+> ```typescript Admin SDK
 import { createAdminClient } from '@spree/admin-sdk'
 
 const client = createAdminClient({

package/dist/developer/core-concepts/data-privacy.md

@@ -19,7 +19,7 @@ A person has the right to a copy of their data and the right to have it
 erased. Both arrive as a `Spree::DataRequest`, which records that the request
 was made and how it was answered.
 
-```
+```http
 POST /api/v3/store/customers/me/data_requests   { "kind": "access" }
 POST /api/v3/store/customers/me/data_requests   { "kind": "erasure", "current_password": "..." }
 ```
@@ -37,7 +37,7 @@ Most requests never reach the storefront. They arrive as email to the
 merchant, often from someone who can no longer sign in, so the same two
 actions exist in the admin:
 
-```
+```http
 GET  /api/v3/admin/customers/:id/export
 POST /api/v3/admin/customers/:id/anonymize
 ```
@@ -69,7 +69,7 @@ A `customer.anonymized` event is published when it completes.
 Spree exports what Spree knows. If your application holds data of its own — a
 loyalty ledger, support history — add it through the hook:
 
-```ruby
+```ruby server/config/initializers/spree.rb
 Spree.hooks.register('data_requests.fulfill.extend_payload', 'MyStore::LoyaltyExport')
 
 class MyStore::LoyaltyExport
@@ -85,7 +85,7 @@ drop what Spree contributes.
 You can also veto an erasure — an open dispute, a fraud investigation, a legal
 hold:
 
-```ruby
+```ruby server/config/initializers/spree.rb
 Spree.hooks.register('customers.anonymize.validate', 'MyStore::LegalHold')
 
 class MyStore::LegalHold
@@ -121,7 +121,7 @@ The Omnibus Directive requires that an announced price reduction shows the
 lowest price of the previous 30 days. Spree records every base price change in
 `Spree::PriceHistory` and exposes the lowest prior price on request:
 
-```
+```http
 GET /api/v3/store/products/:id?expand=prior_price
 ```
 
@@ -129,16 +129,22 @@ Recording is on by default and controlled per store with
 `track_price_history`, since a non-EU store has no use for it. Retention
 defaults to 30 days via `price_history_retention_days`; prune with:
 
-```bash
+
+```bash Spree CLI (Docker)
+spree rake spree:price_history:prune
+```
+
+```bash Without Spree CLI
 bundle exec rake spree:price_history:prune
 ```
 
+
 ## Right of withdrawal
 
 EU buyers may withdraw from a distance sale within 14 days of receiving the
 goods. Orders expose the deadline:
 
-```json
+```json Response
 { "withdrawal_period_ends_at": "2026-09-20T10:30:00Z", "within_withdrawal_period": true }
 ```
 
@@ -150,3 +156,10 @@ goodwill, while withdrawal is a statutory right running from delivery.
 The deadline is computed on read from the order's latest delivery, falling back
 to completion while nothing has been delivered. A stored copy would be wrong
 the moment a parcel arrived.
+
+## Related
+
+- [Pricing](pricing.md) — price history and the `prior_price` an Omnibus display needs
+- [Customers](customers.md) — the account an export or erasure acts on
+- [Markets](markets.md) — where `withdrawal_period_days` is set, since the right is regional law
+- [Events](events.md) — subscribing to erasure and data-request activity

package/dist/developer/core-concepts/delivery-setup.md

@@ -65,6 +65,7 @@ That is how a store with a refrigerated warehouse keeps chilled goods from
 being picked at a dry one: order routing only allocates from locations the
 profile covers.
 
+
 ```typescript Admin SDK
 // What profiles the store has
 const profiles = await adminClient.deliveryProfiles.list()
@@ -75,6 +76,19 @@ await adminClient.products.update('prod_xxx', {
 })
 ```
 
+```bash cURL
+# What profiles the store has
+curl 'https://api.mystore.com/api/v3/admin/delivery_profiles' \
+  -H 'X-Spree-API-Key: sk_xxx'
+
+# Ship a product as a download
+curl -X PATCH 'https://api.mystore.com/api/v3/admin/products/prod_xxx' \
+  -H 'X-Spree-API-Key: sk_xxx' \
+  -H 'Content-Type: application/json' \
+  -d '{ "delivery_profile_id": "dp_digital" }'
+```
+
+
 > **NOTE:** Profiles are a template at creation time, not a live binding: changing a
 > profile does not rewrite products already assigned to it. Reassign a product
 > explicitly when it should ship differently.
@@ -85,6 +99,7 @@ A **delivery method** is what the customer picks — "Standard", "Express", "Col
 
 Zones match on country and state, and also on postal code prefixes and ranges, so you can offer same-day delivery to a handful of city postcodes without listing every one:
 
+
 ```typescript Admin SDK
 await adminClient.deliveryZones.create({
   name: 'London same-day',
@@ -95,6 +110,19 @@ await adminClient.deliveryZones.create({
 })
 ```
 
+```bash cURL
+curl -X POST 'https://api.mystore.com/api/v3/admin/delivery_zones' \
+  -H 'X-Spree-API-Key: sk_xxx' \
+  -H 'Content-Type: application/json' \
+  -d '{
+    "name": "London same-day",
+    "members": [
+      { "member_type": "postal_code", "country_code": "GB", "postal_code_prefix": "SW1" }
+    ]
+  }'
+```
+
+
 A zone member is either a whole country, a state, or a postal code prefix or range.
 
 > **NOTE:** Delivery zones cover delivery only. Tax is handled separately — see [Taxes](taxes.md).
@@ -129,6 +157,7 @@ Package types are that vocabulary: the box parcels ship in, and for wholesale,
 the cartons products are packed into and the pallets or containers an order
 leaves on.
 
+
 ```typescript Admin SDK
 await adminClient.packageTypes.create({
   name: 'Standard mailer',
@@ -139,6 +168,20 @@ await adminClient.packageTypes.create({
 })
 ```
 
+```bash cURL
+curl -X POST 'https://api.mystore.com/api/v3/admin/package_types' \
+  -H 'X-Spree-API-Key: sk_xxx' \
+  -H 'Content-Type: application/json' \
+  -d '{
+    "name": "Standard mailer",
+    "kind": "box",
+    "length": 30, "width": 20, "height": 15, "dimensions_unit": "cm",
+    "weight": 0.4, "weight_unit": "kg",
+    "default": true
+  }'
+```
+
+
 One row is marked `default`, and that is the box quotes are built on. Marking
 another one default demotes the first, so there is never more than one.
 
@@ -162,6 +205,7 @@ falling back to the marketplace's when a seller has not recorded one. Sellers
 manage theirs through the Seller API, and can also pack products into the
 marketplace's cartons — those they read but cannot change.
 
+
 ```typescript Seller SDK
 // Their own packaging — what the seller panel's settings page lists.
 const { data: mine } = await sellerClient.packageTypes.list({ owner: 'mine' })
@@ -176,6 +220,19 @@ available.forEach((row) => {
 })
 ```
 
+```bash cURL
+# The seller's own packaging
+curl 'https://marketplace.example.com/api/v3/seller/package_types?owner=mine' \
+  -H 'Authorization: Bearer $SELLER_JWT' \
+  -H 'X-Spree-Seller-Id: sel_xxx'
+
+# Theirs plus the marketplace's shared rows
+curl 'https://marketplace.example.com/api/v3/seller/package_types' \
+  -H 'Authorization: Bearer $SELLER_JWT' \
+  -H 'X-Spree-Seller-Id: sel_xxx'
+```
+
+
 A seller's settings page asks for `owner: 'mine'`. A list mixing both owners
 reads as "packaging is configured" while the seller has recorded nothing of
 their own, which makes the shipping-box requirement look broken rather than