Skip to main content
  • Partitioned access: Users, templates, and activity are scoped to a single workspace.
  • Usage tracking: See envelopes sent per workspace for clean reporting.
  • Security by design: No cross-workspace exposure of documents or data.
This makes it simple to give every customer or team their own private signing environment while you manage everything through the same API.

Core Endpoints

Core endpoints (see the API reference for full details):
  • POST /workspaces — create a workspace
  • GET /workspaces/{workspace_id} — retrieve workspace details
  • PUT /workspaces/{workspace_id} — update workspace
  • GET /workspaces — list workspaces (pagination)
  • GET /workspace/{workspace_id}/settings — get workspace settings
  • PUT /workspace/{workspace_id}/settings — update workspace settings
See the guide on Rate Limits.
You can also find dedicated reference pages under api-reference/v01.15.00/workspaces:
  • api-reference/v01.15.00/workspaces/create-a-new-workspace
  • api-reference/v01.15.00/workspaces/list-workspaces
  • api-reference/v01.15.00/workspaces/update-a-workspace
Authentication All requests must include an Authorization header using your API key:
Note: never expose your primary API key to end-user browsers. For per-workspace operations that need to be initiated from the frontend, call your backend which holds the key.

Create a workspace

Endpoint: POST /workspaces Required body: { "name": "string" } Example (curl):
Successful response (201) returns the Workspace resource, including the workspace’s api_key (live) and test_api_key. Example shape:
The api_key is the workspace’s live key and test_api_key is its test key. See Authentication for how test mode works. Server example — Node (fetch):
Server example — Python (requests):

Retrieve a workspace

Endpoint: GET /workspaces/{workspace_id} Example (curl):
Response: the Workspace resource (see example above).

Update a workspace

Endpoint: PUT /workspaces/{workspace_id} — full resource replacement. Required body same as CreateWorkspace (e.g., { "name": "New name" }). Example (curl):
Server example — Node (fetch):

List workspaces

Endpoint: GET /workspaces Supports page and page_size query parameters. Example:
Response shape contains results (array of Workspace) and pagination metadata.

RBAC and API key best practices

  • Use scoped API keys where possible: keep a server-only master API key and create per-workspace API keys for integration partners if your platform supports it.
  • Never return API keys to the browser. For operations initiated by end users, call your backend which performs the API call to Firma.
  • The Firma API does not support an Idempotency-Key header. Store the id returned by the first call and check for it before retrying.

Edge cases & troubleshooting

  • Duplicate names: workspace names are display-friendly and may not be unique; use the id for programmatic references.
  • Protected workspaces: the protected flag marks your company’s default workspace. It cannot be deleted, and a regular API key cannot manage it through the API (403 PROTECTED_WORKSPACE); manage it from the dashboard.
  • Owner-only workspace settings: workspace settings stored on the workspace, such as OTP verification, terms acceptance, and the signature frame, can be changed only by an Owner. Owners and Admins can manage webhooks, company settings, users, and signing requests.
  • Rate limits & errors: inspect non-2xx responses for { error, code } and surface meaningful messages to operators.
  • Rate limit exceeded (429): Monitor X-RateLimit-Remaining header and implement exponential backoff for retries.

Next steps