SnozeDevelopers
API referenceConnected Accounts

List my connected accounts

Returns every external account the signed-in user has connected, across all of their workspaces, with the workspaces each one is currently active in. Account-scoped rather than workspace-scoped: these credentials carry with the person, not the workspace. Encrypted secret material is never returned, only whether a secret is present and the account's health.

GET
/v1/me/connected-accounts

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.

Response Body

Success

application/json
  1. response
data*array<>
Example Request
curl -X GET 'https://api.snoze.dev/v1/me/connected-accounts'
Example Response
{  "data": [    {      "id": "string",      "provider": "string",      "label": "string",      "authKind": "oauth",      "shareable": true,      "hasSecret": true,      "health": "unknown",      "failureReason": "revoked",      "scopes": [        "string"      ],      "activeWorkspaceIds": [        "string"      ],      "sharedWorkspaceIds": [        "string"      ],      "createdAt": "string",      "updatedAt": "string"    }  ]}

Connect one of your own accounts

Starts the provider's sign-in for an account that belongs to the caller alone: the result is a personal connected account, with no workspace install, no grant and nothing shared with anyone. Any workspace member may do this (a personal account needs no admin). Returns the sign-in URL to open; the callback sends the browser back to `redirectTo` inside the given workspace. Only Google Workspace is supported.

Connect an external account

Stores a manual API key for the signed-in user and activates it in the workspace the connect flow started in. The caller must be a member of that workspace. Providers Snoze installs through OAuth or an app installation (GitHub, Slack, Google, Discord, ...) are refused here: their accounts are provisioned by the install callback from provider-verified material. A manual key is always a personal `api_key` credential: it cannot be shared with the workspace (`shareWithWorkspace: true` is a validation error) and an automation pinned to it only sends it to the hosts listed in `allowedHosts`. Reconnecting the same provider account replaces the stored secret, bumps its secret version and clears its failure state rather than creating a duplicate.