White-Label E-Signature API Pricing: 5 Providers Compared for 2026

White-label pricing comparison

The table below summarizes the entry-level pricing tiers, per-document transaction costs, and white-labeling features available from five major e-signature API providers in 2026.

What "white-label" actually means

When selecting a signature provider, it is critical to determine the level of white-labeling required. There are three tiers of branding customization, and costs scale rapidly between them:

Most basic applications only require Level 1 customization — ensuring the third-party logo is replaced with your own. However, for a professional SaaS application or custom portal, Level 3 is highly recommended. It guarantees that signers see your domain in the browser address bar, maintaining complete customer trust throughout the document flow.

DNS & SSL CNAME Setup: System Mechanics

For Level 3 white-labeling, pointing a custom domain to an e-signature API requires a system architecture that handles DNS translation, dynamic SSL certificate handshakes, and email domain alignment.

1. How DNS CNAME Routing Works

To establish a custom signing domain, your customers must configure a CNAME record in their DNS zones. For example, if they wish to host signing flows at sign.yourcompany.com, they create a record pointing to the API provider's host:

sign.yourcompany.com CNAME cname.signb.ee

When a signer visits this address, the DNS server resolves sign.yourcompany.com to cname.signb.ee, directing the HTTP/HTTPS request to the provider's edge reverse proxy or load balancer. The proxy reads the incoming Host header to identify which tenant the signing request belongs to.

2. On-Demand Let's Encrypt SSL Handshakes

Since requests use HTTPS, the reverse proxy must serve a valid TLS/SSL certificate matching sign.yourcompany.com. The proxy initiates an automated certificate issuance process using the ACME protocol:

• Dynamic Request Check: The reverse proxy intercepts the TLS client handshake and checks its database to confirm if the requested domain is associated with an active customer.
• ACME HTTP-01 Challenge: If verified, the proxy requests Let's Encrypt or ZeroSSL to issue a single-domain certificate. The Certificate Authority (CA) sends a validation request to http://sign.yourcompany.com/.well-known/acme-challenge/<TOKEN>.
• Challenge Interception: The reverse proxy serves the verification token on port 80. The CA verifies domain control, signs the certificate, and pushes it to the proxy.
• TLS Presentation: The proxy caches the certificate in memory and presents it to the client browser to complete the SSL handshake. This dynamic validation is fully automated, takes less than three seconds on the first request, and renews automatically in the background.

3. Email Alignment: SPF, DKIM, and DMARC

When an API sends signing invitations from your domain (e.g., agreements@yourcompany.com), you must configure three primary DNS records to prevent spoofing and maximize email deliverability:

• SPF (Sender Policy Framework): A TXT record listing authorized sending mail servers. To prevent SPF lookup collisions (due to the DNS limit of 10 lookups per record), you must merge entries instead of creating multiple SPF records. For example:
  v=spf1 include:_spf.google.com include:_spf.signb.ee ~all
• DKIM (DomainKeys Identified Mail): Uses public-key cryptography. The provider signs emails with a private key. You add a DNS record containing the public key (e.g., sig1._domainkey.yourcompany.com CNAME dkim.signb.ee) allowing recipient mail servers to verify the message signature.
• DMARC (Domain-based Message Authentication, Reporting, and Conformance): Instructs mail providers how to handle emails failing SPF/DKIM validation, keeping your white-labeled emails secure from domain spoofing.

DNS Configuration Routing Flow

The ASCII sequence below demonstrates the end-to-end network routing, starting from the client browser to the dynamic TLS reverse proxy and backend servers.

+----------------+       CNAME Resolve      +-------------------------+
| Signer Browser | -----------------------> | DNS Nameserver          |
|                | <----------------------- | sign.yourcompany.com    |
+----------------+   cname.signb.ee CNAME   +-------------------------+
        |
        | HTTPS Request (Target IP of cname.signb.ee)
        v
+---------------------------------------------------------------------+
|                      Reverse Proxy Ingress Engine                   |
|                                                                     |
|  1. Detects Host: sign.yourcompany.com                              |
|  2. Dynamic TLS Engine checks local cache for matching certificate  |
|  3. Cache Miss -> Initiates ACME HTTP-01 Challenge handshake        |
|  4. Let's Encrypt issues cert -> Dynamic SNI presentation            |
|  5. SSL Handshake Completed securely with Browser                   |
+---------------------------------------------------------------------+
        |
        | Internal Reverse Proxy Pass (Encrypted Upstream)
        v
+---------------------------------------------------------------------+
|                      Signbee Application Node                      |
|                                                                     |
|  - Validates tenant API mapping matching custom hostname             |
|  - Loads customized CSS, logos, and branding variables              |
|  - Renders secure Signing UI & initiates signing flow               |
+---------------------------------------------------------------------+

Standard DNS Zone Configuration Table

This table outlines the exact records required in your domain registrar configuration to allow custom signing subdomains and secure email routing.

