SOAP API is deprecated
Please note that we announced deprecation of the SOAP API already a while ago in the product release notes. This documentation is therefore marked as DEPRECATED.
See Api Reference - Introduction REST for the REST API reference which should be considered as the successor of the SOAP API.
Repeating here also how SOAP discontinuation was published in the release notes:
We declared SOAP as deprecated and therefore SOAP will not be included in versions after 21.76 (already postponed by one year, initially the 20.76 was announced). Latest release including SOAP API for eSAW will be 21.76, released in spring 2022 and with the software maintenance on 21.76 until spring 2024.
Therefore, we recommend REST technology for integration. Please see also the migration guide.
The Api Reference Guide explains the basic about the SOAP API. On this page you can find information about the authorization, envelope callbacks and errors. Moreover, you can find the documentation about the following two eSAW SOAP API: eSAW API description and eSAW UserManagement API description.
Your eSignAnyWhere benefits
On this page you will find the eSAW API description and the eSAW UserManagement API description. Morverover we start with a basic overview of the API.
Before you use the API Reference, we recommend you to read the API Documentation, to get an overview about our programming interface, data types and basic concepts. If you are looking for examples, we recommend the Hello World Tutorial, the SoapUI Sample, Postman Sample and our Stories and Examples (with all XML calls).
- The API can be used using SOAP and JSON/REST
- SOAP: All complex types are passed as an XML string
- SOAP: The API does NOT use SoapFaults / Exceptions, instead the result contains information if the request was successful or not
- Authorization is required (Application Key)
- SOAP: All method results have the same basic scheme:
SOAP calls with XML / REST with JSON
SOAP uses XML, which have to be encoded via HTML special charaters (“<” in “&lt;” and “>” in “&gt;”). Higher programming languages takes automatically care of the conversion, so just in lower languages it is required (or also SoapUI). If this encoding is not done you will receive a HTTP 400 Bad Request error.
For authentication, you’ll need an api token. You can find this information in Settings / Api Tokens and Apps. Note that all API methods require authentication. Start with the Hello World, SoapUI Tutorial or REST tutorial using Postman (REST) and you might have a look in the envelope XML guide. Please note, that the email is automatically the user, who sends the envelope.
This section covers a SOAP-integration. The REST/JSON API is similar and you might have a look into Swagger and the Postman Sample. As written in the API Documentation, you have to access API calls with an authorization information. The following code shows a api token authorization.
<authorization> <apiToken >hizit4enf8ellb6b5h12345bgt8mzf1abcedf27jys91hetvesabcd9fdb312348bk</apiToken > </authorization>
The API token is a user specific secret which should not be shared with other users. We recommend to create different API keys for different application integrations, to avoid configuring the same key in various integration systems. This allows, e.g. in case of sharing a key by mistake, to disable one key while keeping other integrations working with their existing configuration. Note that the Authorization XML is passed on as string parameter, not as directly embedded XML – so encode the the < with < and > with > when directly testing e.g. in a SOAP test environment (no extra encoding required when your SOAP library encodes the parameters automatically, e.g. in .NET or Java)
You can also authorize with the organizationKey and the userLoginName. Please see the following configuration:
Note: The organizationKey can also be found in Settings / Api Tokens and Apps
The API allows the definition of several callbacks.
Please note, that only the envelope callback (directly from eSignAnyWhere) is fired, when the envelope is in a final state. The status update callback is fired by a sub-component and you may require to wait a post-processing time that the envelope reaches its final state.
Note: Please send back the HTTP 200 immediately! If you are not returning the HTTP 200 immediately, eSignAnyWhere tries to recall the URL.
Attention: After some attempts the envelope will not be finished!
Please note the following information which applies to all callbacks:
Consider, that our system expects the full callback url, including the parameter list you expect, with the placeholders that should be replaced by values at runtime. You can also add your own paramter for that envelope (e.g. internal references). Moreover, on our shared SaaS and private SaaS environments only HTTPS (default port 443) callbacks are allowed.
This is the basic callback (<CallbackUrl />), which is fired if the envelope reaches a final state (completed, rejected). If you integrate eSAW, please have a look at the Envelope Status Callback (directly below documented), because it might deliver more details about the envelope and might so be more useful for integrating.
- envelopeFinished : when an envelope was finished (completed or rejected)
Envelope Status Callback
Envelopes status callbacks (<statusUpdateCallbackUrl />) are fired, based on envelope events/actions. There are also detailed callbacks available based on events (see this guide).
Placehoder for callback URL:
- workstepFinished : when the workstep was finished
- workstepRejected : when the workstep was rejected
- workstepDelegated : whe the workstep was delegated
- workstepOpened : when the workstep was opened
- sendSignNotification : when the sign notification was sent
- envelopeExpired : when the envelope was expired
- workstepDelegatedSenderActionRequired : when an action from the sender is required because of the delegation
Sample with custom parameter “internalid“:
Draft callbacks are fired, if a draft is used or deleted. The draft callback is set in the DraftOptionsXML (<AfterSendCallbackUrl />) via CreateDraft_v1.
The SOAP response is a XML datastructure with the state of the response and the response itself. In
baseResult you see the state of the call (ok/failed) and in
okInfo the response of your request. In case of an error a helpful message is in the
errorInfo. A list of error codes is also available.
In general, our SOAP endpoint return a HTTP success (HTTP/200) even in case of errors, when your call reached the server. The response then has baseResult false, and contains an errorInfo with error (the error code) and errorMsg (human readable error information).
Some reasons for errors:
- ERR0008: File ‘<file id>’ is missing
- ERR0009: Authorization of user ‘…’ failed
- ERR0011: Parameter envelopeDescriptionXml is incorrect
- ERR0013: Action on envelope ‘…’ is not allowed for envelope state ‘Expired’; You cannot download an expired envelope. Check if you use a wrong envelope id, or if the envelope lifetime was too short.
- ERR0014: User ‘…’ is not allow to perform this action: Document count of organization with id ‘…’ exceeded: XX used Documents / 1 to be added / XX Limit. Check if you should upgrade your license, or if you already got a new license voucher which you didn’t issue yet. Check if you are still using the Evaluation License. You get an HTTP/1.1 400 Bad Request when your call does not reach the SOAP endpoint. Most common reasons therefore:
- The string parameters, which contain xml code, did not encode the < to < and so your SOAP request is invalid (e.g. the authorizationXML)
eSAW API description for SOAP
Methods for sending an envelope or to create a draft of an envelope
An envelope can consist of multiple documents and can contain multiple recipients for signing (steps). Your backend application will provide the documents for the envelope and the configuration of the workflow and worksteps. Once the envelope has been completed or rejected, your backend will be notified from eSignAnyWhere about this (callback). Therefore you can provide a callback url, so you don’t need to poll the eSAW system.
The pattern for sending an envelope
Upload all documents for this envelope (
Optional: Analyze all documents to get a default configuration. (
Optional: Prepare configuration for every signing step in the envelope, by adjusting the xml accordingly.
Start the workflow of the envelope by providing the general configuration of the envelope and the configuration for every step (
The pattern for creating a draft of an envelope:
Upload all documents for this envelope (
Create the draft by providing the general configuration of the envelope (
You can redirect the user to the designer of eSignAnyWhere to manually position and assign fields for the recipients pf this envelope.
Methods for downloading the documents of an completed envelope
Once you get the notification from eSignAnyWhere that an envelope has been completed, you can download the signed documents and the log of the envelope.
The pattern for downloading documents of an completed envelope
Check the status of that Envelope, to be sure it is completed and not rejected. (
Download all the signed documents and the envelope log. (
Methods for managing an envelope
SendReminders_v1: Send reminders to all recipients that currently can sign the envelope
CancelEnvelope_v1: Cancels the envelope
DeleteEnvelope_v1: Delets an envelope or a draft of an envelope
RestartEnvelope_v1: Restarts an expired envelope
Reference eSAW API
The “cancel” operation is related to the workflow. Cancel means, an already sent signing process will be stopped and canceled. The envelope is not deleted (the same applies for a draft, as it hasn’t been started yet).
For this call you just need the templateId. The response of this call is a new SspFileId and the workstep configuration of the template. Therefore, with this call you get all information (workstep configuration and the document) to send an envelope afterwards.
Creates a draft with the given parameters.
sspFileIds: Reference to files already uploaded to the SSP server e.g. using the uploadTemporarySspFileV1 call
envelopeDescriptionXml: The envelope configuration (<envelope>…</envelope>). In a draft, defining a workstep configuration is not supported.
draftOptionsXml: With the draft options, the redirect url and the callback url can be specified. See also callbacks.
After an envelope has been completed (i.e. all signers signed, and the result was downloaded and stored in any kind of document management system), implementors should take care about deleting the envelope from the SignAnyWhere servers. This should be done as general system cleanup best-practise, and also for security issues (there were links sent to recipients containing the envelope reference, why do you want to keep this links alive when documents were moved to a document management system where you probably have a different permission strategy)
Removes the previously uploaded document (using UploadTemporarySspFile_v1) to the SIGNificant Server Platform again.
The file id has to be retrieved from GetEnvelopeById_v1. Attention: just documents of finished envelopes can be downloaded. The returned file id from the uploading call will cause an error (invalid file id).
Please use the FindEnvelopes_v2 function.
empty, “OnlyIdentifiers”, “Extended”
Important note: searchText should be used with care, because it will cause a high load on the system (string based search).
Sends you back an adhoc workstep configuration for a given document.
Get the status of an envelope by its envelopeId.
The status of an envelope can be:
The status of an recipient can be
This request will return you the current status of your organization’s license. Please note that for on premise the data model is a bit different.
Fastest call to the SignAnyWhere server. Can be used to check if server is reachable, or to check the server version.
Result is an apiResult with baseResult type OK, but without an okInfo element. The server version is an attribute of the response’s document root, as in every SOAP response of the eSignAnyWhere API.
This request doesn’t require an authentication.
This function should be used in combination with the advanced tags in documents. See the Plaeholder Use Case for more information about the tags.
Input: list of files, ad-hoc workstep, additional descriptor
Result: an ad-hoc workstep configuration and list of steps for SendEnvelope_v1 (prefilled).
- upload PDFs UploadTemporarySspFile_v1
- call PrepareSendEnvelopeSteps_v1
- in the prepareSendEnvelopeStepsResult: fill in recipient data (firstname, lastname, email)
- optional: in the prepareSendEnvelopeStepsResult: assign unassigned elements in the “ad hoc” config, set advanced recipient properties, …
- create envelope XML with data from PrepareSendEnvelope_v1
- call SendEnvelope_v1 to send Envelope
You can replace a recipient via API as long as it is not the recipient’s turn. You also can replace the workstep configuration of a recipient, if the envelope was created via API and the recipient is a signer.
You can restart only expired envelopes with this function. Just use the envelope id to restart it.
Send a specific template. Therefore the templateId and the overrideOptionsXML is required.
Creates the Envelope on the server and sends notification mails to the recipients (in default configuration). See Implementation for information how to integrate the envelope worksteps in your environment. For more details of parameter envelopeDescriptionXml see: The Envelope XML
In case you don’t want to wait on the automatic reminders for a recipient, you can manually send the reminder. Just use the envelope-id with this function and it will automatically remind the current recipient about his or her signing task. Please note, that you can only resend reminders every 12 hours (default value), to prevent a spaming of the recipient. This value can be changed on private SaaS or on premise instances.
This call only requires an envelope id to unlock a recipient in a parallel use case. So if a signer has opened his document in the parallel case and didn’t finish it, it can be reverted and the others can open it. It is the same functionality as in the UI to unlock the envelope.
Uploads a file for using with an new envelope. Returns a FileId. The FileId is at least valid for 10 min (time-to-live, actual live time depends on clean up service load). Full HTTP Request: https://www.significant.com/api.asmx?op=UploadTemporarySspFile_v1
The file content itself is Base64 encoded.
Returns a file id which is required for further calls referring to this file. Store the generated file id in your application.
This call uploads a document to the users clipboard. This is also used for the MS Word plugin.
This call only verifies your authentication (email and API-key).
Reference Usermanagement API
Usermanagement API can be used by user managers. It allows you to manage users and teams. It should be also used to populate SAML attributes for the users.
All fields are optional. If they are not set, the original value is being kept. Attention: an empty tag will update the value to empty!
Returns the user information by email.
The call is identical to FindUsers_v1, but the result is a list of users with several details. This list can then be used to to calculate required user settings with regards to authorization.
GetTeam returns as response the same structure as required for SetTeams.
GetTeam returns as response the same structure as required for SetTeams.