@mercurjs/docs 2.2.1 → 2.3.0-canary.1

package/content/platform/store/concepts/team.mdx

@@ -0,0 +1,50 @@
+---
+title: "Team & members"
+sidebarTitle: "Team & members"
+description: "Members, roles, invites, and the many-to-many store relationship."
+---
+
+This page covers how a store's team is modeled and how access is structured.
+
+## Member
+
+A member is a dashboard user who can manage one or more stores. A member is
+represented by the `Member` data model (table `member`, id prefix `mem`). Their
+identity is tied to their `email`, which is unique across the system.
+
+## Seller member
+
+The relationship between stores and members is many-to-many. A store can have
+several members, and a member can belong to several stores. Each membership is a
+`SellerMember` record, the pivot between `Seller` and `Member`, unique on
+`(seller_id, member_id)`.
+
+```ts
+await addSellerMemberWorkflow(container).run({
+  input: {
+    seller_id: "sel_123",
+    member: { email: "ops@acme.com" },
+  },
+})
+```
+
+Every membership carries a `role_id`, resolved against the RBAC roles module, and
+an `is_owner` flag.
+
+<Tip>
+  A store must always keep at least one member with admin access. The last admin
+  cannot be removed or demoted.
+</Tip>
+
+## Member invite
+
+Pending invitations are represented by the `MemberInvite` data model. If an
+invited email already belongs to a user, accepting the invite links the new store
+association to their existing account instead of creating a new one.
+
+## Store switcher
+
+A user who belongs to several stores uses the store switcher in the Vendor panel
+to change the active store. Each store context is fully isolated. Switching stores
+shows only that store's offers, orders, and payouts, and it never leaks data
+across stores.

package/content/platform/store/guides/create-a-store.mdx

@@ -0,0 +1,55 @@
+---
+title: "Create a store"
+sidebarTitle: "Create a store"
+description: "Create a seller programmatically with createSellersWorkflow."
+---
+
+In this guide, you'll learn how to create a store from your own server code. This
+is useful in a seed script, a custom API route, or an onboarding flow.
+
+Mercur exposes a `createSellersWorkflow` that creates the `Seller` record along
+with its defaults. Run it from any place that has access to the Medusa container.
+
+## Run the workflow
+
+```ts title="src/api/custom/route.ts"
+import type { MedusaRequest, MedusaResponse } from "@medusajs/framework/http"
+import { createSellersWorkflow } from "@mercurjs/core/workflows"
+
+export async function POST(req: MedusaRequest, res: MedusaResponse) {
+  const { result } = await createSellersWorkflow(req.scope).run({
+    input: {
+      sellers: [
+        {
+          name: "Acme Supplies",
+          email: "team@acme.com",
+          currency_code: "usd",
+        },
+      ],
+    },
+  })
+
+  res.status(201).json({ seller: result[0] })
+}
+```
+
+<Note>
+  An operator can set a new store to `open` right away. A store created through
+  the public self-registration flow starts in `pending_approval` and waits for
+  operator review. See [Moderate stores](/platform/store/guides/moderate-a-store).
+</Note>
+
+## Attach custom data
+
+The workflow accepts an `additional_data` payload. It is passed to the workflow's
+hooks, so you can persist marketplace-specific data alongside the store without
+forking the workflow.
+
+```ts
+await createSellersWorkflow(req.scope).run({
+  input: {
+    sellers: [{ name: "Acme Supplies", email: "team@acme.com", currency_code: "usd" }],
+    additional_data: { referral_code: "SPRING25" },
+  },
+})
+```

package/content/platform/store/guides/manage-the-team.mdx

