Skip to main content
Workspace settings allow you to customize email templates, team contact information, and timezone preferences at the workspace level. These settings apply to all signing requests and templates within the workspace.

Use cases

  • Custom email branding: Personalize email headers and body text for signing request invitations
  • Team contact info: Set a team email for recipient support questions
  • Timezone management: Configure timezone for date/time displays and reminders
  • Multi-tenant applications: Separate settings per workspace for white-label solutions
See the guide on Rate Limits.

Get workspace settings

Retrieve current workspace settings including email templates, team email, and timezone configuration.

Endpoint

Parameters

  • workspace_id (string, required) - UUID of the workspace

Example - cURL

Response (200 OK)

The response includes additional fields beyond email settings - show_qr_code, require_otp_verification, require_terms_acceptance, allow_presigning_download, color settings, signing_button_label_overrides, completion page settings, and more. This guide focuses on the email template and branding subset. See the API reference for the full response schema.

Rate limit headers


Update workspace settings

Update workspace settings. You can update one or more fields - only provided fields will be updated.

Endpoint

Parameters

  • workspace_id (string, required) - UUID of the workspace

Request body

All fields are optional - only include fields you want to update:

Field descriptions

  • signing_request_email_header (string, optional) - Custom header text for signing emails (max 500 characters)
  • signing_request_email_body (string, optional) - Custom body text for signing emails (max 50000 characters)
  • team_email (string, optional) - Valid email address for recipient support
  • timezone (string, optional) - IANA timezone identifier

Example - cURL

Response (200 OK)

Returns the updated workspace settings:

Rate limit headers


Implementation examples

Node.js (Express) - Get settings

Node.js (Express) - Update settings

Python (Flask) - Get settings

Python (Flask) - Update settings

React - Settings management component


Email template customization

Firma supports two layers of email customization that share the same placeholder engine: the signing_request_email_header / signing_request_email_body fields on this settings endpoint (which apply to the signing invitation and next-signer emails, including manual resends of either), and a richer per-type Email Templates editor in the workspace’s Settings page, which lets you customize the subject and body independently for each email type - invitation, next signer, expiration, cancellation, decline, completion, and identity-change notifications.

Template variable reference

Placeholders are case-insensitive and also accept the legacy [bracket] syntax (for example [signer_name]) alongside {{curly}} syntax. A placeholder with no value for a given email simply resolves to nothing - templates never show a raw {{missing_variable}}.

Variable availability by email type

Signer, document, team, and company variables resolve for every email type. Three variables are the exception:
The signing_request_email_header / signing_request_email_body fields on this settings endpoint only affect the invitation and next-signer emails. To customize expiration, cancellation, decline, completion, or identity-change emails, use the per-type Email Templates editor in the workspace’s Settings page.
{{company_logo}} resolves through a fallback chain:
  1. Workspace logo - used if the workspace has its own logo uploaded (rendered with the workspace name as the image alt text).
  2. Company logo - otherwise, falls back to the parent company’s logo.
  3. Hidden - if neither is set, the placeholder resolves to nothing; no broken image is rendered.
The logo image is served through a public logo proxy and constrained to max-width: 200px; max-height: 120px. The height cap prevents unusually tall logos from pushing the rest of the email below the fold.

QR code in emails ({{signing_qr_code}})

Email QR codes render as PNG, not SVG. Gmail strips <img> tags pointing at SVG entirely, and Outlook’s Word-based rendering engine won’t display them either - PNG is the format that renders reliably across email clients.
{{signing_qr_code}} is only populated on signing invitation and next-signer emails. It lets a recipient scan the code to continue signing on another device instead of clicking a link. Whether it’s shown is controlled by a show_qr_code setting that cascades:
  1. Signing request-level setting (if explicitly set)
  2. Workspace-level setting - show_qr_code on this settings endpoint
  3. Company-level default
Set show_qr_code to true or false at the workspace level via PUT /workspace/{workspace_id}/settings, or leave it unset (null) to inherit the company default.

Workspace email ({{team_email}} / {{workspace_email}})

