Sequential signing

---

title: Sequential signing

description: Run ordered multi-party signing with Atlas. Party two waits until party one finishes, tokenized sign URLs, and status polling for your backend.

date: 2026-06-04

updated: 2026-06-04

---

Legal reopened ticket 4412 because the candidate signed the offer before the VP approved the compensation page. The envelope had two signers, but both got email at once from your old vendor. Now ops wants signing order enforced in the API, not in a spreadsheet reminder.

Atlas signs parties one at a time on every envelope. The first signer gets email when you dispatch. Each later signer gets email only after the prior party submits. There is no simultaneous signing on the same envelope.

Share: Party one signs first. Party two waits. No shared inbox surprises.

Why order matters

Many contracts require order:

Company before employee on offer letters
Buyer before seller when pages sit on separate signature blocks
Counsel after client on retainer amendments

Sequential signing prevents later parties from signing before earlier obligations are met. Atlas assigns each party an order integer defaulting to 1, 2, 3.

Party states

Each party row moves through three 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. Everyone else is waiting. When party 1 submits, party 2 promotes to pending and gets email automatically.

Your backend can mirror this with GET /api/envelope/{id}/status:

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

MCP tool check_signing_status returns the same shape for agents.

Step-by-step: two-party offer letter

Imagine an offer that goes company first, then candidate.

1. Create with ordered parties

curl -X POST https://atlaswork.ai/api/envelope \
 -H "Authorization: Bearer $ATLAS_API_KEY" \
 -H "Content-Type: application/json" \
 -d '{
 "document_url": "https://hr.example.com/templates/offer-v3.pdf",
 "parties": [
 {"email": "vp@company.com", "name": "Jordan VP", "role": "Company", "order": 1},
 {"email": "candidate@email.com", "name": "Sam Candidate", "role": "Employee", "order": 2}
 ]
 }'

2. Review and send

Open review_url. Confirm fields bind to the right parties. Click Send or call POST /api/envelope/{id}/send with matching parties and fields_version.

3. VP signs

Jordan gets email with a tokenized link. Sam does not get email yet.

4. Candidate signs

After Jordan submits, Sam promotes to pending and receives email.

5. Webhook closes the loop

On envelope.signed, fetch the signed PDF and update your HRIS.

One credit per envelope send, regardless of party count.

Sign URLs and tokens

Each party receives a link like:

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 distribute links from the API response, not a bare /sign/{id} URL.

Field visibility

Fields carry party_index from detection, resolved to party_order at read time. Signers only see fields assigned to their party. Manual fields without party assignment may need rebinding on the review page before send.

When you pass parties[] at create, Atlas matches your signers to detected parties by role or name string. See field detection.

Polling and reminders

Prefer webhooks in production. Poll GET /api/envelope/{id}/status only in dev or when webhook delivery is blocked.

Nudge the current pending signer with POST /api/envelope/{id}/remind or MCP remind_signer. Remind does not skip order or promote a waiting party early.

Decline and void

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

Voiding a pending envelope with zero completed signers refunds one credit on Atlas.

Platform and MCP

Sequential rules apply identically on REST, MCP, and dashboard sends. Platform connected accounts share the same party model. See e-signature API for create and webhook patterns.

Production checklist

Store envelope_id and party order in your HRIS when you create. Support traces stuck chains faster when IDs match your records.

Wire envelope.signed webhooks before you enable auto-create from offer approvals. Poll status only as a fallback.

Remind nudges the current pending party. It never skips ahead to a waiting signer.

Test decline and void paths in staging. Partially signed envelopes keep artifacts for audit even when the chain stops.

API parties array reference

Pass parties at create or send. Order defaults if omitted. Roles help match detected parties from field grouping.

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

Resends on an already-sent envelope do not re-charge credits. Remind only nudges the current pending signer.

FAQ

Does Atlas support parallel signing?

No. Every party on one envelope signs in order.

Can I change order after send?

No. Void and recreate if order was wrong before anyone signed.

How do agents check progress?

Use MCP check_signing_status or poll the status route.

PDF and DOCX?

Both upload formats work on create. Signing always renders PDF.

Run a two-party test with mailboxes you control before you wire HR automation. Order mistakes are cheaper to fix in staging than in a candidate inbox.