Skip to main content
Concierca AI exposes your business data (customers, orders, products, leads, videos, …) through a registry-driven view model. There are no hardcoded per-table endpoints — everything is discovered and queried generically. Full per-table field definitions — what each source is, how it gets its data, and what every column means — live in the Data Model section: Orders, Order Line Items, Customers, Products, Suppliers, Purchase Orders, Procurement Config, Meeting Notes, Product Demand, Procurement Queue, Customer Reorder Due, Family Trend, Weekly Sales, Seasonality, Strategy, and SOP. For pushing external data in, see the Ingest API.

The view registry model

  • Every queryable surface is a view registered in the platform’s view catalog: a slug, a display label, a source table (or dataset), and a registered column list (column_name + display data_type).
  • Views can be physical-table backed (rows in a real table) or dataset backed (rows in a generic JSONB store, projected to the registered columns). Query semantics are identical for both.
  • Table-level visibility follows department mapping and is default-closed: a view with no department mapping is visible to nobody except tenant admins; otherwise it must be mapped (enabled) to one of your departments. Admins see all views.
  • Queryability requires the source table to be tenant-scoped (both tenant_id and workspace_id columns). Admin meta/audit views are listed for admins with queryable:false and cannot be queried over MCP.
  • Row-level visibility: on a view whose source table has a scope column, you only receive the rows scoped to you — tenant-wide rows, rows of your departments, your own user-scoped rows, and your provider’s rows. Admins see every row, so a member’s counts can legitimately be lower than an admin’s. Views without a scope column are unfiltered at row level.
  • Registry fixed filters: a view may carry admin-defined fixed filters (e.g. a “strategy knowledge” view that only shows one category). These are enforced on every read and cannot be bypassed.
  • Soft archive: views whose source has an archived_at column hide archived rows by default; pass include_archived:true to see them.
  • Per-agent ceilings: when an agent (rather than a user key) queries a view, its admin-set view preferences act as a ceiling — pinned columns are the only requestable columns, default filters are always ANDed in, and a row cap limits every call. These preferences are configured via agent_create.data_sources / agent_update.view_prefs (see Agents).
Column catalog: the concrete set of views and their columns is per tenant and lives in the registry, not in code. Discover it at runtime with data_view_list — that response is always the authoritative column table for your tenant. The Appendix: view & column catalog at the end of this page is a snapshot of the global template views (the defaults every tenant inherits); a tenant may add its own views or hide columns on top of these.

Data types

The data_type shown per column is a display type: text | number | currency | datetime | date | boolean | status | link | email | image | json | markdown. Free-text search matches columns of type text, email, link and markdown (identifier-like columns such as id, *_id, *_by are excluded automatically).

data_view_list

List the data tables (views) this user may query — slugs, labels, columns and a queryable flag. Call before data_query. Parameters: none. Returns:
Non-queryable entries carry a reason. Permissions: read tool; per-view department visibility applies (default-closed for members, all views for admins). Example:

data_query

Query one data view by slug: exact-match filters, free-text search, count-only totals, sort, limit and column projection. This is the typed path for every exact/aggregate/numeric question — counts, prices, inventory, filtered records. For conceptual recall use knowledge_search / memory_search instead. Parameters: Returns: {rows, count, truncated}truncated:true means the result hit the limit and more rows may exist. count_only returns {count}. If a requested search could not be applied (no searchable columns), search_applied:false is included. Unknown filter/sort/projection columns return a clear error listing the valid columns. Row visibility: scoped rows are filtered to your identity as described above; your totals can differ from an admin’s. Example:
Permissions: read tool; view must be visible and queryable for this user.

Row writes

Row writes target registered, tenant-scoped catalog tables (entries of view_type:"table" in data_view_list). Each writable table is gated by its own grant — see Row Write Tools for the full list of insert_/update_ tools. Common rules:
  • tenant_id and workspace_id are set automatically from your credential — never pass them.
  • Only the table’s registered creatable columns are accepted; identity/ownership columns (id, tenant_id, workspace_id, …) are stripped or protected.
  • If the table has an owner column (submitted_by_user_id / owner_user_id / user_id), it is stamped with the calling user, so user-scoped rows really belong to you.
  • Each table needs a per-table write grant on the key/agent: insert_<table> or update_<table> (toggled in Settings → MCP Access → Write access per table; granted automatically on OAuth first connect). Without the grant the call is rejected.
  • All three tools support dry_run:true.

