We publish everything related to our API on github at this location: https://github.com/eZmaxinc. You'll find git repos for the specification, documentation, SDKs and samples.

Documentation, SDKs and samples are provided in english only for easier maintenance, but we also have french speaking integrators that can help you out.

Most of our SDKs provide language specific documentation, but you'll find more details on this page about the general use of the API. Both the SDK's specific document (if you choose to use a SDK) and this documentation can be used in complementarity.

If you find any mistake or omission in the documentation, please notify us. We'll quickly fix the issue.

We highly recommend to schedule an online meeting with your technical team and an eZmax integrator. During this meeting, we go through requirements, business logic, configuration, api key generation, and we go through the list of functions you might need to implement to achieve your goals. Make sure you take this opportunity to speed up your integration project.

If you need help understanding how to use this API, don't waste too much time searching in it. Contact support-api@ezmax.ca, we're here to help. We are developpers so we know programmers don't like to waste time in documentation. If you don't find what you need in the documentation, let us know, we'll improve it and put you rapidly up on track.

We highly believe in open standards and open source. We have adopted the Open API vision where all of the functionnalities of our applications are accessible with open source definition files. We use our own public API's to build our interfaces so you can do pretty much everything we can do. Open API has a rich toolset from editor, generators, mock servers, validators, etc. Learn more at OpenAPI Initiative

If you need our Open API Spec file to use in your toolset, here is a direct link to it: ezmax.v1.0.json

We provide SDKs for customers. They are generated using OpenAPI Generator, we encourage customers to use them as we also provide samples for them. You can choose to build your own implementation manually or can use any compatible OpenAPI 3.0 generator like OpenAPI Generator, Swagger Codegen or any commercial generators.

We try to make it as easy as possible for you to use our SDKs so we publish packages on NPM and Composer. If you don't find your favorite language supported or it we could make your like easier by automating package distribution, let us know !

When you send your API requests, you'll need to send them in the proper region and proper environment where your customer data are stored. Based on your requirements (proximity and legislation), we will create your environment in one of our supported region's.

The general format of the URL where to send requests is: https://{sInfrastructureenvironmenttypeDescription}.api.appcluster01.sInfrastructureregionCode}.ezmax.com/rest/

Where "{sInfrastructureenvironmenttypeDescription}" and "{sInfrastructureregionCode}" need to be replaced with one of the values in the table below.

Our SDKs have a default value of "prod" and "ca-central-1". You will need to call "setHost" to change the default value if needed.

Note: You should always use "prod" for the environment unless otherwise instructed by eZmax's support.

sInfrastructureenvironmenttypeDescription	Description
prod	Production
stg	Staging
qa	Quality Assurance
dev	Development

sInfrastructureregionCode	Description
af-south-1	Africa (Cape Town)
ap-east-1	Asia Pacific (Hong Kong)
ap-northeast-1	Asia Pacific (Tokyo)
ap-northeast-2	Asia Pacific (Seoul)
ap-northeast-3	Asia Pacific (Osaka-Local)
ap-south-1	Asia Pacific (Mumbai)
ap-southeast-1	Asia Pacific (Singapore)
ap-southeast-2	Asia Pacific (Sydney)
ca-central-1	Canada (Central)
eu-central-1	Europe (Frankfurt)
eu-north-1	Europe (Stockholm)
eu-south-1	Europe (Milan)
eu-west-1	Europe (Ireland)
eu-west-2	Europe (London)
eu-west-3	Europe (Paris)
sa-east-1	South America (São Paulo)
us-east-1	US East (N. Virginia)
us-east-2	US East (Ohio)
us-west-1	US West (N. California)
us-west-2	US West (Oregon)

Some of the functions needs to be called on the global infrastructure instead of the regional servers. These functions are all located in the Global section of the documentation.

The general format of the URL where to send requests is: https://{sInfrastructureenvironmenttypeDescription}.api.global.ezmax.com/