@@ -0,0 +1,55 @@
+---
+title: "Manage the team"
+sidebarTitle: "Manage the team"
+description: "Invite and add store members from server code."
+---
+
+In this guide, you'll learn how to manage a store's team from your own server
+code. You can invite members, add them directly, and update their roles.
+
+## Invite a member
+
+`inviteSellerWorkflow` creates a `MemberInvite` and sends the invitation email.
+The invitee sets up access and is linked to the store when they accept.
+
+```ts title="src/api/custom/invite/route.ts"
+import type { MedusaRequest, MedusaResponse } from "@medusajs/framework/http"
+import { inviteSellerWorkflow } from "@mercurjs/core/workflows"
+
+export async function POST(req: MedusaRequest, res: MedusaResponse) {
+  await inviteSellerWorkflow(req.scope).run({
+    input: {
+      email: "ops@acme.com",
+      seller_id: req.params.id,
+    },
+  })
+
+  res.sendStatus(200)
+}
+```
+
+## Add a member directly
+
+When you already have the user, for example during a migration, add them to a
+store without the invite step. Use `addSellerMemberWorkflow`.
+
+```ts
+import { addSellerMemberWorkflow } from "@mercurjs/core/workflows"
+
+await addSellerMemberWorkflow(container).run({
+  input: {
+    seller_id: "sel_123",
+    member: { email: "ops@acme.com" },
+  },
+})
+```
+
+<Tip>
+  Every store must keep at least one admin member. A workflow that would remove or
+  demote the last admin fails instead of leaving a store unadministered.
+</Tip>
+
+## Accept an invite
+
+The invitee's acceptance runs through `acceptMemberInviteWorkflow`. It links the
+member to the store, and if the email already exists, it reuses their account.

package/content/platform/store/guides/moderate-a-store.mdx

@@ -0,0 +1,59 @@
+---
+title: "Moderate stores"
+sidebarTitle: "Moderate stores"
+description: "Approve, suspend, and terminate stores from server code."
+---
+
+In this guide, you'll learn how to drive a store through its lifecycle from your
+own server code. Each transition has a dedicated workflow, so the side effects
+(events, notifications, and compensation) run consistently.
+
+## Approve a store
+
+Move a `pending_approval` store to `open` with `approveSellerWorkflow`.
+
+```ts title="src/api/custom/approve/route.ts"
+import type { MedusaRequest, MedusaResponse } from "@medusajs/framework/http"
+import { approveSellerWorkflow } from "@mercurjs/core/workflows"
+
+export async function POST(req: MedusaRequest, res: MedusaResponse) {
+  await approveSellerWorkflow(req.scope).run({
+    input: { seller_id: req.params.id },
+  })
+
+  res.sendStatus(200)
+}
+```
+
+## Suspend and reinstate
+
+Freeze an `open` store's operations, then reinstate it once the issue is resolved.
+
+```ts
+import {
+  suspendSellerWorkflow,
+  unsuspendSellerWorkflow,
+} from "@mercurjs/core/workflows"
+
+await suspendSellerWorkflow(container).run({ input: { seller_id } })
+// ...later
+await unsuspendSellerWorkflow(container).run({ input: { seller_id } })
+```
+
+## Terminate a store
+
+```ts
+import { terminateSellerWorkflow } from "@mercurjs/core/workflows"
+
+await terminateSellerWorkflow(container).run({ input: { seller_id } })
+```
+
+<Warning>
+  Termination is irreversible. All orders and payouts must be resolved first.
+</Warning>
+
+## React to lifecycle changes
+
+To run your own side effects when a store's status changes, subscribe to the
+events these workflows emit instead of polling. The
+[Event reference](/platform/store/reference/events) lists the event names.

package/content/platform/store/overview.mdx

