What is eSign? Meaning, use cases, and Atlas fit
Plain-language definition of eSign in product and legal contexts, core workflow parts, and when API-first signing beats inbox-only tools.
Shaan F.
Co-founder & CEO, Atlas
On this page
eSign (short for electronic signature) means agreeing to a document through a digital action instead of pen on paper. The signer might draw a signature, type their name, or click an accept button after reading a disclosure. The platform records identity, timestamp, and document hash so you can prove what was signed later.
People also use eSign as a product category label, the way "CRM" covers Salesforce and HubSpot. DocuSign, Adobe Sign, and Atlas all sit in that bucket. The word describes the outcome (a binding electronic agreement), not one vendor.
> Share: "eSign means signing digitally with a recorded audit trail, not faxing a scan of ink."
eSign meaning in everyday language
In sales and ops conversations, "send this for eSign" usually means email a link, collect signatures in order, and file the PDF. Developers mean REST or MCP: create envelope, poll status, webhook on complete.
Same word, different buyer. This page covers both angles.
What eSign is not
- Not a scanned signature pasted into Word. That is a picture, not a structured signing event.
- Not automatic legal advice. Enforceability depends on jurisdiction, document type, and process. Atlas provides audit data; your counsel decides sufficiency.
- Not blockchain by default. Some vendors market ledger storage. Atlas focuses on signed PDFs, webhooks, and sequential audit metadata without chain hype.
Core parts every eSign product shares
- Document: PDF or convertible format (Atlas accepts PDF and DOCX on upload).
- Fields: Where each party signs, dates, or enters text.
- Routing: Who signs when (Atlas is sequential only).
- Consent: Disclosure before signature.
- Artifact: Final PDF plus event log.
When inbox eSign is enough
If one person sends five NDAs a month from a dashboard and legal already approved a vendor, a seat-based incumbent can be fine. You upload, confirm fields, send.
When API eSign wins
Choose an API-first product when:
- Agents or CI create envelopes without a human in a dashboard
- You bill per client send and seat minimums hurt
- You need review before email on new doc types, auto-send on templates
- Embedded signing in your app matters more than a shared DocuSign login
Atlas charges $1 per envelope after five free sends. Create returns review_url on ad-hoc paths. Templates and auto_send: true skip the manual send when you trust the shape.
Who buys which flavor
Ops and legal often start with a dashboard upload after counsel approves a template. Engineering wires REST or webhooks when signing must happen inside a product flow. Founders using agents connect MCP so Claude prepares the envelope while they keep Send on review for new doc types.
None of these are separate products. They are entry points into the same envelope row and signed PDF artifact. Pick one path first, then add the others when volume justifies it.
Atlas proof block
curl -X POST https://atlaswork.ai/api/envelope \
-H "Authorization: Bearer $ATLAS_API_KEY" \
-H "Content-Type: application/json" \
-d '{"document_url":"https://example.com/nda.pdf"}'
Response includes envelope_id and review_url. Open review, confirm fields, then POST /send.
MCP exposes the same lifecycle inside Claude or ChatGPT. See MCP electronic signatures and /mcp.
Key terms
| Term | Meaning |
|---|---|
| eSignature | Same as eSign; slightly more formal |
| Digital signature | Often implies certificate-based identity (QES) |
| Ink on paper | Traditional signing; opposite of eSign in casual speech |
Common mistakes
Teams new to what is esign 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.