Where "{sInfrastructureenvironmenttypeDescription}" needs to be replaced with one of the values in the table below.

Our SDKs have a default value of "prod". You will need to call "setHost" to change the default value if needed.

Note: You should always use "prod" for the environment unless otherwise instructed by eZmax's support.

sInfrastructureenvironmenttypeDescription	Description
prod	Production
stg	Staging
qa	Quality Assurance
dev	Development

Except for a few functions that do not require authorization, most of the functions require an API key that is sent in the request headers. The header name is "Authorization".

There are 4 types of API Key that can be used to make requests to the API.

1. API type key which is static and not session based. It can be generated from the admin console. This is the most common type of authentication for "server to server" kind of integration. Never use this in a web based (client) application as the key could be leaked. This type of key begins with the letter A.

2. Delegated type key which has an expiration time. It is commonly used in mobile or web application where you cannot use an API type key that could be leaked. The application would query a server part that will generate a Delegated type key using an API type key. The Delegated type key could now be used by the mobile or web page application without leaking the API type key. This type of key begins with the letter D.

3. User type key which are session based and can be retrieved after a successful authentication. This type of key is reserved to specific situations where the other types of key are not desirable. This type of key begins with the letter U.

4. Special type key which are for special cases where other types of keys cannot be used. This type of key is reserved to specific situations. This type of key begins with the letter S.

Each API key can be restricted to specific IP addresse(s). This is an optional but recommended security feature you should put in place if all your requests will be coming from a specific range. You can configure the allowed ranges from the eZmax administration console.

Each API Key can be configured to have specific permission(s) so we highly recommend to use the "Least privileges" principle. For example, instead of allowing all permissions to an API Key, you should perhaps create an API Keys each for each of your application having just the specific permissions needed. You can configure the API Key's permission in eZmax's administration console.

Request Signing is a process of signing the request with a Secret that is not transmitted over the Wire. The signing process improves security in case your API Key is leaked or during a MITM attack (Man in the Middle). It will also prevent request manipulation or replay attack. Since all requests must use https these kinds of attacks are hard to conduct but sometimes customers might not be aware their underlying library does not verify SSL Certs validity or that their application can disclose their API key if it's not well secured. It takes a bit of effort to sign requests but it's highly recommended to do so.

Mandatory requirements of signing varies by used key type. For API type keys (most common type), you can configure if signing is mandatory or not in eZmax's administration console. Delegated, User and Special type keys must sign requests otherwise requests will fail.

How to sign a request

To apply a signature to your request you will need to send 3 additional HTTP Headers to the request:

• Ezmax-Date
• Ezmax-Fingerprint
• Ezmax-Signature

Ezmax-Date

Ezmax-Date Is the date/time when you send the request. It needs to be a ISO 8601 formatted date/time. It's a format that supports timezones so you can either use your local timezone of GMT. Be aware certain implementation adds milliseconds to the formatted date which won't be accepted by the API (ex: Javascript's toISOString function).

There is a tolerance of ±5 minutes clock skew between the date/time you specify and the server's time so make sure your time is correct. Usage of a NTP server is recommended. Compute the date/time as close as possible to the actual sending of the request. For example, don't set the current time at the beginning of a long running script that sends 50 requests to the server with the same time/date as you might receive errors related to clock skew.

Examples:

• 2000-12-31T23:59:59Z
• 2000-12-31T23:59:59-05:00

Ezmax-Fingerprint

Ezmax-Fingerprint Is a fingerprint (aka hash) representing the request you are sending. Any alteration in any part of the request would produce a different fingerprint. The hash is computed using SHA256. Most programming languages offer an implementation of SHA256. To make sure your implementation is producing expected values, try to hash the value "foo", it should produce the value "2c26b46b68ffc68ff99b453c1d30413413422d706483bfa0f98a5e886266e7ae".

To compute the Fingerprint, you'll need to concatenate the Method, the URL, the Body, the API Key and the Date. All these values will need to be separated by a line Feed caracter (\n). Make sure your Method is Uppercase (Shoud be "GET", not "Get" or "get"). Make sure your URL Scheme and Host or the URL are lowercase (Should be "https://www.example.com", not "HTTPS://WWW.EXAMPLE.COM"). Also make sure the the URI part of the URL is properly URL encoded (Should be "/Path%20with%20Spaces/?Key=Value%20with%20Spaces", not "/Path with Spaces/?Key=Value with Spaces". If the Body is empty (ex: GET request don't have a body), use an empty string.

