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.

The Ledger Enterprise API employs a rate limiter to help maximize its stability. You can track your rate limit status via dedicated API response headers: X-RateLimit-Limit, X-RateLimit-Remaining X-RateLimit-Reset, Retry-After When the rate limit is exceeded, the API will return a code 420 with rate limitation details

Note that Rate limits are specific to your API plan please get in touch with you Account Manager for more details.

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.