Data access
Control which records a key can see — and how visible the data it writes will be.
Permissions decide what a key may call. Data access decides which records it sees once it does. The two are independent: a key with tickets:read and workspace-wide access sees every workspace-visible ticket and nothing scoped to a group.
Visibility
Synqed already scopes ingested data: an admin can restrict a GitHub repo, a Jira project or a Slack channel to one or more visibility groups (Settings → Sources). Each key picks one of:
| Visibility | Sees | Who can grant |
|---|---|---|
| Workspace-wide | Records every member can see. | Admins, members |
| Selected groups | Workspace-wide records plus records scoped to the chosen groups. | Admins (any group), members (their own groups) |
| All workspace data | Everything except personal, private memories. | Admins |
Records outside a key's visibility behave as if they don't exist: list endpoints skip them, GET /v1/{resource}/{id} returns 404, and search never returns them.
Private memories stay private
Memories that an agent captured for one person (unpublished or private) are never visible to API keys, whatever their visibility.
Sources
Optionally restrict a key to some sources. Records are grouped by where they came from:
| Source | Records |
|---|---|
github, jira, linear, slack, granola | Data ingested from that connector |
api | Documents, memories and context pushed through this API |
agent | Everything agents and people wrote in Synqed itself |
A support-bot key could be limited to api and slack, for example, so it never reads code review history. Everything written through the API is classified api, so a key with documents:write, memories:write or context:write must include the api source.
What your writes look like to others
Data a key writes inherits the key's own visibility:
- a workspace-wide key writes workspace-visible records;
- a group key writes records visible to those groups (and admins);
- an all-data key writes workspace-visible records.
Writes accept an optional visibility field. What a key may ask for depends on its own access:
| Key's data access | Allowed visibility on writes |
|---|---|
| Workspace-wide | "workspace" only |
| Selected groups | { "groups": [...] } with a subset of the key's groups |
| All workspace data | "workspace" or any { "groups": [...] } |
A workspace-wide key can't target groups — it couldn't read the record back. The example below needs a key with the Finance group (or all-data access):
{
"source": "finance-sheets",
"external_id": "q3-forecast",
"title": "Q3 forecast",
"body": "…",
"visibility": { "groups": ["finance"] }
}Anything else fails with 403 visibility_not_allowed. The same applies to changing an existing record: a Selected-groups key can't edit a document that is visible more widely than the key could write — unless the write passes visibility, which narrows the document to the key's groups.
Keys never outgrow their creator
A key created by a member is capped, on every request, at what that member can see today. If they leave one of the key's groups, the key loses that group; if they leave all of them, are demoted to viewer, or leave the workspace, the key stops working. Keys created by admins aren't capped while their creator remains an admin; if that admin is demoted, their keys are capped the same way.