API rules
API Rules are your collection access controls and data filters.
Each collection has 5 rules, corresponding to the specific API action:
listRule
viewRule
createRule
updateRule
deleteRule
Auth collections has an additional options.manageRule
used to allow one user (it could be even
from a different collection) to be able to fully manage the data of another user (eg. changing their email,
password, etc.).
Each rule could be set to:
- "locked" - aka.
null
, which means that the action could be performed only by an authorized admin (this is the default) - Empty string - anyone will be able to perform the action (admins, authorized users and guests)
- Non-empty string - only users (authorized or not) that satisfies the rule filter expression will be able to perform this action
PocketBase API Rules acts also as records filter!
Or in other words, you could for example allow listing only the "active" records of your collection,
by using a simple filter expression such as:
status = "active"
(where "status" is a field defined in your Collection).
The API Rules are ignored when the action is performed by an authorized admin (admins can always access everything)!
Filters syntax
You could find information about the supported fields in your collection API rules tab:

There is autocomplete to help you guide you while typing the rule filter expression, but in general, you have access to 3 groups of fields:
- Your Collection schema fields
This also include all nested relations fields too, eg.someRelField.status != "pending"
@request.*
Used to access the current request data, such as query parameters, body/form data, authorized user state, etc.@request.method
- the HTTP request method (eg.@request.method = 'GET'
)@request.query.*
- the request query parameters (eg.@request.query.page = 1
)@request.data.*
- the submitted body parameters (eg.@request.data.title != ""
)@request.auth.*
- the current authenticated model (eg.@request.auth.id != ''
)
@collection.*
This filter could be used to target other collections that are not directly related to the current one (aka. there is no relation field pointing to it) but both shares a common field value, like for example a category id:@collection.news.categoryId ?= categoryId && @collection.news.author ?= @request.auth.id
The syntax basically follows the format
OPERAND
OPERATOR
OPERAND
, where:
OPERAND
- could be any of the above field literal, string (single or double quoted), number, null, true, falseOPERATOR
- is one of:
=
Equal!=
NOT equal>
Greater than>=
Greater than or equal<
Less than<=
Less than or equal~
Like/Contains (if not specified auto wraps the right string OPERAND in a "%" for wildcard match)!~
NOT Like/Contains (if not specified auto wraps the right string OPERAND in a "%" for wildcard match)?=
Any/At least one of Equal?!=
Any/At least one of NOT equal?>
Any/At least one of Greater than?>=
Any/At least one of Greater than or equal?<
Any/At least one of Less than?<=
Any/At least one of Less than or equal?~
Any/At least one of Like/Contains (if not specified auto wraps the right string OPERAND in a "%" for wildcard match)?!~
Any/At least one of NOT Like/Contains (if not specified auto wraps the right string OPERAND in a "%" for wildcard match)
To group and combine several expressions you could use brackets
(...)
, &&
(AND) and ||
(OR) tokens.
Examples
- Allow only registered users:
@request.auth.id != ""
- Allow only registered users and return records that are either "active" or "pending":
@request.auth.id != "" && (status = "active" || status = "pending")
- Allow access by anyone and return only the records where the title field value starts with
"Lorem" (eg. "Lorem ipsum"):
title ~ "Lorem%"