> ## 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. > Fluid has three navigation APIs; don't mix them up. Storefront website menus (navigation bars, footers) are /api/menus and nested menu_items, in api-reference/content-v0.yaml (API Reference: Website > Navigation menus), with a how-to in themes/navigation-menus; their list uses flat page/per_page pagination. The Fluid mobile app's navigation is /api/v2/mobile_navigations, in api-reference/mobile-v2.yaml (API Reference: Mobile app > Navigation); its list also uses page/per_page. Portal navigations belong to a portal definition (Fluid OS), in api-reference/fluid-os-v0.yaml (API Reference: Portal > Portal navigation), and each has a platform of web or mobile. > 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. # Traffic > See how many people visited your store, which channels, reps and campaigns sent them, and where they were, and build tagged campaign links. **Traffic** shows how visitors arrived at your store and what they did, from the whole store down to individual reps, campaigns and countries. You can also build a tagged link for a campaign. ## Where to find it In the admin sidebar, under **Analytics**, select **Traffic**. To open this screen, your role needs **View only** or **Full access** for **Payment Reports**. On the [Roles](/help/admin/settings/roles) screen, **Payment Reports** is in the **Commerce** card. Open the card and set access from the **Payment Reports** area's menu, not the card's. ## What's on the screen The screen has five tabs: **Traffic**, **Reps**, **Sources**, **Campaigns** and **Geography**. It opens on **Traffic**. At the right of the tab bar, choose the period: **7D**, **30D** or **90D** for the last 7, 30 or 90 days, or **12M** for the last 12 months. It starts at **30D**, and the period you choose applies to every tab. The tab and period are kept in the page's web address, so a link you copy opens on the same view. If a card can't load, click **Try again** on it. Most counts and amounts are rounded, such as 12.4K. Revenue amounts are shown in US dollars, with orders in other currencies converted. Where a figure shows its change from the earlier period, a dash means there's no earlier data to compare. ### Traffic * **Traffic**: the period's dates, compared with the same number of days just before it. **Page views** shows the total and its change, and the chart plots page views over the period. **Visitors** shows the number of distinct visitors, with no chart and no change, and a dash when it can't be measured for the period. Page views count every view, bots included, while visitors leave bots out, so the two don't divide into each other. * **Devices**: the split across **Desktop**, **Mobile** and **Tablet**, plus **Unknown** when there are any. * **New vs returning**: the share of **Returning** and **New** visitors. New means no earlier recorded visit from that browser, so a returning shopper on a new device counts as new. * **Content mix**: the share of views by type: **Products**, **Blog & pages**, **Shared assets** and **Storefront & checkout**. Types with no views are left out. * **Most viewed**: the pages, products and shared assets with the most views. Each row shows the **Destination** with its type, **Views**, a **Trend** line, the **Top source** channel (or **Not recorded**), and **Revenue** with its number of orders. **Revenue** is the full total of paid orders whose visit landed on that item, so the column adds up to less than your store's revenue. ### Reps * **Rep field**: the period's dates and four figures: **Active reps**, with its change; **Share of traffic**, the share of visitors who arrived on rep links; **Rep-driven revenue**; and **New reps**. A line below says what the revenue covers, for example when it's tracked from a later date than the visitor figures. See [Why doesn't Rep-driven revenue match my orders?](#rep-driven-revenue) * **Leaderboard**: reps ranked by visitors sent, with **#**, **Rep**, **Visitors**, **Orders**, **Revenue**, **Trend** and **Top asset** (or **No tracked asset**). If some rep-link visits name no rep, an **Unattributed** row at the bottom counts them, such as an admin's own share. When not every rep fits, the note below says how many are shown, such as Top 25 of 140 reps. Reps hidden from leaderboards aren't listed, but their traffic still counts in **Rep field**. One visitor can arrive on two reps' links, so the rows don't add up to your store's visitors. ### Sources * **Traffic flow**: a diagram of which channels, on the left, sent visits to which content, on the right, with each one's number of visits. Smaller flows are grouped into **Other content**; hover a band or a name to see its visits. * **Channel mix**: the period's visitors by channel: **Rep shares**, **Email**, **Paid**, **Social**, **Organic**, **Referral** and **Direct**. Each channel shows its visitors, its share, its revenue and, when there is one, its conversion rate (**conv**). * **Top referrers**: the outside sites that sent visitors, with **Source**, **Visitors**, **Views**, **Revenue** and **Conv. rate**. The addresses one platform uses are grouped into one row, and smaller sites into **Other sites**. A dash means there's no figure. ### Campaigns This tab covers visits that arrived on links tagged with UTM parameters, such as the links you build with **New campaign link**. * **Campaigns**: the period's dates and four figures: **Active campaigns**, **Tagged visitors**, **Share of traffic** and **Campaign revenue**. * **Campaign performance**: tagged campaigns ranked by visitors, with **Campaign**, **Tags** (the source and medium values, or **None**), **Visitors**, **Revenue** and **Conv. rate**. Each row is one combination of campaign, source and medium, so a campaign sent by email and by paid social shows on two rows. The rest are grouped into **Everything else**. The card also has a search box and the **+** button that opens **New campaign link**. * **UTM explorer**: choose **Campaign**, **Source**, **Medium**, **Content** or **Term** to see each tagged value's **Visitors** and **Page views**. **Term** is filled by paid search only. This card shows visitors and page views, not orders or revenue. ### Geography * **Visitors by country**: a bar chart of up to 8 countries with the most visitors, with the total visitors and number of countries above it. A **+** after the number of countries means some countries are grouped together. * **Countries**: **Country**, **Visitors**, **Share**, **Views** and **Revenue**. Shares are of all visitors, including those who couldn't be placed in a country, so they add up to less than 100%. **Revenue** counts storefront purchases by delivery country, not your full store revenue. A note below gives its dates when they differ from the visitor figures'. Visitor locations are only available from the day the store began recording them, so on a long period the figures can cover fewer days than you chose. * **Cities**: the top cities by visitors, with **City**, **Visitors**, **Share** and **Views**. Cities can cover fewer days than the country figures, so their shares are of the city total. ## Tasks ### Build a campaign link Building a link doesn't save anything. It makes a tagged web address for your store and copies it, and the campaign appears in **Campaign performance** once visitors arrive on the link (see the FAQ below if you can't find it). On the **Campaigns** tab, click **+** (**New campaign link**) at the top of **Campaign performance**. Under **Destination**, choose where the link should land on your store, such as **Home Page**, **Shop**, a product, a collection, a page or a post. **Destination** is required. If you see **That destination has no storefront link**, pick another. Fill in **utm\_source**, **utm\_medium** and **utm\_campaign**. Type your own values or pick a suggestion, such as `klaviyo` or `google` for the source and `email` or `cpc` for the medium. Optionally, add **utm\_content** to tell two creatives apart and **utm\_term** for a paid search keyword. In the link, each value becomes lowercase, each run of other characters (spaces, symbols, accented letters) becomes a single hyphen, and hyphens at the start or end are dropped, so `Spring Restock` becomes `spring-restock`. The three required values each need at least one letter from a to z or a number. **Preview** shows the full link as you type. If **Preview** says it's waiting for your store's address, **Copy link** stays unavailable until the link appears. Click **Copy link**. When you see **Campaign link copied**, the link is on your clipboard and the dialog closes. If you see **Couldn't copy the link**, the dialog stays open, so select the link in **Preview** and copy it yourself. ### Find a campaign On the **Campaigns** tab, type at least 2 characters of a campaign name in the search box on **Campaign performance**. The search covers the period you've chosen, and the line below the box gives the number of matching campaign placements. If you see **More campaigns match**, type more of the name. Click the **×** in the box to see all campaigns again. ## Frequently asked questions A campaign appears in **Campaign performance** once visitors arrive on a link carrying its tags, and only for a period that includes those visits. A campaign with few visitors may be grouped into **Everything else**. Search for its name, as in [Find a campaign](#find-a-campaign), to see it on its own row. It's traffic credit: the rep whose link brought the buyer. As its tooltip says, it isn't commission credit. It also counts only from the day tracking started, which the info icon beside **Rep-driven revenue** shows. **Top referrers** lists only outside sites that sent visitors. Visits with no outside referring site, or from your own store's pages, aren't listed, so a period with only those shows nothing here. **Channel mix** shows the split by channel. ## Related pages * [Home](/help/admin/home) * [Roles](/help/admin/settings/roles) * [FairShare: sales rep attribution](/concepts/fair-share) * [API overview](/api/overview) This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.