E-Signature API Compliance Checklist: ESIGN, eIDAS, HIPAA, SOC 2

Are electronic signatures legally binding?

Yes. This question comes up in every compliance review, and the answer hasn't changed since the ESIGN Act was signed in 2000: electronic signatures have the same legal standing as handwritten signatures in the United States, the European Union, the United Kingdom, Canada, Australia, and most other jurisdictions.

But "legally binding" doesn't mean "automatically compliant." The signature is valid only if your implementation satisfies three universal requirements:

If your e-signature API captures these three elements — with an audit trail to prove it — the signature is enforceable. For a deeper dive into the legal frameworks, see our complete guide to e-signature law.

Checklist 1: ESIGN Act & UETA (United States)

The ESIGN Act (Electronic Signatures in Global and National Commerce Act) and UETA (Uniform Electronic Transactions Act) govern e-signatures in the US. Here's your developer checklist:

Signbee handles all of these automatically. The signing page displays a consent disclosure. The signer can decline. The signed PDF includes a certificate of completion with a SHA-256 hash. See our signing certificate deep-dive for how the hash verification works.

Checklist 2: eIDAS (European Union)

The eIDAS Regulation defines three levels of electronic signatures. Understanding which level you need is the first step:

Most API-based e-signatures are SES or AES. SES is sufficient for the vast majority of business transactions. QES is only required for specific regulated transactions in certain EU member states (e.g., real estate transfers in Italy, public procurement in France). For a complete breakdown, see our AES vs QES guide.

Your eIDAS checklist for SES/AES:

Checklist 3: HIPAA (Healthcare)

If your application handles protected health information (PHI), HIPAA compliance applies to your e-signature workflow. This is the checklist most developers get wrong — not because the requirements are complex, but because they forget that the e-signature provider is a Business Associate.

Critical: Not all e-signature providers offer BAAs. DocuSign offers them on enterprise plans. HelloSign offers them on premium plans. Check with your provider before sending any documents that contain PHI. For healthcare-specific guidance, see our HIPAA e-signature guide.

Checklist 4: SOC 2 (SaaS & enterprise)

If your company is SOC 2 audited (or your customers require it), your e-signature provider needs to be part of your trust boundary. SOC 2 isn't a law — it's a framework for demonstrating security controls. But for SaaS companies, it's table stakes.

Verify compliance in your code

Here's a practical pattern I use to verify that every document sent through the Signbee API meets compliance requirements before it reaches the signer:

interface ComplianceCheck {
  hasConsent: boolean;
  recipientVerified: boolean;
  contentNotEmpty: boolean;
  auditMetadata: Record<string, string>;
}

function verifyCompliance(params: {
  markdown: string;
  recipientEmail: string;
  consentGiven: boolean;
}): ComplianceCheck {
  return {
    hasConsent: params.consentGiven,
    recipientVerified: params.recipientEmail.includes("@"),
    contentNotEmpty: params.markdown.trim().length > 0,
    auditMetadata: {
      initiatedAt: new Date().toISOString(),
      initiatedBy: "system",
      complianceVersion: "2026-05",
    },
  };
}

async function sendCompliantDocument(params: {
  markdown: string;
  recipientName: string;
  recipientEmail: string;
  consentGiven: boolean;
}) {
  const checks = verifyCompliance(params);

  if (!checks.hasConsent) {
    throw new Error("ESIGN: Consent not captured");
  }
  if (!checks.contentNotEmpty) {
    throw new Error("Document content cannot be empty");
  }

  const response = await fetch("https://signb.ee/api/v1/send", {
    method: "POST",
    headers: {
      "Content-Type": "application/json",
      "Authorization": "Bearer sk_live_your_api_key",
    },
    body: JSON.stringify({
      markdown: params.markdown,
      recipient_name: params.recipientName,
      recipient_email: params.recipientEmail,
      metadata: checks.auditMetadata,
    }),
  });

  const result = await response.json();

  // Log for your own audit trail
  await auditLog.create({
    action: "document.sent",
    documentId: result.id,
    recipient: params.recipientEmail,
    complianceChecks: checks,
    timestamp: new Date(),
  });

  return result;
}

This wrapper ensures consent is captured before sending, logs every request to your own audit trail, and attaches compliance metadata to the document. Even though Signbee generates its own audit trail, maintaining your own gives you defense-in-depth for compliance audits.

Provider compliance comparison

Common compliance mistakes developers make

The security layer

Compliance is closely tied to security. Make sure your integration follows these security practices on top of the compliance checklist:

API key management. Never embed API keys in client-side code. Use server-side environment variables. Rotate keys quarterly. Use scoped keys when available.

Webhook verification. Always verify the x-signbee-signature header on incoming webhooks. This prevents attackers from spoofing "document.signed" events and tricking your system into thinking a contract was signed when it wasn't. See our webhooks guide for verification code.

Transport security. All Signbee API calls use TLS 1.2+. Verify that your HTTP client doesn't downgrade to older protocols. For a comprehensive security overview, see our security architecture guide.

Frequently Asked Questions

Last updated: May 17, 2026 · Michael Beckett is the founder of Signbee and B2bee Ltd. This is a developer compliance guide, not legal advice — consult a qualified attorney for your specific requirements.