Skip to main content
The FairShare cart API gives you complete programmatic control over the shopper’s cart. You can read cart state, add or remove items, manage subscription plans, trigger checkout, and control the cart widget UI — either through JavaScript or by adding data-* attributes directly to your HTML elements. Both approaches work together, so you can mix declarative HTML for simple cases and the JavaScript API for anything more complex.

Declarative HTML Controls

For common actions you don’t need to write any JavaScript. Add the following data-* attributes to any HTML element and FairShare handles the rest. Opening and closing the cart panel:
Adding a product to the cart — set data-fluid-add-to-cart to the variant ID:

Cart Display

Place a <span> with id="fluid-cart-count" anywhere in your markup and FairShare will keep its text content in sync with the current cart item count. The count updates automatically when items are added, removed, updated, or when the cart is cleared, created, or refreshed — no JavaScript needed.

JavaScript Cart Methods

All cart methods live on window.FairShareSDK. Async methods return Promises — use await or .then() depending on your environment. The REST-backed cart methods here call the Fluid Public SDK API (public-v2025-06) — the surface the SDK is generated against. They do not call the direct Checkout API that the headless checkout guide teaches. Both surfaces read and write the same cart records, but their request shapes differ, so drive any one cart through one surface only. See Choosing a cart surface if you also call REST directly.

The operation behind each method

Each REST-backed method maps to the Public SDK API operation or operations it calls. Follow a link for the full request and response contract.

Reading Cart State

getCart() fetches the cart. refreshCart() also dispatches the cart-update event that tells mounted widgets to render the fresh state. To adopt a cart created outside the SDK, validate and store its token:
setCartToken() updates local state, mounted widgets, and any configured real-time cart subscription after validation succeeds. It rejects an empty, unavailable, or completed token. Validation and fetch failures that happen before adoption leave the existing local cart intact. Some later failures can reject after local state has changed, so inspect the current cart in your error handler. Only one adoption can run at a time. The CDN loader also recognizes a cart_token query parameter. After a successful adoption, it removes that parameter with history.replaceState.

Modifying the Cart

The numeric shorthand defaults quantity to 1. In the array form, each parent item includes variant_id and quantity. Use subscribe and subscription_plan_id for a parent subscription. For a bundle, put the selected children in bundled_items. Each child includes variant_id and quantity, and can include product_bundle_group_id, subscription, and subscription_plan_id. The direct checkout Add Items contract models all five child fields. The SDK forwards nested child fields at runtime, but its current public TypeScript declaration may omit product_bundle_group_id. JavaScript callers can send it. TypeScript callers may need a local type extension until the SDK declaration catches up. This SDK method uses the FairShare cart lifecycle — it posts to Adds items to cart on the Public SDK API, not to the Add Items operation in the generated Checkout endpoints reference. clearCart() resets the local client state. It does not call a dedicated server-side clear-cart operation.

Subscriptions

Enrollment Packs

Enrollment packs bundle products for new rep onboarding. Add a pack by its numeric ID:
For an enrollment pack with dynamic bundles, pass the selected parent variants and their nested items as bundleSelections:
bundleSelections is the SDK option name. The nested bundled_items array describes the selected items within each parent variant.

Checkout

getCheckoutUrl() returns undefined until a cart token exists. To replace the default checkout behavior, register a handler:

Cart Control

You can open, close, and toggle the cart panel from JavaScript in addition to the declarative HTML attributes described above:
The legacy window.fluidCart namespace is also supported for backwards compatibility:
Prefer window.FairShareSDK.cart.control for new integrations.

Cart Settings

Cart settings let you override the default widget appearance and position on a per-page basis. Settings are page-scoped — they apply to the current URL path and are stored separately for each path, excluding query parameters and URL fragments. This means you can display the cart widget in the bottom-right corner on your homepage while hiding it entirely on a custom checkout page. Setting cart options:
Reading the current settings:
Clearing overrides (reverts to the defaults set on the <fluid-cart-widget> element):

Shop Settings

Read and update shop-level configuration, including locale and language preferences.

Cart operation events

These six methods emit a consistent success or error event on window:
  • addCartItems()
  • addEnrollmentPack()
  • updateCartItems()
  • decrementCartItem()
  • removeCartItemById()
  • updateCartItemVariant()
Listen once to react to these operations across custom controls and FairShare widgets:
Every detail includes operation, the add / update / remove category, the per-call toast preference, identifying IDs when available, and an ISO timestamp. A success can include the updated cart. An error includes the raw thrown error and a human-readable message. When an error reaches the public operation wrapper, all six methods emit CART_OPERATION_ERROR. addCartItems() and decrementCartItem() then resolve undefined to preserve their historical contract. The other four methods rethrow the error. A no-op result from addCartItems(), addEnrollmentPack(), decrementCartItem(), or updateCartItemVariant() emits no success event. updateCartItems() emits success when its void operation completes.

Analytics

Fire events and inspect attribution state directly from your JavaScript code.

Lead Capture

Capture a prospect’s contact information and send it to Fluid without requiring the lead capture widget. This is useful when you’re building a custom form or capturing leads as part of another flow.
The prospect’s details go inside contactname, email, and phone. Keys outside that shape are dropped silently, so a flat payload submits an empty lead and still resolves successfully. Every field is optional, but send at least one of email or phone so the lead is reachable. The lead is attributed to the same rep resolved at SDK initialization.