Legal intake and signing

---

title: Legal intake and signing

description: Wire Atlas signing into legal intake products. Create from matter data, review as compliance gate, sequential signing, and webhooks back to your case system.

date: 2026-06-11

updated: 2026-06-11

---

The intake form captured client details at 9am. By noon the paralegal still had not sent the retainer because someone had to upload PDFs into a separate e-sign dashboard. Your product already owns the matter record. Signing should be one API call and a review link, not a second login.

Legal intake products collect matter details, generate or attach documents, and route them for signature. Atlas fits the signing step when you want API-first create, human review before dispatch, and webhooks back into your case system.

Share: Intake in your app, review before send, webhook when signed.

Typical flow

Intake form captures client and matter data in your app
Your backend renders or fetches a PDF or DOCX
POST /api/envelope creates a draft with detected fields
Paralegal opens review_url, confirms fields, sends
Signers complete sequential signing
Webhook envelope.signed triggers matter update
Optional: contract.extracted delivers structured fields

Atlas does not replace your intake UI. It owns detection, review, send, sign, and signed PDF storage.

Create from intake

curl -X POST https://atlaswork.ai/api/envelope \
 -H "Authorization: Bearer $ATLAS_API_KEY" \
 -H "Content-Type: application/json" \
 -d '{
 "document_url": "https://your-app.com/matters/123/retainer.pdf",
 "parties": [
 { "email": "client@example.com", "name": "Client Name", "role": "Client" }
 ],
 "metadata": {
 "client_reference_id": "matter-123",
 "external_id": "crm-opportunity-456"
 },
 "webhook_url": "https://your-app.com/webhooks/atlas"
 }'

Metadata keys like client_reference_id round-trip for your records. Atlas does not interpret them for routing.

Review as compliance gate

Intake automation should stop at review, not send. Paralegals verify detected fields, party order, and prefill values pulled from CRM. Only then call send or click Send on review.

This matches how legal ops teams think about responsibility: software prepares, humans authorize outbound signature requests.

Platform mode for multi-tenant intake

If each law firm or client org is a tenant, use platform connected accounts:

curl -X POST https://atlaswork.ai/api/envelope \
 -H "Authorization: Bearer $PLATFORM_API_KEY" \
 -H "Atlas-Account: ext_firm_789" \
 -F "file=@engagement.pdf"

Credits and envelope history stay scoped per firm. See platform quickstart.

Sequential signing for client then counsel

Pass ordered parties when both sides sign:

{
 "parties": [
 { "email": "client@example.com", "name": "Client", "order": 1 },
 { "email": "partner@firm.com", "name": "Partner", "order": 2 }
 ]
}

See sequential signing.

Webhooks into matter systems

Verify X-Atlas-Signature on every payload. On envelope.signed, fetch the signed PDF via API and attach to the matter record. On contract.extracted, map structured keys into custom matter fields.

Agent-assisted intake

Some teams let Claude or ChatGPT draft cover emails and prepare envelopes via MCP while intake data still originates in the CRM. Connect MCP with OAuth, use upload session for local PDF or DOCX, and require review before send.

Read MCP electronic signatures and send from Claude.

Compared to bundled intake platforms

Intake platforms that bundle forms, payments, and signing often lock you into one vendor UI. Atlas separates signing as an API with review-first dispatch. You keep intake UX; Atlas handles PDF or DOCX detection, sign pages, audit trail, and signed artifact.

Production checklist

Pass Idempotency-Key on create keyed to matter ID so intake retries do not duplicate envelopes.

Poll fields_status before send. Never auto-send retainer PDFs without paralegal review on first use of a template.

Wire webhooks before production traffic. Treat duplicate delivery as idempotent using envelope_id plus event type.

Train paralegals on review_url first. Auto-send belongs on templates legal already approved, not first-time engagement letters.

Staging checklist

Run one retainer PDF through create, review, send, sign, and webhook in a sandbox matter before you connect production intake forms.

Map client_reference_id to your matter primary key so webhook handlers idempotently attach the signed PDF.

Credits for intake volume

Drafts and field detection are free. Each matter send consumes one credit when email goes out. High-volume intake should batch review so paralegals send many matters in one session rather than one credit per autogenerated draft you never dispatch.

Void refunds one credit on pending envelopes where no signer finished.

Matter metadata you should set

Use metadata.client_reference_id for your matter primary key and metadata.external_id for CRM opportunity IDs. Both round-trip on reads. Atlas does not route on them, but your webhook handler should.

Store review_url on the matter row so paralegals never hunt email for the link.

Add webhook_url in staging first. Production intake should never flip on until HMAC verification passes against test payloads.

FAQ

Does Atlas replace intake software?

No. It replaces the signing step with an API.

PDF and DOCX?

Both supported on create.

Credits?

One per send. Drafts and detection are free.

Compare embed vendors?

See Atlas vs DocuSign and /platforms.

Pilot one matter type end to end before you auto-create envelopes from every intake form submit.