API Overview
Last updated
Last updated
Our API is a RESTful API that provides a comprehensive set of trading-related functionalities. The API is organized into separate OpenAPI files, each covering a distinct domain. The currently available domains are:
Our API follows the OpenAPI 3.0 specification and utilizes the following naming convention:
ObjectData, used for POST operations. The schema will specify which fields are required.
Object, the full schema describing an entity. Includes all of the ObjectData and Object's metadata (such as the entity's identifier).
ObjectUpdate, the schema for performing an update of the object. The identifier of the object is outside of the schema and passed as a path parameter.
ObjectResult, used to package the outcome of POST operations, usually includes one field: the ID of the newly created object instance. Having this value in an object allows better reuse.
Objects, an array of Object, with pagination.
Array of Object, to be used when pagination is not required.
The API follows some principles and concepts to make it easy to use and integrate with.
Many objects have an attribute called externalId. The primary intention of this field is to allow partners to provide their identifiers. In workflows which pass through multiple subproviders, it is a good practice to have an identifier that is available across the whole workflow. This can save a lot of time in the unlikely situation of issue resolution. Another purpose of this field is duplicate detection. Some operations, such as money transfers, can be duplicated between two autonomous systems due to a network glitch or a bug. In most setups, such issue will cause the operation to be repeated. In such situation, operations that do not have unique fields can be double-booked. To prevent this from happening, the externalId is used to detect if a given operation command is pristine or a duplicate.
This environment is available for live testing, however real customer data or any otherwise sensitive information should never be used with it. We will always only use synthetically generated, coherent data in this environment and strongly recommend to not use any real data while testing or building an integration.
When the platform receives the request, it performs the static validation of the requests based on the rules defined in API specification and duplicate detection based on the external id attribute. In case of any issues the request is rejected with the Bad Request or Conflict status code. The platform is not able to perform the full request validation like checking if customer id is valid, customer is active or there is sufficient balance to perform the operation as requests are processed in asynchronous way.
The platform assigns a RECEIVED status to entities created by partners before the request is asynchronously processed. The RECEIVED status is assigned at the perimeter of our platform to help track receipt of partners' commands to our API. Until the partner is notified with the webhook that the request is processed, the status of the created entity is RECEIVED. In case when request does not pass the full validation, the status of the entity changes to INVALID. Otherwise, the entity is created with generated id in the uuid format and relevant status is assigned (for example: CREATED). This status of this entity can be changed to REJECTED as the asynchronous processing is divided into multiple stages for some entities. In other words, the INVALID status is used in scenarios where the API, when processing requests synchronously, would respond with HTTP status codes from the client error class.
The above logic refers only to creating entities. In case of update the request changes the status and data of the entity only when the request is correct, and it passed full request validation. Otherwise, a partner is notified about the reason of rejection of the update with the webhook which not contains status and modifiedOn because the entity was not updated.
The entities with status RECEIVED and INVALID are eventually removed from the platform. External id used by these entities are not removed and cannot be reused by partners.
The Authorization domain is responsible for providing secure access to the API. It includes endpoint for obtaining access tokens.
The Customers domain focuses on the onboarding and management of customers, as well as handling all customer-related information, specifically their documents. It provides a RESTful API that allows you to perform operations on different types of customers, including natural persons and legal entities. The key functionalities of the Customers domain include:
Retrieve a list of customers or a specific customer.
Create and update customer profiles for natural persons and legal entities.
Manage the onboarding process, including starting and retrieving onboarding information.
Documents management: add or replace documents for natural persons in accordance to their role.
Natural person identity management: for managing identity document and related metadata.
Document signature: for signing acceptance of terms and conditions per customer.
The Webhooks domain offers a RESTful API for managing webhooks, which are HTTP callbacks that allow you to receive real-time notifications about specific events occurring within your application. This domain enables you to create, retrieve, and delete webhooks for different event types such as customer and document notifications.
The Trading domain is focused on operations such as requesting quotes, placing orders and retrieving market data.
The Products domain contains information about customer products. It enables you to manage and retrieve product-related data, such as product definitions and customer products.
Each financial operation, such as transfer or order execution will register itself as a transaction. The Transaction History domain includes endpoints for browsing the history of any financial transactions.
The Transfers domain includes all operations for managing and executing money transfers across SEPA network.
For more detailed information about each domain, please refer to the corresponding OpenAPI file.