Skip to main content
A member site declares what it needs in small JSON files next to its build. They’re published with the build, checked by fluid sites lint and fluid sites publish, and never served as files. Each one is optional.
The site’s database is declared in db/schema.json. See The member site database.

​
Fluid data the site uses

config/access.json lists the Fluid API scopes and member fields the site uses:
config/access.json
Each entry in uses is one of these:
  • A scope, <family>: read or <family>: write. A read scope covers GET calls to the family’s Member API routes, and a write scope every other method.
  • A member field, member.<field>, that fluid.auth.me() returns in viewer.fields.
An entry is listed once, and uses holds at most 64 entries.

​
What each visitor gets

A declaration is what the site asks for. What each visitor’s calls may use is narrower: A site with no config/access.json gets no scope for anyone, its owner included. Its calls through fluid.api answer 403 with scope_not_granted. Every call acts as the visitor, on the visitor’s own data. A site never holds a company token and never reads another person’s data through fluid.api.

​
What your company allows

Your company decides which scopes rep sites may use on a visitor’s data. By default that’s the read scope of each family that holds no personal data, which today is search: read. Families that reach a visitor’s personal or sensitive data, such as orders, subscriptions, addresses, contacts and points, and every write scope, are off until your company turns them on. No visitor sees a consent prompt: the company decides. Admins read and change the list with Read the company’s member site policy and Replace the company’s member site policy.

​
Scope families

The Member API reference lists each family’s operations.

​
Member fields

first_name, last_name, full_name, email, status, avatar_url, bio, language_iso, member_type and rank.

​
Page titles and previews

The storefront writes each page’s <title> and link preview tags (og:title, og:description, og:image and twitter:card) from config/meta.json. Link previews read these tags and never run your site’s code.
config/meta.json
As a visitor moves through a single-page app, the storefront also takes the page’s document.title into its own tab title.

​
Routes

config/routes.json says which file of your build answers a path. With no config/routes.json, every path that isn’t a file is answered by /index.html, the fallback a single-page app needs:
For each request, the site’s host looks for an answer in this order:
  1. A file of the build at that path, such as /assets/index-Bx3zQw9a.js.
  2. The path plus /index.html, so /about serves /about/index.html.
  3. The first route whose path is the path, then the longest route whose prefix matches. A path whose last segment has a file extension, such as /logo.png, never falls back to a route: it’s a missing file.
  4. /404.html from your build, with status 404, when the build has one.
  5. Fluid’s own not-found page.
A route is { "path": ..., "file": ... } for one path, or { "prefix": ..., "file": ... } for every path under a prefix:
config/routes.json
Every route must name a file of your build. A build with no config/routes.json must have an index.html. Your build can’t hold a file under /_fluid/, because the site’s host answers that path itself.