> ## 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. # Forms > Build forms that collect extra details at enrollment checkout after payment, set them up for each country, and view, export and follow up on responses. Use the Forms screen to build forms that collect extra information from your shoppers. A **Post Purchase** form asks for what you need when someone enrolls, such as a date of birth, a tax ID or a signed document. It appears on the order confirmation page, after the payment has gone through. A **General** form is a standalone form you share by link or embed on a site. A Post Purchase form never stands between a shopper and paying. Checkout takes the payment and places the order first. The form appears after that, so it doesn't add steps before purchase or cost you orders. ## Where to find it In the admin sidebar, under **More**, click **Content** > **Forms**. If **Forms** isn't in your sidebar, your role can't view forms. An admin who manages roles can change this on [Roles](/help/admin/settings/roles). On the role's **Permissions** tab, the area is **Forms**, in the **Content & Website** card. Its permissions are: * **View forms and their submissions**: shows the screen and each form's responses. * **Build new forms**: shows **Create Form(s)**. * **Edit form fields and settings**: lets you change and save a form, and send reminder emails. * **Delete forms**: shows **Delete**. * **See answers the form builder marked sensitive in responses and exports**: shows answers to fields marked **Sensitive Info**. Without it, those answers are hidden. * **Mark form fields as sensitive, and clear that mark, in the form builder**: lets you change a field's **Sensitive Info** setting. ## How forms work with checkout ### Which checkouts show a form Forms appear only on **enrollment checkouts**, where someone buys an enrollment pack or otherwise enrolls to become a member, for example a rep. A shopper on a regular checkout never sees a form. An enrollment checkout shows every form that meets all three conditions: * Its **Form type** is **Post Purchase**. * It's **Active**. * Its countries include the country of the shopper's cart. You don't attach a form to an enrollment pack, a member type or a product. Every enrollment in a country gets that country's Post Purchase forms. If more than one form matches, the shopper sees their fields together as one form. ### When the shopper sees it The shopper fills in checkout and clicks **Pay now**. Checkout takes the payment and places the order. A form never blocks this step. At the top of the order confirmation page, above the order details, the shopper sees **Hang on, we need additional information to complete your order!** and your form's fields, with a **Submit** button. Checkout checks that every required field has an answer. After a successful submit, the form is replaced by **Congratulations!** and **Enrollment complete**, with a **Continue shopping** button. File fields upload as soon as the shopper drops in a file, before they click **Submit**. Files must be an image or a PDF, up to 5 MB. ### If the shopper doesn't finish the form The order still stands. The payment is taken and the order is placed before the form appears, so leaving the form unfinished doesn't cancel or hold anything. The shopper also becomes a member of the enrollment's member type when the order is placed, not when they submit the form. What stays open is the **enrollment**. It's complete only when every required field has an answer. Until then: * The shopper can come back to the order confirmation page and finish. Answers they already saved are filled in. * Fluid emails them reminders with a link back to that page. The first goes about an hour after checkout, and up to five go out over about 25 days. Reminders go only while the enrollment is incomplete, and only if the enrollment completion reminder email is **Active** on [Communications](/help/admin/settings/communications). * You can see who hasn't finished, and remind them yourself. See [Send reminder emails](#send-reminder-emails). When the enrollment completes, Fluid saves a copy of the answers with the new member's record. Only fields you mark **Required** must be answered. A form whose fields are all optional doesn't hold the enrollment open. ## What's on the screen The page header has the **Create Form(s)** button. Below it, five stats cover all your forms: **Total Forms**, **Total Responses**, **Completed Responses**, **Completion Rate** and **Today's Responses**. Use the **Active** and **Draft** tabs to switch between active forms and draft forms. The table shows each form's **Title**, **Last Updated**, **Status** and number of **Responses**. * Click a row to open the form's responses. See [View responses](#view-responses). * Each row's actions menu has **Share**, **Duplicate** and **Delete**. ## Build a form Click **Create Form(s)**. The form builder opens with the **Set up your form** window on top. Fill in: * **Form title**: for example `Enrollment - United States`. Shoppers don't see the title at checkout. * **Form type**: **Post Purchase** for a form that appears at enrollment checkout, or **General** for a standalone form. See [Form types](#form-types). * **Countries**: pick at least one country. An enrollment checkout shows the form only for carts in these countries. * **Active**: turn this on when the form is ready for shoppers. Leave it off to keep the form as a draft. Click **Create form**. The button stays grayed out until you enter a title and choose a type and a country. In the left panel, on the **Components** tab, drag components into the form in the center. Drag them to change their order. See [Field types](#field-types). Click a field to open its settings on the right. Enter the **Label** the shopper sees, and turn on **Required** for each field the shopper must answer. See [Field settings](#field-settings). Click **Save** in the header. The form isn't created until you save it. The header shows **Unsaved Changes** until you do. Click **Preview** to open the form in a new tab. To change a form's title, type, countries or **Active** setting later, click the settings gear in the builder's header. The **Form Settings** panel has **Form Title**, **Active**, **Form Type**, **Form Redirect URL** and **Where**, which holds the form's countries. **Form Redirect URL** applies to General forms you share. Checkout doesn't use it. ### Form types | Form type | Where it appears | Use it for | | - | - | - | | **Post Purchase** | On the order confirmation page of enrollment checkouts, after payment, for carts in the form's countries | Details you need from new members: identity, tax and compliance details, documents, preferences | | **General** | Only where you share it: a link or an embed from **Share** | Surveys, applications and sign-ups outside checkout | | **Pre Purchase (retired)** | Asked before payment, on older forms only | Nothing new. You can't choose it. To stop asking before payment, change an older form to **Post Purchase** | Checkout shows only Post Purchase fields, but Fluid counts the fields of every active form for a country when it decides whether an enrollment is complete. An active General form for the same country as a Post Purchase form can keep those enrollments from completing. Turn off **Active** on a General form you don't need, or remove from it the countries where you enroll members. ### Field types The **Components** tab groups components into **Header Settings**, **Frequently Used**, **Create Form Scratch**, **Layout**, **Legal** and **Contact**. Some appear in more than one group. | Component | What the shopper sees | Good for | | - | - | - | | **Short Text Entry** | A one-line text box | Tax ID, business name, referral name | | **Long Text Entry** | A multi-line text box | Open-ended answers | | **Number Entry** | A number box | Numeric answers, such as years of experience | | **Email** | An email box | A second contact address | | **Phone Number** | A phone number box | A contact number | | **Legal Name** | A text box for a legal name | Name as it appears on tax or ID documents | | **Full Name** | A text box for a full name | Name for a business or co-applicant | | **Date of Birth** | A date picker | Age checks | | **Social Security Number** | A text box that formats a US SSN as it's typed | US tax reporting. **Sensitive Info** is on by default | | **Yes No Entry** | A choice of **Yes**, **No** and **Maybe** | Simple questions | | **Multiple Choice** | A list of options. Click **Add option** to add one | "How did you hear about us?" and preferences | | **Checkbox** | A checkbox with your label | A confirmation or consent statement | | **File Upload** | A drop box for one image or PDF, up to 5 MB | Signed documents, IDs, certificates | | **File Download** | A **Download file** link to a file you upload | A document the shopper reads, signs and uploads | | **Header**, **Section**, **Helper Text**, **Error Text** | Text and layout | Headings and instructions | ### Field settings Click a field to open ***Field* Settings**, with **Basic**, **Styles** and **Access** tabs. Which settings appear depends on the field. * **Label**: the question the shopper sees. * **Placeholder**: hint text inside an empty box. * **Show Label**: shows or hides the label above the field. * **Required**: the shopper must answer the field before they can submit the form. * **Sensitive Info**: hides the answer from team members who can't see sensitive answers, in the responses list and in exports. You need the permission to mark fields as sensitive to change it. * **Auto Translate**: on by default. Turn it off to enter your own translation of the label for each language in the **Translations** editor. * **Add Max and Min Digits**: on **Number Entry**, adds **Min** and **Max** settings. Checkout doesn't enforce them, so don't rely on them to reject an answer. * **Document Format**: on **Checkbox**, attaches a document to the checkbox as **Text Input**, **Upload Document** or **Input Link**. Checkout checks only that required fields have an answer. It doesn't check a field's answer against a pattern, and forms have no conditional logic, so every field shows to every shopper who sees the form. ## Set up forms for each country Each form covers the countries you choose, so you can ask each market only what it needs. * **One form per country** works best when countries need different fields or different languages. For example, `Enrollment - United States` asks for a W-9, and `Enrollment - Canada` asks for a GST/HST number. * **One form for several countries** works when every country needs the same fields. * **Several forms for one country** also works. The shopper sees their fields together as one form, so make sure two forms don't ask the same question. Write each form's labels in the language its shoppers use. When you turn a country on in [Countries](/help/admin/settings/countries), the setup checklist can offer suggested enrollment fields for that country. Fields you select there are added to a Post Purchase form named for the country, which you then change in the builder. ## View responses Click a form's row on the Forms screen. The responses page shows **Total responses**, **Completed** and **Completion rate**, and has two tabs: * **Responses**: under **Individual responses**, one row per person. Click a row to read their answers, and use **Previous response** and **Next response** to move between people. If you can see sensitive answers, click **Reveal answer** to show one. * **Data visualization**: a summary of what people answered. The header has **Edit Form**, **Share**, and a **More actions** menu with **Export CSV** and, for Post Purchase forms, **Send reminder emails**. A person's own answers also appear on their details page in the admin, in the **Form Submissions** card. ### Export responses On the responses page, open **More actions** and choose **Export CSV**. In **Confirm export**, set a **Start Date** and **End Date**, or leave both blank to export every response. Choose the **Respondent details** and **Questions** columns to include. Click **Export CSV**. ### Send reminder emails **Send reminder emails** appears for Post Purchase forms when manual reminders are turned on for your company and your role can edit forms. It reminds people who paid but haven't finished the form. On the responses page, open **More actions** and choose **Send reminder emails**. Everyone who hasn't finished is reminded unless you pick specific people. You can remind the same person again after 24 hours. Send the reminders. Each person gets an email with a link back to their form. ## Recommended fields ### For enrollment Ask only what you need to pay, report on and support a new member. Each extra field is one more thing between them and **Enrollment complete**. | Field | Component | Required | Notes | | - | - | - | - | | Legal name | **Legal Name** | Yes | Match the name to tax and payout records | | Date of birth | **Date of Birth** | Yes, where you have an age minimum | Checkout doesn't check the age. Review answers if you need to enforce one | | Tax ID | **Short Text Entry**, or **Social Security Number** in the US | Where you pay commissions | Turn on **Sensitive Info**. Name the ID in the label, for example "SIN" or "ABN" | | Tax form | **File Download** and **File Upload** | Where a signed form is required | For example, a blank W-9 to download and a box to upload the signed copy | | Business details | **Short Text Entry** | No | For members who enroll as a business | | Consent | **Checkbox** | Yes | Put the full statement in the label. For legal agreements, use [Agreements](/help/admin/settings/agreements) instead | Agreements you link to an enrollment appear in checkout before the order is placed, and each acceptance is recorded on the agreement's **Responses** table. Use them for terms and policies the shopper must accept. Use a form for the details you collect after. Don't ask for a sponsor or enroller in a form. An answer is stored as text and doesn't change who gets credit for the order or who the new member's sponsor is. ### For attribution and preferences | Field | Component | Notes | | - | - | - | | How did you hear about us? | **Multiple Choice** | Options such as Social media, A friend or family member, A rep, Search, Event. Keep it optional | | Product interests | **Multiple Choice** | One option per product line | | Contact preference | **Multiple Choice** | Email, Text message, Phone call | | Anything else? | **Long Text Entry** | Keep it optional | On a Post Purchase form, these questions reach new members only. To ask every customer, use a General form and share its link, for example in a follow-up email. ## Best practices * **Keep enrollment forms short.** The order is already placed, so a long form doesn't cost you the sale, but every required field delays the enrollment's completion. * **Mark only what you truly need as Required.** Optional fields never hold an enrollment open. * **Turn on Sensitive Info** for tax IDs, SSNs, dates of birth and uploaded identity documents. * **Test before you turn on Active.** Use **Preview**, then place a test enrollment in each country the form covers. * **Keep reminders on.** Leave the enrollment completion reminder email **Active** on [Communications](/help/admin/settings/communications) so new members are prompted to finish. * **Check for duplicates** when more than one form covers a country. ## Frequently asked questions No. A Post Purchase form appears on the order confirmation page, after the payment is taken and the order is placed. Only an older form whose type shows **Pre Purchase (retired)** still asks before payment. Change it to **Post Purchase**. Check that the form is **Active**, that its **Form type** is **Post Purchase**, and that its countries include the cart's country. Also check that the checkout is an enrollment checkout. Regular checkouts never show forms. No. Forms appear only on enrollment checkouts. To ask other customers a question, share a General form's link. Not today. Every enrollment in a country gets that country's Post Purchase forms, whatever the pack or member type. Yes. The order is placed and the shopper becomes a member before the form appears. Only the enrollment stays incomplete until the required fields are answered. From the reminder emails, which link back to the order confirmation page, or by going back to that page. Their saved answers are filled in. A field you remove from the form stops appearing for shoppers. Answers already given to it aren't deleted. The field is marked **Sensitive Info**, and your role can't see sensitive answers. Ask an admin who manages roles to give you **See answers the form builder marked sensitive in responses and exports** under **Forms**. See [Roles](/help/admin/settings/roles). Yes. Developers can read and answer a shopper's enrollment fields through the Checkout API, and subscribe to form and enrollment webhooks. See [Checkout forms](/guides/checkout-forms). Email Fluid support at [help@fluid.app](mailto:help@fluid.app). The [Getting help](/help/getting-help) page lists what to include in your request. ## Related pages * [Checkout forms for developers](/guides/checkout-forms) * [Agreements](/help/admin/settings/agreements) * [Member Types](/help/admin/settings/member-types) * [Countries](/help/admin/settings/countries) * [Communications](/help/admin/settings/communications) * [Roles](/help/admin/settings/roles) This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.