Overview
White labeling in Firma involves several components:- Custom branding - Upload logos, set color themes, and hide Firma branding entirely
- Custom signer terms - Require signers to accept your own terms of service
- Signing button labels - Customize the text on signing buttons per language
- Custom email domains - Send signing request emails from your own domain
- Custom email sender address - Control the “from” address on all outgoing emails
- Custom email templates - Personalize the content and branding of signing notification emails
- Disable Firma emails - Turn off automatic emails per signing request and send your own
- Embedded experiences - Embed signing and template editors directly in your app
All API examples use your API key directly in the
Authorization header. Do not use the Bearer prefix.Custom branding
Customize logos, colors, and branding visibility at both the company and workspace level. Workspace settings override company settings, letting you create distinct branded experiences for each of your customers.Company logo
Upload a logo for your entire Firma account. This logo appears in signing emails and the signing experience.- Format: PNG or JPEG only
- Max size: 2 MB
Workspace logo
Override the company logo for a specific workspace:Color theming
Customize the color palette of the signing experience using hex color values. Colors can be set at both the company and workspace level.
Set company-level colors:
#0066cc). Set a color to null to clear it and fall back to the next level in the hierarchy.
Hide Firma branding
Remove all Firma branding from the signing experience by enablingshow_custom_branding_only at the company level:
Additional display settings
Fine-tune the signing experience with these settings, available at both company and workspace level:
At the workspace level, set these to
null to inherit the company-level setting.
Settings hierarchy
Branding settings follow a cascading hierarchy:- Workspace setting (highest priority)
- Company setting
- Firma default (lowest priority)
null means “inherit from company.”
See the Workspace Settings API Reference for the full list of configurable settings.
Custom signer terms
Require signers to accept your own terms of service or legal agreement before signing. Terms are configured per language and follow the same company/workspace cascade as other settings.How it works
Whenrequire_terms_acceptance is enabled (the default), signers see a terms acceptance checkbox before they can sign. You can customize the statement text and optionally link to a full terms document.
Terms are stored per language so signers see terms in their workspace’s language, falling back through the cascade:
- Workspace terms for the signer’s language (highest priority)
- Company terms for the signer’s language
- Firma default terms (lowest priority)
Set company-level terms
Set workspace-level terms
statement_text(required): HTML text shown next to the acceptance checkbox. Basic HTML tags are allowed (<a>,<b>,<i>,<br>).terms_url(optional): URL to the full terms document.
List terms
Retrieve all configured terms for a company or workspace:Delete terms
Remove custom terms for a specific language to fall back to the next level in the cascade:Disable terms acceptance
To disable the terms acceptance requirement entirely:en, es, it, pt, fr, de, el, ru, pl.
See the Signer Terms API Reference for complete endpoint documentation.
Custom signing button labels
Customize the text on signing buttons per workspace and per language. This lets you match the button labels to your product’s terminology or localization.Set button label overrides
Button labels are set as a JSONB object on workspace settings, keyed by language and then by button key:Clear button label overrides
Set tonull to revert to Firma’s default button labels:
- Each label must be a string, max 500 characters
- Language keys must be valid language codes (max 10 characters)
- HTML tags and control characters are stripped automatically
Button label overrides are a workspace-level setting only. There is no company-level override.
Custom email domains
By default, signing request emails are sent from Firma’s domain. With custom email domains, emails appear to come directly from your company or your customers’ companies.Account-level (company) email domains
Set up a custom email domain for your entire Firma account. All workspaces will use this domain by default unless overridden.Step 1: Add your domain
Use the API to add a custom email domain:Step 2: Add TXT verification record
Add the verification TXT record to your DNS:DNS propagation typically takes a few minutes but can take up to 48 hours.
Step 3: Verify domain ownership
Once the TXT record is added, verify ownership:Step 4: Finalize domain setup
After ownership is verified, finalize the domain to receive email-sending DNS records:Step 5: Add DNS records
Add all three DNS records to your domain:Step 6: Verify DNS records
Once DNS records are added, verify them:Step 7: Set as primary domain (optional)
If you have multiple domains, set one as the default:Workspace-level email domains
For multi-tenant SaaS applications, you can configure different email domains per workspace. Workspace domains override the company-level domain. The workflow is identical to company domains, but uses workspace-scoped endpoints:
Example: Add workspace domain
Custom email sender address
Control the “from” address on all outgoing emails by combining a custom domain with a custom local part.How email addresses are resolved
When Firma sends an email, the sender address is built from three components:- Workspace verified domain (primary preferred)
- Company verified domain
updates.firma.dev(default)
- Workspace
email_local_partsetting - Company
email_local_partsetting support(default)
email_local_part to noreply and your verified domain is sign.acmecorp.com, emails will be sent from:
Setting the email local part
Company level (default for all workspaces):- 1-64 characters, lowercase letters, numbers, dots, underscores, and hyphens
- Must start and end with a letter or number
- No consecutive dots
- Reserved values (
postmaster,abuse,mailer-daemon) are not allowed
null at the workspace level to inherit from the company setting.
Custom email templates
Customize the notification emails Firma sends on your behalf so they match your brand voice and style. You can set templates at both the company and workspace level, with workspace templates overriding company defaults.Customizable email types
Available placeholders
Templates support HTML bodies with dynamic placeholders using{{placeholder}} syntax.
Signer placeholders:
Document placeholders:
Team placeholders:
You can also retrieve this list programmatically:
View default templates
Retrieve Firma’s built-in default templates for any supported language to use as a starting point:en, es, it, pt, fr, de, el, ru, pl.
Set a workspace email template
subject: required, max 500 charactersbody: required, max 50,000 characters
Set a company email template
Delete a custom template
Remove a custom template to revert to the next level in the hierarchy:Template hierarchy
Email templates follow a cascading hierarchy:- Workspace template (highest priority)
- Company template
- Built-in default for the workspace’s language (lowest priority)
Disabling Firma emails
For complete control over customer communications, you can disable Firma’s automatic emails per signing request. This allows you to:- Send signing request links through your own email system
- Integrate with your existing notification workflows
- Customize email timing and follow-up sequences
- Use your own email delivery infrastructure
Email settings on signing requests
Each signing request has settings that control which emails are sent:Create signing request with emails disabled
Get signing URLs for manual distribution
When emails are disabled, retrieve the signing URLs from the API and send them through your own channels:Embedded experiences
The most powerful white-labeling feature is embedding Firma’s interfaces directly in your application. This removes all Firma branding and creates a seamless experience within your product.Embeddable signing
Embed the signing flow so recipients sign documents without leaving your app:Embeddable template editor
Let users create and edit templates within your app using JWT authentication:Embeddable signing request editor
Provide a UI for configuring signing request recipients and options:Complete white-label setup
Here’s a complete example of setting up a fully white-labeled workspace for a customer:1. Create the workspace
2. Upload a logo
3. Configure branding
4. Hide Firma branding (company-level)
5. Set up custom email domain (optional)
6. Customize email templates (optional)
7. Embed the experiences
Best practices
Branding
- Use a consistent color palette across logos, email templates, and embedded experiences
- Upload logos in PNG format with a transparent background for best results
- Enable
show_custom_branding_onlyto fully remove Firma’s branding - Set company-level branding as a baseline, then override per workspace where needed
- Test the full signing flow from your customers’ perspective
Email domain configuration
- Use a subdomain (e.g.,
sign.yourcompany.com) rather than your main domain - Set up all DNS records (SPF, DKIM, DMARC) for optimal deliverability
- Monitor email bounce rates and adjust as needed
- Test email delivery before going live with customers
Email templates
- Use the defaults endpoint to see Firma’s built-in templates as a starting point
- Always include
{{signing_link}}in invite and reminder templates - Set a company-level template as a branded baseline, then override per workspace when needed
- Use
{{company_logo}}in templates to include the workspace or company logo
Security
- Always generate JWT tokens on your backend
- Never expose API keys in client-side code
- Use short token expiration times (recommended: 1-4 hours)
- Validate postMessage origins when handling iframe events
Troubleshooting
Domain ownership verification failed
Possible causes:- DNS records not propagated (wait up to 48 hours)
- Incorrect TXT record name or value
- TXT record added to wrong zone
verification_instructions returned when adding the domain
DNS records not verifying
Possible causes:- Records not propagated yet
- Incorrect record values
- Missing records
GET /company/domains/{id} or verify-dns to see which specific records are pending
Signing iframe not loading
Possible causes:- Invalid signing request user ID
- Expired or cancelled signing request
- Content Security Policy blocking iframe
JWT token expired
Possible causes:- Token TTL too short for use case
- Clock skew between servers
Colors not applying
Possible causes:- Invalid hex format (must be 6-digit, e.g.,
#0066cc, not 3-digit#06c) - Setting applied at company level but workspace has its own override
null at the workspace level to clear an override.
Related guides
- Embeddable Signing - Embed the signing experience in your app
- Embeddable Template Editor - Let users edit templates with JWT auth
- Embeddable Signing Request Editor - Configure signing requests in your UI
- Creating Workspaces - Set up isolated environments for customers
- Webhooks - Track signing events in real-time