Getting Started

Welcome to Quicklysign API Documentaion

To get started, create a developer account in our Sandbox environment, this will allow you to generate an API key that you can use to start making API calls within our demo environment.

To register your developer account, you can go to sandbox.quicklysign.com

Documents sent through the Sandbox are not legally binding.

Once you are ready to have a live account, go to app.quicklysign.com and register an account.

REST

We try to keep all our url endpoints RESTful. Most endpoints will support up to 4 HTTP verbs.

Usage of these is outlined below.

Data formats

All data posted is in JSON Format.
All responses are JSON formatted.

URL Structure

The basic url structure used throughout the api is as follows, each explained below:
[Base_url][Base_url]/[Version]/[Resource]

Base url
In the live Quicklysign environment, all urls start with https://api.quicklysign.com.
If you're developing your application in the testing environment, then use https://sandboxapi.quicklysign.com as the base url.

Version
All url's include a version after the base url. base_url/v0
Currently there are 2 versions available, the latest being v1.

Resource
The plural name for an entity is used for indicating what type of resource you wish to retrieve. For example fetching all documents linked to your account you'll use:
GET base_url/v0/documents
Fetching an individual document:
GET base_url/v0/documents/<doc_key>

Relationships
If we want to fetch resources related to an entity we include the resource type relative to another resource.
For example, fetching documents belonging to a team
GET base_url/v0/teams/<team_key>/documents/

Response Structure

Envelope
All responses have an envelope as follows:

{
    "status": {
        "status_code": 200,
  	      "warnings":[
                     {"code":"warning code",
			                "message":"warning message"
                     }
      		],
      "information":[{"message":"message"}]
    },
    "data": {
        ...
    },
    "pagination": {
        "next": "..."
            }
}

Status
Status will return code 200 for successful operations, 400 for bad requests, 401 for unauthorised and 500 for internal server errors.
If there are warnings, but the request was successful, those will be included in the status.
The information property also isn't always shown unless needed.

In the event that status code 400, 401 or 500 is used, there will be an errors property which will contain details about the error.

Note that http status code is in the http response headers too.

Example error response

{
    "status":{
        "status_code": 400,	 
	        "errors":[
			             {"code”:"error code",
			              "message":"the error message"
                    }
                  ],
          "warnings":[
                    {"code":"warning code",
			               "message":"warning message"
                    }
      							],
         "information":[{"message":"message"}]
	  },
  
}

Data
Contains the data that is being returned. This could be an object or list of objects.

Pagination/Paging
Pagination will only be present when fetching collections of data. The “next” property takes the form of a url with the next cursor included in the url.

For clients that can't parse http error responses

Add the query string parameter always_use_http_status_code_200=true
This will return the http request with 200 status code, but the body will have the actual error.
Example clients that don't support parsing http error response:

• .net WebClient