GuidesAPIMCP

Legal intake and signing

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.

Typical flow

  1. Intake form captures client and matter data in your app
  2. Your backend renders or fetches a PDF or DOCX
  3. POST /api/envelope creates a draft with detected fields
  4. Paralegal opens review_url, confirms fields, sends
  5. Signers complete sequential signing
  6. Webhook envelope.signed triggers matter update
  7. 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 OpenIntake-style products

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.

Compare embed vendors

Credits

Drafts and detection are free. One credit per send. Void refunds one credit if no signer completed on a pending envelope.