Authentication

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

const res = await fetch("https://my.flowsign.app/api/v1/workspaces", {
  headers: { Authorization: `Bearer ${process.env.FLOWSIGN_API_KEY}` },
});

const { data } = await res.json();
console.log(data.active, data.workspaces);

import os

import requests

res = requests.get(
    "https://my.flowsign.app/api/v1/workspaces",
    headers={"Authorization": f"Bearer {os.environ['FLOWSIGN_API_KEY']}"},
    timeout=30,
)
res.raise_for_status()

data = res.json()["data"]
print(data["active"], data["workspaces"])

using System.Net.Http.Headers;
using System.Net.Http.Json;
using System.Text.Json;

using var http = new HttpClient { BaseAddress = new Uri("https://my.flowsign.app") };
http.DefaultRequestHeaders.Authorization = new AuthenticationHeaderValue(
    "Bearer",
    Environment.GetEnvironmentVariable("FLOWSIGN_API_KEY"));

var body = await http.GetFromJsonAsync<JsonElement>("/api/v1/workspaces");
var data = body.GetProperty("data");

Console.WriteLine(data.GetProperty("active").GetString());

​

Creating and managing keys

• Name the key after where it will live (for example “Production server”).
• Role is what the key can do. The key acts with that role’s permissions, not the issuer’s, and only roles with the API access permission are offered.
• Workspace is where the key acts. A key is bound to one workspace for its whole life.
• Expiry is optional. A key with no expiry works until you revoke it; a key with an expiry stops working at the end of that day, in the local time of whoever created it.
• The key value is displayed once in a reveal dialog and cannot be read again. If you lose it, create a new key.
• Revoke a key from the same page. Revocation is immediate and permanent.
• There is no rotate operation. To rotate, create a new key, move your integration to it, then revoke the old one.
• An organisation can hold at most 50 unrevoked keys, and expired keys count until they are revoked. Creating one beyond that returns 409; revoke a key to make room.

​

Who can use the API

• Creating keys requires an owner.
• Permission. The role a key is given must have the API access permission. The built-in Admin profile has it; Sender and Viewer do not. An administrator can grant it from Roles & Permissions.
• Acting as a role. A key acts with the permissions of the role chosen at creation, not the issuer’s, and it is never an owner. Package visibility is the exception: without the view all packages permission (canViewAllPackages), a key sees only the packages its issuer owns or has been shared, including the ones the key created. Endpoints that change data check that role’s permissions, so a key on a role without the send permission cannot send packages (403 Missing permission: canSendPackages). Audit events record the issuing user alongside the key. A key sees every template in its workspace, not only the ones its issuer created; the role’s template access decides whether it can use them (USE) or also create and edit them (CREATE).
• Webhook endpoints (/api/v1/webhooks) need the manage webhooks permission on the key’s role.
• Plan. The public API is included in the Enterprise plan. Webhooks are a separate feature on the same plan. Calls from organisations without the feature return 402.
• IP allowlist. If your organisation has an IP allowlist (Settings > Security), API calls from other addresses are refused with 403 IP address not allowed. A request whose client address cannot be determined is refused the same way.

​

Workspaces

​

Why a request is refused