When parallel beats sequential routing

One Inkpacket envelope can collect more than one signature. The mode that invites everyone at once is parallel routing. The mode that invites the current order first is sequential. Parallel beats sequential when waiting is the risk — two partners on the same cover, two managers acknowledging the same policy, a pair who will not finish if either sits behind the other inbox.

The two modes, the waiting page, and the API flags live in sequential vs parallel signing on one envelope. How to add the recipients is send one envelope to multiple signers. Desk help is Docs. This guide is the fork: when parallel is the honest default, and when it is not.

Pick parallel when order does not matter

Parallel routing invites every recipient at once. Each person gets a tokenized URL, completes the fields assigned to them, and submits. The envelope completes when every signer has finished. Nobody sees a waiting page because someone else has not opened mail yet. Reminders and resend can reach everyone who already has a link — which, on parallel, is everyone.

Use it when the PDF is a joint acknowledgment, not a chain of approvals. Two officers. Two founders. A pair of reviewers who must both mark the same file and should not serialize their Tuesday. Assign every required mark to a recipient slot before send. A mark with no assignee is a gap on the filed PDF — assign fields to each signer.

Still one envelope

Up to 20 recipients. One envelope toward the monthly cap. Sequential or parallel does not multiply the count. A decline still closes the whole envelope. If one of two parallel signers refuses, the other link dies too. That is the same rule as a sequential refuse before the next order is invited. Tell both people that up front.

Keep sequential for a countersign

Sequential routing uses an explicit order. Inkpacket emails the current order, then the next after everyone at that order finishes. Recipients who share the same order sign in parallel with each other, then the envelope advances. After send the desk says First signer was invited. A later signer who opens early sees a waiting page and cannot view the PDF until it is their turn.

Keep sequential when the later person should not see the file until the earlier person has accepted — an offer then a countersign, a requester then a controller, members at order 1 then a chair at order 2. Do not pick sequential just because the list looks ranked in a spreadsheet. Rank is not dependency. If both can sign now, parallel is faster and the reminders are honest.

Not a list job

If each person should have their own envelope, that is bulk send, not routing. Map the CSV. Do not add fifty recipients to one envelope and hope parallel feels like a campaign. Bulk send CSV column mapping is that path. A Web Form fill still creates one envelope for the person who submitted the slug — not a second signer on the same envelope.

After you choose

Reminders and resend only email people who have already been invited. On sequential, a later order does not get a nudge about a link they cannot use yet. Expiration still applies to the envelope as a whole. Void stops every signing and embed link. Correct updates an outstanding signer’s name, email, or phone. Text-message (SMS) reminders are coming soon, and reminders go out by email today. Inkpacket does not text a signing link. The desk still shows the URL.

Embed uses the same token. A later sequential signer framed too early will see the waiting page inside the iframe. Parallel embeds can all be live on day one. Embed signing versus a signing link is that split. If the deal is off, void the envelope. Do not wait for the last parallel signer to decline.

The same fork on send

POST /api/v1/packets/:id/send accepts recipients and routingMode (SEQUENTIAL or PARALLEL). A single name and email still works. Create-from-template first so the marks already have recipient slots. Send an Idempotency-Key if the worker may retry — that header is a client retry, not a second envelope.

Caps and what is not open yet

One multi-signer envelope is one envelope. Free allows 5 packets a month. Free at 5 packets a month is the live cap desk send, bulk rows, Web Form fills, and API send share. Hitting it returns HTTP 402 ENVELOPE_LIMIT. Starter is 20 envelopes — more than Free — plus 3 published Web Forms. Seat counts are planning numbers; invite does not refuse when a workspace is full.

Billing is published, not charging. Checkout is not open. Text-message (SMS) is coming soon. Drive missing: Drive not configured. Stripe off: Payments not live. Routing still runs. The FAQ and signing link on Features describe the same two modes.

Pick parallel when nobody should wait. Pick sequential when the later person must not see the file yet. Stay on one envelope id. Then file the stamped PDF when everyone has finished. Open a workspace on Free — see published pricing — and send one two-signer parallel envelope today so the invite copy is familiar before a real countersign.