When bulk really makes sense: the repeatability test
Bulk signatures sound like a volume problem but are first a process problem. A company sending two thousand contracts, amendments or confirmations for signature every month does not have too many documents but too many manual steps. Anyone creating each invitation individually in a portal, entering signers by hand and maintaining status in spreadsheets practises portal hopping: constant switching between business system, portal and inbox. A bulk signature API replaces that manual work with a flow the business system itself controls.
Not every transaction suits it. The guiding question: is the process repeatable and rule-based? If documents arise by a fixed pattern, signers come from master data and follow-up steps are clear, automation pays off. Typical examples are contract renewals, price adjustment letters, privacy consents for existing customers, employment contract amendments, supplier agreements, policies and powers of attorney. If every document is negotiated individually, bulk is the wrong approach and a single well-designed flow is better.
The one hard distinction of this article: bulk does not mean “many at once” but “many without manual work”. That difference shapes architecture decisions. What matters is not how many transactions per second are possible but whether creation, dispatch, tracking and completion run without human intervention as long as nothing unusual happens. People handle exceptions, not the normal case.
That is why we deliberately quote no throughput figures. Numbers like “X signatures per minute” sound impressive but are worthless without context: they depend on document size, signature level, identification procedure, your business systems and the time signers need to act. In the bulk case the bottleneck is almost never the API but the person who must sign and your own system processing events. A serious statement on load only emerges from tests with your profile.
The signature level matters too. Bulk scenarios often run with SES or AES because identification per signer limits effort. With QES, identification and partner QTSP are added, which lengthens the process and makes planning of waiting states more important. Sign2x is not a QTSP, QES runs through a partner such as Sign8. An introduction to choosing levels is in AES vs QES via API.
A test for your need: count how many minutes your team spends per transaction on creation and tracking and multiply by the monthly volume. If the result is measured in working days, building a flow almost always pays. If it is a few hours, a simpler path often suffices. The Sign2x quiz can support classifying your situation, and we collect use cases under use cases.
Batch patterns: from list to controllable flow
A robust bulk pattern has four building blocks: source, planner, executor and reporter. The source is your business system supplying documents and signers. The planner divides the quantity into manageable packages, the batches, and determines in which order and at which intervals they are processed. The executor creates transactions through the API, attaches documents and starts dispatch. The reporter receives events and transfers states back into the business system.
Splitting into batches has several reasons. It limits damage on errors: if one document in a package of two hundred is defective, a thousand others should not be stuck. It makes progress visible: you see package three of ten is complete. And it gives you the chance to start carefully: a small pilot package before the rest shows whether texts, templates and recipient data are right. Our recommendation is never to start with the full quantity but with a package you can review calmly.
Every transaction needs a unique reference from your system. This reference ensures a rerun creates no duplicates: before the executor creates a transaction, it checks whether one exists for that reference. This pattern is idempotency, and it is indispensable in the bulk case because runs get interrupted and restarted. Skipping it can mean, in the worst case, sending the same contract twice to the same person.
For dispatch consider load and perception. A thousand invitations in the same minute can look like spam to recipients and trigger filters at mail providers. Spread dispatch sensibly and mind sender configuration and subject lines that fit the occasion. In white-label scenarios sender, texts and brand should match the tenant so the mail is recognised as trustworthy. More on this in white-label signature API without context switching.
Feedback runs through webhooks, not polling. At high volume that is not only more elegant but necessary, because polling a thousand open transactions burdens everyone without gain. Events land in your queue and are translated into states by the reporter. The basics, including idempotency, state machine and dead-letter store, are covered in webhook state management for e-signature events. In the bulk case every rule named there applies more strictly.
For control you need a view of the whole run: how many transactions are created, sent, opened, signed, declined, expired or faulty. That view is not just controlling but an operating instrument. It shows when a reminder makes sense, when a package has conspicuously many declines and when a technical fault exists. Build it early, even as a simple table, because without it you fly blind.
Document generation is part of the pattern too. Documents should be final and checked before dispatch. An automatic pre-check, for example for missing mandatory fields, empty placeholders or implausible amounts, prevents faulty contracts from going out. Recalling a document already sent is possible but unpleasant: recipients are unsettled, and you must document the revocation traceably. Prevention is much cheaper than correction here.
Errors and retries: what goes wrong at volume
With single transactions, errors are exceptions; at volume they are normal. With a thousand transactions you almost certainly meet invalid email addresses, unreadable documents, signers who do not respond and brief disruptions on one of the sides involved. A bulk process must expect this and therefore must not fail as a whole as soon as part of it fails.
The first distinction is between permanent and transient errors. A defective document or syntactically invalid address will fail on the tenth attempt too, while a short network outage or overload will not. Retry transient errors automatically with growing intervals and a cap. Permanent errors go straight to an error list a human reviews, without holding up the rest of the batch. This separation is the most important quality feature of a bulk flow.
The second distinction concerns errors on the signer's side. Unreachable mailboxes, expired invitations, aborted identifications and declines are not technical faults but part of the process. Your system should map them as states, such as “delivery failed” or “signer not responding”, and provide business follow-ups: reminder, alternative contact route, escalation to a contact person. Without modelling this you end up with hundreds of transactions in state “open” without knowing why.
For restart a clear principle helps: every run must be safely repeatable. You achieve that through the references mentioned and a log recording per transaction how far it got. After a crash the run restarts, skips what is finished and continues what is open. Test this case deliberately by interrupting a run on purpose. Many teams discover only in an emergency that their restart creates duplicates.
Rate limits belong here too. Every interface limits requests to protect itself. Your executor should respect these limits instead of testing them and throttle speed on corresponding feedback. That is no weakness but good operating practice. Take exact limits and recommendations from the documentation in the developer hub; we deliberately quote no numbers here that would age and raise false expectations.
For observability we recommend a few key figures: share of completed transactions per package, share declined and expired, size of the error list, time from dispatch to signature. These figures quickly show if something is off, for instance when a package suddenly has many declines because a contract text was unclear. Alerts should fire on deviations from your own baseline, not on invented standard values.
Compliance at volume: evidence, data protection, retention
High volume raises pressure on compliance because errors multiply. Three topics deserve attention. The first is evidence: with a thousand transactions you cannot document each manually. Your event history must therefore be complete and queryable. Each transaction needs a gapless chain of events with time, role and document checksum. How this chain works in the context of supply chain duties is described in DORA Article 30 and the signature audit trail. It is evidence, not certification.
The second topic is data protection. Bulk runs process much personal data at once, and errors have broad effect: one wrong assignment can affect hundreds of people. Before a run check whether the legal basis holds for all recipients, whether data is minimised and whether deletion periods are defined. The GDPR applies regardless of volume, but at scale every carelessness becomes more visible. A four-eyes principle for starting a run is a simple, effective measure.
The third topic is retention. Signed documents and event logs must remain available as long as law and contract require and be deleted when the purpose ceases. At volume you need automated rules for this: retention classes per document type, deletion runs, proof of deletion. Clarify early where signed documents are stored long term, in the business system, in an archive or both, and how you can export them in case of a vendor change.
With regulated customers supply chain requirements are added. If your software is used by financial entities, they ask about location, ownership structure and exit of the signing service. The answers should hold uniformly for all runs and tenants. How to structure such evidence is also shown in NIS-2 evidence through the audit trail. We stress: evidence is not certification, and neither DORA nor NIS-2 knows a seal for signature APIs.
Finally communication: with mass dispatch recipients expect clarity. Who sends the document, why, until when must I act, whom do I contact with questions? Good texts reduce queries and drop-offs considerably. Maintain them centrally, version them and adapt them per tenant. Helpful answers for end users can be bundled in the help centre, which you can reference in the invitation.
Hosting and jurisdiction: a frame for large volumes
Large document volumes raise the importance of where they sit. Sign2x runs on the Open Sovereign Cloud (OSC) from T-Systems, a European operation under European law. For companies processing contracts, HR or customer data in large amounts, that is a clear answer to the question of ownership and access. Background on the legal classification is in Cloud Act vs data sovereignty and the deep dive Open Sovereign Cloud for the e-signature API.
Hosting on OSC is a statement about operations and jurisdiction. It replaces neither your data protection review nor load planning. If you plan very large runs, talk to us beforehand about time windows, package sizes and particularities of your profile instead of trusting blanket statements. We work out an approach with you and say openly where we cannot give guarantees. We prefer that to a promise that does not hold in an emergency.
For companies with rules that exclude even sovereign cloud operation, the option exists to run the flow in your own data centre. Sizing then lies with you, and you plan compute, storage and backup to your needs. With QES the partner QTSP remains part of the chain. Whether this operating mode makes sense for your case we clarify in conversation. For most companies standard operation is the leaner solution.
If you want to know how a bulk flow fits your business system, start with a small pilot: one document type, one package of a few hundred transactions, a clear definition of success. Technical basics are in the developer hub, and the path to the first working flow is described in from sandbox to your first QES path. More articles are in the Sign2x blog.
Talk through your bulk scenario with us
Related articles: silent tech: signature without context switching inside ERP surfaces and QTSP partners for ISVs. Legal basis of the levels in the eIDAS Regulation, security guidance at the BSI.
Frequently asked questions
When is a bulk signature API worthwhile?
When transactions are repeatable and rule-based, such as contract renewals, consents or amendments, and your team spends a lot of time on creation and tracking.
What throughput figures does Sign2x guarantee?
We quote no blanket throughput figures. They depend on document size, signature level, identification and your business systems. Reliable statements come from tests with your profile.
How do I avoid duplicates on reruns?
Give each transaction a unique reference from your system and check before creation whether a transaction already exists for it. A per-transaction log enables safe restart.
Where is Sign2x hosted?
On the Open Sovereign Cloud (OSC) from T-Systems. For special requirements, operation in your own data centre is possible case by case.
Does bulk also support QES?
In principle yes. With QES, identification and partner QTSP are added, which lengthens processes. Sign2x is not a QTSP, the qualification runs through a partner such as Sign8.
