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.

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 files to use in your toolset, you can find them in the specs folder.

We provide SDKs for customers. They are generated using OpenAPI Generator, we encourage customers to use them as we also provide samples for them.

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.

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 life easier by automating package distribution, let us know !

You can choose to automatically build and personnalize your own SDK by using any compatible OpenAPI 3.0 generator like OpenAPI Generator, Swagger Codegen or any commercial generators.

To do so, you just need to pass the specification file to your generator. You can find the latest version in the specs folder.

We are integrated into commercial automation platforms that allow users to create workflows to automate tasks and processes We currently support:

• Microsoft Power Automate which is part of Microsoft Office 365 suite
• Salesforce Flow

Various software vendors have seamlessly integrated our API into their solutions, simplifying the adoption process for their customers by eliminating the need for manual integration efforts. If you're utilizing one of these integrated solutions, feel free to reach out to the respective software vendor to activate the functionality.

Below is a partial list of these integrations:

• Hopem
• PG Solutions
• Planiprêt

Contact us if you're interested in being included in this list.

Occasionally, customers may find themselves utilizing a programming language that lacks support from any generator. Alternatively, some may prefer the straightforwardness of directly calling API endpoints without relying on an SDK.

Fortunately, as our API adheres to standard REST principles, you have the freedom to invoke the GET/POST/PUT/PATCH/DELETE methods with appropriate parameters and payloads. Following this approach allows you to handle responses by parsing them manually, offering a flexible and adaptable method for interacting with our services.

Postman is a software tool that facilitates API prototyping and debugging. You might find it useful while working with our Api.

If you want to use it, you can simply use our Postman definition files that you'll find in the specs folder.

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.

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

When you send your Websocket 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: wss://ws.{sInfrastructureregionCode}.ezmax.com/{sInfrastructureenvironmenttypeDescription}/

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

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

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

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 6 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. Presigned type key which are used to presign a url. These keys have an expiration date configured at signing time. This type of key begins with the letter P.

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

6. Webhook type key which is used when a webhook is sent to your server if request signing is enabled. This type of key begins with the letter W.

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 or 4 additional HTTP Headers to the request:

• Ezmax-Date
• Ezmax-Expiration (Optional)
• 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 or 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-Expiration

