What's Inside an E-Signature Audit Trail?

Why the audit trail matters more than the signature

Most developers focus on the signature itself — the drawn squiggle, the typed name, the checkbox. But in a legal dispute, the signature is the least important part. What matters is the evidence trail proving three things:

The ESIGN Act, eIDAS, and ECA 2000 all require these elements for an electronic signature to be legally valid. Without a proper audit trail, your signed document is just a PDF with a picture on it.

What Signbee captures during the signing process

Every document sent through the Signbee API generates a timeline of events with cryptographic proof at each step:

How SHA-256 hashing works (non-cryptographer version)

SHA-256 takes any input — a 1-page NDA or a 500-page merger agreement — and produces a fixed 64-character hexadecimal string. This hash is a one-way function: you can always compute the hash from the document, but you can never reconstruct the document from the hash.

The critical property: even a single changed character produces a completely different hash. Not a slightly different hash. A completely different one.

import { createHash } from "crypto";

// Original document content
const original = "# NDA\nThis agreement is between Party A and Party B.";
const originalHash = createHash("sha256").update(original).digest("hex");
console.log(originalHash);
// → "a3f2b8c1d4e5f67890abcdef1234567890abcdef1234567890abcdef12345678"

// Tampered document — one character changed ("A" → "C")
const tampered = "# NDA\nThis agreement is between Party C and Party B.";
const tamperedHash = createHash("sha256").update(tampered).digest("hex");
console.log(tamperedHash);
// → "7e9f1a2b3c4d5e6f7890abcdef1234567890abcdef1234567890abcdef123456"

// Completely different hash — tamper detected
console.log(originalHash === tamperedHash); // → false

When a document is signed through Signbee, we compute the SHA-256 hash of the document at the exact moment the signature is applied. This hash is stored in our database, embedded in the certificate of completion, and included in the webhook event payload. If you ever need to prove the document hasn't been tampered with, you re-hash it and compare.

The certificate of completion

After a document is signed, Signbee generates a certificate of completion — a separate page appended to the end of the signed PDF. This certificate contains the full audit trail in human-readable format:

Verifying document integrity via the API

You don't need to manually compute hashes. The Signbee API returns the audit trail data for any completed document:

const response = await fetch("https://signb.ee/api/v1/send", {
  method: "POST",
  headers: {
    "Content-Type": "application/json",
    "Authorization": "Bearer sb_live_your_api_key",
  },
  body: JSON.stringify({
    markdown: "# Non-Disclosure Agreement\n\nBetween Party A and Party B...",
    recipient_name: "Jane Smith",
    recipient_email: "jane@example.com",
  }),
});

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

// Later, after signing — check status and get audit trail
const doc = await fetch(
  `https://signb.ee/api/v1/documents/${document_id}`,
  { headers: { "Authorization": "Bearer sb_live_your_api_key" } }
);

const {
  status,         // "completed"
  document_hash,  // SHA-256 of original document
  signed_hash,    // SHA-256 of signed document
  signed_at,      // ISO 8601 timestamp
  signer_ip,      // IP address at time of signing
  certificate_id, // Unique certificate reference
} = await doc.json();

How this compares to DocuSign's audit trail

DocuSign provides a "Certificate of Completion" with similar information — timestamps, IP addresses, and signer details. However, there are key differences in how developers interact with it:

Real-world scenario: disputing a signed contract

Here's a concrete example. A freelancer sends a retainer agreement to a client through the Signbee API. Three months later, the client claims "the agreement said $3,000/month, not $5,000/month."

The freelancer retrieves the signed document and the certificate of completion. The SHA-256 hash on the certificate matches the hash of the document in their records. The hash proves the document has not been altered since the moment the client signed it. The audit trail shows the client's IP address, the timestamp, and the browser they used.

This is non-repudiation in practice. The client cannot credibly claim they signed a different document, because any alteration — even changing "$5,000" to "$3,000" — would produce a completely different SHA-256 hash.

Building your own verification layer

For regulated industries (healthcare/HIPAA, fintech, real estate), you may want to store document hashes independently in your own database as a secondary verification source. This is straightforward with Signbee's webhook events — listen for the document.completed event, extract the hash, and store it alongside your internal records.

For more on how Signbee's signing certificates work at a low level, see our technical guide on how SHA-256 signing certificates work.

Frequently Asked Questions

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