SnozeDevelopers
API referenceConnected Accounts

Read this workspace's connection policy

Returns whether personal accounts are blocked in this workspace and whether unattended automations must run on a workspace connection. Both default to off, so a workspace that has never opened the setting reports a permissive policy. Requires `integrations:read`.

GET
/v1/workspaces/{workspaceId}/connection-policy

Authorization

apiKey
headerAuthorizationBearer <snoze_sk_…>

Workspace API key created in Workspace settings → API keys. Scopes on the key bound what it can read and write.

Path Parameters

workspaceId*string

Response Body

Success

application/json
  1. response
data*
Example Request
curl -X GET 'https://api.snoze.dev/v1/workspaces/string/connection-policy'
Example Response
{  "data": {    "blockPersonalAccounts": true,    "requireWorkspaceRunAs": true  }}

Rebind an automation's credential

Changes which credential an automation runs on, or clears the pin so its nodes fall back to their workspace connection. Deliberately separate from saving the graph: editing conditions or mappings must never silently remove the only credential that works. The current run-as owner may swap the pin for another of their own accounts without further permission; clearing it, moving it onto a workspace connection, or any change by someone else needs `automations:write`. A personal credential can only ever be bound by the person who owns it, and is rejected outright when the workspace requires workspace connections. A workspace target may be a connection created through the connections API or an enabled provider install.

Set this workspace's connection policy

Requires `integrations:write`. Turning on `blockPersonalAccounts` immediately drops every cached reachability answer for this workspace, so shared surfaces stop resolving through personal credentials on the next read rather than when their cache expires.