Documentation

Working with data

Tables

Tables are created and evolved in the data designer (Tables in your app's navigation). Each table belongs to an app — a table task in app core is addressed as core.task in the API.

Creating a table

Tables → New table. Pick the app, name the table, and add columns. Supported column types cover everything you'd expect — text, numeric, boolean, timestamp, JSON, plus platform field types:

  • Reference — a foreign key to another table, rendered as a picker in forms and resolvable in table widgets.
  • File / Image — uploads stored in-database with server-side handling; image fields support client-side crop/resize before upload.
  • Computed — a value derived server-side from an expression.

Every change you make is captured into your active update set.

Editing data

The table view is a full data grid: inline editing, filtering (including reference-aware filters), sorting and bulk actions. It's the same table widget you can place on your own pages.

Row-level security

Each table has an RLS toggle. Enabling it activates PostgreSQL row-level security with a permissive default policy you then narrow down — see Row-level security. Never enable RLS without a policy: with no policy PostgreSQL denies every row.

Protected tables

Platform tables (marked core_lock) can't be dropped or structurally modified from the UI. Your own tables have no such restriction.

Tables over the API

The table registry itself is data: platform meta tables (core._table, core._column, …) are readable through the same data API as your tables, subject to your roles.

# List your tables (meta registry)
curl -H "Authorization: Bearer $TOKEN" \
  "$DATA_API/v1/acme/core/_table?limit=50"