Skip to main content

Localization & Currency

Pass locale and currency headers with any request. For full details, see the Localization reference.

Sales Channels

Select which sales channel scopes a request. The SDK sends the value as the X-Spree-Channel header. Pass either the channel code (e.g. online, pos, wholesale) or the prefixed ID (ch_…) — code is preferred since it’s merchant-meaningful and stable across environments. When omitted, the store’s default channel is used.
The channel scopes product visibility (only products published on that channel are returned), pricing fallback (per-channel pricing rules), and order attribution (a cart created with channel: 'pos' gets order.channel_id set to the POS channel).

Error Handling

Unsuccessful HTTP responses throw a SpreeError. If a proxy or server returns an empty body, non-JSON content, or JSON without a valid Spree error, the error has code http_error, retains the HTTP status, and omits the raw response body. Retry decisions still follow the configured HTTP status policy.

Custom Fetch

You can provide a custom fetch implementation:

Monetary Amounts

All monetary values in the API are returned as strings (e.g., "29.99", "0.0"), not numbers. This preserves decimal precision and avoids floating-point rounding issues.
This applies to all monetary fields across all types: Order, LineItem, Fulfillment, Payment, GiftCard, Price, etc.

Country, Currency and Locale Codes

CountryCode, CurrencyCode and LocaleCode list every code Spree accepts. Each one is both a type and a set of values, so you can autocomplete a code or loop over the list. Your editor shows each code’s name, for example “US Dollar” for CurrencyCode.USD. The Store, Admin and Seller SDKs all export them.
Locale keys use an underscore where the code has a dash (LocaleCode.es_419 is 'es-419'). The lists match the Spree release your SDK version belongs to. The server still decides which codes it accepts, so let it validate input rather than rejecting a value that is missing from these lists.

TypeScript Support

The SDK includes full TypeScript support with generated types from the API serializers:

Available Types

All types are exported as unprefixed names (e.g., Product, Order). Legacy Store* prefixed aliases (e.g., StoreProduct) are still available for backward compatibility.

Core Types

  • Product - Product data
  • Variant - Variant data
  • Cart - Cart data (uses cart_ prefixed IDs)
  • Order - Completed order data (uses or_ prefixed IDs)
  • LineItem - Line item in cart
  • Category - Category
  • Country - Country with states
  • State - State/province
  • Address - Customer address
  • Customer - Customer profile
  • Market - Market configuration (currency, locales, countries)

Commerce Types

  • Payment - Payment record
  • PaymentMethod - Payment method
  • PaymentSession - Provider-agnostic payment session
  • Fulfillment - Fulfillment record
  • DeliveryRate - Delivery rate option
  • DeliveryMethod - Delivery method
  • CreditCard - Saved credit card
  • GiftCard - Gift card
  • Discount - Discount applied to a cart or order

Product Types

  • Media - Product media (images, videos)
  • Price - Price data
  • OptionType - Option type (e.g., Size, Color)
  • OptionValue - Option value (e.g., Small, Red)
  • DigitalLink - Digital download link
  • CustomField - Custom field data

Wishlist Types

  • Wishlist - Wishlist
  • WishlistItem - Wishlist item

Client Types

  • Client - Main client interface
  • StoreClient - Store API client class
  • ClientConfig - Client configuration
  • RequestOptions - Per-request options
  • RetryConfig - Retry behavior configuration

Utility Types

  • PaginatedResponse<T> - Paginated API response
  • ListResponse<T> - List API response
  • AuthTokens - JWT tokens from login
  • AddressParams - Address input parameters
  • UpdateCartParams - Cart update parameters
  • CreatePaymentParams - Direct payment creation parameters
  • CreatePaymentSessionParams - Payment session creation parameters
  • UpdatePaymentSessionParams - Payment session update parameters
  • CompletePaymentSessionParams - Payment session completion parameters
  • ProductFiltersResponse - Product filters response
  • CheckoutRequirement - Checkout requirement ({ step, field, message })

Extending Types

All generated SDK types are TypeScript interfaces, which means you can extend them via declaration merging when you customize API serializers on the backend.

Example: Adding a Brand to Products

If you’ve customized the ProductSerializer in your app to include a brand_id attribute:
You can extend the SDK type in your frontend code so TypeScript knows about the new field:
Now brand_id is available on every Product across your app — no type casting needed:

Extending Zod Schemas

If you use the SDK’s Zod schemas for runtime validation, extend them with .extend():
Declaration merging only affects TypeScript types (compile-time). Zod schemas perform runtime validation and must be extended separately if you need validation of custom fields.