The Qredo API and Partner API are being deprecated and will be replaced by a breaking change in Q4. To receive updates about the release, register here.
Qredo Logo

Partner API


Deprecation Notice

The Qredo Partner API will be deprecated and replaced by Qredo API v2 in Q4 2023. If you want to use it, contact [email protected].

Web App v1/v2

The new Qredo Web App v2 is now available! If you're using the Partner API, you'll be migrated to the new Web App once we replace the Partner API with the new Qredo API v2. Right now you'll be temporarily redirected to the legacy Web App — Qredo Web App v1. All UI steps and concepts mentioned in this section match the legacy Web App.


  • Qredo Partner API v1 is a RESTful Open API 3 service
  • It provides the same functionality as Qredo Web App and Signing App
  • You can create Wallets and move assets
  • Requests must be signed and encrypted using an RSA key
  • This API integrates with the Signing Agent
  • Production and Sandbox environments are available
  • Get started here


This guide introduces the Qredo Partner API. Partner API allows you to perform all operations required to create Wallets and move assets under custody across the Qredo network: similar to the user experience via the Qredo Web App.

If you are not familiar with Qredo and want to learn more about our mission and our products, please visit the Qredo help center.

The Partner API is a 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 is not visible in the Qredo Web App, and vice versa

Qredo provides isolated configuration between Partner API and the Web App. 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.

If you are looking for an API that integrates with the Web App, checkout Qredo API


Partner API integrates with the Signing Agent, a programatic approval service that provides all the functionality that is available to an approver of outgoing Wallet transactions on the Qredo Signing App on mobile devices.

Who uses Partner API?

The Partner API enables ISVs, Exchanges, Custodians, and Market Makers to operate the Qredo Network programmatically from their own applications.

Institutions benefit from decentralized custody over digital assets and a customizable custody suite offering granular control over Wallets and their transactions. The Partner API allows institutions to fully rely on Qredo for custody over their digital assets. Once an Organization (your institution's entity within Qredo) deposits assets in their Qredo Wallets, any transaction out of these Wallets undergoes one or more approvals. The API provides custody policies over transaction approvals and Wallets in a modular way that can fit any business requirement, including automating approval according to pre-defined conditions with Signing Agent.

Partner API Overview

The Partner API allows you to perform actions available to the Qredo Wallet user on the Qredo Network, such as:

  • create and manage a company
  • create and manage a trusted network
  • create and manage one or more funds
  • add or remove one or more Wallets in fund
  • perform transactions (transfers and withdrawals)
  • perform atomic swaps

API-generated actions not integrated via the Qredo Web App!

Actions performed in the Partner API are not visible in the Qredo Wallet Web App, and vice-versa. This applies to Funds, Wallets, assets and transaction history. This is because the Partner API is designed for institutions and exchanges, not for API control over a regular user account.

API environments and Base URLs

Production and Sandbox environments are available. However, keys for authentication are different.


The Production environment allows you to perform both live and Sandbox API calls. You must create and use a dedicated set of keys for each. For test API calls on Production, you will use Sandbox keys. For live operations on Production, you will use production keys. See Generate keys for more info.



The experience on Sandbox is very similar to that on Production. You essentially follow the same process, but with a simplified flow:

  • You can only use Testnet assets on Sandbox
  • Your API access is enabled by default (no need to apply to be a Partner)

Test environment


API timestamps

All API timestamps are in Unix Epoch format.

API requests

The Partner API is served over HTTPS TLS v1.2+ to ensure data privacy; HTTP and HTTPS with TLS versions below 1.2 are not supported. All API requests must be made over HTTPS. Calls made over plain HTTP will fail. API requests without authentication will also fail. All requests must include a Content-Type of application/json and the body must be valid JSON.

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:

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 doesn't include complete examples in CLI using curl. You can copy curl API requests from the specification.

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. Payloads are returned in JSON format.

Response examples

In this guide, any payload is presented as 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 <>.

  "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>"

Error Messages

  "code": "<ERROR_CODE>",
  "msg": "<ERROR_MESSAGE>",
  "detail": {
    "reason": "<NOT_ALWAYS_PRESENT>"
  "code": 401,
  "msg": "Unauthorized",
  "detail": {
    "reason": "empty token"

Qredo uses conventional HTTP response codes to indicate the success or failure of an API request. In general: Codes in the 2xx range indicate success. Codes in the 4xxrange indicate an error that failed given the information provided (e.g. a required parameter was omitted). Codes in the 5xx range indicate an error with Qredo servers (rare).

Some 4xx errors include an error code explaining the error reported.

All errors are returned with the same structure:

Error CodeMeaning
400Bad Request -- The request was not accepted typically due to invalid syntax. Make sure your request is formatted correctly.
401Unauthorized -- The request doesn't have permission to perform the request. Make sure you've entered a correct API Key for authentication.
403Forbidden -- The API key doesn't have permission to perform the request. Is your account set up? Contact Support
404Not Found -- The requested resource doesn't exist. Make sure you've formatted the URL correctly.
429Too Many Requests -- Too many requests hit the API too quickly. Please try again later.
50xInternal Server Error -- Something went wrong on Qredo's end (rare). Please try again later.

Specific data types

The API uses standard tickers for the supported Layer 1 currencies (also referred to as assets). See the full list of supported assets and their tickers.

Use the GET/assets endpoint to retrieve the up-to-date list of all supported L1 assets and scale of the denomination units of each.

Assets and asset types

The cryptocurrency data type used across API endpoints could be asset or asset types, and also code or unicode. For example: "code":"BTC".

Assets amounts and scale

The asset amounts are presented in base units per currency. For example, the base currency of BTC is called satoshi and presents BTC amounts at scale 1:100,000,000. This means that 1 Bitcoin is presented as 100 million satoshi. Likewise, ETH amounts are presented in gwei at scale 1:1000 million. This means that 1 ETH equals 1 billion gwei.


A publicly released version of the Partner API will never change in any way that could impact clients' integrations.

Whenever Qredo makes any API change, a new version of an API will be released that clients can choose to upgrade their integration to.

Read-only API