Three routes to multi-party signing
When a contract needs more than one signature in a specific order (for example: borrower, then co-borrower, then loan officer), you have three common implementation paths.
The first is an enterprise e-signature platform. DocuSign, Adobe Acrobat Sign, and OneSpan Sign all support signing order natively through their envelope APIs. You define each recipient with a routingOrder (or equivalent) integer, and the platform handles notifications, reminders, and the audit trail. These platforms also support conditional routing (skip a signer if a field meets a condition), parallel groups within a sequence, and embedded signing. The tradeoff is pricing: most of them bill per envelope sent (not per envelope completed), and many require paid seats for any user who initiates or approves a workflow.
The second is a developer-first e-signature API. Dropbox Sign, SignNow, and Zoho Sign all expose multi-signer endpoints with a signer order field. Compared to enterprise platforms, they tend to be faster to integrate, with simpler webhook payloads and fewer concepts to learn. The same per-send billing usually applies.
The third is to build the orchestration yourself on top of a more primitive e-signature API. You send the document to signer one, wait for a signature_request.completed webhook, then send a new request to signer two pre-filled with signer one's signature. This gives you the most control but means you own the state machine, retry logic, and audit trail.
How signing order actually works
The mechanics are the same across platforms. Each signer gets an integer order value (1, 2, 3, and so on). Signers with the same value get notified in parallel. Signers with different values get notified in sequence. The platform fires a webhook every time a signer completes or declines, and you key your downstream logic off those events. For compliance use cases (ESIGN, UETA, eIDAS), the audit trail needs to record signer identity, IP, timestamp, and the order of events, so any platform you choose should expose a certificate of completion or signed audit log when the packet finishes.
What to watch for
Three things commonly trip up multi-party signing implementations. First, billing model: a platform that charges per send becomes expensive when many signature packets never get completed, because you pay regardless. Second, signer reminders: not every platform auto-nudges signer two when signer one finishes, so verify whether reminders are automatic, configurable, or off by default. Third, signing-order edits mid-flight: if you need to reassign a signer or change the order after the packet is sent (common in loan origination when a co-borrower is added late), check whether the API supports it without invalidating signatures already collected.
If you want signing-order support without the per-send billing model, Anvil Etch handles sequential signing by default and offers unordered (parallel) signing when you need it, all through one API call to create a packet. Pricing is per completed packet, not per send, so unsigned packets don't cost anything.
Back to All Questions