7 posts tagged with "embed"

Your product embeds a signature step, and your backend waits for IgniSign's webhook to move the flow forward. Then a deploy goes wrong, or a TLS certificate expires on your server, and the endpoint answers with errors for twenty minutes. Users kept signing during that window. The question for the integrating developer is simple: how does your backend catch up on the events it missed? There are two answers, and they do different jobs.

Your product has a new flow that ends with a signature: a contract attached to a deal, a mandate attached to an account, a consent attached to an onboarding. On your side, that document belongs to a record in your database. On the IgniSign side, it belongs to a signature request. Every webhook that reaches your backend names the signature request, so before your handler can do anything useful it has to answer one question: which of my records is this about? You can answer it with the IgniSign id or with your own.

Your product already has users. The first time one of them signs inside your app, IgniSign needs a signer: a record with a name, an email and whatever else the signer profile asks for. The second time the same user signs, you face a small decision that shapes your integration: do you point the new signature request at the signer you already have, or describe the person again on the new request?

When you add a signature step inside your product, the first technical choice is not the UI mode. It is what you put in the signature request. Your app may already hold a PDF contract, an office file, a JSON or XML record, or a document you prefer not to upload. IgniSign accepts those shapes. The integrating developer’s decision is which payload matches the object your product already owns — and what proof you expect back.

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.

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 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.