Download OpenAPI specification:Download
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:
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.
edges
PropertyThis property contains the relevant data as a JSON array. Each element of this array is an object with two properties:
cursor
property which is an integer equivalent to the index of the element
in the current view.node
property which represents the actual object being queried, in this
case a Transaction
type (which schema is described in our openAPI
specification).page_info
PropertyThis 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).
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.