Sequential signing

Atlas signs parties one at a time. The first signer gets email when you dispatch. Each subsequent signer receives email only after the prior party completes.

Why sequential

Many contracts require order: employer before employee, company before witness, buyer before seller on separate pages. Sequential signing prevents later parties from signing before earlier obligations are met.

Atlas does not offer simultaneous signing on the same envelope. Every party has an order integer defaulting to 1, 2, 3.

Party states

Status	Meaning
`pending`	Current signer may open the sign page
`waiting`	Not yet their turn
`signed`	Completed

On send, the first signing party is pending. Others are waiting. When party 1 submits, party 2 promotes to pending and gets email.

Sign URLs and tokens

Each party receives a tokenized link:

https://atlaswork.ai/sign/{envelope_id}?t={token}

The token resolves which party is signing and filters fields server-side. Without ?t=, multi-party envelopes may show every field to every signer. Always use buildSignUrl patterns from the API response.

Field visibility

Fields carry party_index from detection clustering, resolved to party_order at read time. Signers only see fields assigned to their party. Manual fields without party assignment may require review-page binding before send.

API parties array

Pass parties at create or send:

{
  "parties": [
    { "email": "alice@company.com", "name": "Alice", "role": "Company", "order": 1 },
    { "email": "bob@client.com", "name": "Bob", "role": "Client", "order": 2 }
  ]
}

Order defaults if omitted. Roles help match detected parties from field clustering.

Polling status

GET /api/envelope/{id}/status returns:

{
  "status": "pending",
  "signed_count": 1,
  "total": 2,
  "next_signer_email": "bob@client.com",
  "sign_url": "https://atlaswork.ai/sign/...?t=..."
}

MCP: check_signing_status returns the same shape.

Reminders

POST /api/envelope/{id}/remind or MCP remind_signer nudges the current pending signer. Does not skip order.

Decline and void

Decline sets envelope-level declined_at. Void sets voided_at. Both stop the chain. Partially signed envelopes retain completed party artifacts.

Credits

One credit per envelope send, regardless of party count. Resends do not re-charge.

Platform and MCP

Sequential rules apply identically on REST, MCP, and dashboard sends. Platform connected accounts share the same party model.