The cryptographic close, as one call
DocuSign and Sign.com sell you a signing application — their UI, their identity flow, their storage, their seal. seal.123 sells the one thing underneath it: the cryptographic closing-seal, as an API. You keep your product, your identity flow, your audit trail — and the document never touches our storage.
Request — the entire integration
POST /v1/seal Authorization: Bearer sk_live_… Content-Type: multipart/form-data pdf=@agreement.pdf client_ref=anexo:123 document_type=anexo
Response — a sealed, self-verifying PDF
200 OK { "seal_id": "seal_9f2c…", "sealed_pdf": "JVBERi0xLjc…", // PAdES, base64 "output_hash": "sha256:4a7b…", "tsa_time": "2026-07-13T09:14:02Z", // trusted timestamp "cert_serial": "3f:a1:…", "deduplicated": false }
No SDK to adopt, no envelopes, no UI to embed — one HTTP call is the whole surface. Identity, OTP, and your audit trail never leave your app.
The idea
Every e-signature platform ships the same four layers as a single product you move into. Only one of them is genuinely expensive to run: the cryptographic seal — a licensed certificate, a timestamp contract (qualified when you need it), and a PAdES-LTV engine. We run that layer, and only that layer, behind an API. You keep the other three.
A signing application
You build on their platform. Their API is the door into all four layers — take them together or not at all.
Signing infrastructure
You build on your own stack and call us for the one operation that needs a licensed certificate and a trusted timestamp.
Side by side
All three can be reached over an API. What that API gives you is the difference — a whole platform to adopt, or a single sealed PDF back.
| DocuSign | Sign.com | seal.123 | |
|---|---|---|---|
| What it is | Signing platform & app | Web signing tool + REST API | API-only sealing engine |
| You integrate | Their envelopes & platform | Their signing flow | One operation — seal() |
| Your UX & identity | Theirs (UI / embedding) | Theirs (hosted flow) | Stays yours — portals, OTP, ledger |
| Your document | Stored on their platform | Stored on their platform | Never stored — hashes + TSA token only |
| The seal | Platform digital seal | Platform seal (SES) | PAdES, provider certificate (open standard) |
| Timestamp | Platform timestamp | Audit-trail events | Trusted timestamp — qualified optional |
| Proof, years later | Via their platform | Via their platform | Inside the PDF (LTV) — offline, without us |
| Billing | Per seat / envelope / plan | Subscription (from $49/mo) | Per document — one seal, one charge |
DocuSign and Sign.com both offer APIs — the point isn't whether there's an API, it's what the call gives back: their whole platform, or a self-verifying sealed PDF.
Inside the seal
The bytes we return aren't a proprietary format — they're an open ETSI/eIDAS standard any validator recognises. Offline LTV verification and a trusted Adobe/DSS check describe the production seal; the current pilot is timestamped but not yet there (see the status note below).
The provider's certificate signs the finished PDF as a standard PAdES signature — tamper-evident and checkable in Adobe or the EU DSS validator. Change one byte and it fails.
Validation data — the certificate chain, OCSP/CRL — lives inside the file. Adobe, the EU DSS validator, or valide.redsara.es confirm it with our service switched off and the certificate long expired.
The service stores hashes, metadata and the timestamp token — not the PDF. Under GDPR the provider is a processor touching almost nothing. Less to breach, less to leak.
The result is ETSI/eIDAS PAdES, verifiable with standard tools by anyone — a court's expert, the counterparty, you. You are never tied to us to prove a signature.
Two ways to seal · same one call
Every seal is a self-verifying PAdES file, and your document is never stored — at both tiers. The upgrade is one thing: whose clock signs the timestamp, and the legal weight that carries. Same API, one flag.
A tamper-evident PAdES signature, a trusted RFC 3161 timestamp, LTV for offline verification, and your hash-chained ledger. Everything DocuSign and Sign.com's SES gives you — unbundled, and without handing over your document.
Swap the timestamp for a qualified one from a TSL-listed QTSP and it carries the eIDAS art. 41.2 presumption: in an EU or Spanish court, the burden of disproving the time and integrity shifts to whoever challenges it. For adversarial disputes and regulated procurement.
The API is the product
There is no console, no envelope model, no signer seats — because there is nothing to adopt but four HTTP routes. The seal is idempotent and metered: retry the same document safely, get charged once.
Your app already knows who the signer is, already runs the OTP, already renders the PDF. It hands us the finished bytes; we hand back the sealed ones. The expensive, licensed, regulated parts live on our side of one call.
(client_ref, input_hash) returns the same seal_id, one charge.502 and no partial seal. No timestamp, no seal.Where the evidence lives
On your side, every signer action is an append-only, hash-chained event — login, OTP, the exact hash of the PDF they saw — each row linking to the SHA-256 of the one before it, so a later edit breaks the chain. On our side sits the cryptographic closing seal that locks the whole file. Two independent layers of tamper-evidence, neither depending on a single vendor staying alive.
Swap the Company signer's email after the fact and re-hash — the genesis hash no longer equals the prev_hash the Student event already recorded. There's nowhere to hide the edit.
Start with one call
Send a finished PDF to /v1/seal and get back a tamper-evident, self-verifying file — qualified when you need it. Tell us what you're signing and we'll wire you an API key.
Key
Every abbreviation on this page in one place — the standards, the trust framework, and the plumbing.