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

If you're building a SaaS prod

uct 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 email domains, embedded interfaces, notification control, and secure tenant isolation. 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 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. 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 never see the platform's brand at all.

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

• Email domain configuration

• 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 Four Pillars of White-Labeling

1. Custom Email Domains

By default, signing request emails come 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. 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.

2. Notification Control

Custom domains change the sender. Full notification control lets you replace the emails entirely.

Firma.dev sends four types of automated emails: signing requests, completion confirmations, expiration warnings, and cancellation notices. You can disable any or all of them per signing request.

Turn them off, retrieve the signing URLs via the API, and send notifications through your own email system. This lets you:

• Match your existing email templates and brand voice

• Control timing for reminders and follow-ups

• Integrate with your transactional email infrastructure (SendGrid, Postmark, Customer.io)

• Trigger notifications based on your own business logic

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

3. Embedded Editors

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

Firma.dev offers two embeddable components:

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.

Both editors use JWT authentication. Your backend generates a short-lived token, and the frontend loads the component with that token. No API keys 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 How to White-Label a Document Signature API in Your SaaS Product for the full implementation breakdown.

4. Embedded Signing

The final piece. Instead of redirecting signers to a hosted signing page, you embed the signing interface directly in your application.

Users sign documents without leaving your domain. They see your header, your navigation, your design. The signing UI appears as a seamless part of your product.

This is the full white-label solution. Combined with custom email domains and notification control, your users never encounter Firma.dev's brand at any point in the workflow.

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? 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 DNS records. Custom email domains require SPF, DKIM, and DMARC records. Coordinate with your ops team or your customers' IT teams if you're doing workspace-level domains.

Generate JWTs on the backend. Never expose API keys to the client. Use short-lived tokens (1-4 hours) for embedded components.

Handle compliance. White-labeling doesn't change the legal validity of signatures. Firma.dev supports ESIGN, UETA, eIDAS, and other frameworks regardless of branding. But if you disable the Firma.dev terms screen, make sure your own terms cover e-signature consent.

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.

Get Started

Ready to build? The Firma.dev White Labeling Guide in our docs has the technical details: API endpoints, code examples, and configuration options.

Or jump straight in. Get your API key and start integrating in hours, not weeks.