data_row_save

Upsert one row keyed on external_id — the write counterpart of data_query. A second save with the same external_id updates the existing row instead of creating a duplicate. Use for ingestion watchers (videos, leads, orders). Returns: the saved row / upsert receipt (dry-run: the would-be upsert). Permissions: write; requires insert_<table> or update_<table> grant.

data_row_create

Insert a new row (no external_id required — the database assigns the row id and any auto-generated columns such as sequence numbers). Returns: the created row (including its new id). Permissions: write; requires insert_<table> grant.

data_row_update

Update one row by id. Filters on both tenant and workspace — a row id from a different workspace returns “not found”. external_id can never be set or changed here (use data_row_save for upserts). Returns: the updated row. Permissions: write; requires update_<table> grant.

View management

data_view_create

Create a new data view in the registry with columns and department visibility. The source table must already exist and be tenant-accessible. Returns: the created view (id + slug). Permissions: write; Company-Admin only.

data_view_update

Update an existing view: rename, replace columns, or set department visibility. Returns: the updated view. Permissions: write; Company-Admin only.

Appendix: view & column catalog

Snapshot of the global template views (cockpit.views where tenant_id IS NULL) and their columns, generated from the live registry on 2026-08-13. These are the defaults every tenant inherits. Your tenant’s live set may differ — data_view_list is always authoritative. Legend: Vis = shown by default · Filt = filterable · Search = full-text searchable · Edit = updatable via data_row_update/data_row_save · Create = settable on data_row_create. A DB-view source (v_*) is read-only regardless of flags.

agents — public.agents

Capabilities: read · Columns: 9

agent_runs — public.agent_runs

Capabilities: read (read-only) · Columns: 17

agent_inbox — public.inbox_agents

Capabilities: read (read-only) · Columns: 9

decision_log — public.decision_log

Capabilities: read (read-only) · Columns: 13

decisions — public.decisions

Capabilities: read + catalog + ingest · Columns: 61

knowledge — cockpit.knowledge_base

Capabilities: read + history · Columns: 21

knowledge_strategy — cockpit.knowledge_base

Capabilities: filtered (category=strategy) + history · Columns: 21 Same column set and flags as knowledge above — the view adds a fixed filter category=strategy that is enforced on every read.

knowledge_sop — cockpit.knowledge_base

Capabilities: filtered (category=sop) + history · Columns: 21 Same column set and flags as knowledge above — the view adds a fixed filter category=sop that is enforced on every read.

memories — cockpit.memories

Capabilities: read + history · Columns: 25

skills — cockpit.skills

Capabilities: read + history · Columns: 19

meeting_notes — public.meeting_notes

Capabilities: read + ingest · Columns: 9

orders — public.orders

Capabilities: read + catalog + history · Columns: 51

order_line_items — public.order_line_items

Capabilities: read + catalog + history · Columns: 21

customers — public.customers

Capabilities: read + catalog + history · Columns: 15

products — public.products

Capabilities: read + catalog + history · Columns: 29

suppliers — public.suppliers

Capabilities: read + catalog + ingest · Columns: 9

purchase_order_lines — public.purchase_order_lines

Capabilities: read + catalog + ingest · Columns: 19

procurement_config — public.procurement_config

Capabilities: read + catalog · Columns: 5

v_product_demand — public.v_product_demand

Capabilities: read + catalog (DB view, read-only) · Columns: 37

v_procurement_agent_queue — public.v_procurement_agent_queue

Capabilities: read + catalog (DB view, read-only) · Columns: 51

v_customer_reorder_due — public.v_customer_reorder_due

Capabilities: read + catalog (DB view, read-only) · Columns: 15

v_family_trend — public.v_family_trend

Capabilities: read + catalog (DB view, read-only) · Columns: 11

v_product_sales_weekly — public.v_product_sales_weekly

Capabilities: read + catalog (DB view, read-only) · Columns: 7

v_seasonality_effective — public.v_seasonality_effective

Capabilities: read + catalog (DB view, read-only) · Columns: 11