Developer Platform

Permission-aware data access

Every data surface resolves through the same record, role, location, and capability envelope.

BuildWithHQ's data model is designed around a simple promise: an integration should never see more data merely because it used an API instead of the application UI.

The permission envelope

Before data is returned or an action is executed, the runtime can combine several dimensions of context:

• the authenticated application/account;
• the user or API-client identity;
• DataRole membership and capability permissions;
• record-to-role sharing;
• location scope;
• the object/module and requested action; and
• additional policy attached to the specific field, workflow, or extension endpoint.

This evaluation happens on the server. A caller cannot broaden access by modifying a hidden field, adding another record ID, or requesting a different transport.

Data keys

For dashboards, composed pages, AI context, and other curated reads, BuildWithHQ can expose named data keys: registered operations with known parameters and known result shapes. A caller asks for the key, not a query string or procedure name.

{
  "dataKey": "inbox.kpis",
  "parameters": {}
}

Data keys are useful when a page needs a secure, purpose-built JSON shape rather than generic record CRUD. REST resources and data keys complement each other: resource APIs cover general integration needs; data keys cover reviewed, high-level projections.

AI and MCP follow the same envelope

AI features do not receive a privileged copy of the database. MCP tools and AI context retrieval should resolve through the same secured record set, with AI-specific permissions applied where configured.

Capability review: 2026-09-14. For exact current technical availability, use the generated API Map and first-class module inventory.