Once the SHA256 hash is computed, prefix it with "v1=" which is future proofing version identifier.

Here is an example implementation in PHP:

public static function getFingerprintV1 ($sAuthorization, $dtDate, $sMethod, $sURL, $sBody = '') {
    $sContentToHash = "$sMethod\n$sURL\n$sBody\n$sAuthorization\n$dtDate";
    return 'v1='.hash('sha256', $sContentToHash);
}

Here are two examples of what a GET and POST requests Fingerprints could look like. You can validate if your algorithm work by using these sample values and comparing them to the expected values. In the example below the litteral "\n" should be replaced with a linefeed character.

GET\n
https://prod.api.appcluster01.ca-central-1.ezmax.com/rest/1/object/activesession/getCurrent\n
\n
ThisIsMyAuthorizationKey\n
2000-12-31T23:59:59Z

Expected result for Ezmax-Fingerprint (GET): v1=8f6f3ed75edb6e2cbe777b4fda5cab1a6adaebadc758780eb82c3d49934f354a

POST\n
https://prod.api.global.ezmax.com/1/module/sspr/sendUsernames\n
{"pksCustomerCode": "demo","fkiLanguageID": "2","eUserTypeSSPR": "Native","sEmailAddress": "example@domain.com"}\n
ThisIsMyAuthorizationKey\n
2000-12-31T23:59:59Z

Expected result for Ezmax-Fingerprint (POST): v1=6dbdbc26437f1216f9cd0068a4fc35c272a062b1f638c7557d497ebbf3702ded

Ezmax-Signature

Ezmax-Signature Is the actual signature proving the request was generated by the key owner using its secret. The signature is computed using HMAC and SHA256. Don't confuse SHA256 (aka SHA2-256) and SHA3-256, these are 2 distinct algorithms. Most programming languages offer an implementation of HMAC with SHA256. To make sure your implementation is producing expected values, try to hash the value "foo" with the key "bar", it should produce the value "147933218aaabc0b8b10a2b3a5c34684c8d94341bcf10a4736dc7270f7741851".

To compute the Signature, you'll need to concatenate the Ezmax-Fingerprint, the API Key and the Ezmax-Date. The 3 values are concatenated WITHOUT separators. Then calculate the HMAC using SHA256 using your Secret as the key.

Once the HMAC-SHA256 hash is computed, prefix it with "v1=" which is future proofing version identifier.

Here is an example implementation in PHP:

public static function getSignatureV1 ($sAuthorization, $dtDate, $sFingerprint, $sSecret) {
    $sContentToSign = "$sFingerprint$sAuthorization$dtDate";
    return 'v1='.hash_hmac('sha256', $sContentToSign, $sSecret);
}

Here are two examples of what the GET and POST requests Signature would be. You can validate if your algorithm work by using these sample values and comparing them to the expected values. For the below examples, we have used the same API Key, Fingerprint and Date as in the Fingerprint section above. The only new variable is the Secret which is "ThisIsTheSecretAssociatedToTheAuthorizationKey" for this example.

v1=8f6f3ed75edb6e2cbe777b4fda5cab1a6adaebadc758780eb82c3d49934f354aThisIsMyAuthorizationKey2000-12-31T23:59:59Z

Expected result for Ezmax-Signature (GET): v1=3a95fde64d27527745bcb0dd91be8caf7917c6778197e22d1d56c87245f979f5

