Skip to content

API introduction

This section introduces the basics of the Qredo Partner API. The Partner API is a standard RESTful web service that uses standard HTTPS communication and exchanges JSON-formatted data. The content type of requests (where applicable) and responses is application/json.

Configuration via API not visible in the Qredo Web app, and vice versa

Qredo provides isolated configuration between the API and the Web application. This results in separated management views: the Web app configuration cannot be viewed through the API, and API configuration is not visible via the Web application.

API environments and Base URLs

Currently, two API environments are available: API Production (prod) and API Play (the test env).


On Production, you have the option to perform both live and sandbox API calls using different authentication keys. To perform tests with the Production API, you can create and use Sandbox keys. For live operations you will need to generate and use production keys. See Generate keys for more info.

Base URL on Production

The same Base URL is available for both test and live API action. However, keys for authentication are different.

All API examples use the Prod base URL

All API call examples presented in this guide use the base URL for the Production environment.


Experience on Play is very similar as with Production. You follow the same process. Available with transactions of Testnet assets only. See the Play Swagger UI documentation. Note that the Swagger documentation on Play may be slightly different from Production.

Base URL on Play

API timestamps

All API timestamps are in Unix Epoch format.

API requests

The API requests use standard HTTP methods: GET, PUT, POST, DELETE. Every request submitted to the API must be signed and encrypted using an RSA key. This provides request integrity and adds a security layer in terms of authorization with the API service.

Request headers

All API resources use the same header format. The Qredo API uses RSA keys to sign and encrypt API requests. Each API call signature is combined with a timestamp or nonce. This ensures that each request is unique and also the response is readable only by the API user who has the private key to decrypt it.

With every API request header, you must supply:

  • accept: application/json: all payloads are in JSON.
  • x-nonce or Unix Epoch x-timestamp: use either (not both).
  • x-sign: a unique signature generated for each API request.
  • X-API-KEY: the API key copied from the Qredo web application.

Signatures in API calls headers

The x-sign header must contain the signature generated for the API request (including the JSON payload). It is coupled with either the x-timestamp header or x-nonce generated with the signature.

An example request header would contain information as shown:

-H "accept: application/json" \
-H "x-timestamp: <Epoch timestamp>" \
-H "x-sign: <signature generated_using your RSA key>" \
-H "X-API-KEY: <API key created in Qredo web app>" \

Note that this tutorial does not include complete examples in CLI using curl. You can copy curl API requests using Swagger UI.

Headers are excluded from examples

In this guide, the request headers are omitted in examples. You will need to generate the signature and timestamp with each API call. To facilitate your understanding and use of signatures, Qredo provides a dedicated example tool to sign and timestamp your requests.

Request examples

In this guide, all requests are presented as curl requests:

curl -X GET

The body of each request (where relevant) is presented as uncompressed JSON.

{"name": "random_inc"}

API responses

Responses use standard HTTP codes to indicate status and errors. Return data in responses of successful API calls is formatted as JSON.

Response examples

In this guide, the return data in each response is presented and formatted JSON.

  "company_id": "1va2cJ2pqdLSFAN5t1knBrnuMvw",

To avoid confusion or accidentally listing real user data, many of the actual values in response examples contain descriptions of expected data enclosed in <> so you can easily tell these are not actual values.

  "company_id": "<company_hash_id>",
  "total_count": "<total number of trusted parties>",
  "list": [
        "list": {
          "trusted_entity_id": "<user's trusted network ID>",
          "name": "<first and last name>",        
          "address": "<email address>",
          "type": "<user type>", 
          "created": "<Epoch timestamp>" 

Get started with the Partner API

The following steps and corresponding sections provide the flow to get you started with Qredo and the Partner API:

  1. Sign up using Qredo web app Qredo signing app and then apply for Partner API access. See Create account.
  2. With access granted, generate RSA keys for API call signatures, then generate your API key in the Qredo web app, and finally add public signing key on the very same screen in Qredo web app. See Generate keys.
  3. Learn how Start signing calls using the so called Partner API Signing client. See Sign API calls.

Last update: 2022-01-11