Every table has five operations and each has its own rule. A rule decides, for each request, whether the caller may do that thing to that record. This page is how to set them for a table. The language of rules, with every operator and many recipes, is in Access rules.

​
The five operations

An operation is off until you switch it on. Off means the API acts as if it doesn’t exist (and if all five are off, the table isn’t served).

​
In Studio

Open a table and choose the Access tab.

​
Quick access sets

Quick access set fills in all five actions at once. You can still change each one afterwards. Use one policy for everything applies a single rule to all five. If your choices don’t match a set, the picker shows Custom.

​
Per-action rules

For each action there is a toggle and a rule picker. The picker offers:

​
Warnings

Studio flags choices that open a table too far:
  • Red: “Anyone on the internet, signed in or not, can add records” (a write set to public).
  • Red: the named rule doesn’t exist in this environment, so saving would refuse it.
  • Amber: a write has no rule of its own, so any signed-in user can. Pick one to be explicit.
  • Blue: every action is off, so the table isn’t served through the API: only Studio and secret keys reach it.

​
How rules protect lists

For a list, the rule is worked out before any rows are read. A rule like “the owner column equals the caller” becomes part of the database query, so only the person’s rows are read, pages are the right size, and counts are right. A rule that can’t be turned into a filter is checked row by row afterwards, which is why total can be null and pages can come back short. Prefer simple equality rules on big tables. See How rules are evaluated.

​
What your app sees

​
Defaults to start from

Access rules

The full rule language.

Testing rules

Prove they work.