v1=6dbdbc26437f1216f9cd0068a4fc35c272a062b1f638c7557d497ebbf3702dedThisIsMyAuthorizationKey2000-12-31T23:59:59Z

Expected result for Ezmax-Signature (POST): v1=71e05f01eaab704ec76a078a9a5c49abe9d5a490786e43b86156d281acda7cba

Wrapping up the examples

The whole process was detailed above but here is summary of what your http headers should look like to sign these example requests considering the following common variables:

Variable	Example value
Date	2000-12-31T23:59:59Z
Authorization	ThisIsMyAuthorizationKey
Secret	ThisIsTheSecretAssociatedToTheAuthorizationKey

For a GET request to https://prod.api.appcluster01.ca-central-1.ezmax.com/rest/1/object/activesession/getCurrent:

Authorization: ThisIsMyAuthorizationKey
Ezmax-Date: 2000-12-31T23:59:59Z
Ezmax-Fingerprint: v1=8f6f3ed75edb6e2cbe777b4fda5cab1a6adaebadc758780eb82c3d49934f354a
Ezmax-Signature: v1=3a95fde64d27527745bcb0dd91be8caf7917c6778197e22d1d56c87245f979f5

For a POST request to https://prod.api.global.ezmax.com/1/module/sspr/sendUsernames with this body content = '{"pksCustomerCode": "demo","fkiLanguageID": "2","eUserTypeSSPR": "Native","sEmailAddress": "example@domain.com"}' :

Authorization: ThisIsMyAuthorizationKey
Ezmax-Date: 2000-12-31T23:59:59Z
Ezmax-Fingerprint: v1=6dbdbc26437f1216f9cd0068a4fc35c272a062b1f638c7557d497ebbf3702ded
Ezmax-Signature: v1=71e05f01eaab704ec76a078a9a5c49abe9d5a490786e43b86156d281acda7cba

We use standard HTTP Status Codes to return details about completed function calls.

You should always validate the HTTP response's status code before trying to read the content of the body. Our SDKs do this automatically. In each of the documented function, we document only the function's specific return code to facilitate the reading of the documentation. Even if a generic return code is not documented at the function's level, it could be returned by the API.

