@spree/docs 0.1.230 → 0.1.232

package/dist/api-reference/store.yaml

@@ -15251,6 +15251,34 @@ components:
       required:
       - id
       x-typelizer: true
+    StoreCreditEvent:
+      type: object
+      properties:
+        id:
+          type: string
+        action:
+          type: string
+        authorization_code:
+          type: string
+          nullable: true
+        display_action:
+          type: string
+          nullable: true
+        amount:
+          type: string
+        display_amount:
+          type: string
+        created_at:
+          type: string
+      required:
+      - id
+      - action
+      - authorization_code
+      - display_action
+      - amount
+      - display_amount
+      - created_at
+      x-typelizer: true
     StoreCredit:
       type: object
       properties:

package/dist/developer/agentic/agent-skills.md

@@ -52,7 +52,7 @@ The plugin delivers everything the skills CLI does **plus** `/spree:doctor`, `/s
 
 The skills detect your project flavor before running commands:
 
-- **create-spree-app projects** (Docker, Rails app in `backend/`) — commands route through the [Spree CLI](../cli/quickstart.md) (`spree migrate`, `spree console`, …).
+- **create-spree-app projects** (Docker, Rails app in `server/`) — commands route through the [Spree CLI](../cli/quickstart.md) (`spree migrate`, `spree console`, …).
 - **Classic Rails apps** (Spree gems in a plain Rails app, no Docker — typical for apps created before Spree 5.4) — the skills fall back to native commands (`bin/rails`, `bundle exec rake`) from the app root.
 
 ## Updating

package/dist/developer/cli/quickstart.md

@@ -114,13 +114,13 @@ Production upgrades only need the third stage — `bundle install` and `db:migra
 
 ### `spree eject`
 
-Switch from the prebuilt Docker image to building from your local `backend/` directory. This lets you customize the Rails app — add gems, override models, add migrations, etc.
+Switch from the prebuilt Docker image to building from your local `server/` directory. This lets you customize the Rails app — add gems, override models, add migrations, etc.
 
 ```bash
 spree eject
 ```
 
-After ejecting, the Docker image is built from `backend/Dockerfile`. Edit files in `backend/` and run `spree dev` to rebuild and restart with your changes.
+After ejecting, the Docker image is built from `server/Dockerfile`. Edit files in `server/` and run `spree dev` to rebuild and restart with your changes.
 
 See [Customizing the Backend](../create-spree-app/quickstart.md#customizing-the-backend) for details on what you can customize.
 

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

@@ -126,6 +126,7 @@ curl -X POST 'https://api.mystore.com/api/v3/store/customers/me/addresses' \
 
 On a cart you can point at a saved address or send a new one inline:
 
+
 ```typescript Store SDK
 // Reuse something from the address book
 await client.carts.update(cartId, {
@@ -148,6 +149,18 @@ await client.carts.update(cartId, {
 })
 ```
 
+```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 '{
+    "shipping_address_id": "addr_xxx",
+    "billing_address_id": "addr_yyy"
+  }'
+```
+
+
 Setting the shipping address is what makes delivery options and tax appear, so do it before asking the customer to choose delivery. The updated cart comes back with new totals — you don't need a second request.
 
 > **WARNING:** An address is **copied onto the order** when the cart completes, not linked to. Editing a saved address next year does not rewrite last year's invoice — which is exactly what you want when a customer moves house.

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

@@ -94,7 +94,7 @@ const calculators = await adminClient.deliveryMethods.calculators()
 await adminClient.deliveryMethods.create({
   name: 'Standard shipping',
   delivery_zone_id: 'dz_xxx',
-  calculator_type: 'Spree::Calculator::Shipping::FlatRate',
+  calculator_type: 'flat_rate',
   calculator_attributes: {
     preferences: { amount: '7.00', currency: 'USD' },
   },
@@ -105,6 +105,11 @@ await adminClient.deliveryMethods.create({
 spree api get /delivery_methods/calculators
 ```
 
+```bash cURL
+curl 'https://api.mystore.com/api/v3/admin/delivery_methods/calculators' \
+  -H 'X-Spree-API-Key: sk_xxx'
+```
+
 
 Each calculator declares which settings it takes, so a form can be built for it without knowing the calculator in advance — which is how the dashboard renders these.
 

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

@@ -101,15 +101,24 @@ Every change returns the whole cart with new totals, so you never need a second
 
 When a guest signs in, attach their cart to the account:
 
+
 ```typescript Store SDK
 await client.carts.associate(cartId, { spreeToken: 'abc123' })
 ```
 
+```bash cURL
+curl -X POST 'https://api.mystore.com/api/v3/store/carts/cart_xxx/associate' \
+  -H 'X-Spree-API-Key: pk_xxx' \
+  -H 'Authorization: Bearer $CUSTOMER_JWT' \
+  -H 'X-Spree-Token: abc123'
+```
+
+
 ## Checkout requirements
 
 A cart tells you what it still needs before it can be completed:
 
-```json
+```json Response
 {
   "requirements": [
     {
@@ -176,12 +185,21 @@ For providers like Stripe, create a payment session and confirm it with their ow
 
 Discount codes, gift cards and store credit can be applied any time before completion:
 
+
 ```typescript Store SDK
 await client.carts.discountCodes.apply(cartId, 'SUMMER20')
 await client.carts.giftCards.apply(cartId, 'GIFT-XXXX')
 await client.carts.storeCredits.apply(cartId)
 ```
 
+```bash cURL
+curl -X POST 'https://api.mystore.com/api/v3/store/carts/cart_xxx/discount_codes' \
+  -H 'X-Spree-API-Key: pk_xxx' \
+  -H 'Content-Type: application/json' \
+  -d '{ "code": "SUMMER20" }'
+```
+
+
 ## What completion guarantees
 
 Completing a cart moves real money, so Spree is careful about it:

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({