Hey! These docs are for version 1.0, which is no longer officially supported. Click here for the latest version, 3!

Embedded Signing

Embedded Signing will enable your signers to sign documents within your website or mobile apps. You can embed the signing experience in an iFrame or in a pop-up/new tab.

This is a guide on building this embedded signing functionality on your app (web or mobile). You would need a master account that would be initiating signature requests. Instead of the signers receiving signing links in their email inbox, the signing links will be available to you via an API which can then be used to collect signatures from your signers when they are ready to sign.

1. Setup master account and API keys

Create an account you would use to manage all your signature requests. This will be your master account that will hold all of your data and documents. You can create a new account here.

You will then have to generate your API keys using the API Key Generator.


Not for use in production

The keys generated by the API key generator are strictly for development purposes and not intended for use in production. Developer API keys will expire in 30 days.

2. Import the document that needs to be signed

Once you have identified the document that you want to be signed, upload the document using the API key generated in the previous step. The API to be used for uploading/importing a new document is here.

Note the id in the response of the API. This will be your original_file_id of the document you just imported.

3. Create a signature request for that document

Create a signature request (with or without fields), using the original_file_id from Step #2.

Ensure that you set the embedded_signing parameter in the body of the request, to true. This will ensure that your document signers (recipients) do not receive the link to sign the document in their email inbox and instead sign the document on your own application and at the time you choose.

You would have to also add the email address of the signer in the recipients key, as part of the body parameters along with the other required parameters. Even though the signers will not receive any emails, email addresses are still required to generate the audit trail at the end and for regulatory reasons.

Note the id in the response. This will be the pending_file_id of the signature request you just initiated.

Using Templates

Note that you can also initiate a signature request using Templates using this API to start a signature request. Use the same parameters (embedded_signing) as described above, and all the steps remain the same.

No emails or notifications

Using embedded signing means that SignEasy will not contact or reach out to your signers regarding their pending signature requests. Your signers will also not receive any automated reminders/notifications/communication over email or otherwise. You are completely responsible for ensuring that they sign your documents.

4. Get your signers to sign the document

For each signer who needs to now sign on your website, you will first need the signing URL which lets them sign the document. This signing URL can be embedded on your website/app as an iframe or pop-up.

Get the signing URL using this API, using the pending_file_id from Step #3 and email address of the signer who needs to sign.

The URL you receive in the response can now be used to have the document signed by your signers without your application.


Signers need to be logged in or verified!

Ensure that your signers are logged in to their user accounts on your site/app before you let them sign the documents using the signing URL. This is to ensure that the identity of the signers is validated (using your application login) before they sign the document.

This is necessary if you want your signatures to be legally binding.

The audit trails generated will contain information on whether SignEasy has verified the identity of the signers. In case of documents signed via embedded signing, this would be false.

If there is ever a dispute raised by your customers on the veracity or identity of the signing parties, you will be required to provide proof for the same.

5. Be notified of the signing activity

Once the signers have signed the document, you would usually want to be notified so that you can kick off the next step in the workflow or update the status of the document on your dashboard.

You can be notified about document signing activity in a couple of ways - webhooks or redirect URL.

Redirect URL

You can redirect the signer to a URL of your choice once they have finished signing the document so that the control is passed back to you after Step #4.

Once a signer has finished signing, they will be redirected to the URL specified along with pending_file_id of the signature request they just signed. Use this pending file ID to fetch the latest status of the document and show an appropriate message or screen to the signer. The signers are redirected to your URL, even in cases where they decline the signature request.

Redirect URL can be set, when you call the embedded signing link API, using the redirect_url parameter.


Setup a webhook receiver on your backend, and we will ping you whenever there is any activity on your signature requests along with the details of the request. Read about all the different kinds of webhooks and how to use them here.

6. Download the signed document

Once all signers in a signature request have finished signing, you will be able to download the completed document using the signed_file_id and the signed file download API.

You can get the "signed_file_id" either from rs.completed webhook or,

If you are using redirect URL, you can fetch the list of signed documents using this API and look for the signed file whose value of pending_file is the same as the one from Step #5.

You now have the ID of the signed document that was just signed and completed, and you can download it using the same download API as earlier.

What’s Next