Collections & API Rules
Collections are PocketBase’s tables. Each collection defines a schema (typed fields) and a set of API rules that control who can list, view, create, update, and delete its records. Getting the rules right is the single most important step in securing your app.
Creating a collection
- Open the admin panel at
https://<instance-name>.pocketbasecloud.com/_/ - Click New collection
- Choose the type:
- Base — regular data (posts, products, comments, …)
- Auth — user accounts with login capability
- View — read-only collection backed by a SQL
SELECT
- Add fields and click Create
Field types
PocketBase supports the field types you’d expect:
| Type | Use for |
|---|---|
text, editor, number, bool | Basic values, rich text |
email, url, date | Validated formats |
select | One or more values from a fixed list |
relation | References to records in another collection |
file | File uploads |
json | Arbitrary structured data |
Relations are expanded on demand with the expand query parameter:
const post = await pb.collection("posts").getOne("RECORD_ID", {
expand: "author,comments_via_post",
});
API rules
Each collection has five rules — List, View, Create, Update, and Delete — edited from the lock icon on the collection page. A rule is a filter expression; the operation is allowed only when the expression matches.
Three states matter:
- Locked (superusers only) — the rule is
null; only superusers via the admin panel or admin token can perform the operation - Empty string — anyone can perform the operation
- Filter expression — allowed only when the expression evaluates to true
Common rule recipes
Only signed-in users can read:
@request.auth.id != ""
Users can only see and edit their own records (with an owner relation
field pointing to users):
owner = @request.auth.id
Anyone can read published posts, authors see their drafts too:
status = "published" || author = @request.auth.id
Validate incoming data on create — e.g., force the owner field to the
current user:
@request.auth.id != "" && @request.body.owner = @request.auth.id
Rules can reference the current record’s fields, @request.auth (the
authenticated user), @request.body, @request.query, and even fields across
relations (author.verified = true).
Testing your rules
The admin panel’s API preview on each collection shows the exact REST
endpoints and lets you copy example requests. A quick way to verify rules is
to call the API without a token and confirm you get a 403 or filtered
results, then repeat with a logged-in user.
Important: never leave Create/Update/Delete rules empty on a production collection unless you truly want them public. Locked-by-default is the safe starting point.