Workspaces - Flowsign

An organisation is divided into workspaces: offices, regions or teams, each with its own packages, templates, contacts and members. Every organisation has a default workspace. An API key is issued for one workspace and acts there on every request. To act in another workspace, issue another key from Settings > API keys.

Listing workspaces

GET /api/v1/workspaces returns the key’s workspace, and confirms in active which workspace the call acted in.

curl https://my.flowsign.app/api/v1/workspaces \
  -H "Authorization: Bearer fsk_your_key_here"

{
  "data": {
    "active": "ws_akl",
    "workspaces": [
      { "id": "ws_akl", "name": "Auckland", "slug": "auckland", "isDefault": false }
    ]
  }
}

The `X-Workspace-Id` header

The header is optional and cannot switch workspace. Send it with the key’s own workspace id to be explicit about where a call lands. Packages and templates you list, create or act on are scoped to that workspace.

curl "https://my.flowsign.app/api/v1/packages?status=IN_PROGRESS" \
  -H "Authorization: Bearer fsk_your_key_here" \
  -H "X-Workspace-Id: ws_akl"

Rules:

Omit the header to act in the key’s workspace.
Any other id (unknown, or another workspace in the organisation) returns 401. The call never lands in a different workspace and is never widened to the whole organisation.
GET /api/v1/workspaces reports the workspace actually used in active, so you can confirm a header was honoured.

Webhook endpoints are workspace-scoped too. An endpoint registered with a key belongs to the key’s workspace and receives events only for that workspace’s packages, and GET /api/v1/webhooks lists that workspace’s endpoints. To receive events from another workspace, register an endpoint with a key for it. See Webhooks.