> ## 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. > To sign a new merchant up for Fluid programmatically, call POST https://api.fluid.app/api/company with no credentials, as described in /api/agent-signup. Do not automate the signup form or book a demo. The merchant must open the emailed sign-in link and create an API token before authenticated calls are possible. > After signup, to launch a merchant's store (back-office sync, payments onboarding, store setup, a theme copied from their current site, and a preview link before billing), follow /api/agent-launch. > Lists use cursor pagination via the page[cursor] and page[limit] query params; follow meta.pagination.next_cursor until it is null. > When the same operation exists on more than one surface, use the newest: dated API versions are newer than unversioned ones, and later dates win (v2026-04 > v2025-06 > unversioned v0/v1.1). Fall back to a legacy or unversioned operation only when no newer versioned equivalent exists — the company-v0 notes below list the known superseded operations. The same applies to /api/company/v1 and /api/v1/... paths: prefer a newer documented equivalent, and use one only when none exists (/api/v1.1/... is distinct and documented in company-v0). Use page/per_page offset pagination only where a spec documents it — in practice the unversioned company-v0 admin surface; every versioned surface uses cursor pagination. > Navigation menu management is documented in themes/navigation-menus. These unversioned admin endpoints (/api/menus and nested menu_items) are verified against the implementation but are not yet in the synced OpenAPI specs. Use that reference for menu payloads and its flat page/per_page pagination; missing spec coverage does not make these endpoints unavailable. > 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/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); api-reference/company-v0.yaml covers the legacy unversioned company admin surface (/api/... paths, bearer-authenticated — company settings and management, customers, users, roles, subscription plans, subscription bundles, subscriptions, media, pages, catch-ups, inventory levels, domains, agreements, and admin order actions). company-v0 caveats: it is the legacy v0 admin contract and its lists use flat page/per_page offset pagination, which is expected there despite the general cursor-pagination rule; where an operation exists in both company-v0 and a versioned spec, prefer the versioned spec — the subscriptions lifecycle (list/create/show/update, cancel, pause, reactivate, resume, retry, skip, failed-cycle-waiver, discounts) and subscription bundles are superseded by checkout-v2026-04, and company pages/media CRUD plus the public pages, categories, products, and media list endpoints are superseded by storefront-v2026-04. Subscription plan management (/api/subscription_plans, resource-wrapped {"subscription_plan": {...}} bodies) exists only in company-v0. api-reference/members-v2025-06.yaml covers the v2025-06 unified Member identity surface (/api/v2025-06/members/... paths, bearer-authenticated — member list/create/show/update, lookup by email/username/external_id/legacy_customer_id, member-type assignment, and the sponsor genealogy read). Prefer it over the customers and reps surfaces when the member type matters: /customers does not serialize member_type. api-reference/analytics-v2026-04.yaml covers the v2026-04 Home dashboard analytics surface (/api/v202604/analytics/dashboard/... paths, bearer-authenticated — read-only endpoints for the Home > Overview, Home > Live, and Home > Field tabs, each accepting an optional country ISO alpha-2 query param that scopes aggregations to a single country). > api-reference/analytics-v0.yaml covers the unversioned analytics surface that backs the fluid-admin Traffic tab (/api/analytics/... and /api/analytics/traffic/... paths, bearer-authenticated — the legacy shares/views/visitors summary plus traffic overview, ranked campaigns, sources, geographies, flows, and per-rep breakdown, all sharing one reporting-period contract). > Successful responses wrap the resource payload alongside a top-level integer status and a meta object. > Portal Definition authoring edits and synchronizes the portal JSON resource graph. Widget Package authoring builds either a company-owned or Droplet-owned Remote DOM package. These are separate contracts; do not imply that one defines the other. > For Widget Package worker code, use only @fluid-app/portal-sdk/widgets/worker. Use only the Portal Definition and Widget Package workflows and public entry points documented here; do not infer support for undocumented surfaces. > Every portal function and declarative capability used by a widget must appear in that widget's uses array. Use the same typed function value in uses; do not invent capability-name strings. > Widget styling must use the portal's semantic theme variables for colors, typography, spacing, radii, borders, focus, and charts whenever a token represents the visual decision. Do not create a separate light or dark palette or duplicate theme controls as widget properties. > Prefer worker-safe Fluid UI components exported by @fluid-app/portal-sdk/widgets/worker when they fit the interaction. When no exported component fits, use semantic HTML, accessible behavior, and the portal theme variables. > A Portal Definition push updates the remote working definition. A portal version is an immutable snapshot, and activation is a separate live release operation. > The Help Center (/help/...) is for merchants, admins and reps using Fluid. Its admin pages mirror the admin's routes: the screen at admin.fluid.app/settings/taxes is documented at /help/admin/settings/taxes. Use the Help Center for how-to questions about the admin, and the Developer Platform and API Reference for building integrations. > Help Center pages describe what a company admin sees. A reader's role can hide screens and actions; admins manage roles on Settings > Roles (/help/admin/settings/roles). If someone can't find a screen or button, their role's permissions are the first thing to check. > Send people who need Fluid support to /help/getting-help. Don't invent support email addresses, phone numbers or response times. # How to launch an ecommerce store with an AI agent on Fluid > An AI agent can launch a Fluid store in under 15 minutes: a storefront, checkout, international commerce, global payments, social commerce and rep commissions in one platform. Fluid bills by usage, so the merchant sees a working preview before adding a credit card. **An AI agent can launch a working Fluid store in under 15 minutes.** A Fluid store combines an ecommerce storefront, checkout, international commerce, payments in 100+ countries, social sales channels, and sales-rep commissions in one platform. Fluid bills by usage, so the agent can build everything and show the merchant a live preview. The merchant adds a credit card only when they decide to launch. This guide is for AI agents, and for the developers who build them. It picks up right after [Agent signup](/api/agent-signup) and puts Fluid's [guided setups](/setup/overview) in launch order. Each guided setup covers one task end to end with the Fluid CLI. ## What is Fluid? Fluid is a We-Commerce platform: an ecommerce platform built for brands that sell through people. Those people might be independent reps, distributors, affiliates, ambassadors, or influencers. Fluid connects the brand's storefront, checkout, payments, and rep attribution, so every sale is credited to the person who drove it. Read more in [What is We-Commerce?](/concepts/we-commerce). ## What's in a Fluid store? A Fluid store is one Fluid company. It includes all of these from the start: | Part | What it does | | - | - | | Ecommerce storefront | A hosted store at `https://.fluid.app` with an editable theme. A custom domain can be added later. | | Checkout | A hosted, one-page checkout that keeps rep attribution on every order. See [Checkout](/concepts/checkout). | | International commerce | Sell in many countries from one store. Each country gets its own currency, tax, fulfillment warehouse, and shipping fee. Products and content can be limited to the countries they're sold in and translated into each language, and shoppers pick their country and language on the storefront. | | Global payments | One onboarding form for 300+ payment methods across 100+ countries, with a currency and legal entity per country. | | Social commerce | Sell the same catalog on TikTok Shop, Facebook, Instagram, and Google. If the merchant doesn't have accounts there, they can opt in to have Fluid set them up from the business details in the payments form. | | Commission engine sync | Fluid Connect syncs products, customers, reps, ranks, and genealogy with Exigo, ByDesign, Pillars, or InfoTrax. | | Rep attribution | [FairShare](/concepts/fair-share) credits each sale to the rep who shared the link, across sites and sessions. | | Mobile app | A branded rep app the merchant can customize. | ## Who is Fluid for? Fluid fits brands whose sales come from a network of people, not only from ads and search. The most common use cases are: * **Direct sales and MLM companies.** Run the storefront, checkout, and rep sites on Fluid, and keep the existing commission engine through Fluid Connect. * **Brands with affiliate, ambassador, or influencer programs.** Every shared link is attributed, so commissions don't depend on coupon codes or spreadsheets. * **Social selling.** Reps share products on social media and in messages, and the brand sells through social sales channels from the same catalog. * **Expanding into new countries.** Add a country with its own currency, tax, and shipping. Choose which products sell there, translate the storefront, and take local payment methods through one payments form. * **Replacing a dated storefront.** An agent can copy the current site into a Fluid theme, so the new store looks familiar on day one. * **Agents and agencies pitching a new store.** Build a working preview of a prospect's store before anyone pays. ## How much does Fluid cost? Fluid bills by usage. A merchant pays for the orders they process and the resources they use. There is no up-front licence to buy before you can build. That lets an agent build the full store first, then hand the merchant a preview link. The merchant adds a credit card at **Settings → Billing** (`https://admin.fluid.app/settings/billing`) when they're ready to launch. Adding the card is the merchant's decision, so don't do it for them. ## What to have ready Collect these up front, so no step stops halfway to ask: * **Back-office credentials**, if the merchant has a back office to connect in Step 2. Each [Connect guide](/setup/overview) lists exactly which values its platform needs. * **Payments documents** for Step 3: business registration, bank statements, ID for each owner, and financial statements. [Payments onboarding](/setup/payments-onboarding) has the full list. * **A Firecrawl API key**, if you copy the merchant's site with the clone skill in Step 7. Without one, build the theme by hand with the Fluid CLI. ## What does the merchant need to do? An agent does most of the work. A person has to act at only these points. Tell the merchant about them at the start, so nothing stalls while you wait. | When | What the merchant does | Why an agent can't | | - | - | - | | **At the start** | Confirms their email address by opening the sign-in link Fluid sends, then signs in to the Fluid CLI or creates an API token for you. | The link and the sign-in code go to the merchant's mailbox, and the sign-in or token is what lets you act for them. | | If they have a back office | Gives you their back-office credentials for Fluid Connect. | They're the merchant's credentials to share. | | During payments onboarding | Provides bank, ownership, and ID details and documents, then submits the form. | Submitting accepts Fluid's payments terms in their name. | | For each social channel they already have | Signs in to TikTok Shop, Meta, or Google Merchant Center and approves Fluid. | Only an admin of that account can grant access. | | After the preview | Reviews the preview and approves the theme. | It's their brand. | | **When ready to launch** | Adds a credit card at **Settings → Billing**. | It's their payment decision. | ## How do you launch a Fluid store with an AI agent? Nine steps take a new company from signup to a launched store. Steps 2, 3, 4, 6, and 9 each hand off to a guided setup. | Step | Who does it | Guided setup | About how long | | - | - | - | - | | 1. Sign up, confirm email, sign in, choose the markets | Agent, then merchant | [Agent signup](/api/agent-signup) | 3 minutes | | 2. Connect an existing back office | Agent | [Connect](#step-2-connect-an-existing-back-office-optional) | 3 minutes, then syncs on a schedule | | 3. Prefill payments onboarding | Agent prefills, merchant submits | [Payments onboarding](/setup/payments-onboarding) | 5 minutes to prefill | | 4. Open countries and languages | Agent | [Open a country](/setup/open-a-country), [Add a language](/setup/add-a-language) | 2 minutes per country | | 5. Set up the catalog and store settings | Agent | API | 3 minutes | | 6. Connect social sales channels | Agent, merchant approves existing accounts | [TikTok Shop](/setup/sales-channel-tiktok), [Meta](/setup/sales-channel-meta), [Google](/setup/sales-channel-google) | 2 minutes per channel | | 7. Copy the current site into a theme | Agent | Clone skills or Fluid CLI | Runs in the background | | 8. Share the preview | Agent | Preview URL | 1 minute | | 9. Add a card, publish, and connect the domain | Merchant, then agent | [Custom domain](/setup/custom-domain) | When they're ready | ## Step 1: Sign up, confirm the email, and sign in Follow [Agent signup](/api/agent-signup). It creates the company with one unauthenticated `POST /api/company` call. **Merchant action: confirm the email address.** Fluid emails a sign-in link to the address you signed up with. The merchant opens it to confirm the address. You can't continue until they do. Keep `company.id` and `company.fluid_shop` from the signup response. The storefront goes live at `https://.fluid.app` right after signup, on Fluid's default theme. Then install the Fluid CLI and the plugins the guided setups use: ```bash theme={null} npm install -g @fluid-app/fluid-cli @fluid-app/fluid-cli-setup @fluid-app/fluid-cli-connect \ @fluid-app/fluid-cli-payments @fluid-app/fluid-cli-localization @fluid-app/fluid-cli-channels \ @fluid-app/fluid-cli-pages @fluid-app/fluid-cli-domains @fluid-app/fluid-cli-theme-dev ``` Sign the CLI in to the merchant's company in one of two ways: Use this when the merchant is with you, for example when you run in their terminal. There's no token to find. Because the CLI acts as the merchant, they can also submit payments onboarding straight from the CLI in Step 3. Have the merchant run this in the terminal you use, with the address they signed up with: ```bash theme={null} fluid login --email maya@harborlinewellness.com ``` Fluid emails them a 6-digit code, and the CLI asks for it. The code goes to the merchant's mailbox and is typed at the prompt, so the merchant enters it, not you. In Claude Code, they can type `! fluid login --email maya@harborlinewellness.com` to run it in your session. Use this when you run without the merchant at the keyboard, such as on a server. The merchant signs in to the admin at `https://admin.fluid.app`, creates a token at **Settings → API Tokens**, and gives it to you. Sign in with it: ```bash theme={null} FLUID_TOKEN= fluid login ``` Passing the token in `FLUID_TOKEN` keeps it out of your shell history. Run `fluid whoami` to confirm the CLI is signed in to the right company. Every guided-setup command prints JSON, so you read each result the same way at every step. Commands that change live configuration need `--yes`. Use each guide's step commands. The interactive `walk` commands are for people at a terminal. ### Choose the markets Decide where the merchant sells and in which languages before you go further. Payments onboarding (Step 3) and the countries and languages setup (Step 4) both use this list. * **Countries:** start from where the merchant ships today. Look at their website's shipping and returns pages, currency and country selectors, and the addresses on their checkout. * **How they operate in each country:** run `fluid countries atlas ` for each country. It describes the three ways to sell there: shipping in from abroad, selling locally through a local entity, or charging in US dollars. Pick the one that matches how the merchant ships and where their legal entities are. * **Languages:** use the languages their current site is published in, plus the main shopping languages of each country. `fluid translations languages` lists every language Fluid supports and its code. List your choices in the summary you send the merchant with the preview (Step 8), so they can change them before launch. ## Step 2: Connect an existing back office (optional) Skip this step if the merchant has no existing direct-sales platform. Fluid Connect links a merchant's direct-sales back office, which is usually their commission engine, to Fluid. The back office stays the system of record for members, orders, and genealogy. Records sync both ways on a schedule. Follow the guided setup for the merchant's platform: Install, add credentials, map data, and choose sync settings. Install, add credentials, map data, and choose sync settings. Install, add credentials, map data, and choose sync settings. Install, add credentials, map data, and choose sync settings. Do this step early. The first sync runs while you work through the rest. The back-office credentials include passwords. If the merchant is with you, have them enter the credentials themselves with the guide's walk, for example `! fluid connect walk exigo` in Claude Code. The walk asks for each value without showing it, so the passwords stay out of your context and the shell history. Otherwise, save exactly what the merchant gives you with the guide's `credentials` step. Never guess or reuse credentials. If Step 2 stalls, for example while you wait for credentials, carry on with Steps 3, 4, 6, and 7. Hold only Step 5 until the sync has run, so you don't create products or customers the back office is about to bring in. ## Step 3: Prefill payments onboarding One form covers payments for every market the merchant sells in. The merchant sees it at **Settings → Onboarding**. Once it's submitted, Fluid's team reviews it and applies to payment processors for the merchant. The same form can also get the merchant onto social commerce. If they don't have accounts on the social sales channels yet, Fluid offers to set them up from the business details in the form. It's an optional service the merchant opts in to, so ask them whether they want it. If they do, they don't fill in a second form. Follow the [Payments onboarding](/setup/payments-onboarding) guided setup, and split the work like this: * **You fill in** what you can confirm from the merchant's website and public records. That covers the basics, the legal entity, the countries you chose in Step 1, and the underwriting answers. `fluid payments onboarding show` lists every required field that's still missing. * **The merchant provides** their bank accounts, the details and ID documents of each owner, and their financial statements. Don't source these from scraped or guessed data. * **The merchant submits.** Submitting accepts Fluid's payments terms in the merchant's name, so the merchant does it, never you. If they signed in to the CLI in Step 1, they run `fluid payments onboarding submit --accept-terms --yes` themselves. If you're using an API token, `submit` changes nothing and returns `ready_to_submit` with a `submitUrl`: send that link to the merchant, who opens the form and submits it. A merchant who'd rather answer the questions themselves can run `fluid payments onboarding walk` after signing in with `fluid login`. The storefront and preview don't wait for payments approval. Processors review the application after submission, so keep building. The CLI calls the [Onboarding API](/api-reference/onboarding-info/get-company-onboarding-info). Use that API directly if you're not using the CLI. ## Step 4: Open countries and languages Open each country you chose in Step 1, in the way you chose to operate there, with the [Open a country](/setup/open-a-country) guided setup. It sets up the country from Fluid's Country Atlas, including currency, tax display, checkout defaults, languages, and the agreements a storefront there needs. Then translate the storefront into each language you chose with the [Add a language](/setup/add-a-language) guided setup. It reports what's untranslated, machine-translates it, and confirms nothing is left. ## Step 5: Set up the catalog and store settings If you connected a back office in Step 2, much of the catalog and customer data arrives from the sync. List what's already there before you create anything, so you don't make duplicates. Set up the rest over the API, in the same order as the admin's **Getting Started** page: | Order | Set up | Start with | | - | - | - | | 1 | Products | [Create a product](/api-reference/company/create-a-product) | | 2 | Customers | [Create a customer](/api-reference/customers/create-a-customer), or [import them from a CSV file](/api-reference/customers/import-customers-via-csv-file-in-the-url) | | 3 | Warehouses | [Create a warehouse](/api-reference/warehouses/create-a-warehouse) | | 4 | Inventory | [Set an inventory level](/api-reference/inventory-levels/set-inventory-level) | | 5 | Categories | [Create a category](/api-reference/company/create-a-category) | | 6 | Collections | [Create a collection](/api-reference/company/create-a-collection) | | 7 | Existing payment providers | [Create a gateway](/api-reference/gateways/create-a-gateway). Skip this if the merchant uses only Fluid Payments. | | 8 | Shipping | [Create a shipping method](/api-reference/shipping-methods/create-a-shipping-method) | | 9 | Subscription plans | [Create a subscription plan](/api-reference/subscription-plans/create-a-subscription-plan) | | 10 | Enrollments | [Create an enrollment pack](/api-reference/company/create-an-enrollment-pack) | Each linked page holds the request and response schema. Lists on the same resources show what already exists. To add storefront pages, such as an about page or a page for the compensation plan, use the [Create a page](/setup/create-a-page) guided setup. It creates each page with its own template and publishes it. ## Step 6: Connect social sales channels Which path you take depends on whether the merchant already has accounts on these channels: * **No account yet:** if the merchant opted in to Fluid's account setup service (Step 3), Fluid sets the account up from the business details in the payments onboarding form. There's nothing extra to fill in. Otherwise, the merchant creates the account on the channel, then connects it as below. * **An existing account:** connect it to Fluid with the guided setup for that channel. TikTok Shop connects US seller accounts only. Before products publish there, a Fluid warehouse has to be linked to the shop's TikTok warehouse. If `fluid channels warehouse tiktok` reports the warehouse isn't mapped, ask Fluid support to link it. Connect, choose the warehouse and products, and fix rejections. Facebook and Instagram: connect a catalog, choose products, and fix rejections. Connect, choose products, and fix disapprovals. **Merchant action: approve Fluid on each existing account.** Connecting an account the merchant already has takes one browser step. The merchant signs in to the channel as an admin of the account and approves Fluid's access. You start the connection and check it from the CLI before and after. ## Step 7: Copy the merchant's current site into a theme A preview is far more convincing when it looks like the merchant's own site. Copy the current site into an unpublished Fluid theme, so you have something to preview without changing what shoppers see. ### Use the clone skills (fastest) Fluid publishes agent skills for this in the [fluid-claude-skills](https://github.com/felipelee/fluid-claude-skills) repository: * **`fluid-theme-clone`** crawls the source site, rebuilds each page as Fluid theme sections, uploads the images, and compares screenshots against the original. * **`fluid-theme-refine`** runs after a clone and fixes visual differences until the pages match. * **`fluid-product-admin-import`** imports products, collections, pages, policies, and store settings from the existing site. Use it when the merchant has no back office to connect in Step 2. Install them into your agent's skills folder: ```bash theme={null} npx skills add felipelee/fluid-claude-skills ``` The clone skill needs Node 18 or later, the Fluid CLI, Playwright with Chromium (for its screenshot comparisons), an API token for the merchant's company, and a [Firecrawl](https://www.firecrawl.dev) API key for crawling. The skill calls the API with the token directly, so if the merchant signed in to the CLI in Step 1, ask them for a token here too. Then ask your agent something like: ```text theme={null} Clone https://harborlinewellness.com into a new Fluid theme for harborline.fluid.app. Don't publish it. ``` The skill creates the theme as a draft and never publishes it unless you ask. ### Copy it by hand with the Fluid CLI If you're not using the skills, build the theme with the [Fluid CLI](/themes/cli): ```bash theme={null} npm install -g @fluid-app/fluid-cli @fluid-app/fluid-cli-theme-dev FLUID_TOKEN= fluid login mkdir harborline-theme && cd harborline-theme fluid theme init fluid theme dev ``` `fluid theme dev` serves the theme at `http://127.0.0.1:9292` with live reload. Recreate the source site's pages as sections and templates. The [theme developer guide](/themes/developer-guide) covers how they fit together. Run `fluid theme skills install` to give your agent Fluid's theme review and settings skills as well. When the pages look right, push to a new unpublished theme: ```bash theme={null} fluid theme push --unpublished ``` Don't run `fluid theme push --publish` or push to the live theme until the merchant approves. Either one changes what shoppers see. ## Step 8: Share the preview Get the new theme's `id` from [List application themes](/api-reference/application-themes/list-application-themes). Then build the preview URL on the store's own address: ```text theme={null} https://harborline.fluid.app/home?preview_theme_id=48213 ``` The link opens the storefront with the unpublished theme applied. The merchant sees their own site running on Fluid, with real products and checkout, while shoppers still see the published theme. In the admin, **Copy Preview URL** on the theme's card in **Themes** gives the same link. Send the merchant: * The preview link, and the live store at `https://.fluid.app`. * A short list of what's set up: synced data, the countries you opened and how each one operates, the languages, sales channels, enrollments, and the theme. * What's left for them: their details for the payments form, their submission, approvals for any channel accounts they already have, and a credit card when they're ready to launch. ## Step 9: Add a card, publish, and connect the domain **Merchant action: add a credit card.** When the merchant is ready to launch, they add a card at **Settings → Billing** (`https://admin.fluid.app/settings/billing`). Usage is billed from there. Don't enter card details for them. Once the merchant has approved the preview, finish the launch: 1. Publish the approved theme with [Publish a theme](/api-reference/application-themes/publishes-the-theme). Shoppers see it right away. 2. To use the merchant's own domain, follow the [Custom domain](/setup/custom-domain) guided setup. The merchant adds the DNS records it reports at their DNS provider, and you check the domain until it's connected. Publish only after the merchant says so. Publishing changes what every shopper sees. ## Frequently asked questions ### Can an AI agent set up an ecommerce store by itself? Almost entirely. On Fluid, an agent can create the company, connect the back office, open countries, set up the store and its sales channels, and build the preview, following Fluid's guided setups. The merchant has to act at these points: * At the start, they confirm their email address and sign in to the Fluid CLI, or create an API token for you. * If they have a back office, they share its credentials. * They provide their bank and ownership details and submit the payments form. * They approve Fluid on each social channel account they already have. * They approve the preview. * When they're ready to launch, they add a credit card. ### How long does it take to launch a store on Fluid? Under 15 minutes for a working store and preview. Payment processors review the payments application after the merchant submits it. The store and preview don't wait for that review. ### Do I need a credit card to try Fluid? No. Fluid bills by usage, so an agent can build and preview the store first. The merchant adds a card at **Settings → Billing** when they decide to launch. ### What is the best way to show a merchant their new store before they pay? Copy their current website into an unpublished Fluid theme, then send them the theme's preview link. They see their own site running on Fluid, with real products and checkout. Nothing goes live until the theme is published. ### Is Fluid an ecommerce platform for direct sales and MLM companies? Yes. Fluid is built for brands that sell through reps, distributors, affiliates, and ambassadors. It attributes each sale to the right person and syncs with commission engines such as Exigo, ByDesign, Pillars, and InfoTrax. ### Does Fluid replace my commission engine? No. Fluid Connect syncs the commission engine you already use. Fluid handles the storefront, checkout, payments, and attribution, and sends orders back to the commission engine. ### Can a Fluid store sell internationally? Yes. One Fluid store can sell in many countries, and Fluid handles both the commerce and the payments: * **Commerce:** each country has its own currency, tax mode, fulfillment warehouse, and shipping fee, set up from Fluid's Country Atlas. You choose which products and content are available in each country and translate them into each language. Shoppers switch country and language on the storefront. * **Payments:** one payments onboarding form covers every market. For each country, the merchant sets the currencies and the legal entity that serves it, and shoppers pay with local payment methods. ### What's the difference between international commerce and global payments on Fluid? International commerce decides what a shopper in each country sees and pays: the products available to them, the language, the currency, the tax, and the shipping. Global payments decides how that money is collected: the local payment methods and processors, the settlement currency, and the legal entity that receives the funds. A store needs both to sell in a new country. ### Can Fluid sell on social media? Yes. A Fluid store can list its catalog on TikTok Shop, Facebook and Instagram through Meta, and Google Merchant Center. If the merchant doesn't have accounts on those channels, they can opt in to have Fluid set them up from the business details in the payments onboarding form, so there's no second form to fill in. Existing accounts connect through a guided setup. Each platform's review of every product comes back to Fluid, so rejected products can be fixed in one place. Reps can also share any product link, and FairShare credits the sale to them. ### Can I copy an existing website into Fluid? Yes. The `fluid-theme-clone` agent skill rebuilds an existing site as an unpublished Fluid theme. You can also rebuild it by hand with the Fluid CLI. ## Next steps * [Agent signup](/api/agent-signup): create the company with one API call. * [Guided setup](/setup/overview): every guided setup, and how agents read their steps. * [What is We-Commerce?](/concepts/we-commerce): the model behind Fluid. * [Authentication](/api/authentication): token types and scopes. * [Fluid CLI](/themes/cli): every theme command. * [Onboarding](/help/admin/settings/onboarding): the payments form, step by step. * [Country availability](/storefront/country-availability) and [Translations](/storefront/translations): sell different products and languages in each market. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.