Everything Fóir does

Define the shape of your data from sixteen built-in field types, including rich text, exact decimals, media, references and geopoints, in the console or in code.

Point one model at another with a reference field and read across it in one query, with relationship kinds that decide whether access and deletes follow the reference.

Rich text that holds your own models among the paragraphs in any order, inline models you define once and reuse as field types, and typed lists.

Declare a reference field as a model's hierarchy and its records form a tree, with every read returning the record's path and its ancestors.

Translate text and prose fields per locale, with a fallback chain walked field by field and a strict mode that reports which fields had no translation.

Vary a whole record, a single field or a single prose entry by audience, with the variant selected on the server from reusable, prioritised targeting rules.

Build audiences from context dimensions such as device, platform, locale and sign-in status, and from rule-based segments the server evaluates on every request.

Address a record by a readable key, and declare extra unique lookup keys on a model so a handle or a SKU finds it in one typed query.

Colour, type and spacing held as tokens on the project and served from the API, so an app that reads them at runtime shows a rebrand once it is published.

On a model with publishing on, each save writes a draft while the API keeps serving the published version. The console previews a draft as the API would serve it.

On versioned models each save is a numbered version, kept for a window set by your plan. Restoring adds a new version, and a dry run reports the effect first.

Set a publish time on a record version, and an unpublish time if the content should come down again. A schedule can be changed or cancelled until it fires.

A rollout publishes a named batch of record versions at one scheduled moment. A failed item is skipped and can be retried, and the batch can be rolled back.

Changes to models and configuration are staged as drafts and released together, now or at a set time, with a diff of breaking changes and a rollback.

Versioning, publishing and variants are switched on per model and are off by default, so each model takes on only the workflow its records need.

Fóir generates a GraphQL schema from your models. Production serves the published schema, and a CLI check fails your build when committed types fall behind the project.

A read passes a locale, a context and a preview flag. The server applies the locale fallback, picks the variant and selects the draft or published version.

Subscribe over a WebSocket to hear when records change. Events carry the id of what changed, and the SDK's live module applies them to your query cache.

Each key is public or secret and belongs to one project. It holds the scopes you give it, and can be narrowed to chosen models and operations or one organisation.

The GraphQL API caches resolved responses for 60 seconds by default and drops them when a record they contain is written. A CLI command purges by hand.

A typed client that writes the GraphQL for your application, with types generated per key, and a CLI for content, schema, publishing and configuration with JSON output for scripts.

Request rates are set per key by your plan, and query depth, field count and aliases are capped before a query runs. Responses report the limits in their headers.

A sign-in page that Fóir hosts for your users on a login domain you verify, carrying your project's name, logo and colour, with password, emailed-code and provider sign-in.

Your users sign in through any identity provider that publishes an OpenID Connect discovery document. You supply its discovery URL and your client credentials, and Fóir runs the exchange.

Require a passkey or an authenticator-app code as a second step after a password, before a sensitive operation or on every sign-in to an app.

A role is a set of permissions you compose, granted across a workspace or on one project. Your users' roles are declared per project in config or the CLI.

A model declares who owns its records, and each record is private or public. A private record can be shared with a named person by a grant you can revoke.

A field can name which kinds of caller may read it and which may write it. There are five kinds, decided by the credential a request carries.

The console lists the sessions your users hold on a custom login domain, per sign-in app, and revokes any one. Other sign-ins end by token revocation or expiry.

Who did what and when, recorded alongside the change and readable in the console by team members who hold the permission. Entries are kept for 90 days.

Access rules are compiled into Postgres row-level security, so the database filters what a request can read and a forgotten check in application code does not expose a row.

A workspace is your account. Every governed row carries its id, and the policy on the table compares that id with the caller's session before anything else is considered.

Each project has its own content, users, files, keys, secrets and sign-in domains. An API key belongs to exactly one project and cannot be pointed at another.

When your product has tenants of its own, each one is an organisation. The database stamps every row with its organisation and filters every read by it.

When Fóir staff need to look inside a workspace to help, one of its administrators approves the request with a one-time code. The visit lasts an hour and is recorded.

The engine that compiles the rules is open source, so you can read how the policies are written and run its tests yourself.

Each client gets a project with its own content, keys, users and sign-in. One workspace administers them all, and a client you invite reaches only their own project.

Give your product tenants of its own. Each customer of yours is an organisation inside your project, with its own members, users, data and limits.

Organisations nest to any depth. A parent reads everything beneath it and changes only its own rows, and models and settings are inherited down the tree.

One call creates an organisation with its brand, its settings, its first member and a key confined to it. Run it twice and you still get one organisation.

One config file declares staging and production as named projects, and the CLI pushes to one per run. They stay identical apart from declared destinations, and drift is reported.

A project can serve its API from a domain you verify, and a sign-in app can serve the hosted sign-in page from one. Both are optional, with TLS issued automatically.

Upload a file once and reference it by id from any record, with dimensions and a placeholder read from images when the upload is confirmed.

Each image is served in eight named sizes and four formats, rendered the first time a URL is requested, with crops and focal points set per usage.

A file has its own owner and visibility, with public files served from a plain URL and private files through a signed link that expires.

Every uploaded video gets a thumbnail, a short animated preview and its duration, and adaptive HLS streaming is included on some plans.

A schedule runs one of your operations on a cron expression, in a timezone you name, and can be paused, resumed or triggered by hand.

A hook runs one of your operations when something happens in a project, such as a record being published, and every delivery is stored with its status.

An operation is an HTTP endpoint you host and register with Fóir, which calls it with a signed payload, retries failures and records every run.

A quota caps how often an operation can run in a rolling window, per signed-in user or across a wider pool, and returns a message you write.

A precondition decides whether an operation may run, by the caller's segment membership or by a rule on the input, and refuses with a message you write.

A vault for the credentials your operations use, stored encrypted, addressed by reference and rotated without a redeploy.

Send email, in-app and push notifications to your users, directly or from an event, with preferences each user sets per category and channel.

Keyword search across the records in a project, ranked by relevance and confined to the records the caller is allowed to read.

Fóir generates embeddings for the models you opt in, so records can be retrieved by meaning, matched to a similar record, or searched with your own vectors.

Add a geopoint field to a model and query for the records nearest a point or another record, ordered by distance and optionally limited to a radius.

Threaded comments your team attaches to a record, a file, a model or another subject, down to one field or one passage, with mentions and an inbox per project.

Assign a note to a team member and it becomes a task, with a due date, sub-tasks and a queue per person. Settling the note marks it done.

An assistant in the console that works with the signed-in person's own permissions. Its edits arrive as unsaved changes, as drafts or as requests you approve.

Hand a note thread to the assistant for one short unattended run. It reads the project and answers on the thread, and it cannot edit, publish or delete content.

Connect your own agent to Fóir's hosted MCP server. It works inside the permissions of whoever connected it, or the scopes of the secret key it was given.

Signed-in users can write notes about a record and read your team's replies. A React widget files the note for you, and a project can accept visitor feedback.

One command exports a project as typed Postgres tables generated from your models, with foreign keys, your published content and download links for your files.

The export bundle includes Postgres row-level security for which rows each user can read. You apply it yourself. Field permissions, API scopes and write rules stay behind.

Fóir does not host your code. You register a function you host as an operation, and Fóir calls it with a signed, scoped token, retries failures and records each run.

Extend the console with your own tools. An app is a web page you host, embedded as a page, an editor tab, a sidebar or a field editor.

Models, API keys, hooks, sign-in providers and the rest of a project's configuration in one file you commit. A push stages a draft and a release publishes it.