Skip to main content

5 posts tagged with "api"

View All Tags

Reuse the signer or create one per request: mapping your users to IgniSign signers

· 4 min read
Julien Jenoudet
CEO of IgniSign

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?

PDF, data, or hash: what your signature request should carry

· 5 min read
Julien Jenoudet
CEO of IgniSign

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.

Development, staging, or production: which environment meters what

· 4 min read
Julien Jenoudet
CEO of IgniSign

You create an IgniSign application once, then you get three environments: development, staging and production, each with its own API keys. The integrating developer’s decision is which of those environments you use for which work, and what that choice costs when a signature request runs. The answer is not “everything is free until production.” It depends on the environment and on what the request does.

Callback or webhook: which signal moves your embedded flow forward

· 4 min read
Julien Jenoudet
CEO of IgniSign

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.

Check the token or trust the call: verifying signature webhooks

· 4 min read
Julien Jenoudet
CEO of IgniSign

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?