team_email is a workspace-level field, configured on this settings endpoint (or from the workspace’s Settings page, under Team Contact Email). If left unset, it falls back to support@firma.dev.
team_email is a display value only - it’s substituted wherever {{team_email}} or {{workspace_email}} appears in a template. It is not used as the email’s Reply-To address; replies from recipients go to Firma’s sending address, not to team_email.
team_email also has a second, unrelated role: for identity-change notifications, it’s the actual recipient. Firma emails your team at this address when a signer changes their name mid-flow, falling back to the account owner’s email if team_email isn’t set.

Best practices

Email header (max 500 characters):
  • Keep it concise and action-oriented
  • Clearly state the purpose (“Sign your agreement”, “Review document”)
  • Avoid generic text like “You have a notification”
Email body (max 50000 characters):
  • Explain what the recipient needs to do
  • Include support contact information
  • Set expectations (urgency, deadline if applicable)
  • Keep tone professional but friendly

Example templates

Professional services:
Real estate:
HR onboarding:
Generic/flexible:

Supported timezones

Workspace settings support all IANA timezone identifiers. Common timezones:

United States

  • America/New_York - Eastern Time
  • America/Chicago - Central Time
  • America/Denver - Mountain Time
  • America/Los_Angeles - Pacific Time
  • America/Anchorage - Alaska Time
  • Pacific/Honolulu - Hawaii Time

Europe

  • Europe/London - GMT/BST
  • Europe/Paris - Central European Time
  • Europe/Berlin - Central European Time
  • Europe/Madrid - Central European Time
  • Europe/Rome - Central European Time

Asia Pacific

  • Asia/Tokyo - Japan Standard Time
  • Asia/Shanghai - China Standard Time
  • Asia/Singapore - Singapore Time
  • Asia/Dubai - Gulf Standard Time
  • Australia/Sydney - Australian Eastern Time

Americas

  • America/Toronto - Eastern Time (Canada)
  • America/Vancouver - Pacific Time (Canada)
  • America/Mexico_City - Central Time (Mexico)
  • America/Sao_Paulo - Brasilia Time
Full list of IANA timezones

Rate limiting

Get workspace settings

  • Limit: 200 requests per minute
  • Use case: Frequent reads for dashboard displays
  • Recommendation: Cache settings client-side for 5-10 minutes

Update workspace settings

  • Limit: 120 requests per minute
  • Use case: Admin configuration changes
  • Recommendation: Debounce updates in UI (wait 1-2 seconds after user stops typing)

Rate limit headers

Every response includes:

Handling rate limits

If you exceed the limit:
Best practices:
  • Implement client-side caching
  • Debounce frequent updates
  • Check X-RateLimit-Remaining before making requests
  • Implement exponential backoff for retries

Error responses

400 Bad Request - Validation error

Invalid input data (e.g., malformed email, invalid timezone):

401 Unauthorized

Invalid or missing API key:

403 Forbidden

You don’t have access to this workspace (cross-company or insufficient permissions):

404 Not Found

Workspace doesn’t exist or has been deleted:

429 Too Many Requests

Rate limit exceeded:
Check the X-RateLimit-Reset header (ISO 8601 timestamp) for when you can retry.

Multi-tenant best practices

For multi-tenant applications (multiple workspaces):

1. Cache settings per workspace

2. Validate workspace access

Always verify the authenticated user has access to the workspace:

3. Audit logging

Log all settings changes for compliance:

4. Default settings on workspace creation

Set sensible defaults when creating new workspaces:

Troubleshooting

Settings not applying to emails

Symptom: Updated settings don’t appear in signing emails Possible causes:
  • Email template cache not cleared
  • Wrong workspace ID used
  • Updates didn’t save (check API response)
Solution:
  • Verify update was successful (check 200 response)
  • Test with a new signing request (not existing draft)
  • Check workspace ID matches signing request

Invalid timezone error

Symptom: 400 error when setting timezone Solution: Use IANA timezone identifiers (e.g., America/New_York). The API validates format only (letters, underscores, slashes) - abbreviations like EST pass validation but may not behave correctly for daylight saving transitions. Always use the full IANA zone name.

Team email validation failure

Symptom: 400 error on team email update Solution: Ensure valid email format (contains @ and domain)

Rate limit exceeded

Symptom: 429 errors when updating settings Solution:
  • Implement debouncing on form inputs
  • Cache settings client-side
  • Wait for X-RateLimit-Reset before retrying
See the guide on Rate Limits.

API reference

For complete details on workspace operations, see:

Workspace Management

Workspace Settings


Next steps