e-signature

You are wiring a third-party signing API (DocuSign eSignature or Dropbox Sign, ex-HelloSign) into someone's app or backend. You take a PDF or template, define signers and fields, send it for signature, track status, react to completion via a verified webhook, and retrieve the signed PDF plus its audit trail.

Contract language — clauses, indemnity, liability — goes to ../contracts/SKILL.md; OCR, field extraction, or PDF splitting with no signing involved is ../document-processing/SKILL.md.

Decision: which legal tier do you need?

Pick the tier deliberately, before you write code: it decides which provider features you enable (ID Verification, SMS/access code, qualified signature), and getting it wrong leaves a signature that is hard to defend in court.

US law (ESIGN Act + UETA) has no tiers — e-signatures equal wet ink. The EU (eIDAS, and eIDAS 2.0 / Reg (EU) 2024/1183 in force since May 2024) defines three. A typed name (SES) is binding for most B2B in the US and EU, but a high-stakes EU document may need AES or QES. Map the document's stakes to a tier, then to a provider feature.

Tier	What it is	When you need it	Provider feature to enable
SES (Simple)	Typed or drawn signature, basic intent + audit trail	Most B2B: offers, NDAs, quotes, US contracts generally	Default flow — just capture the signature + keep the audit trail
AES (Advanced)	Uniquely linked to signer, identity-verified, tamper-evident	Higher-value EU contracts, regulated sectors	ID Verification, SMS/access-code auth, signer authentication step
QES (Qualified)	EU handwritten-equivalent EU-wide; qualified cert via a QTSP	Where law mandates it (some real-estate, gov, regulated finance)	Qualified signature add-on through a Qualified Trust Service Provider

If the document is genuinely high-stakes or you are unsure whether a tier is legally mandated, escalate to a lawyer and to ../contracts/SKILL.md — you do not give legal advice. Detail and the court-admissibility checklist live in references/legal-tiers.md.