Ezmax-Expiration Is optional. It must be a positive integer representing the number of minutes (starting from Ezmax-Date) after which the signed request will be considered expired.

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, the Date and the Expiration (Expiration must be appended only if defined). 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 = '', $iExpiration = null) {
    $sContentToHash = "$sMethod\n$sURL\n$sBody\n$sAuthorization\n$dtDate" . (is_null($iExpiration) ? '' : "\n$iExpiration");
    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": "email@example.com"}\n
ThisIsMyAuthorizationKey\n
2000-12-31T23:59:59Z

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

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=da829efd4c2a8722ce17d3cf977c4e86adf7d2dbaa47e1b2ee3b4ade6c9cb642ThisIsMyAuthorizationKey2000-12-31T23:59:59Z

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

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:

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": "emain@example.com"}' :

Authorization: ThisIsMyAuthorizationKey
Ezmax-Date: 2000-12-31T23:59:59Z
Ezmax-Fingerprint: v1=da829efd4c2a8722ce17d3cf977c4e86adf7d2dbaa47e1b2ee3b4ade6c9cb642
Ezmax-Signature: v1=b924269145ff74f64985992325e82e79445bbe3aa994b90d2f24b3023b8d5f09

We use a custom type base naming convention for variables.

Each variable name is composed of up to 6 indicators

1. Array (Optional) a_ when we are dealing with an array.
2. Key (Optional) pk when we are dealing with a primary key or fk for foreign key.
3. Type Will always be in lowercase and represent the type of the variable.
4. Table The first letter in uppercase and the rest in lowercase and represents the table name from where the variable was retrieved.
5. Field (Optional) The first letter is uppercase and the rest is lowercase and represents the field name.
6. Discriminator (Optional) Will be present only when two identical fields are stored in the same table to differenciate one from the other.

Here is a summary table explaining the convention.

Here are examples of typical variables' names

Every GetList Endpoint has a sFilter query parameter that can be used to filter the returned elements.

The sFilter parameter's syntax is not documented at the endpoint's level since it would be redundant. This section documents the syntax.

• Every property returned by the endpoint can be used to build the sFilter string. Except for rare exceptions.
• Each filter can be joined by the and operator
• Not every property supports every operator. The list of valid operators is based on the variable type. For example, only strings support the like operator. You can refer to the Variables article in the Conventions section of the documentation to learn about variable types.
• Variables of type Enum have predetermined list of filters which will be documented at the endpoint's level.
• sFilter's value must be url encoded.
• String values need to be enclosed in single quotes

Valid operators for boolean values:

Valid operators for integer values:

Valid operators for date and datetime values:

Valid operators for string values:

Valid operators for enum values (valid values are documented at the endpoint's level):

Example of combining multiple filter together:

sFilter=bEzsigndocumentEzsignclause eq true and iEzsigndocumentPagetotal gt 10 and iEzsigndocumentPagetotal lte 100 and dtEzsigndocumentDuedate gt '2001-01-01 00:00:00' and dtEzsigndocumentDuedate lte '2025-12-31 23:59:59' and sEzsigndocumentName like '%con%' and eEzsigndocumentStep eq 'PartiallySigned' and fkiEzsignfoldertypeID in '1,2,3' and dtEzsigndocumentDuedate rg '=m,=m+7d'

Same example, but properly url encoded:

sFilter=bEzsigndocumentEzsignclause%20eq%20true%20and%20iEzsigndocumentPagetotal%20gt%2010%20and%20iEzsigndocumentPagetotal%20lte%20100%20and%20dtEzsigndocumentDuedate%20gt%20%272001-01-01%2000%3A00%3A00%27%20and%20dtEzsigndocumentDuedate%20lte%20%272025-12-31%2023%3A59%3A59%27%20and%20sEzsigndocumentName%20%20like%20%27%25con%25%27%20and%20eEzsigndocumentStep%20eq%20%27PartiallySigned%27%20and%20fkiEzsignfoldertypeID%20in%20%271%2C2%2C3%27%20and%20dtEzsigndocumentDuedate%20rg%20%27%3Dm%2C%3Dm%2B7d%27

Dates in list filter can use a "rg" operator for ranges. This allows to filter data based on relative dates. The range operator is just another way to compute filters dates.

For the rest of this section, let's assume today's date is February 25th 2019 and the time is 10:15:37. Let's assume that we want to filter on dtInvoiceDate.

If we wanted to get all the invoices that were generated in the previous month, we could do (not url encoded for readability purposes): sFilter=dtInvoiceDate gte '2019-01-01 00:00:00' and dtInvoiceDate lte '2019-01-31 23:59:59'

Range operator is useful to transfer the complexity of date computation to the api instead of the calling application.

The general format of the range operator is: dtInvoiceDate rg '[STARTDATE],[ENDDATE]'

Both [STARTDATE] and [ENDDATE] use the same format which is a sequence of 1 or more [SUBSECTION] so for example, we could have: dtInvoiceDate rg '[SUBSECTION],[SUBSECTION][SUBSECTION][SUBSECTION][SUBSECTION]'

Both [STARTDATE] and [ENDDATE] have a starting time equal to current time (so in this example 2019-02-25 10:15:37)

[SUBSECTION] start with an operator which can be either = to reset the pointer, + to move forward in time or - to move backward in time.

The = operator can be directly followed by a letter representing the [PERIOD] (ex: =m) to initialize the date to the start or end of the period or by a number and a letter representing the [PERIOD] (ex: =7m) to set the [PERIOD] to a specific value.

The + and - operators are followed by a number then by a letter representing the [PERIOD] (ex: +7d or -1m)

Here is a list of valid [PERIOD]

= operator without a number resets the pointer to either the beginning or the end of the [Period] depending if it's being used in the [STARTDATE] or [ENDDATE]. This table shows the time when the pointer is reset

* Week start day is configurable per user

= operator with a number resets the [PERIOD] to a specific value and works the same for both [STARTDATE] or [ENDDATE]. Here are some example. Please note it's not possible to reset the week like this (ex: =7w)

Combining [SUBSECTION]

You can combine multiple [SUBSECTION] under the same operator. For example:

• Instead of using "=m=7d=8h=6m=32s" you can simplify as "=m7d8h6m32s"
• Instead of using "+7d+7h+7m+7s" you can simplify as "+7d7h7m7s"
• Instead of using "=3m=m" you can simplify as "=3mm"

Order of precedence

[STARTDATE] and [ENDDATE] are evaluated from left to right. The order is important. For example, these values would give different results in [ENDDATE]:

• "=m-1m" would give "2019-01-28 23:59:59"
• "-1m=m" would give "2019-01-31 23:59:59"

Examples of use

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)

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

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.

These codes are documented in the Activesession getCurrent endpoint only to simplify the documentation but they can be returned in any of the endpoints.

Webhook delivery successful code

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

When the API returns an HTTP status code in the range 200-299, a property could be returned indicating one or more warnings occured. The array contain objects with 2 properties:

• eWarningCode
• sWarningMessage

We highly suggest you use eWarningCode to do any warning validation logic in your code or to create your own warning message for your users. sWarningMessage 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 eWarningCode you could receive.

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)

