---
title: "Permission-aware data access"
section: "Developer Platform"
canonical_url: "https://support.buildwithhq.com/api/data-access.html"
reviewed_at: "2026-09-14"
authority: Official
---

# Permission-aware data access

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

## In brief

- **Isolation:** Application-scoped
- **Filtering:** Server-side
- **Query exposure:** No SQL or procedure names

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.

Tip

Design one authorization kernel and reuse it everywhere. REST, workflows, MCP, and container calls should differ in transport — not in what they are allowed to see.

---

Capability review: 2026-09-14. [View the canonical guide](https://support.buildwithhq.com/api/data-access.html).