SaaS System ArchitectureUpdated September 2026 · 12 min read

Best E-Signature API for SaaS Platforms: Multi-Tenant Embedded Signing

When your SaaS platform expands into digital contracts, proposals, or vendor onboarding, choosing an e-signature provider is primarily an architectural and unit economics decision. Per-seat pricing can instantly destroy your product margins, while legacy SDKs bloat serverless cold starts. Here is how to architect an embedded, multi-tenant signing engine using a single REST endpoint and consumption-based pricing.

Michael Beckett
Michael Beckett

Founder, Signbee

$0.50

Per Document

100%

Multi-Tenant

< 30 min

Integration

SHA-256

Audit Seals

Architectural TL;DR

Per-seat pricing from legacy vendors creates a toxic misalignment for SaaS companies: you pay monthly user license fees regardless of whether your tenants send 1 document or 100. Modern B2B SaaS architectures require an API-first, per-document pricing model ($0.50 flat per execution) combined with multi-tenant data isolation via PostgreSQL Row Level Security (RLS) and HMAC-verified webhook fan-out.

The Multi-Tenant SaaS Signing Architecture

In a multi-tenant B2B SaaS platform (such as an ATS, CRM, or billing system), your application serves hundreds of customer organizations under a shared infrastructure. The signing engine must maintain rigorous tenant data boundaries:

Multi-Tenant Embedded Signing Architecture
[Tenant Workspace: "Acme Corp"]           [Tenant Workspace: "Starlight Ltd"]
           │                                                   │
           ▼                                                   ▼
┌────────────────────────────────────────────────────────────────────────┐
│                        SaaS Application Backend                        │
│                                                                        │
│  1. Injects tenant_id & tenant branding (sender_name, sender_email)   │
│  2. Dispatches atomic HTTP POST to Signbee REST API                    │
│  3. Records document_id in PostgreSQL (Row Level Security protected)   │
└───────────────────────────────────┬────────────────────────────────────┘
                                    │
                                    ▼
                         [Signbee Signing Cloud]
               (Compiles PDF, delivers unbranded email ceremony)
                                    │
                                    ▼ (Signer executes in mobile web)
┌───────────────────────────────────┴────────────────────────────────────┐
│                    Webhook Consumer: POST /api/webhooks                │
│                                                                        │
│  1. Verifies HMAC-SHA256 signature via X-Signbee-Signature             │
│  2. Resolves tenant_id by document_id in database                      │
│  3. Emits WebSocket event strictly to target tenant's browser session  │
└────────────────────────────────────────────────────────────────────────┘

Database Schema Design: PostgreSQL Row Level Security (RLS)

To ensure that Tenant A can never view or access signed contracts belonging to Tenant B, enforce Row Level Security directly in PostgreSQL:

schema.sql — Multi-Tenant Contracts Table
-- Multi-tenant contracts schema
CREATE TABLE tenant_contracts (
    id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
    tenant_id UUID NOT NULL REFERENCES organizations(id) ON DELETE CASCADE,
    document_id VARCHAR(64) NOT NULL UNIQUE,
    document_title VARCHAR(255) NOT NULL,
    recipient_email VARCHAR(255) NOT NULL,
    status VARCHAR(32) NOT NULL DEFAULT 'PENDING',
    signing_url TEXT,
    pdf_download_url TEXT,
    sha256_hash VARCHAR(64),
    created_at TIMESTAMPTZ NOT NULL DEFAULT NOW(),
    signed_at TIMESTAMPTZ
);

-- Enable Row Level Security (RLS)
ALTER TABLE tenant_contracts ENABLE ROW LEVEL SECURITY;

-- Enforce strict tenant isolation policy
CREATE POLICY tenant_isolation_policy ON tenant_contracts
    FOR ALL
    USING (tenant_id = current_setting('app.current_tenant_id')::UUID);

TypeScript / Next.js Multi-Tenant Dispatch Controller

Here is how your SaaS backend handles contract creation with dynamic tenant branding:

api/contracts/send/route.ts
import { NextRequest, NextResponse } from "next/server";

