07 · Tables A→ZM · Share & audit
Control who can do what
A table-centric recap of Eddytor's role model - who can read, edit, build, and administer.
Access in Eddytor is role-only - there's no seat type, plan tier, or subscription gate. What a caller can do to a table is decided entirely by their role (and, for API-key callers, the scopes on the key). Full details in Roles & scopes; here's the table-centric view.
What each role can do to tables
| Role | On tables |
|---|---|
| Viewer | Query/read, view schema & metadata, download objects. |
| Editor | + Insert / update / delete rows, import data, connect storage, run AI queries. |
| Builder | + Create / modify / delete tables, write domains, delete objects, create/revoke API keys, manage AI credentials. |
| Admin | + Org management and reading the audit log. |
Roles are cumulative - each includes everything below it.
API keys narrow, never widen
Good to know
An API key's effective permission is
role ∩ scopes. A key can never exceed its creator's role - so a Builder can
mint a read-only key for a dashboard, but a Viewer can't mint a key that writes.
The destructive ones need Builder/Admin
drop_table requires Builder or Admin (and
confirm=true). Reading the audit log is
Admin-only.