Open-Source E-Signature API: Docuseal vs Signbee vs Self-Hosted

Introduction & The Open-Source Paradigm Shift

Integrating electronic signatures is a standard requirement for modern SaaS platforms, legal tech, and enterprise workflows. Historically, developers were forced into expensive, proprietary ecosystems like DocuSign, which come with steep API entry costs and complex integration protocols. Today, the landscape is divided between self-hosted open-source platforms (such as Docuseal and OpenSign) and API-first, developer-friendly managed services like Signbee. Each choice carries significant architecture, compliance, and legal responsibilities that developers must evaluate before deploying to production.

Licensing Deep Dive: AGPLv3 vs. Permissive Licenses (MIT/Apache 2.0)

When selecting an open-source e-signature core, the licensing model defines the legal bounds of your entire software stack. E-signature platforms typically use one of two licensing paradigms: Copyleft (GNU Affero GPL v3) or Permissive (MIT or Apache 2.0).

The AGPLv3 and the SaaS Loophole: The GNU General Public License (GPL) was written for an era of distributed desktop software, triggering source code disclosure only when binaries were distributed. Modern SaaS companies bypassed this by hosting GPL software in the cloud, exposing the functionality over web interfaces without distributing files—a practice known as the SaaS loophole. The Affero GPL (AGPLv3) was explicitly engineered to close this gap. Under AGPLv3 Section 13, if you modify the software and make it interactively available to remote users over a network, you MUST make the complete, modified source code of the application available to those users at no charge.

For self-hosted platforms like OpenSign or the open-source version of Docuseal (which utilize AGPLv3), this means that if you modify the interface, alter the PDF rendering logic, or add proprietary branding directly to the application code, you are legally obligated to make those modifications public. Simply exposing the signing view to your customers triggers this clause.

Permissive Licenses (MIT / Apache 2.0): Permissive licenses place almost no restrictions on reuse. Developers can fork MIT-licensed code, add proprietary features, bundle it with closed-source systems, and commercialize it as a SaaS without disclosing a single line of modifications. This allows full business model flexibility, though it places the burden of security and maintenance entirely on the developer.

Compliance and Integration Boundaries: A common question is whether integrating an AGPLv3 e-signature service via a network boundary (REST API) infects the calling application with copyleft requirements. If the self-hosted AGPL e-signature service is strictly isolated in its own container and communicates with your main application solely via REST API calls, your proprietary code remains safe. However, if you import AGPL packages into your main application runtime, link libraries dynamically, or share a database schema without strict isolation, your entire application risk being classified as a 'derivative work,' forcing you to publish your core proprietary code.

Side-by-side comparison

API Specification Matrix

For architectural decisions, understanding the low-level system designs of each framework is vital. The matrix below compares the developer features of self-hosted engines vs. Signbee.

Architectural Design: Multi-Tenant Request Routing

Implementing a multi-tenant structure in self-hosted configurations forces a trade-off between PostgreSQL Row-Level Security (RLS) and database-per-tenant architectures.

Row-Level Security (RLS) Isolation: Here, a single database cluster and schema house all tenants. Each row is tagged with a `tenant_id`. PostgreSQL enforces limits using policies like `CREATE POLICY tenant_isolation ON documents USING (tenant_id = current_setting('app.current_tenant_id'))`. While cost-effective and simple to maintain, a single configuration bug or connection leak could theoretically compromise tenant boundary safety. Furthermore, 'noisy neighbors' can saturate the shared connection pool.

Database-per-Tenant isolation: This separates tenants at the physical or logical database layer. The gateway dynamically connects to the correct database based on incoming headers or subdomains. Although providing absolute data isolation and independent backup strategies, this model dramatically inflates connection pooling overhead and schema migration complexity.

Figure 1: Multi-tenant database routing flow (RLS vs Database-per-tenant)

                  +-----------------------------------+
                  |  Multi-Tenant Client Request      |
                  |  (Subdomain/Header Identification)|
                  +-----------------+-----------------+
                                    |
                                    v
                  +-----------------+-----------------+
                  |      API Gateway / Router         |
                  +-----------------+-----------------+
                                    |
                                    |--[ Option A: Row-Level Security ]
                                    |   (Shared DB, Tenant Scoped Session)
                                    |   v
                                    |   +----------------------------------+
                                    |   | Set Local Context:               |
                                    |   | SET LOCAL app.tenant_id = 'XYZ'  |
                                    |   +----------------+-----------------+
                                    |                    |
                                    |                    v
                                    |   +----------------+-----------------+
                                    |   | PostgreSQL Engine (Shared Schema)|
                                    |   | Policy: WHERE tenant_id = context|
                                    |   +----------------+-----------------+
                                    |                    |
                                    |                    v
                                    |          [ Shared PostgreSQL DB ]
                                    |
                                    |--[ Option B: Database-per-Tenant ]
                                        (Dynamic Connection Routing)
                                        v
                                        +----------------------------------+
                                        | Dynamic Connection Pool Manager  |
                                        | Lookup DB URI for Tenant 'XYZ'   |
                                        +----------------+-----------------+
                                                         |
                                        +----------------+-----------------+
                                        |  [Tenant A DB]   [Tenant B DB]   |
                                        |  (Isolated)      (Isolated)      |
                                        +----------------------------------+

Webhook Security & Signature Verification

