> ## 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. # Admins > Add admins, email them an invitation, choose their roles, and edit or delete admin accounts for your company. Use the **Admins** screen to add, invite and manage the people who can log in to your company's admin. Each admin needs at least one role, which controls what they can see and do. ## Where to find it In the admin sidebar, under **People**, select **Admins**. To open this screen, your role needs **View only** or **Full access** for **Company Admins**. To add, edit, delete or export admins, it needs **Full access**. To add or edit an admin, it also needs **View only** or **Full access** for **Roles**, so the form can list your company's roles. To send invites, your role also needs the **Edit user profiles, status, and details** switch for **Users (Customers & Admins)**. On the [Roles](/help/admin/settings/roles) screen, **Company Admins** and **Users (Customers & Admins)** are in the **People** card, and **Roles** is in the **Settings** card. Open the card and set access from the area's menu, not the card's. To turn on a single switch, click the area's name to show its switches. ## What's on the screen **New Admin** and **Export** are at the top of the page. The banner above the list lets you **Try it** with the new Admins table, which keeps your search, sort and page when you come back from an admin's page; **Switch back** returns to this table. ### Admins list * Use the search box to find an admin. * You can sort the list by **Username**, **Name** or **Email**. The list has these columns: * **Username** * **Name**: the admin's full name, or **No Name Provided**. * **Email** * **Status** * **Roles**: up to three of the admin's roles, then a count such as **+2 more**. Click an admin to open their page. Each row's actions menu has **Edit**, **Send Invite** and **Delete**. To delete several admins at once, select their rows and use the menu in the table header, which shows the count, such as **Delete 3 Admins**. ### Admin page The admin page opens when you click **New Admin** or an admin in the list. A new admin's page is titled **Invite Admin**. A saved admin's page is titled **Admin Details** and shows the admin's name with a status badge. The main cards: * **New Admin** (**Admin Details** on a saved admin): **Email Address**, **First Name** and **Last Name**, all required. * **Additional Details**: **Phone Number**, **External ID** and **Username**, all optional. Click the card's title to hide or show them. **Email Address** and **External ID** can't be changed after the admin is created. The cards on the right: * **Roles**: check one or more of your company's roles. At least one is required. On a new admin, a role named **Admin** starts checked if your company has one. **Manage Roles** opens the [Roles](/help/admin/settings/roles) screen. * **Status**: **Active** means the admin can log in and access the platform. A new admin starts as **Active**; leave it that way when you add an admin. On a saved admin, **Inactive** means they can't log in. * **Email is the Primary Key**, on a new admin only: if the email address already belongs to a customer or rep account, the new admin is linked to that account. * **Profile**: **Country** and **Language**, from your company's countries and languages. A new admin starts with your own country and language. On a new admin's page, **Cancel** and **Send Invite** are at the top. On a saved admin's page, **Save** and the **Admin actions** menu are there instead. If the admin is also a rep with the same email address, **View Customer** opens their record on the [Customers](/help/admin/customers) screen. ## Tasks ### Add an admin On the **Admins** screen, click **New Admin**. Enter the **Email Address**, **First Name** and **Last Name**. Fill in **Additional Details** if you need them. In the **Roles** card, check at least one role. Check the **Country** and **Language**. Click **Send Invite** to create the admin and email them an invitation. To create the admin without emailing them, click the arrow next to **Send Invite** and choose **Create Without Invite**. A confirmation message appears and you return to the admins list. If your role can't send invites, use **Create Without Invite**. See [Where to find it](#where-to-find-it). ### Edit an admin In the list, click the admin, or choose **Edit** from their row's actions menu. Change the fields you need. **Save** becomes available once you change something. Click **Save**. A confirmation message appears, and you stay on the admin's page. ### Send an invite In the list, open the admin's row actions menu. Or open the admin and click the **Admin actions** menu. Choose **Send Invite**. Fluid emails an invitation to the admin's email address, and a confirmation message appears. ### Delete an admin In the list, click the admin. Open the **Admin actions** menu and choose **Delete**. In the **Delete this admin?** dialog, click **Delete**. A confirmation message appears and you return to the admins list. You can also choose **Delete** from an admin's row actions menu in the list, or select several rows and choose **Delete** from the table header's menu. Deleting an admin can't be undone. When you delete from the list, check that you've picked the right admins first. ### Export admins On the **Admins** screen, click **Export**. In the **Export Admins** dialog, click **Export**. Your browser downloads `exported_admins_data.csv`. The file has a row for each of your company's admins, so check it before you share it. Each row has the admin's first and last name, email, phone, username, external ID, whether they're active, when they were created, and their roles. ## Frequently asked questions Your role has **View only** for **Company Admins**. With **View only**, you can open admins but not change them: the list has no actions menus, and an admin's page has no **Save** and its fields are grayed out. Ask an admin who manages roles to give your role **Full access** for **Company Admins**. See [Roles](/help/admin/settings/roles). Either your company has no roles yet, or your role can't view roles. An admin needs at least one role, so you can't save the admin until roles appear. To add roles, or to give your role **View only** for **Roles**, see [Roles](/help/admin/settings/roles). **Email Address** and **External ID** are set when you create the admin. On a saved admin's page, they're grayed out. When you create an admin, Fluid links them to any existing customer or rep account with the same email address. If they're also a rep, **View Customer** on their admin page opens their record on the [Customers](/help/admin/customers) screen. ## Related pages * [People](/help/admin/people) * [Customers](/help/admin/customers) * [Roles](/help/admin/settings/roles) This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.