export async function POST(req: NextRequest) {
  // Extract authenticated tenant session
  const tenantId = req.headers.get("x-tenant-id");
  const { recipientName, recipientEmail, contractTitle, markdownBody } = await req.json();

  // Retrieve tenant branding settings from DB
  const tenantOrg = await db.organizations.findUnique({ where: { id: tenantId } });

  // Dispatch via Signbee REST API
  const response = await fetch("https://signb.ee/api/v1/send", {
    method: "POST",
    headers: {
      "Authorization": `Bearer ${process.env.SIGNBEE_API_KEY}`,
      "Content-Type": "application/json",
    },
    body: JSON.stringify({
      markdown: markdownBody,
      sender_name: tenantOrg.companyName,
      sender_email: `contracts@${tenantOrg.domain}`,
      recipient_name: recipientName,
      recipient_email: recipientEmail,
      webhook_url: "https://api.yoursaas.com/v1/webhooks/signbee",
      expires_in_days: 14,
    }),
  });

  if (!response.ok) {
    const errorText = await response.text();
    return NextResponse.json({ error: errorText }, { status: 500 });
  }

  const { document_id, signing_url } = await response.json();

  // Persist record under tenant context
  await db.tenant_contracts.create({
    data: {
      tenant_id: tenantId,
      document_id,
      document_title: contractTitle,
      recipient_email: recipientEmail,
      status: "PENDING",
      signing_url,
    },
  });

  return NextResponse.json({ success: true, document_id, signing_url });
}

Multi-Tenant Webhook Ingestion & Event Fan-Out

In a multi-tenant platform, your central webhook receiver must securely route incoming document events (such as document.completed, document.viewed, or document.declined) to the correct customer workspace without cross-tenant data leaks.

By passing tenant workspace identifiers inside the document metadata at creation time, your webhook handler can perform zero-latency tenant resolution, verify HMAC cryptographic authenticity, and publish real-time notifications to the client browser via WebSockets or Server-Sent Events (SSE):

app/api/webhooks/signbee/route.ts — Multi-Tenant Webhook Consumer
import { NextRequest, NextResponse } from "next/server";
import crypto from "node:crypto";
import { db } from "@/lib/db";
import { eventBus } from "@/lib/event-bus";

export async function POST(req: NextRequest) {
  const rawBody = await req.text();
  const signature = req.headers.get("x-signbee-signature");
  const webhookSecret = process.env.SIGNBEE_WEBHOOK_SECRET!;

  // 1. Verify cryptographic HMAC-SHA256 signature
  const expectedSignature = crypto
    .createHmac("sha256", webhookSecret)
    .update(rawBody)
    .digest("hex");

  if (
    !signature ||
    !crypto.timingSafeEqual(Buffer.from(signature), Buffer.from(expectedSignature))
  ) {
    return NextResponse.json({ error: "Invalid signature" }, { status: 401 });
  }

  const payload = JSON.parse(rawBody);
  const { event, document_id, metadata, pdf_download_url, sha256_hash } = payload;
  const tenantId = metadata?.tenant_id;

  if (!tenantId) {
    return NextResponse.json({ error: "Missing tenant_id in metadata" }, { status: 400 });
  }

  // 2. Atomic state update partitioned by tenant_id
  if (event === "document.completed") {
    await db.tenant_contracts.updateMany({
      where: {
        document_id: document_id,
        tenant_id: tenantId, // Strict partition defense
      },
      data: {
        status: "COMPLETED",
        pdf_download_url: pdf_download_url,
        sha256_hash: sha256_hash,
        signed_at: new Date(),
      },
    });

    // 3. Emit isolated tenant WebSocket notification
    eventBus.publish(`tenant:${tenantId}:contracts`, {
      type: "CONTRACT_SIGNED",
      document_id,
      signedAt: new Date().toISOString(),
    });
  }

  return NextResponse.json({ received: true });
}

Tenant Data Isolation & Compliance (SOC 2, GDPR, HIPAA)

When embedding digital contracts into B2B software, enterprise buyers frequently demand strict adherence to compliance standards. Your architecture must guarantee three core guarantees:

1. Encryption at Rest with Per-Tenant KMS Scoping

While raw PDFs are compiled and signed in the ephemeral Signbee cloud, once the completed agreement is downloaded via the webhook callback, store the signed binary in your object storage (AWS S3 or Cloudflare R2) encrypted with AWS KMS or envelope encryption keys strictly compartmentalized by tenant ID.

