bigcommerce-commerce/skills/bc-orders/SKILL.md
Work with BigCommerce orders — order lifecycle, statuses, line items, shipments, refunds, order metafields, and fulfillment. Use when building order management integrations or processing orders programmatically.
npx skillsauth add orcaqubits/agentic-commerce-claude-plugins bc-ordersInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
Fetch live docs:
site:developer.bigcommerce.com rest orders for Orders API referencebigcommerce order api v2 v3 for endpoint availabilitybigcommerce order status list for status definitionsOrders are primarily managed via V2 API:
| Endpoint | Methods | Description |
|----------|---------|-------------|
| /v2/orders | GET, POST, PUT | Orders CRUD |
| /v2/orders/{id}/products | GET | Order line items |
| /v2/orders/{id}/shipping_addresses | GET | Shipping addresses |
| /v2/orders/{id}/coupons | GET | Applied coupons |
| /v2/orders/{id}/shipments | GET, POST, PUT, DELETE | Shipments |
| /v2/orders/{id}/taxes | GET | Tax details |
| /v2/order_statuses | GET | Available order statuses |
| Endpoint | Description |
|----------|-------------|
| /v3/orders/{id}/metafields | Order metafields |
| /v3/orders/{id}/payment_actions | Payment actions (capture, void) |
| /v3/orders/settings | Order-level settings |
| /v3/orders/{id}/transactions | Payment transactions |
Incomplete → Pending → Awaiting Payment → Awaiting Fulfillment
→ Partially Shipped → Shipped → Completed
→ Awaiting Pickup → Picked Up
→ Cancelled / Declined / Refunded / Disputed
| ID | Status | Description | |----|--------|-------------| | 0 | Incomplete | Checkout not completed | | 1 | Pending | Awaiting processing | | 2 | Shipped | All items shipped | | 3 | Partially Shipped | Some items shipped | | 4 | Refunded | Fully refunded | | 5 | Cancelled | Order cancelled | | 6 | Declined | Payment declined | | 7 | Awaiting Payment | Payment not yet received | | 8 | Awaiting Pickup | Ready for customer pickup | | 9 | Awaiting Shipment | Awaiting fulfillment | | 10 | Completed | Order completed | | 11 | Awaiting Fulfillment | Ready to be fulfilled | | 12 | Manual Verification Required | Payment needs manual review | | 13 | Disputed | Payment dispute opened | | 14 | Partially Refunded | Partial refund issued |
Create custom statuses via admin or API — they map to one of the standard status groups for reporting.
Key fields returned by GET /v2/orders/{id}:
id — order numberstatus_id — current statusstatus — status labelsubtotal_inc_tax, subtotal_ex_taxtotal_inc_tax, total_ex_taxdiscount_amountshipping_cost_inc_tax, shipping_cost_ex_taxitems_total — total number of itemspayment_method — payment providercurrency_codebilling_address — billing address objectcustomer_id — associated customerdate_created, date_modifiedGET /v2/orders/{id}/products returns:
product_id, variant_idname, sku, quantityprice_inc_tax, price_ex_taxtotal_inc_tax, total_ex_taxproduct_options — selected optionsPOST /v2/orders with:
customer_id or billing_addressproducts array with product_id, quantity, and optionally price_inc_taxstatus_idshipping_addresses arrayUseful for: POS integrations, phone orders, order imports.
POST /v2/orders/{id}/shipments:
{
"tracking_number": "1Z999AA10123456784",
"shipping_method": "UPS Ground",
"shipping_provider": "ups",
"items": [
{ "order_product_id": 15, "quantity": 1 }
]
}
POST /v3/orders/{id}/payment_actions/refund:
{
"items": [
{
"item_type": "PRODUCT",
"item_id": 123,
"quantity": 1,
"reason": "Customer requested return"
}
]
}
Store custom data on orders (V3):
POST /v3/orders/{id}/metafieldsnamespace + key = unique per ordermin_id / max_id — ID rangemin_date_created / max_date_created — date rangestatus_id — filter by statuscustomer_id — filter by customeremail — filter by customer emailpayment_method — filter by payment provideris_deleted — include/exclude deleted ordersV2 uses page and limit parameters, plus Link headers for navigation.
store/order/created, store/order/statusUpdated) for real-time order processingFetch the BigCommerce Orders API reference for exact endpoint paths, request/response schemas, and status definitions before implementing.
development
Build with Spree's headless Next.js storefront — the official `spree/storefront` repo (Next.js 16 App Router with Server Actions and Turbopack, React 19 Server Components, Tailwind CSS 4, TypeScript 5, `@spree/sdk`, Sentry), server-only auth (httpOnly JWT cookies + publishable key), MeiliSearch faceted catalog, one-page checkout with Apple/Google Pay/Klarna/Affirm/SEPA, multi-region market routing, GA4 + JSON-LD SEO, and Vercel/Docker deployment. Use when forking or customizing the storefront, or evaluating headless adoption.
tools
Build Spree extensions as Rails engines — gem scaffolding, `bin/rails g spree:extension`, mounting routes/migrations/assets, the modern `prepend` decorator pattern (`*_decorator.rb` with `self.prepended(base)`), generators (`spree:model_decorator`, `spree:controller_decorator`), the four customization surfaces in preference order (Events > Webhooks > Dependencies > Decorators), Spree::Dependencies for swapping service objects, gem release/versioning, and the deprecated Deface engine. Use when building a reusable Spree extension or adding non-trivial customization to an app.
development
Build with Spree's event bus and Webhooks 2.0 — `Spree::Events` publication, `Spree::Subscriber` DSL with `subscribes_to` and `on`, wildcard matching, lifecycle events (`{model}.created/.updated/.deleted` via `publishes_lifecycle_events`), the canonical event catalog (order.*, payment.*, shipment.*, product.*), Webhooks 2.0 endpoints, HMAC-SHA256 signing (`X-Spree-Webhook-Signature`), exponential-backoff retries, and Sidekiq job orchestration. Use when wiring event-driven business logic, building webhook consumers, or replacing ActiveSupport callback chains.
tools
Cross-cutting Spree development patterns — the customization preference hierarchy (Events > Webhooks > Dependencies > Decorators), `Spree::Dependencies` service-object swapping, the `_decorator.rb` + `prepend` + `self.prepended` idiom, idempotent subscribers and webhook receivers, multi-store scoping discipline, prefixed IDs, calculator polymorphism (shipping/promotion/tax share the base), service-object composition with `dry-monads` or simple results, why to avoid `class_eval` reopening and Deface, and Spree-on-Rails idioms (Hotwire/Turbo Stimulus, ActiveStorage, Action Cable, Sidekiq). Use when designing the architecture of a Spree extension or solving cross-cutting concerns.