Vault API (1.8.1)

Download OpenAPI specification:Download

Introduction

Overview

The Ledger Vault exposes a RESTful API that you can integrate with your system. You can access it through a single Docker image deployed in your infrastructure, which exposes the different endpoints defined in this documentation.

The Ledger Vault's API allows you to:

  • Create, approve, or reject transactions.
  • Create and register API users.
  • Retrieve different kinds of information, such as details on existing accounts, groups, and whitelists.

For more information on the Ledger Vault API, refer to the Help Center.

Get in touch with your Account Manager to access the Ledger Vault API or fill out this form and we'll get back to you as soon as possible.

Rate limitations

Make sure you're aware of these limitations before you get started. You can't:

  • Create more than 100 pending requests at the same time in your Vault workspace.
  • Do more than 50 successful POST HTTP calls per hour on transaction route.
  • Do more than 600 successful POST HTTP calls per hour on other routes.

Pagination

When necessary we use a pagination mechanism to fetch big volumes of data when the dataset is too large.

For example, let's take a look at a call on the /transactions endpoint:

GET /transactions?page=2&page_size=5

Here, the API is queried to return the second page of our queryset, each page containing 5 elements

Here is the resulting json:

{
  "edges": [
    {
      "cursor": 0,
      "node": {...}
    },
    {
      "cursor": 1,
      "node": {...}
    },
    {
      "cursor": 2,
      "node": {...}
    },
    {
      "cursor": 3,
      "node": {...}
    },
    {
      "cursor": 4,
      "node": {...}
    }
  ],
  "page_info": {
    "count": 73,
    "has_next_page": True
  }
}

There are two properties, edges and page_info, at the root level, explained in the following sections.

The edges Property

This property contains the relevant data as a JSON array. Each element of this array is an object with two properties:

  • a cursor property which is an integer equivalent to the index of the element in the current view.
  • a node property which represents the actual object being queried, in this case a Transaction type (which schema is described in our openAPI specification).

The page_info Property

This property gives you the total number of objects contained in this particular queryset (count property), and allows you to know if the page you have queried is the last of a given view (has_next_page parameter).

About ordering

By default, results are sorted by creation date in descending order, newest objects being first.

We believe this makes search results more useful, but it can also be an issue when new objects are regularly added as this could affect pagination, creating what looks like duplicates in two successive pages.

This is particularly the case for transactions. If you were to successively fetch the first two pages of your transactions, and 20 new transactions were created between the two GET calls, then both responses would contain the exact same results.

This issue can be avoided by making further use of filters (on accounts, creation date, etc.) and we recommend that you always de-duplicate by using the object ids.