Overview

The B2Core IB REST API provides methods for performing CRUD operations to B2Core IB objects. The API returns JSON-encoded responses unless some other data format is requested and uses standard HTTP headers, methods, response codes and authentication.

A text payload for requests and responses is encoded in UTF-8.

In method descriptions, the parameters that must be included in requests are marked as required.


Base URL

All endpoints are relative to the API base URL ([base]).

To find your base URL for making requests, navigate to Introducing brokers > Preferences > Network in the B2Core Back Office. Your base URL is available in the API base URL field of the Network section.


HTTP headers

Depending on the request, you can include the following HTTP headers in your requests:

Accept: <media-type>

Indicates the response format, which is required to operate with a response body.

For example: Accept: application/json

Accept-Language: <language-code>

Indicates the natural language, which is required to operate with a response body.

For example: Accept-Language: ja

Content-Type: <media-type>

Indicates the request format, which is required to operate with a request body.

For example: Content-Type: application/json


Supported HTTP methods

The B2Core IB API uses the following HTTP methods:

POST

Creates a resource.

GET

Reads a resource.

PUT

Updates a resource. Instead of this method, you can use a similar method that uses the HTTP verb PATCH.

PATCH

Updates a resource. Instead of this method, you can use a similar method that uses the HTTP verb PUT.

DELETE

Removes a resource.


HTTP response codes

The B2Core IB API uses standard HTTP response codes to indicate the success or failure of a request:

Successful responses

200 OK

The request succeeded.

201 Created

The request succeeded, and a new resource was created as a result. This is typically the response sent after POST requests.

202 Accepted

The request was accepted for processing, but the processing will start later.

204 No Content

The request succeeded, but returned no response body.

Client error responses

400 Bad Request

The request was invalid (for example, malformed or syntactically incorrect). This code may indicate one of the following issues:

  • The API can’t convert the payload data to the underlying data type.

  • The data isn’t in the expected data format.

  • Required fields aren’t available.

  • A data validation error occurred.

401 Unauthorized

The request didn’t include an authentication token or the authentication token was expired.

403 Forbidden

The client didn’t have permissions to access the requested resource.

404 Not Found

The requested resource wasn’t found because the specified URI was invalid or the requested resource was unavailable (for example, a URI pointed to an empty database).

405 Method Not Allowed

The HTTP method in the request wasn’t supported by the resource.

406 Not Acceptable

The request wasn’t completed because the server doesn’t support the requested response format. For example, the request contained the Accept: application/xml header, but the API can generate only the application/json response format.

413 Payload Too Large

The request payload was larger than the server was able to process.

415 Unsupported Media Type

The request was rejected by the sever because it doesn’t support the requested data format. For example, the request contained the Content-Type: application/xml header, but the API only accepts the application/json request format.

429 Too Many Requests

The rate limit was reached. The rate limit set for the user, app, or token exceeded a predefined value.

Server error responses

500 Internal Server Error

The request wasn’t completed due to an internal error on the server side.

503 Service Unavailable

The server is down for maintenance.

For a full list of valid response codes, refer to the IANA HTTP Status Code Registry.


Query parameters

When invoking methods, you can additionally specify your requests by applying one or more query parameters divided by &.

Pagination

Pagination enables you to control the output of an HTTP response.

These parameters are universal and applicable to all GET-requests that return a list of entities.

limit

Specify this parameter to define the maximum number of items that may be returned in a response.

The minimum value is 1. The maximum value is 1000. The default value is 10.

For example, limit=10 returns the first ten items.

offset

Specify this parameter to exclude from a response the first N items of a resource collection.

The minimum value is 0. No maximum value. The default value — 0.

For example, offset=5&limit=5 returns the items 6 through 10.

Filtering

Filters help you refine searching within a collection.

This parameter is applicable to all GET-requests that return a list of entities.

You can filter an entities list by one or more properties at a time; available filter parameters are listed in the Query parameters section of each method.

By default, all filters are disabled.

filter

To apply a filter, specify a key-value pair in the following format: filter[<key>]=<value>.

For example: filter[currencyAlphaCode]=BTC.

If a method supports multiple filter parameters, you may include them in a single request.

For example: filter[clientId]=1&filter[platformId]=2&filter[productId]=3

Sorting

Sorting helps you facilitate the output of an HTTP response by organizing a list of entities in a defined order.

These parameters are applicable to all GET-requests that return a list of entities.

You can sort an entities list by only one property at a time; available sorting parameters are listed in the Query parameters section for each method.

By default, sorting by createTime in descending order is applied.

sort_by

Sort items in the response by a specified parameter.

For example: sort_by=createTime.

sort_order

Sorts the items in the response in the ascending or descending order.

For example: sort_by=createTime&sort_order=asc or sort_by=createTime&sort_order=desc

Query

Queries allow you to extend a response body with additional information.

This parameter is applicable to all GET, POST and PUT requests.

You can use one or more queries at a time; available options are described in the Query parameters section for each method.

By default, all queries are disabled.

query

Specify additional information which should be included in the response in the following format: query[<key>]=<value>, where <value> is boolean: 1 — true, 0 — false.

For example: query[profile]=1

If a method supports multiple query parameters, you may include them in a single request.

For example: query[contacts]=1&query[links]=1


Date and time formats

The B2Core IB API supports the RFC 3339 format for date and time representation.

Such formats as the Unix timestamp or LDAP timestamp, that are often used on trading platforms and return no ambiguous data, are also supported in responses.


Integrations

The B2Core IB API provides for the possibility of integration into external systems.

Most of IB objects contain the uuid field which can be used to store an external ID, hash or any other identifier represented as a string value up to 255 characters.

Using this field, you can map data of an external database with your IB instance (clicks, page views and so on). It can be useful, for example, for data impersonalization when you don’t want personal data of your clients to be stored and processed in IB.