Webhooks transmit mission-critical document state changes, such as 'completed' signing status. Because these endpoints are public web listeners, verifying webhook signatures is essential to prevent spoofing attacks. A shared secret is used to generate an HMAC-SHA256 hash. Receivers must reconstruct this signature, verify its matching value, and validate the timestamp to mitigate replay attacks.

Node.js (Express & TypeScript) Webhook Receiver

The Node.js implementation below uses native crypto. We perform string comparisons via `timingSafeEqual` to safeguard against timing side-channel attacks.

import crypto from 'crypto';

interface WebhookVerificationResult {
  isValid: boolean;
  error?: string;
}

export function verifyWebhookSignature(
  rawBody: string,
  signatureHeader: string,
  timestampHeader: string,
  webhookSecret: string,
  toleranceSeconds = 300 // 5 minutes replay protection
): WebhookVerificationResult {
  // 1. Check for missing headers
  if (!signatureHeader || !timestampHeader) {
    return { isValid: false, error: 'Missing signature or timestamp headers' };
  }

  // 2. Validate timestamp age (Replay Attack Prevention)
  const timestamp = parseInt(timestampHeader, 10);
  const currentTime = Math.floor(Date.now() / 1000);
  if (isNaN(timestamp) || Math.abs(currentTime - timestamp) > toleranceSeconds) {
    return { isValid: false, error: 'Timestamp tolerance exceeded (potential replay attack)' };
  }

  // 3. Construct signature payload: timestamp.body
  const signaturePayload = `${timestamp}.${rawBody}`;

  // 4. Calculate expected HMAC-SHA256 signature
  const expectedSignature = crypto
    .createHmac('sha256', webhookSecret)
    .update(signaturePayload)
    .digest('hex');

  // 5. Securely compare signatures (Timing-attack prevention)
  const isMatch = crypto.timingSafeEqual(
    Buffer.from(signatureHeader, 'hex'),
    Buffer.from(expectedSignature, 'hex')
  );

  if (!isMatch) {
    return { isValid: false, error: 'Invalid signature. Signature match failed.' };
  }

  return { isValid: true };
}

Python (FastAPI / Flask) Webhook Receiver

The Python validation script relies on `hmac.compare_digest` to achieve secure signature verification.

import hmac
import hashlib
import time

def verify_webhook_signature(
    raw_body: bytes,
    signature_header: str,
    timestamp_header: str,
    webhook_secret: str,
    tolerance_seconds: int = 300
) -> bool:
    """
    Verifies the webhook signature using HMAC-SHA256.
    
    Args:
        raw_body: The raw request body as bytes.
        signature_header: The hex signature from the header.
        timestamp_header: The timestamp string from the header.
        webhook_secret: The shared secret key.
        tolerance_seconds: Maximum allowed age of the webhook request.
        
    Returns:
        bool: True if signature is valid, raises ValueError otherwise.
    """
    # 1. Verify headers exist
    if not signature_header or not timestamp_header:
        raise ValueError("Missing signature or timestamp header")

    # 2. Check for replay attack using the timestamp
    try:
        request_time = int(timestamp_header)
    except ValueError:
        raise ValueError("Invalid timestamp format")

    current_time = int(time.time())
    if abs(current_time - request_time) > tolerance_seconds:
        raise ValueError("Webhook request expired (replay protection failed)")

    # 3. Construct the signature payload
    # Format: timestamp.body (using bytes)
    secret_bytes = webhook_secret.encode('utf-8')
    payload = f"{timestamp_header}.".encode('utf-8') + raw_body

    # 4. Generate the expected signature
    expected_signature = hmac.new(
        secret_bytes,
        payload,
        hashlib.sha256
    ).hexdigest()

    # 5. Secure comparison to prevent timing attacks
    if not hmac.compare_digest(expected_signature, signature_header):
        raise ValueError("HMAC signature verification failed")

    return True

The hidden cost of "free"

Self-hosting Docuseal is free in software licensing, but the total cost includes:

At $0.50/doc with Signbee, you'd need to send 70-140 documents per month before the managed option costs more than self-hosting. Below that volume, managed is actually cheaper when you factor in time.

Horizontal Scalability & Performance Constraints

Scalability constraints present another bottleneck for self-hosted instances. Processing digital signatures is CPU-heavy. Generating a cryptographic certificate signature, merging dynamic input fields, flattening PDF pages, and extracting layout coordinates trigger significant hardware overhead. Under load, single self-hosted VM instances running Rails or Express API layers will saturate CPU resource limits.

To resolve this, self-hosted configurations must split into separate worker clusters (using queue runners like Redis Sidekiq or BullMQ). Uploaded files must sit in shared, secure object storage (e.g. AWS S3) rather than the local container disk. Furthermore, scaling database replication nodes, implementing proxy pooling layers (PgBouncer), and handling sticky session load-balancers add complex layers of maintenance overhead.

When to self-host

• Data sovereignty requirements — regulated industries where data must stay on your servers
• High volume (>500 docs/mo) — the per-document savings become significant
• Existing DevOps team — marginal cost of maintaining one more service is low
• Custom UI requirements — Docuseal's iFrame embed gives more UI control

When to use a managed API

• Startups shipping fast — integrate in 30 minutes or less
• No DevOps team — don't spin up Docker for one feature
• Low-to-medium volume — below 140 docs/month, managed is cheaper
• AI agent integration — Signbee has an MCP server for Claude, Cursor, and Windsurf

Frequently Asked Questions

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