Generic return codes (Documented at the function's level)

HTTP Status Code	Meaning	Detail
200	OK	The request completed successfully and valid data was returned in the body
201	Created	The request completed successfully. Some elements were created and details about the created items was returned in the body
204	No Content	The request completed successfully. There was no need to return any data in the body
403	Forbidden	The request is not allowed to be executed. Look for detail about the error in the body
404	Not Found	The request failed. The element on which you were trying to work does not exists. Look for detail about the error in the body
422	Unprocessable entity	The request was syntactically valid but failed because of an interdependance condition. Look for detail about the error in the body

Generic return codes (Undocumented at the function's level)

HTTP Status Code	Meaning	Detail
400	Bad Request	The request does not meet specifications. For example: an invalid type for a variable, a value that does not pass validation or a protocol violation. Look for details about the error in the response's body
401	Unauthorized	The API Key is either not present, expired, invalid or inactive. It could also mean you are calling the API from an unauthorized IP address
403	Forbidden	The Provided API Key is valid, but it is not allowed to execute the request. Verify the Key's permissions
404	Not Found	Your request was sent to a URL that does not exist. Make sure you are calling the proper version number of the function and look for typos in the URL
405	Method Not Allowed	The URL is valid, but the Method is not allowed. For example, have you call a GET while the function expects a POST ?
429	Too Many Requests	Too many requests were received from your API Key/IP address. Make sure to optimize your requests or ask for a limit increase. For example, make a single request to create 100 objects instead of calling 100 requests each creating a single objet
500	Internal Server Error	This should never happen. There is either a temporary problem that should resolve quickly or an error you should report to technical support.
503	Service Unavailable	This should never happen. There is either a temporary problem that should resolve quickly or an error you should report to technical support

Custom return codes (Undocumented at the function's level)

These codes can only be generated for User type API Key. The API, Delegated and Special types keys will never return such codes. (See Authorization section for more information). Most users should not be concerned with these status codes.

HTTP Status Code	Meaning	Detail
350	Authentication required	User must authenticate because session is invalid
351	Phone Validation required	(2FA) User needs to complete a Voice Call or SMS challenge
352	Question Validation required	(2FA) User needs to complete a question/answer challenge
353	Clause Acceptance required	User need to accept electronic signature terms and conditions
354	Computer Validation required	User's computer is not authorized
355	Password Change required	User must change it's password
356	Native Application Version Check	The user is not running the latest version of the native application

Webhook delivery successful code

These codes will be considered as a succesful delivery when they are returned by your webpage during a Webhook delivery.

HTTP Status Code	Meaning	Detail
202	Accepted	The request has been received but not yet acted upon. It is intended for cases where another process or server handles the request, or for batch processing.
204	No Content	The request completed successfully. There was no need to return any data in the body

When the API returns an HTTP status code in the range 400-599, a JSON object will be returned with 2 properties:

• eErrorCode
• sErrorMessage

We highly suggest you use eErrorCode to do any error validation logic in your code or to create your own error message for your users. sErrorMessage has more detail for a human to read, but is intended for the developper and is always returned in english.

Here is the complete list of eErrorCode you could receive for each HTTP status code and examples of situations where they could be returned.

HTTP 400 (Bad Request)

eErrorCode	Examples
BADREQUEST	Unserializable JSON, invalid parameter, invalid signature, invalid fingerprint
BADREQUEST_CLOCKSKEW	The time on the client computer is wrong

HTTP 401 (Unauthorized)

eErrorCode	Examples
UNAUTHORIZED_BADAUTH	Invalid credentials during Authentication
UNAUTHORIZED_REQUEST	The request is invalid (bad ip source, signature, invalid api key)

HTTP 403 (Forbidden)

eErrorCode	Examples
FORBIDDEN	Generic Forbidden
FORBIDDEN_CONFIGURATION	A configured setting prevent access to the element
FORBIDDEN_MODULE	Module is not activated
FORBIDDEN_NOACCESS	Not allowed to access the element
FORBIDDEN_PERMISSION	Missing a permission to access the route
FORBIDDEN_SUBSCRIPTION	No subscription, for example to eZsign

HTTP 404 (Not Found)

eErrorCode	Examples
NOTFOUND	Generic not found
NOTFOUND_OBJECT	Object does not exist in database
NOTFOUND_ROUTE	The route does not exist (url, API version)

HTTP 405 (Method Not Allowed)

eErrorCode	Examples
METHODNOTALLOWED	The route is valid but the method is not allowed ex: POST on a GET only route

HTTP 422 (Unprocessable entity)

eErrorCode	Examples
UNPROCESSABLEENTITY_CANNOTDELETE	The element cannot be deleted
UNPROCESSABLEENTITY_NOTHINGTODO	The request was valid, but no action was necessary
UNPROCESSABLEENTITY_NOTREADY	The element is not in a state that allows the action (Sending a document without signature, downloading an unsigned document)
UNPROCESSABLEENTITY_PDF_INCOMPATIBLE	The pdf document cannot be signed
UNPROCESSABLEENTITY_PDF_PASSWORD	The pdf document contains a password and cannot be signed
UNPROCESSABLEENTITY_PDF_XFA	The pdf document contains XFA form and cannot be signed
UNPROCESSABLEENTITY_TEMPLATE_MISMATCH	The number of pages between the document and the template do not match

HTTP 500 (Internal Server Error)

eErrorCode	Examples
ERROR_INTERNAL	Unhandled error on server

A Webhook (also called a web callback or HTTP push API) is a way for your application to be notified of an event in real time.

For example, if you send a contract for signing and need to be notified as soon as it get signed.

You could program a loop to query the document status every 5 minutes for many days until you receive a response saying the document is signed. This is a bad approach as it will waste a lot of resources everytime you make a call to the API for no reason.

A better approach would be to configure a webhook in the eZmax's administration console to watch for a specific event. In this exemple, the event to monitor is "DocumentCompleted" from the module "Ezsign". This way, as soon as the document gets signed, a request will be made to YOUR server to let you know about the event that just happened.

When you configure eZmax to notify you of events, you must provide your server's URL and a fallback email address. The URL provided must use HTTPS for security reasons.

Types of Webhook:

Look for purple indicators with the word "EVENT" throughout the documentation to see currently available Webhooks events you can subscribe to. If you have a need for an event that is not available, please send a feature request to technical support.

Important:

• The event will be delivered using a POST request.
• Your server will need to reply with a HTTP Status Code 202 or 204 to let eZmax know you've accepted the message and we shall not try to deliver the message again. If the server does not respond with a 202 or 204 Code, the message will be sent over and over until all tries are exhausted.
• The 202 or 204 response must be returned in less than 30 seconds otherwise a timeout will occur and the event will be retried following the retry schedule.
• Make sure to secure your Webhook receiving URL to make sure someone does not send forged messages to your application. You can do this by providing a secure token in your URL, for example "?token=mysecuretoken1234", or by validating the webhook message's signature.

Testing

In eZmax's administration module, you'll find a "Test" button that you can use as many time as you need to test your server code easily with a sample event.

eZmax will attempt to deliver the event to your server instantly but will retry many times if your server does not respond successfully for some reason (see schedule below). After all attempts are exhausted, the event will be forwarded to the configured fallback email in the same format as the webhook. The email body will contain the JSON request in the same format as the webhook. This way, you'll be able to send the request to your server using Postman, Curl or similar tool.

Retry Delivery schedule

This is the approximate retry schedule. Since there is a 30 seconds timeout on each try, there could be a cumulative overhead up to 3½ minutes.

Minutes after previous step	Minutes after event	Method
N/A	0	HTTPS
1	1	HTTPS
5	6	HTTPS
15	21	HTTPS
15	36	HTTPS
15	51	HTTPS
15	66	HTTPS
0	66	Email

Failed attempt reporting

If you don't receive the event on the first attempt, there will be debugging information about each previous attempt in the body of the event. You'll be able to see the timestamp of each previous attempt and the return code returned by your server or a timeout indication if your server hasn't replied.

All notable changes to this project will be documented in this section.

Version numbers are using MAJOR.MINOR.PATCH numbering format for example 1.2.23

MAJOR will be incremented only if there is an incompatible breaking change. New distinct documentation and specification files will be published.

MINOR will be incremented only if a function becomes deprecated or deleted (after being deprecated in a previous version)

PATCH will be incremented everytime changes and additions are released.

You can always safely update to newer PATCH version if you stay in the same MAJOR.MINOR prefix.

You can safely update to a newer MINOR version as long as you don't jump more than a version at a time. For example, let say there is a function named "foo" in version 1.0.23. We might deprecate this function in version 1.1.1 but you can continue using it. We might decide to remove it in version 1.2.1 so then you would have a breaking change if you try to update to version 1.2.1 without having fixed the issue with your deprecated "foo" function.

For each version, there will be the list of changes:

• Early Adopters for new features not yet considered officially in production.
• Added for new features.
• Changed for changes in existing functionality.
• Deprecated for soon-to-be removed features.
• Removed for now removed features.
• Fixed for any bug fixes.
• Security in case of vulnerabilities.

[1.0.47] - 2021-09-20

Early Adopters

• POST /1/object/ezsigndocument/{pkiEzsigndocumentID}/getWordsPositions
• GET /1/object/ezsigndocument/{pkiEzsigndocumentID}/getFormsData

Added

• Early Adopters mention in documentation for endpoints not ready to be used in production

Changed

• Normalized internal definition of AllOf (Objects vs additionnal properties)

Fixed

• (CsharpSDK) Requests don't have to be mandatory signed anymore

[1.0.46] - 2021-06-03

Fixed

• Minor changes

[1.0.45] - 2021-06-02

Added

• Enum values "DeclinedToSign" and "PrematurelyEnded" to field eEzsigndocumentStep

[1.0.44] - 2021-05-31

Added

• Enum value "City" for Ezsignsignature
• Password can be sent in encrypted form in authenticate method

Fixed

• (AxiosSDK) Fingerprint header on GET requests was sometimes invalid

[1.0.43] - 2021-05-25

Added

• (SDK) cpp-qt-client
• POST /2/module/authenticate/authenticate/{eSessionType}

Removed

• (SDK) cpp-qt5-client

[1.0.42] - 2021-04-21

Changed

• (AxiosSDK) Minor changes

[1.0.41] - 2021-04-21

Changed

• (AxiosSDK) Minor changes

[1.0.40] - 2021-04-19

Changed

• (AxiosSDK) Minor changes

[1.0.39] - 2021-03-26

Added

• (CsharpSDK) Automatic request signing
• (CsharpSDK) Secret handling in configuration class
• eErrorCode in Error model
• Error Codes documentation section
• Documentation for 350 Redirection code (Authentication)

Changed

• Signature algorithm now supports HMAC SHA256

[1.0.38] - 2021-03-22

Fixed

• (CsharpSDK) Hyphens in Class Name

• [1.0.37] - 2021-03-18

  Added

• (AxiosSDK) Published to NPM

Changed

• (AxiosSDK) Minor changes

[1.0.33] - 2021-03-14

Added

• (PHPSDK) Automatic request signing
• (PHPSDK) Secret handling in configuration class
• (AxiosSDK) Automatic request signing
• (AxiosSDK) Secret handling in configuration class

Fixed

• Extra slash in /1/module/sspr/resetPasswordRequest

[1.0.32] - 2021-03-05

Added

• POST /1/module/sspr/validateToken
• Webhooks successful codes in Status Codes documentation section
• fkiUserID in the response of Activesession getCurrent
• fkiApikeyID in the response of Activesession getCurrent

Changed

• Webhooks now consider an HTTP Code of 202 to be a successful delivery
• Minor changes

Removed

• sEzsigndocumentFilename in the request of Create Ezsigndocument
• sEzsigndocumentFilename in the response of Create Ezsigndocument

[1.0.31] - 2021-02-28

Added

• Changelog section in documentation
• Special type Authorization key
• Security section in documentation
• Request Signing section in documentation
• POST /1/module/sspr/unlockAccountRequest
• POST /1/module/sspr/unlockAccount
• POST /1/module/sspr/resetPasswordRequest
• POST /1/module/sspr/resetPassword
• POST /1/module/sspr/validateToken

Changed

• Authorization section moved under security section in documentation

Removed

• PUT /1/object/ezsigndocument/{pkiEzsigndocumentID} that was documented but unimplemented
• PUT /1/object/ezsignfolder/{pkiEzsignfolderID} that was documented but unimplemented
• PUT /1/object/ezsignfoldersignerassociation/{pkiEzsignfoldersignerassociationID} that was documented but unimplemented
• PUT /1/object/ezsignsignature/{pkiEzsignsignatureID} that was documented but unimplemented

[1.0.30] - 2021-02-12

Added

• Added global endpoint in servers list
• POST /1/module/sspr/sendUsernames
• Introduction section in documentation
• Servers section in documentation
• Authorization section in documentation
• Status Codes section in documentation
• Webhooks section in documentation

[1.0.29] - 2021-02-10

Added

• GET /1/customer/{pksCustomerCode}/endpoint

[1.0.28] - 2021-02-04

Changed

• Minor changes

[1.0.27] - 2021-02-03

Changed

• Minor changes

[1.0.26] - 2021-01-08

Added

• Added Audit objets to some responses

[1.0.25] - 2021-01-08

Changed

• Minor changes

[1.0.24] - 2021-01-07

Added

• POST /1/object/apikey

[1.0.23] - 2020-12-21

Changed

• Minor changes

[1.0.22] - 2020-12-21

Changed

• Minor changes

[1.0.21] - 2020-12-21

Added

• WEBHOOK User-UserCreated

[1.0.20] - 2020-12-17

Added

• POST /1/module/user/createezsignuser
• POST /1/object/ezsigndocument/{pkiEzsigndocumentID}/applyezsigntemplate

Changed

• Reorganized Documentation Categories

[1.0.19] - 2020-12-01

Changed

• Minor changes

[1.0.18] - 2020-10-14

Changed

• Minor changes

[1.0.17] - 2020-09-30

Changed

• Minor changes

[1.0.16] - 2020-09-29

Added

• GET /1/object/franchisebroker/getAutocomplete/{sSelector}

[1.0.15] - 2020-09-28

Removed

• GET /1/object/period/getAutocomplete

Added

• GET /1/object/period/getAutocomplete/{sSelector}

[1.0.14] - 2020-09-28

Added

• GET /1/object/period/getAutocomplete

[1.0.13] - 2020-09-08

Changed

• Minor changes

[1.0.12] - 2020-09-08

Changed

• Minor changes

[1.0.11] - 2020-09-04

Added

• POST /1/object/franchisereferalincome/

[1.0.10] - 2020-08-11

Changed

• Minor changes

[1.0.9] - 2020-08-06

Added

• GET /1/object/ezsigndocument/{pkiEzsigndocumentID}/getDownloadUrl/{eDocumentType}
• GET /1/object/ezsignfoldersignerassociation/{pkiEzsignfoldersignerassociationID}/getInPersonLoginUrl

[1.0.8] - 2020-08-04

Changed

• Minor changes

[1.0.7] - 2020-07-29

Changed

• Minor changes

[1.0.6] - 2020-07-29

Changed

• Minor changes

[1.0.5] - 2020-07-29

Added

• WEBHOOK Ezsign-DocumentCompleted
• WEBHOOK Ezsign-FolderCompleted

[1.0.4] - 2020-07-09

Added

• POST /1/object/ezsignsignature
• GET /1/object/ezsignsignature/{pkiEzsignsignatureID}
• DELETE /1/object/ezsignsignature/{pkiEzsignsignatureID}
• GET /1/object/ezsignsignature/{pkiEzsignsignatureID}/getChildren

[1.0.3] - 2020-07-08

Changed

• Documentation improvement

[1.0.2] - 2020-07-26

Added

• GET /1/object/activesession/getCurrent
• POST /1/object/ezsignfoldersignerassociation
• GET /1/object/ezsignfoldersignerassociation/{pkiEzsignfoldersignerassociationID}
• DELETE /1/object/ezsignfoldersignerassociation/{pkiEzsignfoldersignerassociationID}
• GET /1/object/ezsignfoldersignerassociation/{pkiEzsignfoldersignerassociationID}/getChildren
• POST /1/object/ezsignfolder/{pkiEzsignfolderID}/send

[1.0.1] - 2020-06-26

Changed

• Minor changes

[1.0.0] - 2020-06-26

Added

• Initial Release

Customer contains details about the customer code assigned to your account

Authenticate contains details action related to authenticating users to the platform

Sspr module contains actions related to the Self Service Password Reset portal.

There is an option in the admin interface to disable the portal if you don't want your users to be able to reset their own password.

Generic return codes (Documented at the function's level)

HTTP Status Code	eErrorCode	Detail
200	OK	The request completed successfully and valid data was returned in the body
201	Created	The request completed successfully. Some elements were created and details about the created items

User module contains actions that can be called to interract with users

Activesession contains detail about the currently executing api request.

Apikey contains detail about an api key used to access the API

Ezsigndocument contains detail about a document to sign

Ezsignfolder contains detail about the container containing signers, documents to sign, etc. Sometimes referred as "Envelopes" in competitor products