Skip to main content
A 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 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. In the Fluid admin, open Website > Sites and click Visitor data. Tick the scopes Sites may use on a visitor’s data, then click Save. Admins can also 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

config/meta.json holds page titles, descriptions, preview images, the routes to prerender and the Site’s address for its sitemap. Every member is optional, so {} is a valid file, and the Site’s SEO settings decide whatever the file doesn’t name. See SEO and indexing.

​
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.