@@ -0,0 +1,86 @@
+---
+title: "Store"
+sidebarTitle: "Overview"
+description: "Manage sellers, their teams, and their lifecycle on the marketplace."
+---
+
+Use Mercur to control who is allowed to sell on your marketplace and what each
+person on a store's team can do.
+
+Governing your sellers starts here. The Store domain decides who may sell,
+enforces role-based access so every member acts only within their store, and
+keeps each store's data isolated from the rest. On top of that control layer, a
+store carries its own team, a governed account lifecycle, and the business
+details used to settle payouts. Every offer, order, payout, and storefront page
+belongs to a store, and all of it is exposed directly through the Admin and
+Vendor APIs.
+
+<Note>
+  A store is the `Seller` entity. The Admin and Vendor panels call it a "Store".
+  The API and core modules call the same record a `Seller` (id prefix `sel`). You
+  never need to know Medusa to work with stores.
+</Note>
+
+## Key features
+
+- **Role-based access control:** many-to-many members, roles resolved per store, and a store switcher for users who belong to several stores.
+- **Store isolation:** each store sees and acts on only its own data.
+- **Governed lifecycle:** a four-state account model with operator-only transitions.
+- **Self-service onboarding:** create stores yourself, or let sellers register publicly.
+- **Scheduled closures:** temporary offline windows that don't change account status.
+- **Premium placement:** an operator-only flag the storefront uses for featured curation.
+- **Single-currency accounts:** each store settles in exactly one currency.
+
+## Get started
+
+Learn how the domain fits together.
+
+<CardGroup cols={2}>
+  <Card title="The store" icon="store" href="/platform/store/concepts/store-entity">
+    The seller entity, its profile, currency, and business identity.
+  </Card>
+  <Card title="Team & members" icon="users" href="/platform/store/concepts/team">
+    Multi-user stores, roles, invites, and the store switcher.
+  </Card>
+  <Card title="Lifecycle" icon="arrows-rotate" href="/platform/store/concepts/lifecycle">
+    Statuses, transitions, scheduled closures, and premium.
+  </Card>
+</CardGroup>
+
+## Examples
+
+Build against the Store domain in your own code.
+
+<CardGroup cols={2}>
+  <Card title="Create a store" icon="plus" href="/platform/store/guides/create-a-store">
+    Run `createSellersWorkflow` from a route or seed script.
+  </Card>
+  <Card title="Moderate stores" icon="gavel" href="/platform/store/guides/moderate-a-store">
+    Approve, suspend, and terminate stores in code.
+  </Card>
+  <Card title="Manage the team" icon="user-plus" href="/platform/store/guides/manage-the-team">
+    Invite and add members programmatically.
+  </Card>
+</CardGroup>
+
+## Resources
+
+Data models, workflows, service methods, and events for the Store domain.
+
+<CardGroup cols={2}>
+  <Card title="Data models" icon="table" href="/platform/store/reference/data-models">
+    The `Seller`, `Member`, and related entities.
+  </Card>
+  <Card title="Links" icon="link" href="/platform/store/reference/links">
+    How the Store domain links to other modules.
+  </Card>
+  <Card title="Workflows" icon="diagram-project" href="/platform/store/reference/workflows">
+    Seller and member lifecycle workflows.
+  </Card>
+  <Card title="Service" icon="gear" href="/platform/store/reference/service">
+    Module service methods for working with records directly.
+  </Card>
+  <Card title="Events" icon="bell" href="/platform/store/reference/events">
+    Events emitted as stores and members change.
+  </Card>
+</CardGroup>

package/content/platform/store/reference/data-models.mdx