HTTP 401 (Unauthorized)

HTTP 403 (Forbidden)

HTTP 404 (Not Found)

HTTP 405 (Method Not Allowed)

HTTP 406 (Not Acceptable)

HTTP 413 (Content Too Large)

HTTP 422 (Unprocessable entity)

HTTP 429 (Too Many Requests)

HTTP 500 (Internal Server Error)

HTTP 501 (Not Implemented)

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 red 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.
• The User-Agent for the request will be Ezmax-Webhook

Request Signing

You can enable request signing in the webhook configuration section. This will add an extra layer of security by adding an Authorization, a Date, a Fingerprint and a Signature to each request that you can validate. This can help to authenticate the request, prevent forgery and prevent replay attacks.

The following HTTP headers will be added to each request:

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

You can read more on Request Signing in the Security section of the documentation.

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.

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.

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

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

Removal lifecycle
Once a function becomes Deprecated, we monitor its usage to track how many users are still using it. After a long period of time, if a minority of users are still using the function, we might ask users to update to the newer version of the function and give them ample time to do so. Only after that delay expires (or no more users are still using it), we will have the function Removed.

[1.2.1] - 2024-

Added

[1.2.0] - 2024-04-14

Added

• DELETE /1/object/creditcardclient/{pkiCreditcardclientID}
• DELETE /1/object/discussion/{pkiDiscussionID}
• DELETE /1/object/discussionmembership/{pkiDiscussionmembershipID}
• DELETE /1/object/discussionmessage/{pkiDiscussionmessageID}
• DELETE /1/object/usergroupdelegation/{pkiUsergroupdelegationID}
• DELETE /1/object/usergroupexternal/{pkiUsergroupexternalID}
• GET /1/module/location/search
• GET /1/object/activesession/getDocumentationUrl
• GET /1/object/attachment/{pkiAttachmentID}/download
• GET /1/object/attachment/{pkiAttachmentID}/getAttachmentlogs
• GET /1/object/buyercontract/{pkiBuyercontractID}/getCommunicationList
• GET /1/object/creditcardclient/getList
• GET /1/object/discussion/{pkiDiscussionID}
• GET /1/object/electronicfundstransfer/{pkiElectronicfundstransferID}/getCommunicationList
• GET /1/object/ezsigndiscussion/{pkiEzsigndiscussionID}
• GET /1/object/ezsigndocument/{pkiEzsigndocumentID}/getAttachments
• GET /1/object/ezsigndocument/{pkiEzsigndocumentID}/getEzsigndocumentdiscussions
• GET /1/object/ezsignfolder/{pkiEzsignfolderID}/getAttachmentCount
• GET /1/object/ezsignfolder/{pkiEzsignfolderID}/getAttachments
• GET /1/object/ezsignsigningreason/getAutocomplete
• GET /1/object/ezsignsigningreason/getList
• GET /1/object/ezsignsigningreason/{pkiEzsignsigningreasonID}
• GET /1/object/inscription/{pkiInscriptionID}/getAttachments
• GET /1/object/inscription/{pkiInscriptionID}/getCommunicationList
• GET /1/object/inscription/{pkiInscriptionID}/getCommunicationsenders
• GET /1/object/inscriptionnotauthenticated/{pkiInscriptionnotauthenticatedID}/getCommunicationList
• GET /1/object/inscriptiontemp/{pkiInscriptiontempID}/getCommunicationList
• GET /1/object/invoice/{pkiInvoiceID}/getAttachments
• GET /1/object/invoice/{pkiInvoiceID}/getCommunicationList
• GET /1/object/otherincome/{pkiOtherincomeID}/getCommunicationList
• GET /1/object/rejectedoffertopurchase/{pkiRejectedoffertopurchaseID}/getCommunicationList
• GET /1/object/user/{pkiUserID}/getApikeys
• GET /1/object/user/{pkiUserID}/getUsergroupexternals
• GET /1/object/user/{pkiUserID}/getUsergroups
• GET /1/object/usergroup/{pkiUsergroupID}/getUsergroupdelegations
• GET /1/object/usergroupexternal/getList
• GET /1/object/usergroupexternal/{pkiUsergroupexternalID}/getMembers
• GET /1/object/usergroupexternal/{pkiUsergroupexternalID}/getUsergroups
• GET /2/module/location/{sLocationPlaceid}
• GET /2/object/country/getAutocomplete/{sSelector}
• GET /2/object/creditcardclient/getAutocomplete/{sSelector}
• GET /2/object/creditcardclient/{pkiCreditcardclientID}
• GET /2/object/ezsigntemplateglobal/getAutocomplete/{sSelector}
• GET /2/object/ezsigntemplateglobal/{pkiEzsigntemplateglobalID}
• GET /2/object/module/getAutocomplete/{sSelector}
• GET /2/object/province/getAutocomplete/{sSelector}
• GET /2/object/usergroupdelegation/{pkiUsergroupdelegationID}
• GET /2/object/usergroupexternal/getAutocomplete/{sSelector}
• GET /2/object/usergroupexternal/{pkiUsergroupexternalID}
• PATCH /1/object/discussion/{pkiDiscussionID}
• PATCH /1/object/discussionmessage/{pkiDiscussionmessageID}
• POST /1/object/creditcardclient
• POST /1/object/discussion
• POST /1/object/discussion/{pkiDiscussionID}/updateDiscussionreadstatus
• POST /1/object/discussionmembership
• POST /1/object/discussionmessage
• POST /1/object/ezsigndocument/{pkiEzsigndocumentID}/applyEzsigntemplateglobal
• POST /1/object/ezsigndocument/{pkiEzsigndocumentID}/createEzsignelementsPositionedByWord
• POST /1/object/ezsignfolder/{pkiEzsignfolderID}/endPrematurely
• POST /1/object/ezsignfolder{pkiEzsignfolderID}/reassign
• POST /1/object/ezsignsigningreason
• POST /1/object/user/{pkiUserID}/sendPasswordReset
• POST /1/object/usergroup/{pkiUsergroupID}/editUsergroupdelegations
• POST /1/object/usergroupdelegation
• POST /1/object/usergroupexternal
• POST /1/object/webhook/{pkiWebhookID}/regenerateApikey
• POST /2/object/ezsignfoldertype
• POST /2/object/webhook
• PUT /1/object/creditcardclient/{pkiCreditcardclientID}
• PUT /1/object/ezsignsigningreason/{pkiEzsignsigningreasonID}
• PUT /1/object/usergroupdelegation/{pkiUsergroupdelegationID}
• PUT /1/object/usergroupexternal/{pkiUsergroupexternalID}
• PUT /2/object/ezsignfoldertype/{pkiEzsignfoldertypeID}
• Avanced search filters sContactFirstname, sContactLastname and sEzsigndocumentName to Ezsignfolder list
• New error code 413 Content too large
• Property a_objEzsignelementdependency in ezsignformfield-RequestCompound, ezsignformfield-ResponseCompound, ezsignsignature-RequestCompound and ezsignsignature-RequestCompound
• Property a_objEzsigntemplateelementdependency in ezsigntemplateformfield-RequestCompound, ezsigntemplateformfield-ResponseCompound, ezsigntemplatesignature-RequestCompound and ezsigntemplatesignature-RequestCompound
• Property a_objEzsigntemplateglobal in ezsign-suggestTemplates-v1-Response-mPayload
• Property a_objWarning in ezsigndocument-applyEzsigntemplate-v2-Response
• Property bEzsignfoldersignerassociationAllowsigninginperson in ezsignfoldersignerassociation-Response
• Property bEzsignfoldertypeAllowdownloadattachmentezsignsigner in Custom-Ezsignfoldertype-Response, ezsignfoldertype-Request and ezsignfoldertype-Response
• Property bEzsignfoldertypeAllowdownloadattachmentezsignsigner in ezsignfoldertype-Request and ezsignfoldertype-Response
• Property bEzsignfoldertypeAllowdownloadproofezsignsigner in Custom-Ezsignfoldertype-Response, ezsignfoldertype-Request and ezsignfoldertype-Response
• Property bEzsignfoldertypeAllowdownloadproofezsignsigner in ezsignfoldertype-Request and ezsignfoldertype-Response
• Property bEzsignfoldertypeDelegate in Custom-Ezsignfoldertype-Response, ezsignfoldertype-Request and ezsignfoldertype-Response
• Property bEzsignfoldertypeReassignezsignsigner in Custom-Ezsignfoldertype-Response ezsignfoldertype-Request and ezsignfoldertype-Response
• Property bEzsignfoldertypeReassignuser in Custom-Ezsignfoldertype-Response ezsignfoldertype-Request and ezsignfoldertype-Response
• Property bEzsignfoldertypeSendattachmentezsignsigner in ezsignfoldertype-Request and ezsignfoldertype-Response
• Property bEzsignfoldertypeSendattachmentuser in ezsignfoldertype-Request and ezsignfoldertype-Response
• Property bEzsignfoldertypeSendproofemail in ezsignfoldertype-Request and ezsignfoldertype-Response
• Property bEzsignfoldertypeSendproofezsignsigner in ezsignfoldertype-Request and ezsignfoldertype-Response
• Property bEzsignfoldertypeSendproofreceivealldocument in ezsignfoldertype-Request and ezsignfoldertype-Response
• Property bEzsignfoldertypeSendproofuser in ezsignfoldertype-Request and ezsignfoldertype-Response
• Property bEzsignfoldertypeSendsignedtoezsignsigner in ezsignfoldertype-Request and ezsignfoldertype-Response
• Property bEzsignfoldertypeSendsignedtouser in ezsignfoldertype-Request and ezsignfoldertype-Response
• Property bEzsignformHasdependencies in ezsignfolder-ListElement
• Property bEzsignformfieldAutocomplete in ezsignformfield-Request and ezsignformfield-Response
• Property bEzsigntemplateformfieldAutocomplete in ezsigntemplateformfield-Request and ezsigntemplateformfield-Response
• Property bPhoneInternational in phone-ResponseCompound
• Property bVersionDeprecated in Common-Response-objDebugPayload
• Property dEzsignfolderCompletedpercentage in ezsignfolder-ListElement
• Property dtEzsignfolderDelayedsenddate in ezsignfolder-ListElement
• Property dtResponseDate in Common-Response-objDebugPayload
• Property dtUserEzsignprepaidexpiration in activesession-ResponseCompound
• Property dtUserEzsignprepaidexpiration in activesession-ResponseCompound
• Property eBrandingLogointerface in branding-Request and branding-Response
• Property eEzsigndocumentSteptype in ezsigndocument-ResponseCompound
• Property eEzsignfolderCompletion in ezsignfolder-Response
• Property eEzsignfoldertypeCompletion in ezsignfoldertype-Response and ezsignfoldertype-Response
• Property eEzsignformfieldDependencyrequirement in object ezsignformfield-Request and ezsignformfield-Response
• Property eEzsignformfieldDependencyrequirement in object ezsignformfield-Request and ezsignformfield-Response
• Property eEzsignformfieldgroupTextvalidation in ezsignformfieldgroup-Response
• Property eEzsignformfieldgroupTextvalidation in ezsignformfieldgroup-Response
• Property eEzsignsignatureDependencyrequirement in ezsignsignature-Request and ezsignsignature-Response
• Property eEzsigntemplateformfieldDependencyrequirement in ezsigntemplateformfield-Request and ezsigntemplateformfield-Response
• Property eEzsigntemplateformfieldDependencyrequirement in ezsigntemplateformfield-Request and ezsigntemplateformfield-Response
• Property eEzsigntemplateformfieldPositioning in ezsigntemplateformfield-Request and ezsigntemplateformfield-Response
• Property eEzsigntemplateformfieldPositioningoccurence in ezsigntemplateformfield-Request and ezsigntemplateformfield-Response
• Property eEzsigntemplateformfieldgroupTextvalidation in ezsigntemplateformfieldgroup-Request and ezsigntemplateformfieldgroup-Response
• Property eEzsigntemplatesignatureDependencyrequirement in ezsigntemplatesignature-Request and ezsigntemplatesignature-Response
• Property eEzsigntemplatesignaturePositioning in ezsigntemplatesignature-Request and ezsigntemplatesignature-Response
• Property eEzsigntemplatesignaturePositioningoccurence in ezsigntemplatesignature-Request and ezsigntemplatesignature-Response
• Property eEzsigntemplatesignatureTextvalidation in ezsigntemplatesignature-Request and ezsigntemplatesignature-Response
• Property eUserEzsignaccess in activesession-ResponseCompound
• Property eUserEzsignprepaid in activesession-ResponseCompound
• Property fkiBillingentityinternalID in Custom-EzmaxinvoicingEzsigndocument-Response and Custom-EzmaxinvoicingEzsignfolder-Response
• Property fkiEzsignsigningreasonID in ezsignsignature-sign-v1-Request
• Property iBrandingInterfacecolor in branding-Request and branding-Response
• Property iCommunicationattachmentSize in communicationattachment-Response
• Property iEzsignformfieldgroup in ezsignfolder-ListElement
• Property iEzsignformfieldgroupCompleted in ezsignfolder-ListElement
• Property iEzsignsignatureMaxlength in ezsignsignature-Request and ezsignsignature-Response
• Property iEzsignsignatureStep in ezsignsignature-Response
• Property iEzsignsignaturecustomdateOffsetx in ezsignsignaturecustomdate-Request and ezsignsignaturecustomdate-Response
• Property iEzsignsignaturecustomdateOffsety in ezsignsignaturecustomdate-Request and ezsignsignaturecustomdate-Response
• Property iEzsigntemplateformfieldPositioningoffsetx in ezsigntemplateformfield-Request and ezsigntemplateformfield-Response
• Property iEzsigntemplateformfieldPositioningoffsety in ezsigntemplateformfield-Request and ezsigntemplateformfield-Response
• Property iEzsigntemplatesignatureHeight in object ezsigntemplatesignature-Request and ezsigntemplatesignature-Response
• Property iEzsigntemplatesignatureMaxlength in ezsigntemplatesignature-Request and ezsigntemplatesignature-Response
• Property iEzsigntemplatesignaturePositioningoffsetx in ezsigntemplatesignature-Request and ezsigntemplatesignature-Response
• Property iEzsigntemplatesignaturePositioningoffsety in ezsigntemplatesignature-Request and ezsigntemplatesignature-Response
• Property iEzsigntemplatesignatureWidth in object ezsigntemplatesignature-Request and ezsigntemplatesignature-Response
• Property iEzsigntemplatesignaturecustomdateOffsetx in ezsigntemplatesignaturecustomdate-Request and ezsigntemplatesignaturecustomdate-Response
• Property iEzsigntemplatesignaturecustomdateOffsety in ezsigntemplatesignaturecustomdate-Request and ezsigntemplatesignaturecustomdate-Response
• Property objContactNameDelegation in ezCustom-Ezsignfoldertype-Responsesignsignature-Response
• Property objEzsignfoldertype in ezsignfolder-Response
• Property sBrandingLogointerfaceBase64 in branding-Request
• Property sBrandingLogointerfaceurl in branding-ResponseCompound
• Property sEzsigntemplateFilenamepattern in ezsigntemplate-Request and ezsigntemplate-Response
• Property sEzsigntemplateformfieldPositioningpattern in ezsigntemplateformfield-Request and ezsigntemplateformfield-Response
• Property sEzsigntemplatesignaturePositioningpattern in ezsigntemplatesignature-Request and ezsigntemplatesignature-Response
• Property sEzsigntemplatesignatureRegexp in ezsigntemplatesignature-Request and ezsigntemplatesignature-Response
• Property sUserJobtitle in user-Request, user-Response and user-ListElement
• Property sUsergroupNameX in usergroup-Response
• Value AgentBrokerEzsignUserNormal for sSelector in GET /2/object/user/getAutocomplete/{sSelector}
• Value AllButEveryone for sSelector in GET /2/object/usergroup/getAutocomplete/{sSelector}
• Value Consultation for eEzsignsignatureType and eEzsigntemplatesignatureType
• Value Discard in eEzsigndocumentForm and eEzsigntemplatedocumentForm
• Value EzsignTemplateEdit in sSelector for /object/ezsignfoldertype/getAutocomplete
• Value NameReason for eEzsignsignatureType
• Value NameReason for eEzsigntemplatesignatureType
• Value PendingCompletion for eEzsigndocumentStep
• Value fkiUserID for sFilter in GET /1/object/ezsignfolder/getList
• Values Number, Date in Field-eEzsignformfieldgroupType and Field-eEzsigntemplateformfieldgroupType
• Values DocumentFormCompleted, DocumentUnsent, FolderDisposed, FolderSent, FolderUnsent and SignatureSigned for eWebhookEzsignevent
• New 401 error code UNAUTHORIZED_REQUEST_APIKEY
• New 401 error code UNAUTHORIZED_REQUEST_PRESIGNED
• New 422 error code UNPROCESSABLEENTITY_EZSIGNSIGNATURE_SIGNED
• New Authorization key starting with "W" for webhooks
• New iso environment for isolated customers
• Webhook Document Form Completed
• Webhook Document Unsent
• Webhook Folder Disposed
• Webhook Folder Sent
• Webhook Folder Unsent
• Webhook Signature Signed
• Webhook Request signing
• Webhook User-Agent
• Support for PowerAutomate flows
• Support for Salesforce flows

