The Complete Guide to White-Label E-Signatures for SaaS

If you're building a SaaS product with e-signatures, you have two choices. You can bolt on a signing tool that reminds your users they're using someone else's software. Or you can white-label the entire experience so it feels native to your product.

Most developers think white-labeling means swapping a logo. In practice, it's deeper than that. A fully white-labeled e-signature flow involves custom logos, color themes, email domains, custom email templates, notification control, and embedded interfaces. And for multi-tenant SaaS products, you need the ability to white-label not just for your brand, but for each of your customers' brands too.

This guide covers everything you need to build a fully branded signing experience with Firma.dev.

Two Levels of White-Labeling

Here's what most e-signature APIs miss: SaaS companies often need white-labeling at two levels.

Level 1: Your brand. Signing emails come from your domain. The signing interface shows your logo and colors. The whole thing is embedded in your app. Your customers never see the underlying API provider.

Level 2: Your customers' brands. Each of your customers gets their own branded experience. Their users see emails from their domain, not yours. The signing UI shows their logo and color palette. Documents and templates are isolated. Usage is tracked separately.

A property management platform, for example, might want Level 2. Each property management company on the platform sends lease agreements from their own domain (leases@acmeproperties.com), and their tenants see that company's logo and branding throughout the signing flow.

An HR SaaS might only need Level 1. The signing experience is branded to the HR platform, and all their customers' employees interact with that single brand.

Firma.dev supports both. The key is Customer Workspaces.

Customer Workspaces: Secure Separation by Design

Customer Workspaces let you create isolated environments for each of your customers. Every workspace has its own:

• Templates

• Signing requests and documents

• Envelope usage tracking

• Logo and color theme

• Email domain configuration

• Email templates

• API key (optional, for workspace-scoped access)

There's no cross-workspace exposure. Customer A can't see Customer B's documents. Templates created in one workspace don't appear in another. Usage reports are scoped per workspace.

This isn't just about organization. It's about security and compliance. If you're serving enterprise customers or operating in regulated industries (healthcare, finance, legal), data isolation isn't optional. Workspaces give you that separation without building tenant isolation yourself.

For SaaS platforms that manage customer-specific documents and workflows, workspaces are the foundation. You create a workspace for each customer account, and everything flows from there.

The Six Pillars of White-Labeling

1. Visual Branding

The most visible layer of white-labeling. Firma.dev lets you control the look and feel of the signing experience at both the company and workspace level.

Custom logos. Upload your company logo (PNG or JPEG, up to 2 MB) to appear in signing emails and the signing interface. For multi-tenant products, each workspace can have its own logo that overrides the company default. When a workspace logo is removed, it falls back to the company logo automatically.

Color theming. Customize the full color palette of the signing experience using hex values. You control six settings: primary accent color, primary foreground (text on buttons), page background, text color, card/panel background, and border color. Like logos, colors can be set at the company level and overridden per workspace.

Hide Firma.dev branding. Enable show_custom_branding_only at the company level to remove all Firma.dev branding from the signing experience entirely. Combined with a custom logo and color theme, your users will never see any indication that a third-party API is involved.

Display settings. Fine-tune additional details like whether to show signature drawing frames and partial-document watermarks. These settings are available at both levels, and workspace settings inherit from company settings when set to null.

All of these follow a cascading hierarchy: workspace setting takes priority, then company setting, then Firma.dev's defaults. This means you can set company-wide branding and override it selectively for specific workspaces. See the White Labeling Guide for the full API reference.

2. Custom Email Domains

By default, signing request emails are sent from Firma.dev's domain. With custom email domains, they come from yours.

You can configure this at two levels:

Company-level: All workspaces inherit your domain. Emails go out as documents@yourcompany.com.

Workspace-level: Each workspace can have its own domain. Customer A's emails come from sign@customera.com. Customer B's come from contracts@customerb.com.

Setup involves adding DNS records (SPF, DKIM, DMARC) to verify ownership and ensure deliverability. The process is API-driven: add the domain, verify ownership with a TXT record, finalize to recieve your sending DNS records, then verify those. Once verified, the domain is active immediately.

For a step-by-step walkthrough, see How to White-Label Your E-Signature Emails and Signing Links.

3. Custom Email Sender Address

Beyond the domain, you can control the local part of the sender address too. By default, emails from a custom domain use support@yourdomain.com. Set the email_local_part to change this to something like noreply, signing, or documents.

The full sender address is built from three components: the sender name (the person who initiated the signing request), the local part, and the domain. Each component resolves through a fallback chain, with workspace settings taking priority over company settings, which take priority over Firma.dev's defaults.

For example, if you set email_local_part to noreply and your verified domain is sign.acmecorp.com, emails will be sent as Jane Smith <noreply@sign.acmecorp.com>.

4. Custom Email Templates

Firma.dev sends 11 types of automated emails throughout the signing lifecycle: signing invitations, next-signer notifications, resend notifications, reminders, expiration notices, cancellation notices, decline notices (to both signers and admins), completion confirmations, and signer identity change alerts.