@@ -0,0 +1,89 @@
+---
+title: "Data models"
+sidebarTitle: "Data models"
+description: "The data models owned by the Store (Seller) domain."
+---
+
+The Store domain is owned by the **Seller module**. This reference lists its data
+models and their fields. For the full module overview, see the
+[Store overview](/platform/store/overview).
+
+## Seller
+
+Table `seller`, id prefix `sel`. The store account and profile.
+
+| Field | Type | Notes |
+| --- | --- | --- |
+| `id` | text | Primary key |
+| `name` | text | Unique, searchable |
+| `handle` | text | Unique; auto-generated from `name` when omitted |
+| `email` | text | Unique, searchable |
+| `phone` | text | Nullable |
+| `description` | text | Nullable |
+| `logo` / `banner` | text | Nullable |
+| `website_url` | text | Nullable |
+| `external_id` | text | Nullable; unique when set |
+| `currency_code` | text | The store's single operating currency |
+| `status` | enum | `SellerStatus`, default `pending_approval` |
+| `status_reason` | text | Nullable |
+| `approved_at` / `rejected_at` | dateTime | Nullable |
+| `is_premium` | boolean | Default `false`; operator-set only |
+| `closed_from` / `closed_to` | dateTime | Nullable; scheduled closure window |
+| `closure_note` | text | Nullable |
+| `metadata` | json | Nullable |
+
+Relations: `professional_details`, `address`, `payment_details` (one-to-one,
+deleted with the seller), `members` (many-to-many through `SellerMember`),
+`member_invites` (one-to-many, deleted with the seller).
+
+## ProfessionalDetails
+
+Table `professional_details`, id prefix `selprodet`. Presence marks the store as
+a registered business.
+
+| Field | Type |
+| --- | --- |
+| `corporate_name` | text, nullable |
+| `registration_number` | text, nullable |
+| `tax_id` | text, nullable |
+
+## SellerAddress
+
+Table `seller_address`, id prefix `seladdr`. Fields: `name`, `company`,
+`first_name`, `last_name`, `address_1`, `address_2`, `city`, `country_code`,
+`province`, `postal_code`, `phone`, and `metadata`. All are nullable.
+
+## PaymentDetails
+
+Table `payment_details`, id prefix `selpaydet`. Fields: `country_code`,
+`holder_name`, `bank_name`, `iban`, `bic`, `routing_number`, and
+`account_number`. All are nullable.
+
+## Member
+
+Table `member`, id prefix `mem`. A dashboard user that can belong to one or more
+stores.
+
+| Field | Type | Notes |
+| --- | --- | --- |
+| `email` | text | Unique, searchable |
+| `first_name` / `last_name` | text | Nullable |
+| `locale` | text | Nullable |
+| `is_active` | boolean | Default `true` |
+| `metadata` | json | Nullable |
+
+## SellerMember
+
+Table `seller_member`, id prefix `selmem`. Pivot between `Seller` and `Member`,
+unique on `(seller_id, member_id)`.
+
+| Field | Type | Notes |
+| --- | --- | --- |
+| `role_id` | text | Nullable; resolved against the RBAC roles module |
+| `is_owner` | boolean | Default `false` |
+| `metadata` | json | Nullable |
+
+## MemberInvite
+
+Table `member_invite`, id prefix `meminv`. A pending team invitation, carrying
+the invited `email`, target `seller_id`, `role_id`, and an expiry.

package/content/platform/store/reference/events.mdx

@@ -0,0 +1,43 @@
+---
+title: "Event reference"
+sidebarTitle: "Events"
+description: "Events emitted by the Store domain, for subscribers and side effects."
+---
+
+The Store domain emits events as stores and members change. Subscribe to them to
+run side effects such as sending notifications, syncing external systems, or
+kicking off follow-up workflows, instead of polling.
+
+```ts title="src/subscribers/store-approved.ts"
+import type { SubscriberArgs, SubscriberConfig } from "@medusajs/framework"
+
+export default async function storeApprovedHandler({
+  event,
+  container,
+}: SubscriberArgs<{ id: string }>) {
+  const sellerId = event.data.id
+  // ...send a welcome email, provision resources, etc.
+}
+
+export const config: SubscriberConfig = {
+  event: "seller.approved",
+}
+```
+
+## Store events
+
+| Event | Emitted when | Payload |
+| --- | --- | --- |
+| `seller.created` | A store is created | `{ id }` |
+| `seller.updated` | A store's profile changes | `{ id }` |
+| `seller.approved` | A store is approved (`→ open`) | `{ id }` |
+| `seller.suspended` | A store is suspended | `{ id }` |
+| `seller.terminated` | A store is terminated | `{ id }` |
+
+## Member events
+
+| Event | Emitted when | Payload |
+| --- | --- | --- |
+| `member_invite.created` | A team invite is sent | `{ id }` |
+| `member_invite.accepted` | An invite is accepted | `{ id }` |
+| `seller_member.created` | A member is added to a store | `{ id }` |