Remove

• GET /1/object/ezmaxinvoicing/getAutocomplete/{sSelector}
• GET /1/object/ezsignfoldertype/getAutocomplete/{sSelector}
• GET /1/object/franchisebroker/getAutocomplete/{sSelector}
• GET /1/object/period/getAutocomplete/{sSelector}
• POST /1/object/activesession/answerSecretquestion
• POST /1/object/ezsignfoldersignerassociation/reassign
• POST /1/object/ezsignfoldertype
• POST /1/object/franchisereferalincome
• POST /1/object/webhook
• POST /2/object/ezsignfolder/{pkiEzsignfolderID}/send
• Property bEzsignfoldertypeIncludeproofsigner in ezsignfoldertype-Request and ezsignfoldertype-Response
• Property bEzsignfoldertypeIncludeproofuser in ezsignfoldertype-Request and ezsignfoldertype-Response
• Property bEzsignfoldertypeSendattatchmentsigner in ezsignfoldertype-Request and ezsignfoldertype-Response
• Property bEzsignfoldertypeSendsignedtolimitedgroup in ezsignfoldertype-Request and ezsignfoldertype-Response
• Support for eZmax-SDK-apex as we are moving to Salesforce flows
• Support for eZmax-SDK-javascript please use eZmax-SDK-typescript-axios instead

Deprecated

• POST /1/object/ezsignfoldersignerassociation/reassign
• POST /1/object/webhook
• Property iEzsigntemplatesignaturecustomdateX
• Property iEzsigntemplatesignaturecustomdateY
• Property eEzsignformfieldgroupSignerrequirement
• Property eEzsigntemplateformfieldgroupSignerrequirement

Documentation and changelog for older releases can be found here

• 1.1.x Releases Documentation (Full)
• 1.0.x Releases Documentation (Full)

Customer contains details about the customer code assigned to your account

Customer contains details about the customer code assigned to your account

Ezmaxclient contains details about the native Ezmax Applications

Ezsign contains actions related to Ezsign

Report contains actions related to utility functions for the reports

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

Activesession contains detail about the currently executing api request