2. Ephemeral Cloud Processing & Zero Retention

Unlike traditional platforms that store customer agreements in proprietary document vaults indefinitely, an API-first engine treats contract compilation as an ephemeral pipeline. Once both parties have executed the document and your webhook confirms receipt of the SHA-256 certificate and PDF, the source records expire from memory, satisfying stringent GDPR Article 17 "Right to Erasure" requirements automatically.

3. Immutable Cryptographic Chain of Custody

Every signed document produces a standalone cryptographic Certificate of Completion containing the SHA-256 digest of the markdown template, signers' verified IP addresses, Unix timestamps, and Amazon SES delivery receipt message-IDs. This ensures incontrovertible legal admissibility under US Federal Rules of Evidence Rule 902 without requiring recurring vendor platform dependencies.

Unit Economics: Per-Seat vs Per-Document Pricing

The difference between per-seat and per-document pricing models is the difference between healthy 85% gross margins and losing money on every customer subscription:

SaaS Tenant ScenarioDocuSign Per-Seat ($25/user/mo)PandaDoc Per-Seat ($49/user/mo)Signbee Per-Document ($0.50/doc)
Small Agency (10 users, 20 docs/mo)$250 / mo ($12.50/doc)$490 / mo ($24.50/doc)$10.00 / mo ($0.50/doc)
Mid-Market (50 users, 100 docs/mo)$1,250 / mo ($12.50/doc)$2,450 / mo ($24.50/doc)$50.00 / mo ($0.50/doc)
Enterprise (250 users, 400 docs/mo)$6,250 / mo ($15.62/doc)$12,250 / mo ($30.62/doc)$200.00 / mo ($0.50/doc)
Gross Margin ImpactSeverely degradedNegative on low-volume seats> 90% Gross Margin

Frequently Asked Questions

Why does per-seat pricing fail for multi-tenant SaaS applications?

Per-seat pricing models—promoted by legacy providers like DocuSign and PandaDoc at $10 to $65 per user per month—assume that every user in a software workspace signs documents continuously every day. In multi-tenant B2B SaaS platforms (such as CRMs, HR portals, property management apps, or marketplaces), hundreds or thousands of tenant team members may only require signature capabilities once or twice a quarter. Paying $15/user/month across a 500-seat customer organization costs $7,500/month just for signing infrastructure. A consumption-based per-document model ($0.50 flat per agreement) aligns infrastructure costs directly with actual transaction volume, protecting SaaS gross margins.

How should a multi-tenant SaaS isolate signature data across customer workspaces?

Data isolation in multi-tenant architectures requires two defensive layers: database segregation and webhook routing. In your relational database (such as PostgreSQL with Row Level Security), every contract record must include a tenant_idforeign key, enforcing strict tenant partition boundaries across all SQL queries. For webhooks, the SaaS backend listens on a centralized secure webhook receiver, inspects the document_id in the payload, looks up the corresponding tenant workspace in the database, verifies the HMAC-SHA256 signature, and fans out state updates strictly within that tenant's event stream.

Can SaaS platforms white-label the signing experience for end customers?

Yes. In an API-first multi-tenant setup, your backend dynamically passes the tenant's brand metadata—including company name, custom sender address, and tenant logo—within the REST dispatch payload. The signing invitation email originates from the tenant's verified domain, and the browser-based signing ceremony displays the tenant's styling. Signbee does not inject promotional watermarks or third-party vendor footers, ensuring that your SaaS customers experience an uncompromised white-label signing workflow.

What is the difference between building an in-house signing system vs using an API?

Building an in-house e-signature system involves far more than drawing a canvas signature line. It requires developing a high-fidelity PDF rendering engine, maintaining mail servers with flawless SPF/DKIM inbox reputation, constructing tamper-evident SHA-256 cryptographic audit certificate chains, and conducting legal audits to comply with the US ESIGN Act, UETA, and European eIDAS regulations. Engineering teams typically expend 3 to 6 months of senior engineering resources ($50,000–$100,000+ in capitalized payroll) and incur ongoing maintenance costs. Integrating an established API takes less than an hour and costs pennies per document.

Embed E-Signatures in Your SaaS Today

Multi-tenant ready. Single REST endpoint. Free tier includes 5 documents per month with zero credit card required.