Give an integration only the intended row-data access and document its owner and replacement procedure.
Match the credential to the job
The official token guide distinguishes database tokens for row-data operations from account-session/JWT access used for broader operations. It describes per-table operation permissions and regeneration of an exposed token. Do not grant an account-level credential merely because the integration needs to read a report.
Hypothetical example: a reporting service needs to read Orders but must not edit them or access Staff. Give that service its own identity in the credential inventory. Its owner should know what consumes the token, where it is stored and how to replace it without leaving a forgotten copy active.
Documentation: Baserow: Database tokens
Test the boundary in a synthetic workspace
Write an access matrix before creating the token. List each table and the required operation. “Integration access” is too broad: a tool that submits new records has a different requirement from one that reads an existing list. Check the current documentation’s permission semantics rather than assuming each toggle is independent.
Use only synthetic data for negative tests. An intentionally denied edit should target a disposable sample, because an incorrectly broad token might allow it. Inspect the resulting data as well as the response so a request cannot silently change the fixture while the evaluator assumes it failed.
- Create a dedicated integration token using authorized administration access.
- Set the narrowest table and operation scope consistent with the workflow.
- Store it in the integration’s secret configuration, not browser-visible source or screenshots.
- Try an allowed request and an unauthorized table/operation against synthetic records.
- Record expected and actual outcomes, then remove any disposable test changes.
Plan for replacement before exposure occurs
A token inventory needs a purpose and owner, not its secret value. Keep operational records free of credentials. When a service is retired, its integration entry should lead you to the matching token so access can be removed deliberately.
For replacement, identify all consumers first, create or regenerate through the documented method, update the secret configuration, and verify the integration’s ordinary workflow. Where regeneration invalidates the old value immediately, plan the brief interruption rather than assuming both values will work during transition.
Do not publish tokens in a tutorial, client-side page or shared issue. If access fails, check the destination, table identity, header format and assigned scope before increasing privileges. A wrong table ID is not a reason to grant all-table access. This page is a scope-review procedure, not a security certification of an installation.
Hypothetical report-reader access matrix
This is an illustrative worksheet to adapt to your own evaluation. It is not a measured product test or a claim about results in your installation.
| Resource or action | Intended result | Evidence to record |
|---|---|---|
| Read Orders | Allowed | Sample row returned |
| Update Orders | Denied | No sample change |
| Read Staff | Denied | No staff fixture exposed |
| Retire report service | Access removed | Owner confirms consumers stopped |
A credential is ready when its purpose, boundary, owner and replacement path are all documented.
Inspect the official interface evidence
These previously captured interfaces provide orientation. Their versions and dates are distinct from the documentation review above.
Inspect the interface, with its context.
Open a specimen to see the source image and the observations it supports. A vendor demonstration is distinct from a self-hosted installation.
BaserowOfficial live template · Demo version not disclosed
- Table navigationThe sidebar separates the demo’s task-management examples.
- View controlsFilter, sort, group and hide-field controls are visible in this preview.
- Calculated fieldsFormula columns display generated task names and identifiers.
Check the facts and their boundaries.
Official documentation supports the product statements. The evaluation procedures and synthetic examples are editorial guidance. We have not independently run the installation, migration or recovery procedures described here.
Current database-token semantics and permissions; no live credentials used. Reviewed 2026-11-01.