Features Locations Pricing FAQ Docs Blog
Log in Get Started →

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

  1. Open the admin panel at https://<instance-name>.pocketbasecloud.com/_/
  2. Click New collection
  3. Choose the type:
    • Base — regular data (posts, products, comments, …)
    • Auth — user accounts with login capability
    • View — read-only collection backed by a SQL SELECT
  4. Add fields and click Create

Field types

PocketBase supports the field types you’d expect:

TypeUse for
text, editor, number, boolBasic values, rich text
email, url, dateValidated formats
selectOne or more values from a fixed list
relationReferences to records in another collection
fileFile uploads
jsonArbitrary 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.

Next steps