The Pocketbase API is a CRUD api to interact with our system.
It is exposed by Pocketbase and is covered in detail on their api docs page

I find the pocketbase docs to be a bit confusing to read and look through at times. There is a lot of information there for many different systems within pocketbase, and the info is often not where you would expect.

This doc is meant to outline how we use the api, and link to the relevant docs.


n8n integration

The main purpose of this api is for use within n8n automations.
I have created sub-workflows that hide the more technical aspects of using the api like authentication and provide an easy to use interface.

There are currently 4 operations that should cover any need we have.


PB:List

Performs queries for multiple items/searches.
Returns an object that contains an array of items and meta fields.
PB Docs

Inputs:

  • collection*
  • filter (optional)
  • sort (optional)
  • expand (optional)
  • fields (optional)
  • page (optional) | pagination page, default: 1
  • perPage (optional) | number per page, default: 30
  • skipTotal (optional) | boolean to skip total count for speed up, default: false

PB:View

Fetches information of a single record.
PB Docs

Inputs:

  • collection*
  • recordID*
  • expand (optional)
  • fields (optional)

PB:Create

Creates a new record.
PB Docs

Inputs:

  • collection*
  • body (object) | the object to create

PB:Update

Updates an existing record.
PB Docs

Inputs:

  • collection*
  • recordID*
  • body (object) | any field that is being updated in the record

An “*” means that input is required.

Note there is no PB:Delete function. This is simply because it’s a bit dangerous and we don’t have a use for it right now. Pocketbase also provides a PB:Batch endpoint for updating many records at once, but we don’t need that yet either.

This API replaces the Legacy API.


Auth

This API uses pocketbase _superadmin privileges, meaning it can do anything within our system.

Details on how it is set up is in the sudo API Keys section of the PB docs.
Basically the requests attach an impersonate token that allows it to act as a superadmin.

These tokens have an expiry and cannot be renewed, but luckily can be easily rotated in an n8n credential without needing to update all sub workflow nodes.

This means the permissions from the app do not apply. You could potentially return incorrect data or share private information if you do not structure your queries correctly.