You can customize the subject line and HTML body of each email type, with dynamic placeholders for signer details, document information, and team branding. Placeholders like {{signer_name}}, {{signing_link}}, {{company_logo}}, and {{team_name}} let you build templates that feel completely native to your product.

Templates follow the same cascading hierarchy as everything else. Set company-wide templates for consistency, then override specific ones per workspace when needed. You can also retrieve Firma.dev's built-in default templates as a starting point, available in 9 languages including English, Spanish, French, German, and Portuguese.

For more details, see Custom Email Templates for Your E-Signature API.

5. Notification Control

Custom domains and templates change the branding of emails. Full notification control lets you replace them entirely.

Firma.dev's automated emails can be disabled per signing request with four boolean settings: send_signing_email, send_finish_email, send_expiration_email, and send_cancellation_email. Turn off any or all of them.

When emails are disabled, you retrieve the signing URLs from the API and send notifications through your own system. This lets you:

• Match your existing email infrastructure (SendGrid, Postmark, Customer.io)

• Control timing for reminders and follow-ups

• Trigger notifications based on your own business logic

• Integrate signing notifications into existing customer communication flows

Some teams use custom domains and templates with Firma.dev handling delivery. Others turn off everything and own the entire communication layer. Both work.

6. Embedded Experiences

The signing experience shouldn't feel like a redirect to another product. Embedded interfaces let you build the entire workflow into your application.

Firma.dev offers three embeddable components:

Signing interface. Embed the signing flow so recipients sign documents without leaving your app. Combined with custom branding and show_custom_branding_only, users see your logo, your colors, and your navigation throughout the process.

Template editor. Let your users (or your customers' users) create and edit templates directly in your app. Upload documents, place signature fields, define signer roles, all within your UI.

Signing request editor. Configure signing requests, add recipients, set signing order, and preview documents without leaving your product.

All three use JWT authentication. Your backend generates a short-lived token, and the frontend loads the component in an iframe with that token. No API keys are exposed to the client.

For products where document preparation is a core workflow, embedded editors are worth the implementation effort. Your app feels cohesive, and users never context-switch to a third-party interface. See the Embeddable Signing Guide for full implementation details.

The Settings Hierarchy

All branding and configuration settings in Firma.dev follow a cascading hierarchy:

1. Workspace setting (highest priority)

2. Company setting

3. Firma.dev default (lowest priority)

This lets you set company-wide defaults and override them per workspace. At the workspace level, setting any value to null means "inherit from company." This applies to logos, colors, email domains, email templates, sender addresses, and display settings.

For multi-tenant products, this hierarchy is powerful. Set your platform's branding at the company level, then let each customer workspace define its own identity where needed.

Choosing the Right Approach

Not every product needs full white-labeling. Here's how to decide:

If you're building a multi-tenant SaaS where each customer needs their own branding, add Customer Workspaces to any of these approaches. The workspace model scales whether you're serving 10 customers or 10,000.

Implementation Checklist

Before you start:

Define your white-labeling scope. Which touchpoints matter most? Logos and colors? Emails? The signing UI? Template creation? Map the user journey and identify where third-party branding would break the experience.

Decide on single-brand vs. multi-brand. If you need per-customer branding, plan your workspace structure early. Create a workspace when you onboard each customer, and scope all their activity to that workspace.

Set up visual branding first. Upload your logo and configure your color theme at the company level. This takes minutes and immediately improves the signing experience for all users.

Add your email domain. Register your domain, add the DNS records, and verify. This is the single highest-impact change for most products, since it's the first thing recipients notice.

Customize email templates. Retrieve the default templates, adapt the copy and HTML to match your brand voice, and set them at the company or workspace level.

Plan your embedded strategy. If you're embedding, decide which components you need. Signing only? Template editing too? The embeddable signing interface is the most common starting point. Template and signing request editors add more value for products where document preparation is part of the core workflow.

Test the full flow. Send a signing request through every touchpoint. Check the email sender, the email content, the signing interface, and the completion notification. Make sure every step feels like your product.

For the full technical API reference with code examples for every feature covered here, see the Firma.dev White Labeling Guide.

What This Costs

Enterprise e-signature platforms often charge premium fees for white-labeling. Sometimes it's a separate add-on. Sometimes it's locked behind a higher pricing tier.

Firma.dev includes all white-labeling capabilities at every pricing level. Custom email domains, embedded editors, embedded signing, Customer Workspaces. All included.

Pay-as-you-go at €0.029 per envelope. No contracts. No minimums. No extra fees for branding your signing experience.

Getting Started

Firma.dev includes all white-labeling capabilities at every pricing tier. No premium plans, no feature gates. Pay €0.029 per envelope (~3¢ USD) and get access to logos, colors, custom domains, email templates, embedded interfaces, and Customer Workspaces.

Get started with Firma.dev for free, no credit card required.