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
To watch a walkthrough DEMO on generating your access token go to Creating your access token
Documents sent through the Sandbox are not legally binding.
Once you've completed your testing on our sandbox environment and are ready to have a live account, go to app.quicklysign.com and register an account.
If you're currently using V0 of the api, please see migration guide here
REST
We try to keep all our url endpoints RESTful. Most endpoints will support up to 4 HTTP verbs.
HTTP Verb | Description |
---|---|
GET | Fetches an entity or list of entities (more on this later) |
POST | Creates an entity |
PUT | Updates an entity |
DELETE | Deletes an entity |
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:
[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/v1
- Currently there are 2 versions available, the latest being v1.
Resource
- A minor change to note between the v0 and v1 API process we've introduced using /v1/document_packs instead of /v0/document.
- To see above fields in action, to grab all document_packs for your sandbox account you'll use: base_url/v1/document_packs
- To grab just a single/specific document pack using it's unique key, you'll simply provide the document_packs API with a <document_key>: base_url/v1/document_packs/<document_key>.
Relationships
- A minor change to note between the v0 and v1 API process we've introduces the team_key as a parameter to our /v1/document_packs API.
- For example, fetching documents belonging to a team/workspace: GET base_url/v1/document_packs?team_key=<team_key>
TO JUMP RIGHT IN
See our walkthrough DEMO's here, starting from creating your access token to setting up your first document_pack and sending it off for signatures! Start your walkthrough process here > Creating your access token
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
Updated over 2 years ago