Overview¶
Welcome to the Qredo User API. The User 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.
Work in progress
As of Q2 in 2022, the API and its respective documentation is work in progress and is subject to future updates. Currently, the Qredo user API offers the option to view the user's balance (read-only).
To take advantage of the Qredo user API, you must have a Qredo account with API access.
Get started with Qredo user API¶
The following steps and corresponding sections provide the flow to get you started with the Qredo User API:
- Sign up to Qredo using the Qredo web app and the Qredo signing app. Once account creation is complete sign in the web app. Go to account Settings in the web app and generate an API key and API secret. See Generate API key and secret.
- Learn how to sign API requests using your API secret using the dedicated API Tool provided by Qredo. See Sign API calls.
- Begin your experience with the User API.
API introduction¶
This section introduces the basics of the Qredo User API. The User 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.
API environments and Base URLs¶
Currently, two API environments are available: API Production (prod env) and API Play (the test env).
Production¶
On Production, everything you do pertains to real-life users and assets.
Base URL on Production
https://api.qredo.network/qapi/v1/
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.
Play¶
Experience on Play is very similar to that on Production. There are a few differences, for example, you can only use Testnet assets on Play. You can find more details this
Base URL on Play
https://play-api.qredo.network/qapi/v1/
Available with transactions of Testnet assets only.
Authentication¶
The header of every API request must contain your API key and API secret. The API key authenticates your API user whereas you sign and encrypt every API request using the API secret. For more info, see sections Generate API key & secret and Sign API calls.
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 the HMAC-SHA256 hashing algorithm. 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.
With every API request, you must supply the following headers:
| Header | Description |
|---|---|
accept: application/json |
All payloads are in JSON |
qredo-api-sig |
The unique signature generated for each API request (including the JSON payload where applicable) |
qredo-api-ts |
The signature timestamp |
qredo-api-key |
The API key as generated by the user in the Qredo web app |
Headers are excluded from examples
In this guide, the request headers are usually omitted in examples. You will need to generate and pass 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, requests are presented as curl requests:
curl -X GET https://api.qredo.network/qapi/v1/balance
The body of each request (where relevant) is presented as uncompressed JSON.
API responses¶
Responses use standard HTTP codes to indicate status and errors. Return data is in JSON format.
Response examples¶
In this guide, the return data in each response is presented as formatted JSON. For example, the return body of GET /balance is structured as follows:
{
"assets": {
"ETH-TESTNET": {
"total": 1800000000,
"available": 1800000000,
"pendingIn": 0,
"pendingOut": 0,
"scale": 1000000000
}
}
}
To avoid confusion or accidentally listing real user data, many of the actual values in response examples contain descriptions of expected data enclosed in brackets: [].
{
"assets": {
"[asset type, e.g. BTC or ETH]": {
"total": "[total value of assets per asset type, presented in base units]",
"available": "[total unlocked value of asset]",
"pendingIn": "[total value of inbound transfers pending approval]",
"pendingOut": "[total value of outbound transfers pending approval]",
"scale": "[the base units per asset type: *satoshis* per BTC, *gweis* per ETH]"
}
}
}