6 posts tagged with "webhooks"

Your product has a new flow that ends with a signature: a mandate, an onboarding contract, a consent. Your backend listens to IgniSign webhooks, and a few weeks after launch an auditor asks for the signed file behind one of your records. That is when a small choice in your webhook handler starts to matter: which event did your code treat as "done"? The signature request completing and the proof being ready are two separate events, and they do two different jobs.

You have embedded signing in your product: the signer opens a page in your app, the IgniSign iframe loads inside it, and they sign without leaving. Then two things happen almost at once. The iframe tells your page that the signer is done, and IgniSign sends a webhook to your backend. Both say "signed". The decision for the integrating developer is which of the two signals your product acts on, and for what.

Your product has a new flow: a user signs a mandate inside your app, and the moment the signature is done your backend activates the account, releases the file or moves the deal forward. That moment arrives as a webhook. The decision every integrating developer faces is simple to state: does your handler act on any call that reaches the endpoint, or does it first confirm that the call really came from IgniSign?

Many product flows ask a signer for more than one document at once: an onboarding contract with its data-processing annex, a mandate with a consent form, a set of terms that changed together. With the IgniSign API you can put them all in one signature request. The decision left to the integrating developer is how the signer gets through them: one document at a time, which is now the default for requests with several documents, or every document with a single swipe. This post is about that choice and what it changes in your backend.

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.

When a new flow in your product needs a signature (an onboarding contract, a mandate, a consent), the first technical decision is not the signature level or the document format. It is where the signer will be when they sign. For documents, IgniSign gives you two answers: embedded, where the signing interface runs in an iframe inside your page, and BySide, where the signer opens an IgniSign-hosted signing page from a link. Both start from the same signature request. This post is about picking one.