When one signature needs to cover several documents at once

Some signing situations genuinely involve more than one document. A new hire might need to sign an employment contract, an NDA, and an equipment agreement all in the same sitting. Treating those as three separate deliveries, three separate emails, three separate signing sessions, doesn't just create friction for the signer, it creates ambiguity about whether the three documents were really meant to be accepted as one connected package or as three independent, unrelated acts.

Signedy's answer was to rework what a "delivery" fundamentally means: instead of one delivery per document, a delivery became an envelope that can bundle several documents, signed together as a single legal transaction.

The relationship had to flip

Originally, a document referenced the delivery it belonged to in a fairly simple, direct way. Moving to multi-document envelopes meant restructuring that relationship: a delivery now owns a collection of documents rather than a document owning a single delivery reference. That's a real schema change, not a cosmetic one, requiring a migration to move existing data into the new shape without losing the history of deliveries that had already happened under the old model.

Getting that migration right mattered more than usual, because Signedy's data includes legally significant records under GDPR. A migration that's careless with historical signing data isn't just a bug, it's a compliance problem.

A change big enough to break the API on purpose

The shift also meant changing what Signedy's API actually expects. Where an endpoint used to accept a single documentId, it now accepts documentIds, plural, because a delivery can genuinely contain more than one. That's a breaking change, not something that could be smoothed over with backward-compatible defaults, since the entire point was that a delivery's relationship to its documents had fundamentally changed shape.

Breaking changes are usually something to avoid. Here, avoiding it would have meant keeping the API's shape tied to an assumption, one document per delivery, that no longer matched what the product actually needed to do. Sometimes the honest move is admitting the old contract can't represent the new reality and shipping the change that reflects it, rather than contorting the new feature to fit inside an interface that was never designed for it.

Coordinated deploy, not a rolling one

Because the signing ceremony, the signing app, and delivery creation all needed to agree on the new envelope model at the same time, this wasn't something that could roll out gradually across services. All the affected pieces had to deploy together, since a partial rollout would mean some parts of the system still expecting the old one-document-per-delivery shape while others had already moved to envelopes, a recipe for exactly the kind of inconsistency the whole redesign was meant to eliminate.

Envelopes are also what made the Flows automation engine able to hand off a whole signed package as one unit once a delivery completes, rather than firing separate automation for each document as if they weren't really part of the same transaction. The two features share the same underlying idea: a set of documents signed together should be treated as one connected thing throughout the system, not stitched together after the fact from parts that never really knew about each other.

More on how deliveries and documents work together is on Signedy's product page.