package/content/platform/store/reference/links.mdx

@@ -0,0 +1,71 @@
+---
+title: "Links to other modules"
+sidebarTitle: "Links"
+description: "How the Store (Seller) domain links to other modules across the marketplace."
+---
+
+Modules in Mercur never reference each other directly. They connect through
+**module links**. The Seller module is the most linked domain in the marketplace,
+and almost every other module attaches to a store. Once a link is defined, you
+retrieve related records with `query.graph` using the link alias.
+
+```ts
+const { data: stores } = await query.graph({
+  entity: "seller",
+  fields: ["id", "name", "offers.*", "payout_account.*"],
+})
+```
+
+## Commerce
+
+| Linked module | Relationship |
+| --- | --- |
+| **Offer** | A store has many offers (`offer.seller_id`, read-only). Offers are how a store sells against a master product. |
+| **Product** | Many-to-many allowlist (`product_seller`) that controls which stores may sell a given master product. |
+| **Product category** | Many-to-many link to the categories a store is associated with. |
+| **Order** | Each order belongs to one store; a store has many orders. |
+
+## Payouts
+
+| Linked module | Relationship |
+| --- | --- |
+| **Payout** | A store has many payouts. |
+| **Payout account** | A store has one payout account (its provider onboarding record). |
+
+## Customers
+
+| Linked module | Relationship |
+| --- | --- |
+| **Customer** | Many-to-many link to the customers associated with a store. |
+| **Customer group** | A customer group is owned by exactly one store; a store owns many groups. |
+
+## Fulfillment & inventory
+
+| Linked module | Relationship |
+| --- | --- |
+| **Shipping profile** | A store has many shipping profiles. |
+| **Shipping option** | A store has many shipping options. |
+| **Service zone** | A store has many service zones. |
+| **Fulfillment set** | A store has many fulfillment sets. |
+| **Stock location** | A store has many stock locations. |
+| **Inventory item** | A store has many inventory items. |
+
+## Pricing & promotions
+
+| Linked module | Relationship |
+| --- | --- |
+| **Price list** | A store has many price lists. |
+| **Promotion** | A store has many promotions. |
+| **Campaign** | A store has many campaigns. |
+
+## Access & reviews
+
+| Linked module | Relationship |
+| --- | --- |
+| **RBAC role** | A member's role on a store (`seller_member.role_id`, read-only) resolves against the roles module. |
+| **Review** | A store has many reviews. |
+
+<Note>
+  Read-only links (Offer, RBAC role) are resolved from the field on the owning
+  record and can't be written through the link itself.
+</Note>

package/content/platform/store/reference/service.mdx

