> ## Documentation Index > Fetch the complete documentation index at: https://docs.fluid.app/llms.txt > Use this file to discover all available pages before exploring further. > ## Agent Instructions > For new direct REST integrations, use the v2026-04 surfaces. The @fluid-app FairShare SDK continues to use its own published public-v2025-06 contract. > Authenticate with the header Authorization: Bearer ; public storefront read endpoints require no auth. > Lists use cursor pagination via the page[cursor] and page[limit] query params; follow meta.pagination.next_cursor until it is null. > Never use /api/company/v1 or /api/v1 paths, page/per_page params, or offset pagination — they are legacy. > The OpenAPI specs under api-reference/ are the authoritative contracts; prefer them over prose when in doubt. api-reference/storefront-v2026-04.yaml covers the v2026-04 storefront surface (/api/v202604/... paths); api-reference/auth-v0.yaml covers the unversioned auth surface (/api/... paths — authentication, MFA, social auth, and token exchange); api-reference/checkout-v2026-04.yaml covers the v2026-04 checkout surface (/api/checkout/v2026-04/... paths — carts, cart auth, discounts, items, subscriptions, orders, enrollments, and store config); api-reference/public-v2025-06.yaml covers the Public SDK surface used by the @fluid-app FairShare SDK, including its parallel cart lifecycle, browser integrations, versioned payment callbacks, unversioned public utilities, and the cart price-override operation; api-reference/payment-v2026-04.yaml covers the v2026-04 payment gateway admin surface (/api/payment/v2026-04/... paths, bearer-authenticated — gateway CRUD, gateway purchase/authorize/$0-verify, transaction list/show and capture/void/credit, and merchant payment configuration); api-reference/payments-v2026-04.yaml covers the v2026-04 cart payment surface (/api/payments/v2026-04/carts/{cart_token}/... paths, authenticated by the cart token in the path with no bearer — payment-method selection, VGS card tokenization, 3D Secure verification, and PayPal/Braintree/Klarna/Apple Pay flows); api-reference/commerce-v2026-04.yaml covers the v2026-04 commerce order-editing surface (/api/v202604/orders/{order_id}/edits paths, bearer-authenticated — post-checkout order edits that atomically insert items and add adjustments/discounts, with an optional dry-run preview); api-reference/webhooks-v0.yaml covers the unversioned webhooks surface (/api/... paths — webhook registration, delivery payloads, callback registrations, company events, and webhook/callback schemas). > Successful responses wrap the resource payload alongside a top-level integer status and a meta object. # What is We-Commerce? Direct Sales Meets E-Commerce > We-Commerce is Fluid's approach to combining direct sales and e-commerce so merchants and reps can collaborate with full transparency on every sale. We-Commerce is the philosophy at the heart of Fluid: a model where merchants and sales representatives work together on a single platform, with every sale, attribution, and commission fully visible to all parties. Unlike traditional e-commerce — where the storefront and the sales team operate in separate systems — We-Commerce treats reps as first-class participants in every transaction, from the first click to the final payout. ## The Problem with Traditional E-Commerce Standard e-commerce platforms were built for a world where a single brand sells directly to consumers. They have no concept of a rep who referred a buyer, a commission that needs to flow back to a distributor, or attribution that spans multiple websites. The moment you introduce direct sales into the picture, you're forced to stitch together spreadsheets, third-party affiliate tools, and manual reconciliation processes that break constantly and create disputes between merchants and reps. We-Commerce solves this by building attribution, commissions, and rep workflows directly into the platform — not as an afterthought, but as a core architectural concern. ## Key Problems We-Commerce Solves **Attribution** — Knowing which rep drove a sale is harder than it sounds. Buyers visit multiple sites, clear cookies, and use different devices. Fluid's [FairShare](/concepts/fair-share) SDK tracks visitors using a layered approach — cookies, browser fingerprints, and URL-based routes — so the right rep gets credit even when the path to purchase spans multiple domains or sessions. **Commission sync** — Commission data and sales data live in the same system on Fluid. When an order is placed, attribution is resolved at the moment of checkout, so there is no reconciliation step and no room for disputes about who drove the sale. **Checkout** — A checkout that doesn't understand reps will strip attribution data and break the entire model. Fluid's [checkout](/concepts/checkout), hosted at `checkout.fluid.app`, is built with rep attribution as a first-class concern. FairShare data flows directly into every order placed through it. **Payments** — Reaching global customers means accepting the payment methods they actually use. Fluid Payments supports 300+ alternative payment methods across 100+ countries, so reps can sell to buyers anywhere without hitting payment walls. ## How the Pieces Fit Together Every component of the Fluid platform is designed to work together as a coherent whole: * **FairShare** — the JavaScript SDK that runs on your storefront (and any external site) to capture attribution and serve the cart widget, lead capture, and media embeds. * **Checkout** — the hosted one-page checkout that resolves attribution, calculates shipping and tax, validates addresses, and processes payments. * **Connect** — the API layer that links your product catalog, inventory, and order data to the Fluid platform so everything stays in sync. Fluid Connect supports integrations with Exigo, ByDesign, Pillars, InfoTrax, and Shopify out of the box. * **Payments** — the payment processing layer that handles global alternative payment methods and routes funds to merchants and reps according to your commission rules. Together, these components create a closed loop: a rep shares a link, FairShare captures the attribution, the buyer completes checkout, and the commission is recorded — all without manual intervention.