Skip to content

The disclosure gate

The data-disclosure gate is the rule that separates structure from data. It is the reason the object API is split the way it is (see API overview).

  • Metadata / structureGET /object/{name}/metadata returns the SQL-free schema (columns, fields, layout). It carries no record values and no SQL, so it is available to any authenticated user. The UI needs it just to know how to render.
  • Record values & mutations — every endpoint that runs the view’s SQL is gated by the caller’s RBAC verbs for that resource.
Operation Endpoint Required verb
Read schema GET /object/{name}/metadata authentication only
Grid rows POST /object/{name}/table List / View
Record values (edit) POST /object/{name}/form View / Update
Record values (read-only) POST /object/{name}/view View
Create or update POST /object/submit Create (new) or Update (existing)
Delete a row POST /object/delete-row Delete
Row action POST /object/execute-row-action the action’s declared verb (typically Execute)
Export POST /object/export-data Export
Import POST /object/import-data Import

submit picks its verb from the request: Update when the body carries a valid, non-zero Id on a form whose name is not a Create/New/Add/Register/Request-style form; otherwise Create. The check happens before any data is touched.

Exposing the shape of a form (that a “Product” has a Name and a Price) discloses nothing sensitive — it’s the same information a screenshot would. Exposing a row (“Product #42 costs $9.99”) is real data, so it sits behind the gate. Splitting the two lets the client cache structure aggressively while still enforcing per-user access on every value it fetches.