Evia Sign
  • Welcome to Evia Sign
    • What can Evia Sign do?
  • How to send signature request?
    • How to enable multiple signatories to access and sign documents at the same time?
    • How to add approvers and CC recipients to a signature request?
    • How do you add authentication to your request?
    • How do you send a private message?
  • How to sign documents?
    • Opening a document through Evia Sign inbox
    • Explore the different ways to add your signature
  • How to draft documents?
    • Components of DRAFTS in Evia Sign
  • Explore Evia Sign Inbox
  • How to create and use templates
    • Components of TEMPLATES
  • How to save your signature and initial?
  • How to add date stamp to your signature?
  • How to set up automatic reminders & expiration for signature requests
  • Users
    • How to import O365 users?
    • How to add new users?
    • How to delete users?
    • How to activate and deactivate users?
  • How do I change the current subscription plan of my account?
    • How to cancel and renew plan?
    • How do I purchase additional user licenses?
  • How to work with Enadoc Integration?
  • Terms to be familiar
  • FAQs
    • How to login into Evia Sign?
    • How do I make an account recovery?
    • How do you configure stamps?
    • How do you manually send reminders to signatories?
    • How do you view document history?
    • How do you decline a document?
    • How do you download a document?
    • What is a digitally certified document?
    • How are additional user licenses purchased?
    • How do you send reminders to signatories?
    • How to modify your session duration?
    • How do I monitor the request usage of my Evia Sign account?
  • Release Notes
  • Evia Sign API
    • V1
      • Overview
      • Authorization of the API Access
      • Requests
        • Document Upload
        • Send Requests
      • Request Types
        • Template
        • Fixed Positioning
        • Auto Stamping
    • V2
      • Welcome to Evia Sign API Version2
      • How to Migrate from API v1 to v2
        • Basic Guide with minimal changes
        • Access Token Request (v1 ➞ v2)
      • Authorization & Authentication
        • How to Register Your Application
        • Requesting the Authorization Code
        • Exchange Authorization Code for Access Token
      • Upload Document for Signing
      • Creating a Signature Request
      • Add Signatory to a Signature Request
      • Add Stamps to a Signatory
      • Send Signature Request
      • Webhook Management
      • Glossary & Common Fields
  • Welcome to the New and Improved Evia Sign
  • How to Use the PDF Commenting Feature in Evia Sign
  • How to Upload Documents from SharePoint in Evia Sign
Powered by GitBook
On this page
  • Token Exchange URL
  • Request Headers
  • Request Body Parameters (Form-Encoded)
  • Sample Request (Raw Format)
  • Successful Response
  • Error Response Example
  • Using the Access Token in API Requests
  • Refresh Access Token
  • Request URL
  • Request Headers
  • Request Body Parameters
  • Successful Response
  • Error Response
  • Using the New Token

Was this helpful?

  1. Evia Sign API
  2. V2
  3. Authorization & Authentication

Exchange Authorization Code for Access Token

After successfully receiving the authorization code, the next step in the OAuth 2.0 flow is to exchange that code for an access token. This token acts as a credential that authorizes your application to securely access Evia Sign API endpoints on behalf of the authenticated system.

The exchange must be performed by your backend server, using your Client ID and Client Secret, along with the received code. The resulting access token must then be included in the Authorization header of all subsequent API requests.

Token Exchange URL

POST /_apis/falcon/auth/api/v2/token

This endpoint is used to exchange a valid authorization code for an access token. The access token is required to authenticate and authorize all subsequent API requests to the Evia Sign platform.

This request must be made server-side to ensure secure handling of the Client Secret.

Request Headers

Include the following headers to authenticate your request and ensure it’s correctly processed by the server.

Name
Value

Authorization

The Authorization header must use Basic Authentication. Format the value as: Basic base64(client_id:client_secret)

Content-Type

Must be set to application/x-www-form-urlencoded to ensure that the request body is interpreted correctly by the server.

Request Body Parameters (Form-Encoded)

The request body should be sent in x-www-form-urlencoded format. Below are the required parameters:

Parameter
Required
Description

grant_type

✅ Yes

Must be set to authorization_code

client_id

✅ Yes

Your application's Client ID (same used in the authorization request)

client_secret

✅ Yes

Your Client Secret

code

✅ Yes

The authorization code received from the previous step

Sample Request (Raw Format)

POST https://evia.enadocapp.com/_apis/falcon/auth/api/v2/token
Authorization: Basic base64(client_id:client_secret)
Content-Type: application/x-www-form-urlencoded

Body

{
  "grant_type": "authorization_code",
  "client_id": "your-client-id",
  "client_secret": "your-client-secret",
  "code": "received-auth-code"
}

Successful Response

If the request is valid, Evia Sign will return a response with an access token:

{
  "access_token": "abc123...",
  "token_type": "bearer",
  "expires_in": 3600,
  "refresh_token": "xyz456..."
}
Field
Description

access_token

This is the actual token your app will use to make authorized API requests. You must include it in the Authorization header as Bearer abc123...

token_type

Always set to bearer. This just tells you how the token should be used in the header

expires_in

The number of seconds the access token is valid for. In this case, 3600 seconds = 1 hour. After that, the token is no longer valid.

refresh_token

A token that can be used to request a new access_token after it expires—so your app doesn’t need to go through the full authorization flow again.

Error Response Example

{
  "error": "invalid_request"
}

Common causes include:

  • Missing or incorrect client_id or client_secret

  • Expired or reused authorization code

  • Incorrect or mismatched redirect_url

Using the Access Token in API Requests

Once the access token is received, include it in the Authorization header of all subsequent API requests:

Authorization: Bearer abc123...

This token allows Evia Sign to verify the identity of your registered application and authorize its access to the API, based on the scopes granted during app registration.

Refresh Access Token

After the original access_token has expired, you can request a new one using a valid refresh_token. This allows your application to maintain its authenticated session with the Evia Sign API without re-running the full authorization flow.

Request URL

POST/ _apis/falcon/auth/api/v2/Token

This endpoint is used to exchange a valid refresh token for a new access token. The request must be made server-side, as it involves sending your Client ID and Client Secret in the Authorization header.

Request Headers

Header
Required
Description

Authorization

✅ Yes

Basic Auth using base64(client_id:client_secret)

Content-Type

✅ Yes

Handled automatically as multipart/form-data via the --form flag

Authorization: Basic Base64(client_id:client_secret)
Content-Type: multipart/form-data

Request Body Parameters

Parameter
Required
Description

Refresh_Token

✅ Yes

The valid refresh token previously issued by Evia Sign.

Grant_Type

✅ Yes

Must be set to Refresh_Token (case-sensitive on some systems).

Refresh_Token: "457F4F73-025C-451A-8484-674C5FDC11B59F421000-10CD-4B3E-871D-586EFD38139C"
Grant_Type: "Refresh_Token"

Successful Response

{
  "access_token": "new-access-token-123...",
  "token_type": "bearer",
  "expires_in": 3600,
  "refresh_token": "new-refresh-token-456..."
}

Error Response

{
  "error": "invalid_request"
}

Possible causes:

  • Missing or expired Refresh_Token

  • Incorrect Grant_Type

  • Invalid or malformed Authorization header

Using the New Token

Once you receive the new access_token, include it in the Authorization header like this:

Authorization: Bearer new-access-token-123...
PreviousRequesting the Authorization CodeNextUpload Document for Signing

Last updated 25 days ago

Was this helpful?