Authenticating
Send your API key as a Bearer token in theAuthorization header. Keys start with fsk_, are created at Settings > API keys and are shown once, so if you no longer have the value, create a new one. Consider issuing a key with an expiry date just for exploring and revoking it when you are done. See Authentication.
X-Workspace-Id is optional. A key is bound to one workspace and every request already acts there, so send the header only to be explicit, and give it the key’s own workspace id. Any other value returns 401. See Workspaces.
Editing the request
The samples use example ids that do not exist in your workspace, so a request run unchanged returns404. Swap them for ids from your own responses. Required fields are marked on the page; leave an optional field out rather than sending it empty. See Endpoint pages for a tour of the whole page.
A safe first sequence
These three reads change nothing in your workspace.1
GET /api/v1/account
Confirms the key is accepted and returns the organisation and workspace it acts in, the role it acts as, and the user work is attributed to (the key’s issuer).
2
GET /api/v1/workspaces
Lists the key’s workspace and names it in
active. Copy that id if you plan to send X-Workspace-Id.3
GET /api/v1/packages
Pages through the packages the key can see. Filter with
status or search. See Pagination.POST /api/v1/packages/from-template without "status": "sent" creates a DRAFT, which sends nothing until you act on it.
If you get a 402
A402 means the organisation’s plan does not include the public API, which is part of the Enterprise plan. The message names the missing feature. The same status comes back from a send when the organisation has no credit left. See Errors and rate limits.
