Access Rules

Access rules define which roles can perform specific HTTP methods on your collections and views.

Structure

Access rules are defined per HTTP method with a list of allowed roles:

{
  "access": [
    { "method": "GET", "roleNames": ["_AUTHENTICATED_USER"] },
    { "method": "POST", "roleNames": ["manager", "editor"] },
    { "method": "PATCH", "roleNames": ["manager", "editor"] },
    { "method": "DELETE", "roleNames": ["manager"] }
  ]
}

Supported Methods

Method	Description
GET	Read items from the collection
POST	Create new items
PUT	Replace existing items
PATCH	Update existing items
DELETE	Remove items
LISTEN	Subscribe to real-time updates

note

The LISTEN method is required for real-time functionality. Without LISTEN access configured, clients cannot subscribe to changes on that collection. See Real Time for more details.

LISTEN authorization ends at this gate — it applies no per-row check. A role that can subscribe gets change notifications for every row in the collection, whatever the security policy, view filter or _CREATOR would allow on a read. Notifications carry only record ids, and a follow-up read of a collection or a view is filtered as usual — see Access and Scope.

Never grant LISTEN to _CREATOR. It reads as "notify each user about their own rows" and does nothing of the kind: it hands the whole collection's stream to any authenticated caller.

Role Names

Access rules accept both built-in and custom role names:

{ "method": "GET", "roleNames": ["_EVERYONE"] }
{ "method": "POST", "roleNames": ["_AUTHENTICATED_USER"] }
{ "method": "DELETE", "roleNames": ["manager", "moderator"] }

Multiple Roles

When multiple roles are specified, access is granted if the user has any of the listed roles:

{ "method": "PATCH", "roleNames": ["manager", "editor", "_CREATOR"] }

This allows managers, editors, or the record creator to update items.

_CREATOR is narrower than it looks

_CREATOR restricts a caller to their own rows only when no other rule on that method already grants them access. Alongside a custom role it works as above — a manager gets every row, every other authenticated caller gets their own. Alongside _EVERYONE or _AUTHENTICATED_USER on the same method it becomes a no-op: the blanket role grants those exact callers access that _CREATOR no longer narrows. Any security policy or view filter on the collection is a separate gate and still applies.

Three further limits:

• Collections and views only. A query is not filtered by _CREATOR, even when its access rule names it.
• Never creation. _CREATOR doesn't grant POST — nothing has a creator yet — so a POST rule listing only _CREATOR denies every ordinary caller.
• Not a PUT guard. A PUT without a record id inserts rather than updates, and that insert isn't owner-filtered: it stores a row with an empty createdBy that the caller can no longer read or edit. Pair PUT with a real role.

Configuring Access Rules

In the Developer Portal

1. Navigate to your API
2. Open a collection or view
3. Go to the Access tab
4. Configure permissions for each method

In Schema JSON

Define access rules in your schema file:

{
  "collections": [
    {
      "name": "posts",
      "access": [
        { "method": "GET", "roleNames": ["_EVERYONE"] },
        { "method": "POST", "roleNames": ["_AUTHENTICATED_USER"] },
        { "method": "PATCH", "roleNames": ["_CREATOR", "manager"] },
        { "method": "DELETE", "roleNames": ["_CREATOR", "manager"] }
      ],
      "properties": [...]
    }
  ]
}

View-Level Access

Views can have their own access rules independent of the base collection:

{
  "collections": [
    {
      "name": "posts",
      "access": [
        { "method": "GET", "roleNames": ["_AUTHENTICATED_USER"] }
      ],
      "views": [
        {
          "name": "public-posts",
          "filter": "status eq \"published\"",
          "access": [
            { "method": "GET", "roleNames": ["_EVERYONE"] }
          ]
        }
      ]
    }
  ]
}

In this example:

• The base posts collection requires authentication
• The public-posts view is accessible to everyone

Common Patterns

Public Read, Authenticated Write

[
  { "method": "GET", "roleNames": ["_EVERYONE"] },
  { "method": "POST", "roleNames": ["_AUTHENTICATED_USER"] },
  { "method": "PATCH", "roleNames": ["_AUTHENTICATED_USER"] },
  { "method": "DELETE", "roleNames": ["manager"] }
]

Owner-Only Access

[
  { "method": "POST", "roleNames": ["_AUTHENTICATED_USER"] },
  { "method": "GET", "roleNames": ["_CREATOR"] },
  { "method": "PATCH", "roleNames": ["_CREATOR"] },
  { "method": "DELETE", "roleNames": ["_CREATOR"] }
]

The POST rule is required — without it nothing can be created in the collection at all, since _CREATOR never grants creation.

Manager Full Control

[
  { "method": "GET", "roleNames": ["manager", "viewer"] },
  { "method": "POST", "roleNames": ["manager"] },
  { "method": "PUT", "roleNames": ["manager"] },
  { "method": "PATCH", "roleNames": ["manager"] },
  { "method": "DELETE", "roleNames": ["manager"] }
]

Access Denied Responses

When access is denied, the API returns:

• 401 Unauthorized — No valid authentication token
• 403 Forbidden — Authenticated but insufficient permissions