Step-by-Step Developer Implementation Guide

For developers implementing a custom hostname routing system, the following steps outline the required database schemas, background workers, and proxy ingress configurations.

Step 1: Database Tracking

Define a database model to track domain verification states, DNS verification status, and timestamp indicators for your tenants.

CREATE TABLE tenant_domains (
    id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
    tenant_id UUID NOT NULL REFERENCES tenants(id) ON DELETE CASCADE,
    hostname VARCHAR(255) UNIQUE NOT NULL,
    cname_verified BOOLEAN DEFAULT FALSE,
    ssl_active BOOLEAN DEFAULT FALSE,
    verified_at TIMESTAMP WITH TIME ZONE,
    created_at TIMESTAMP WITH TIME ZONE DEFAULT CURRENT_TIMESTAMP
);

Step 2: Programmatic DNS Verification

Implement a background worker (e.g., using Node.js) to resolve client DNS configuration records. This verifies that CNAME properties are mapped correctly before authorizing SSL issuance.

import { resolveCname } from "dns/promises";

async function verifyTenantCNAME(hostname: string, expectedTarget: string): Promise<boolean> {
  try {
    const resolvedCNAMEs = await resolveCname(hostname);
    // Validate target domain match
    return resolvedCNAMEs.some(cname => cname.toLowerCase() === expectedTarget.toLowerCase());
  } catch (error) {
    console.error(`DNS verification failed for ${hostname}:`, error);
    return false;
  }
}

Step 3: Ingress Proxy Configuration (Caddy On-Demand TLS)

Using a proxy like Caddy, configure On-Demand TLS parameters. Caddy intercepts incoming host names and issues dynamic Let's Encrypt certificates over ACME, querying your web server API to validate allowed domains.

# Caddyfile System Configuration
{
    on_demand_tls {
        ask http://localhost:3000/api/v1/whitelabel/validate-domain
        interval 2m
        burst 10
    }
}

:443 {
    tls {
        on_demand
    }
    reverse_proxy localhost:3000 {
        header_up Host {header.Host}
        header_up X-Real-IP {remote_host}
    }
}

Architectural Trade-offs of 5 E-Signature APIs

Different e-signature APIs approach white-labeling and customization with distinct trade-offs regarding developer effort, operational overhead, and recurring subscription costs.

Signbee

Signbee is designed specifically for the agentic web, featuring a lightweight, direct API that requires no custom SDKs. White-labeling (including custom subdomains and custom CSS variables) is built directly into all standard plan levels at $0.50 per document. This pricing structure makes it ideal for startups and growing SaaS companies requiring Level 3 customization without complex enterprise negotiations.

Docuseal

Docuseal offers an open-source, developer-centric package that can be self-hosted via Docker. It supports embedded signing using iframes. Because you run the container on your own infrastructure, Level 3 white-labeling is free. However, self-hosting shifts the responsibility of database replication, PDF rendering performance, security audits, and SMTP deliverability directly to your engineering team.

BoldSign

BoldSign provides feature-rich React/Next.js integrations, custom email layouts, and webhooks. It features standard plans beginning at $249/month, but custom domains (Level 3 white-labeling) are restricted to custom Enterprise contracts. This introduces higher entry costs for startups seeking a complete, native-branded client experience.

HelloSign (Dropbox Sign)

HelloSign offers mature SDKs, robust iframe styling libraries, and high API reliability. While standard developer integrations are easy to implement, full custom domain routing is gated behind HelloSign Premium, which begins at $4,999/year. This pricing is standard for mid-market applications but remains a barrier for early-stage products.

DocuSign

DocuSign is the market leader, providing comprehensive international compliance, PKI validation, and enterprise-grade user management. However, its REST API is historically complex, and Level 3 custom domain mapping requires dedicated Enterprise contracts starting at $25,000+/year, requiring enterprise budget approvals and procurement cycles.

Legal Compliance & Custom Audit Trails

Under regulations like the USA ESIGN Act, the Uniform Electronic Transactions Act (UETA), and eIDAS (EU), digital signatures require tamper-evident integrity controls. An audit trail must document details like signer IP addresses, email verification hashes, and session timestamps.

When applying a white-label custom domain, the signature certificate must retain legal compliant security properties. APIs like Signbee sign PDFs cryptographically with a secure, tamper-evident private key. The visual rendering of the audit certificate is customized with your branding, colors, and legal naming conventions. This satisfies both legal audit standards and white-label design requirements simultaneously.

Annual cost at 500 docs/month

To demonstrate the pricing disparity between standard and enterprise plans, the list below outlines the projected yearly cost for generating 500 signed documents per month (6,000 documents per year) with Level 3 white-labeling (custom domain + embedded interface) enabled:

Frequently Asked Questions

Last updated: May 29, 2026 · Michael Beckett is the founder of Signbee and B2bee Ltd.