eSign consent: what signers must see before signing
How electronic signature consent and consumer disclosure work in practice, and how Atlas handles disclosure on every send without skip flags.
Shaan F.
Co-founder & CEO, Atlas
On this page
Consent is the moment a signer agrees to use electronic records and to be bound by their electronic signature. Skip it or bury it in fine print and you risk disputes, not just UX complaints.
Atlas treats consent as part of the signing ceremony, not an admin checkbox you disable to speed up demos.
> Share: "eSign consent is a visible disclosure before signature, not a pre-checked footer link."
What consent covers
Typical consumer disclosures explain:
- The signer agrees to transact electronically
- They can request paper copies where applicable
- They need hardware or software to access records
- How to withdraw consent if the vendor allows it
Exact wording varies by vendor and jurisdiction. Atlas shows a consumer disclosure on the sign page before signers can fill fields. consumer_disclosure is hard-coded to true on create. There is no supported skip_disclosure flag.
Consent vs clicking Send
Two different actors, two different moments:
| Actor | Action | Purpose |
|---|---|---|
| Sender | Review fields, click Send | Confirms document is ready for signers |
| Signer | Read disclosure, sign | Confirms agreement to sign electronically |
The trust ladder applies to senders: review first on new docs. Signers always get disclosure at sign time regardless of auto-send.
Sequential signing and consent
Atlas signs parties one at a time. Each signer completes their own disclosure and field set. Party 2 never sees Party 1's field values on the sign page.
Tokens on sign URLs ensure multi-party envelopes resolve the correct party. Without ?t=, signers could see the wrong field set.
API and embedded flows
If you embed signing in your product, you still route signers through Atlas's sign page (or a supported embed path) where disclosure renders. Do not strip disclosure to match your app's minimal UI unless counsel explicitly approves an alternative flow.
Webhooks fire after consent-backed events: sent, signed, declined, voided.
Recording consent in the audit trail
Signed PDFs include timestamps and signer metadata. Store webhook payloads and envelope IDs in your system of record. When someone asks "did they agree to eSign?", you point to the artifact and event log, not a screenshot of an inbox.
Common mistakes
Pre-checked consent boxes. Regulators and opposing counsel notice.
Reusing one sign link for multiple people. Breaks identity and consent attribution.
Sending before fields are verified. Consent on the wrong document version is worse than slow sends. Use review on first-time doc types.
Auto-send before legal review. Templates and auto_send: true are for shapes counsel already approved, not for skipping sender review on new language.
Atlas-specific behavior
- Disclosure on every signer session
- No client-side bypass in public API
- Decline path available if signer refuses (
POST /api/envelope/{id}/decline)
Developers: see e-signature API for send and status routes. Ops: open a test envelope from signup and walk the sign page once before production.
Embedded and white-label flows
If your product iframe or deep-links the sign page, disclosure still renders before signers can fill fields. Do not hide the disclosure step to match a minimal UI skin unless counsel signs off on an alternative ceremony. Webhooks after sign still fire the same events your archive job expects.
Regulated industry note
Banking, healthcare, and government filings may require disclosures or identity steps beyond a standard consumer disclosure. Atlas shows a general commercial disclosure by default. Work with counsel before you promise a one-size ceremony to enterprise buyers. Default text targets general US commercial use unless you negotiate enterprise branding.
Common mistakes
Teams new to esign consent often send before field detection finishes. Wait until fields_status is ready. If you hit 409, open review_url and check the banner.
Another miss: sharing a bare /sign/{id} link on multi-party deals. Each signer needs their token in the URL so they only see their fields.
Do not store API keys in frontend code or chat bot configs. Create envelopes from a server you control.
Staging checklist
Run one envelope to your own email before production traffic. Confirm webhook delivery, signed PDF download, and credit decrement match what finance expects.
Log create responses in structured JSON. When a signer says "I never got email," envelope ID finds the row faster than subject search.
If you use agents, document three approved prompts: create send, check status, remind signer. Wild prompts in live deal threads cause wrong-party sends.
When Atlas is the wrong tool
Atlas targets builders, agents, and usage-priced sends. If legal mandated DocuSign for every department, keep DocuSign for those flows and use Atlas where code creates the envelope.
If you need clickwrap on a marketing site with no review step, compare specialized clickwrap vendors. Atlas assumes a PDF or DOCX artifact and sequential signing.
Practical tips
Save envelope_id beside your CRM or ticket ID. Use metadata.client_reference_id on create so you can match webhooks back to your records.
Alert on 402 (out of credits) and 409 (fields still processing) in production jobs.
Train support to ask for envelope ID first. Subject lines lie.
Review credit burn monthly if you run seasonal bulk sends.
FAQ
Does Atlas accept PDF and DOCX?
Yes. Upload either format when you create an envelope. DOCX files become PDF before anyone signs.
How do I sign in?
Use a Bearer API key from your dashboard settings. MCP connectors in ChatGPT and Claude use OAuth instead.
When do credits get used?
One credit per send, not per upload. You get five free sends when you sign up.
Where should I start?
/docs and API reference.