@@ -0,0 +1,51 @@
+---
+title: "Service reference"
+sidebarTitle: "Service"
+description: "The Seller module service and its methods for working with records directly."
+---
+
+The Seller module exposes a service you can resolve from the Medusa container to
+read and write records directly, without going through a workflow. Use it inside
+custom services, subscribers, or scheduled jobs.
+
+```ts
+import { MercurModules } from "@mercurjs/types"
+
+const sellerModuleService = container.resolve(MercurModules.SELLER)
+
+const [sellers, count] = await sellerModuleService.listAndCountSellers({
+  status: "open",
+})
+```
+
+## Generated methods
+
+Each data model gets a standard set of auto-generated methods. For `Seller`:
+
+| Method | Description |
+| --- | --- |
+| `createSellers(data)` | Create one or more stores |
+| `retrieveSeller(id, config?)` | Retrieve a store by id |
+| `listSellers(filters?, config?)` | List stores matching filters |
+| `listAndCountSellers(filters?, config?)` | List stores with a total count |
+| `updateSellers(data)` | Update one or more stores |
+| `deleteSellers(ids)` | Delete one or more stores |
+
+The same set exists for every model in the module, such as `Member`, `SellerMember`,
+`MemberInvite`, `ProfessionalDetails`, `SellerAddress`, and `PaymentDetails`
+(e.g. `createMembers`, `listMemberInvites`, `updatePaymentDetails`).
+
+## Team methods
+
+| Method | Description |
+| --- | --- |
+| `addSellerMember(data)` | Attach a member to a store |
+| `removeSellerMember(sellerId, memberId)` | Detach a member from a store |
+| `createMemberInvites(data)` | Create pending team invitations |
+| `updateMember(data)` | Update a member record |
+
+<Warning>
+  Prefer [workflows](/platform/store/reference/workflows) for anything with side
+  effects (status changes, invites, payouts). The service writes records
+  directly and does **not** emit events or run compensation.
+</Warning>

package/content/platform/store/reference/workflows.mdx

@@ -0,0 +1,35 @@
+---
+title: "Workflows"
+sidebarTitle: "Workflows"
+description: "Seller and member workflows, service methods, and events."
+---
+
+This reference lists the workflows, service methods, and events for the Store
+domain. Import workflows from `@mercurjs/core/workflows` and run them against the
+Medusa container.
+
+## Seller workflows
+
+| Workflow | Input | Purpose |
+| --- | --- | --- |
+| `createSellersWorkflow` | `{ sellers[], additional_data? }` | Create stores with defaults |
+| `updateSellersWorkflow` | `{ selector, update }` | Update store fields |
+| `deleteSellersWorkflow` | `{ ids[] }` | Delete stores |
+| `approveSellerWorkflow` | `{ seller_id, additional_data? }` | `pending_approval` → `open` |
+| `suspendSellerWorkflow` | `{ seller_id }` | `open` → `suspended` |
+| `unsuspendSellerWorkflow` | `{ seller_id }` | `suspended` → `open` |
+| `terminateSellerWorkflow` | `{ seller_id }` | → `terminated` (irreversible) |
+
+## Member workflows
+
+| Workflow | Input | Purpose |
+| --- | --- | --- |
+| `inviteSellerWorkflow` | `{ email, seller_id }` | Create + send a member invite |
+| `acceptMemberInviteWorkflow` | `{ token }` | Accept an invite, link the member |
+| `addSellerMemberWorkflow` | `{ seller_id, member }` | Add a member directly |
+| `removeSellerMemberWorkflow` | `{ seller_id, member_id }` | Revoke access |
+| `updateMemberRoleWorkflow` | `{ id, role_id }` | Change a member's role |
+
+To work with records directly instead of through a workflow, see the
+[Service reference](/platform/store/reference/service). To run side effects when
+a store changes, see the [Event reference](/platform/store/reference/events).

package/content/references/api/admin/commission-rates/create-commission-rate.mdx

@@ -11,7 +11,7 @@ Creates a commission rate, optionally with scoping rules and per-currency values
 <ParamField body="name" type="string" required>The rate's display name.</ParamField>
 <ParamField body="code" type="string" required>Unique code identifying the rate.</ParamField>
 <ParamField body="type" type="string" required>The rate type: `fixed` or `percentage`.</ParamField>
-<ParamField body="value" type="number" required>The commission value — a percentage or a fixed amount.</ParamField>
+<ParamField body="value" type="number" required>The commission value, a percentage or a fixed amount.</ParamField>
 <ParamField body="currency_code" type="string">Currency of a fixed rate's value.</ParamField>
 <ParamField body="include_tax" type="boolean">Whether commission is calculated on tax-inclusive amounts.</ParamField>
 <ParamField body="include_shipping" type="boolean">Whether shipping is included in the commission base.</ParamField>

