Skip to main content
Generic row writes go through data_row_create, data_row_save and data_row_update (see Data). But each writable catalog table is gated by its own grant: insert_<table> to create a row, update_<table> to modify one. A key holds only the table grants it was given — so two Company-Admin keys can differ in exactly which tables they may write. Common rules (identical to the generic tools):
  • tenant_id, workspace_id and any owner column (submitted_by_user_id / owner_user_id / user_id) are stamped server-side from your credential — never pass them.
  • Only the table’s registered creatable columns are accepted; identity/ownership columns are stripped or protected.
  • Without the matching insert_<table> / update_<table> grant the call is rejected.

The writable tables

Agent provenance. When an agent run writes to a table that has agent_id / run_id columns (Company Signals, Decisions), the platform stamps both from the run context on every insert and strips them from every update. Values supplied in the payload are ignored — provenance can never be forged or lost.
Upsert on data_row_save keys on external_id (on products, the identity key is identity_key); see the Ingest API for the ingest counterpart. A Company-Admin OAuth connect grants all table writes; a Member connect grants none by default.