VNX Platform API v1 (1.2.5)

This document describes usage of the VNX Platform Trading API that allows minting, burning and trading of VNX coins in an automated manner. Our API is organized into publicly accessible endpoints (trading pairs, quotes) which require authentication with a public key only, and private authenticated endpoints (balance, trading) which require requests to be signed with a private key. You can generate API keys in the My Account section on the VNX Platform.

Requests

Request payloads are form-encoded (Content-Type: application/x-www-form-urlencoded) or JSON (Content-Type: application/json), and all requests must specify a User-Agent header.

Responses

Responses are JSON encoded and differ for accepted(received) and error responses. The accepted response contains keys specific to a particular request and possibly an error key in case of business level error (reject)

Examples of Accepted(Received) Response

  {
      "timestamp": "2021-03-22T17:18:03Z",
      "OrdId": 1,
      "OrdStatus": "Filled"
  }

  {
      "timestamp": "2021-03-22T17:18:03Z",
      "ordId": 2,
      "ordStatus": "Rejected",
      "error": {
          "code": "limit_too_far_from_market_price",
          "message": "The limit price is too far from the market price" 
      }
  }

The error response has HTTP status other than Ok and contains the key error with subkeys: code, status, message.

Example Error Response

  {
      "code": "invalid_nonce",
      "status": 400,
      "message": "Invalid nonce"
  }

An ECDSA256 public-private keys pair is required to access the authenticated endpoints, you can generate the keys in the My Account section on the VNX Platform

CAUTION Never share your private key with anyone, it should only be used to generate the x-app-signed-data signature for your request

Authenticated requests must include x-app-public-key, x-app-signed-data and x-app-nonce HTTP headers.

x-app-nonce

The nonce. Nonce must be an always increasing, unsigned 64-bit integer, unique for each request that is made with a particular Public key. While a simple counter starting from 1 would provide a valid nonce, a more usual method of generating a valid nonce is to use a UNIX timestamp in milliseconds.

NOTE There is no way to reset the nonce for a Public key to a lower value, so be sure to use a nonce generation method that won't produce numbers less than the previous nonce. Too many requests with invalid nonces can result in temporary bans. Problems can arise from requests arriving out of order due to Public keys being shared across processes, or from system clock drift/recalibration.

x-app-public-key

The Public key of your key pair

x-app-signed-data

Encrypted signature of your message. Authenticated requests must be signed with a signature generated with your private key, nonce, payload, and URI path according to:

Sign of (URI path + POST data + nonce) with private key and convert it to base64url

The code snippet for generating the signature in Node.js follows below.

Code Examples

Node JS

  const crypto = require('crypto');

  /** Sign Data
  *
  * @param {string} path         - URL of the request endpoint starting with /api, e.g. /api/v1/private/queryOrders
  * @param {object} request      - JSON object with all parameters and their values, e.g. {symbol:"VCHF/CHF"}
  * @param {number} nonce        - unique always increasing positive integer number, e.g. UNIX timestamp in milliseconds
  * @param {string} pk64         - base64 encoded private key in PEM format
  */
  signData(path, request, nonce, pk64) {

    // Create private key object
    let pk = Buffer.from(pk64, 'base64').toString();

    const sortedRequest = sortObjectDeep(request);
    const data = path + JSON.stringify(sortedRequest) + String(nonce);

    const signer = crypto.createSign('sha256');
    signer.update(data);
    signer.end();

    // Create signature
    const signature = signer.sign(pk);
    // Convert signature to Base64url
    const signatureBase64url = signature.toString('base64');

    return signatureBase64url;

  }

Request body (POST data) must be serialized into canonical JSON with recursive lexicographic key ordering. The code snippet for sortObjectDeep method in Node.js follows below.

Code Examples

Node JS

  /**
  * Recursively sorts object keys in lexicographic order to produce a canonical JSON structure.
  *
  * Request body must be serialized into canonical JSON with recursive lexicographic key ordering.
  *
  * This function:
  * - Sorts keys of plain objects (`{}`) at all nesting levels
  * - Preserves array order (does NOT sort arrays, only processes their elements)
  * - Leaves primitive values (string, number, boolean, null) unchanged
  * - Ignores non-plain objects (Date, Buffer, class instances, etc.)
  *
  * The resulting object can be safely passed to `JSON.stringify()` to produce
  * a deterministic and stable string representation for cryptographic signing.
  *
  * @param {*} value - Any JSON-serializable value (object, array, primitive)
  * @returns {*} New value with all object keys sorted recursively
  *
  */
  function sortObjectDeep(value) {
      if (Array.isArray(value)) {
          return value.map(sortObjectDeep);
      }

      if (value && typeof value === 'object' && value.constructor === Object) {
          const sorted = {};
          Object.keys(value)
              .sort()
              .forEach((key) => {
                  sorted[key] = sortObjectDeep(value[key]);
              });
          return sorted;
      }

      return value;
  }

We have various safeguards in place to protect against system abuse, DDoS attacks, etc. For REST API requests, these are broadly organised into request limits specific to the REST API.

NOTE (Temporary) Maximum 1 request per 1 sec for a particular Public key.

• June 2024 - Initial version
• September 2024 - Added queryOrders and queryTrades endpoints
• November 2024 - Added assets, depositAddress, withdrawAddresses, withdraw, mintTokens and burnTokens endpoints
• June 2025 - Added support for dest_tag on XRP blockchain
• October 2025 - Modified fee structure in Get Trading Pairs response
• March 2026 - Modified quotes and assets responses, updated mintTokens and burnTokens endpoints to fully support minting and burning of commodity based tokens (e.g. VNXAU), added querySupplyChanges endpoint
• April 2026 - added Payment Rails endpoints

Below you can find the endpoints that require authentication with a public key.

Below you can find the endpoints that require requests to be signed with a private key.

Below you can find the endpoints that require JSON (Content-Type: application/json) requests to be signed with a private key.