package/content/references/api/admin/commission-rates/list-commission-rates.mdx

@@ -7,7 +7,7 @@ description: "Retrieve a paginated list of commission rates."
 Returns commission rates with their rules and currency-specific values.
 
 <Note>
-  `scope_type` is a virtual filter derived from each rate's rules — it is not a
+  `scope_type` is a virtual filter derived from each rate's rules. It is not a
   stored column. Use it to filter rates by the scope their rules target.
 </Note>
 
@@ -35,7 +35,7 @@ Returns commission rates with their rules and currency-specific values.
     <ResponseField name="name" type="string">The rate's display name.</ResponseField>
     <ResponseField name="code" type="string">The rate's unique code.</ResponseField>
     <ResponseField name="type" type="string">The rate type: `fixed` or `percentage`.</ResponseField>
-    <ResponseField name="value" type="number">The commission value — a percentage or a fixed amount.</ResponseField>
+    <ResponseField name="value" type="number">The commission value, a percentage or a fixed amount.</ResponseField>
     <ResponseField name="currency_code" type="string | null">Currency of a fixed rate's value.</ResponseField>
     <ResponseField name="include_tax" type="boolean">Whether commission is calculated on tax-inclusive amounts.</ResponseField>
     <ResponseField name="include_shipping" type="boolean">Whether shipping is included in the commission base.</ResponseField>

package/content/references/api/admin/commission-rates/update-commission-rate.mdx

@@ -20,7 +20,7 @@ Updates a commission rate's properties.
 <ParamField body="name" type="string">The rate's display name.</ParamField>
 <ParamField body="code" type="string">Unique code identifying the rate.</ParamField>
 <ParamField body="type" type="string">The rate type: `fixed` or `percentage`.</ParamField>
-<ParamField body="value" type="number">The commission value — a percentage or a fixed amount.</ParamField>
+<ParamField body="value" type="number">The commission value, a percentage or a fixed amount.</ParamField>
 <ParamField body="currency_code" type="string">Currency of a fixed rate's value.</ParamField>
 <ParamField body="include_tax" type="boolean">Whether commission is calculated on tax-inclusive amounts.</ParamField>
 <ParamField body="include_shipping" type="boolean">Whether shipping is included in the commission base.</ParamField>

package/content/references/api/admin/offers/batch-create-offers.mdx

@@ -10,13 +10,13 @@ Creates multiple offers on behalf of a seller. The authenticated admin user is r
 
 <ParamField body="seller_id" type="string" required>ID of the seller the offers belong to.</ParamField>
 <ParamField body="offers" type="object[]" required>
-  The offers to create — between 1 and 100.
+  The offers to create, between 1 and 100.
   <Expandable title="properties">
     <ParamField body="sku" type="string" required>The offer's SKU.</ParamField>
     <ParamField body="variant_id" type="string" required>ID of the product variant to offer.</ParamField>
     <ParamField body="shipping_profile_id" type="string" required>ID of the seller's shipping profile.</ParamField>
     <ParamField body="prices" type="object[]" required>
-      Offer prices — at least one.
+      Offer prices, at least one.
       <Expandable title="properties">
         <ParamField body="amount" type="number" required>The price amount.</ParamField>
         <ParamField body="currency_code" type="string" required>The price currency.</ParamField>
@@ -26,7 +26,7 @@ Creates multiple offers on behalf of a seller. The authenticated admin user is r
       </Expandable>
     </ParamField>
     <ParamField body="inventory_items" type="object[]" required>
-      Inventory items backing the offer — at least one.
+      Inventory items backing the offer, at least one.
       <Expandable title="properties">
         <ParamField body="title" type="string">The inventory item's title.</ParamField>
         <ParamField body="sku" type="string">The inventory item's SKU.</ParamField>