Copy or reference: where your product keeps the signature proof

When a signature request completes, your product has a new thing to look after: the proof. One day an auditor, a customer or your own support team will ask for it, often months after the signer finished. So the integrating developer has to decide early how the backend treats that proof: copy it into your own storage as soon as the signature is done, or keep a reference and fetch it from IgniSign when someone asks. This post is about that choice.

What the proof is, in practice

For each signed document, IgniSign produces:

• a signed PDF with a signature page that summarises who signed and references the document;
• a proof web page, linked from a QR code on that signature page;
• depending on your configuration, a kit with the signature files and the audit log.

Your backend retrieves these through the API, per document, once the signature request is complete. The webhook tells your backend when that moment has come.

Option 1: copy on completion

Your webhook handler receives the completion event, checks the verification token that comes with the delivery, and queues a job. The job downloads the signed PDF (and the kit, if you use it) and writes it to your own storage, next to the record it belongs to: the contract, the mandate, the onboarding file.

Choose copy when:

• The signed document is part of your product's data. Users download it from your interface, and you want that page to work from your own storage.
• Your own records policy decides how long the document is kept, independently of any supplier.
• Your auditor wants every artefact in one place, under your access controls.

What it costs you: storage, a background job, and one more thing to back up. The download job also has to be dependable. Make it idempotent and key it on the document ID, so a second delivery of the same event does not create a second copy. If your endpoint was down when the event was sent, the webhook event log shows it and lets you resend it manually.

Option 2: reference and fetch on demand

Your backend stores identifiers only: the signature request ID and the document IDs. When someone needs the proof, you call the API with the document ID and stream the file to them.

Choose reference when:

• Proofs are rarely opened. Most signatures in your flow are a gate, not a document users come back to.
• You do not want signed files in your own storage yet, or you are still deciding where they should live.
• You want a first version live with the smallest possible backend.

What it costs you: every access depends on an API call at the moment someone asks, so your support flow depends on that call. Your records also depend on the file still being held at IgniSign when you need it, so compare that with how long your own policy says you must keep it.

A combination that works

The two options are not exclusive. A pattern that holds up well:

1. On the completion webhook, store the signature request ID and the document IDs on your own record. This is cheap and immediate.
2. Queue a copy of the signed PDF for the flows where users or auditors will want the file: contracts, mandates, anything a customer may ask for later.
3. Keep the other flows as references, and fetch on demand.

Write down which flows fall into which group. That short list is what you show an auditor who asks how your product handles proof.

Habits that apply either way

• Let the webhook trigger the proof work, not the browser. A signer can close the tab one second after signing; your backend still learns the outcome.
• Key everything on IgniSign IDs, so you can always go back to the source.
• Run the whole loop (signature request, signature, webhook, proof download) in your development environment before you use production keys.
• Remember the proof web page. Even if you copy the files, the page behind the QR code is often the simplest thing to point an outside party to.

A two-question test

1. Will a user or an auditor ask your product for the signed file later? Copy it on completion.
2. Is the signature a gate in the flow, rarely revisited? Store the reference and fetch on demand.

If you are unsure, store references from day one and add the copy job for the flows that need it. The webhook handler you write first does not change; you add one step after it.