Match-Trade

Introduction

Authentication

gRPC

PositionsServiceExternal

LedgerServiceExternal

GroupServiceExternal

TradingEventsServiceExternal

OrderServiceExternal

QuotationsServiceExternal

AccountInfoServiceExternal

SymbolsServiceExternal

Errors

Examples

Branches, Offers, Roles

Get Branches

Get Offers

Get Roles

Accounts

Get Accounts

Get Account by Email

Get Account by UUID

Get Account's Timeline Events

Create Account

Update Account Info

Change Account's Password

Add Note

Add Task

Trading Accounts

Payments

Get Payment Gateways

Get Deposits

Get Withdrawals

Manual Deposit

Manual Withdrawal

Credit In

Credit Out

Trading

Get Symbols

Open Position

Create Pending Order

Cancel Pending Order

Edit Position

Close Position

Close Position (Partially)

Trading Data

Prop Trading

Prop gRPC

Configuration

Challenges

Targets

Evaluation Requests

Competitions

Add Ons

Admin Gateway

Broker API

Sandbox

<p class="slate-p " >The Broker API is a versatile API platform designed for various integrations, enabling streamlined management and interaction with multiple services through a single access point. This API supports REST and gRPC protocols, providing flexibility in integration and ensuring compatibility with diverse client systems. It facilitates secure, efficient administrative operations and service management, making it an essential tool for clients looking to optimize their operational workflows.</p><p class="slate-p " >In our system, each broker has a unique <code class="slate-code">partnerID</code> assigned. Every operation via this API is performed within that particular partnerID. Since we encode your partnerID in your Authorization token, you don&apos;t have to consider this parameter when sending requests, but you will see this parameter across multiple different endpoints. For the Sandbox environment, <code class="slate-code">partnerID</code> = 0 and is shared between every account in the system. It means you will have access to test data added by other integrations.</p><p class="slate-p " ></p><div style="width:100%;
	min-width:100%;" class="callout-widget" data-type=info ><div class="callout-icon"><svg width="20" height="20" viewBox="0 0 20 20" fill="none" xmlns="http://www.w3.org/2000/svg"><path d="M10.0628 14.1676C10.2434 14.1676 10.3927 14.1086 10.5107 13.9905C10.6288 13.8725 10.6878 13.7232 10.6878 13.5426V9.77177C10.6878 9.6051 10.6253 9.46274 10.5003 9.34469C10.3753 9.22663 10.2295 9.1676 10.0628 9.1676C9.88227 9.1676 9.73296 9.22663 9.61491 9.34469C9.49685 9.46274 9.43783 9.61205 9.43783 9.7926V13.5634C9.43783 13.7301 9.50033 13.8725 9.62533 13.9905C9.75033 14.1086 9.89616 14.1676 10.0628 14.1676ZM10.0003 7.62594C10.1948 7.62594 10.358 7.56344 10.4899 7.43844C10.6219 7.31344 10.6878 7.15371 10.6878 6.95927C10.6878 6.76482 10.6219 6.59816 10.4899 6.45927C10.358 6.32038 10.1948 6.25094 10.0003 6.25094C9.80588 6.25094 9.64269 6.32038 9.51074 6.45927C9.3788 6.59816 9.31283 6.76482 9.31283 6.95927C9.31283 7.15371 9.3788 7.31344 9.51074 7.43844C9.64269 7.56344 9.80588 7.62594 10.0003 7.62594ZM10.0003 18.3343C8.81977 18.3343 7.72255 18.1225 6.70866 17.6989C5.69477 17.2752 4.81283 16.6884 4.06283 15.9384C3.31283 15.1884 2.72602 14.3065 2.30241 13.2926C1.8788 12.2787 1.66699 11.1815 1.66699 10.0009C1.66699 8.83427 1.8788 7.74399 2.30241 6.7301C2.72602 5.71621 3.31283 4.83427 4.06283 4.08427C4.81283 3.33427 5.69477 2.74399 6.70866 2.31344C7.72255 1.88288 8.81977 1.6676 10.0003 1.6676C11.167 1.6676 12.2573 1.88288 13.2712 2.31344C14.285 2.74399 15.167 3.33427 15.917 4.08427C16.667 4.83427 17.2573 5.71621 17.6878 6.7301C18.1184 7.74399 18.3337 8.83427 18.3337 10.0009C18.3337 11.1815 18.1184 12.2787 17.6878 13.2926C17.2573 14.3065 16.667 15.1884 15.917 15.9384C15.167 16.6884 14.285 17.2752 13.2712 17.6989C12.2573 18.1225 11.167 18.3343 10.0003 18.3343ZM10.0003 17.0843C11.9448 17.0843 13.6114 16.3898 15.0003 15.0009C16.3892 13.612 17.0837 11.9454 17.0837 10.0009C17.0837 8.05649 16.3892 6.38982 15.0003 5.00094C13.6114 3.61205 11.9448 2.9176 10.0003 2.9176C8.05588 2.9176 6.38921 3.61205 5.00033 5.00094C3.61144 6.38982 2.91699 8.05649 2.91699 10.0009C2.91699 11.9454 3.61144 13.612 5.00033 15.0009C6.38921 16.3898 8.05588 17.0843 10.0003 17.0843Z" fill="#3960B4"></path></svg></div><div ><p class="slate-p " >Server time is GMT (UTC+0). </p></div></div><div style="width:100%;
	min-width:100%;" class="callout-widget" data-type=info ><div class="callout-icon"><svg width="20" height="20" viewBox="0 0 20 20" fill="none" xmlns="http://www.w3.org/2000/svg"><path d="M10.0628 14.1676C10.2434 14.1676 10.3927 14.1086 10.5107 13.9905C10.6288 13.8725 10.6878 13.7232 10.6878 13.5426V9.77177C10.6878 9.6051 10.6253 9.46274 10.5003 9.34469C10.3753 9.22663 10.2295 9.1676 10.0628 9.1676C9.88227 9.1676 9.73296 9.22663 9.61491 9.34469C9.49685 9.46274 9.43783 9.61205 9.43783 9.7926V13.5634C9.43783 13.7301 9.50033 13.8725 9.62533 13.9905C9.75033 14.1086 9.89616 14.1676 10.0628 14.1676ZM10.0003 7.62594C10.1948 7.62594 10.358 7.56344 10.4899 7.43844C10.6219 7.31344 10.6878 7.15371 10.6878 6.95927C10.6878 6.76482 10.6219 6.59816 10.4899 6.45927C10.358 6.32038 10.1948 6.25094 10.0003 6.25094C9.80588 6.25094 9.64269 6.32038 9.51074 6.45927C9.3788 6.59816 9.31283 6.76482 9.31283 6.95927C9.31283 7.15371 9.3788 7.31344 9.51074 7.43844C9.64269 7.56344 9.80588 7.62594 10.0003 7.62594ZM10.0003 18.3343C8.81977 18.3343 7.72255 18.1225 6.70866 17.6989C5.69477 17.2752 4.81283 16.6884 4.06283 15.9384C3.31283 15.1884 2.72602 14.3065 2.30241 13.2926C1.8788 12.2787 1.66699 11.1815 1.66699 10.0009C1.66699 8.83427 1.8788 7.74399 2.30241 6.7301C2.72602 5.71621 3.31283 4.83427 4.06283 4.08427C4.81283 3.33427 5.69477 2.74399 6.70866 2.31344C7.72255 1.88288 8.81977 1.6676 10.0003 1.6676C11.167 1.6676 12.2573 1.88288 13.2712 2.31344C14.285 2.74399 15.167 3.33427 15.917 4.08427C16.667 4.83427 17.2573 5.71621 17.6878 6.7301C18.1184 7.74399 18.3337 8.83427 18.3337 10.0009C18.3337 11.1815 18.1184 12.2787 17.6878 13.2926C17.2573 14.3065 16.667 15.1884 15.917 15.9384C15.167 16.6884 14.285 17.2752 13.2712 17.6989C12.2573 18.1225 11.167 18.3343 10.0003 18.3343ZM10.0003 17.0843C11.9448 17.0843 13.6114 16.3898 15.0003 15.0009C16.3892 13.612 17.0837 11.9454 17.0837 10.0009C17.0837 8.05649 16.3892 6.38982 15.0003 5.00094C13.6114 3.61205 11.9448 2.9176 10.0003 2.9176C8.05588 2.9176 6.38921 3.61205 5.00033 5.00094C3.61144 6.38982 2.91699 8.05649 2.91699 10.0009C2.91699 11.9454 3.61144 13.612 5.00033 15.0009C6.38921 16.3898 8.05588 17.0843 10.0003 17.0843Z" fill="#3960B4"></path></svg></div><div ><p class="slate-p " >All time-related fields accept and return values according to the RFC 3339 standard. For example <code class="slate-code">2024-01-13T09:20:04.651Z</code>.</p></div></div><div style="width:100%;
	min-width:100%;" class="callout-widget" data-type=info ><div class="callout-icon"><svg width="20" height="20" viewBox="0 0 20 20" fill="none" xmlns="http://www.w3.org/2000/svg"><path d="M10.0628 14.1676C10.2434 14.1676 10.3927 14.1086 10.5107 13.9905C10.6288 13.8725 10.6878 13.7232 10.6878 13.5426V9.77177C10.6878 9.6051 10.6253 9.46274 10.5003 9.34469C10.3753 9.22663 10.2295 9.1676 10.0628 9.1676C9.88227 9.1676 9.73296 9.22663 9.61491 9.34469C9.49685 9.46274 9.43783 9.61205 9.43783 9.7926V13.5634C9.43783 13.7301 9.50033 13.8725 9.62533 13.9905C9.75033 14.1086 9.89616 14.1676 10.0628 14.1676ZM10.0003 7.62594C10.1948 7.62594 10.358 7.56344 10.4899 7.43844C10.6219 7.31344 10.6878 7.15371 10.6878 6.95927C10.6878 6.76482 10.6219 6.59816 10.4899 6.45927C10.358 6.32038 10.1948 6.25094 10.0003 6.25094C9.80588 6.25094 9.64269 6.32038 9.51074 6.45927C9.3788 6.59816 9.31283 6.76482 9.31283 6.95927C9.31283 7.15371 9.3788 7.31344 9.51074 7.43844C9.64269 7.56344 9.80588 7.62594 10.0003 7.62594ZM10.0003 18.3343C8.81977 18.3343 7.72255 18.1225 6.70866 17.6989C5.69477 17.2752 4.81283 16.6884 4.06283 15.9384C3.31283 15.1884 2.72602 14.3065 2.30241 13.2926C1.8788 12.2787 1.66699 11.1815 1.66699 10.0009C1.66699 8.83427 1.8788 7.74399 2.30241 6.7301C2.72602 5.71621 3.31283 4.83427 4.06283 4.08427C4.81283 3.33427 5.69477 2.74399 6.70866 2.31344C7.72255 1.88288 8.81977 1.6676 10.0003 1.6676C11.167 1.6676 12.2573 1.88288 13.2712 2.31344C14.285 2.74399 15.167 3.33427 15.917 4.08427C16.667 4.83427 17.2573 5.71621 17.6878 6.7301C18.1184 7.74399 18.3337 8.83427 18.3337 10.0009C18.3337 11.1815 18.1184 12.2787 17.6878 13.2926C17.2573 14.3065 16.667 15.1884 15.917 15.9384C15.167 16.6884 14.285 17.2752 13.2712 17.6989C12.2573 18.1225 11.167 18.3343 10.0003 18.3343ZM10.0003 17.0843C11.9448 17.0843 13.6114 16.3898 15.0003 15.0009C16.3892 13.612 17.0837 11.9454 17.0837 10.0009C17.0837 8.05649 16.3892 6.38982 15.0003 5.00094C13.6114 3.61205 11.9448 2.9176 10.0003 2.9176C8.05588 2.9176 6.38921 3.61205 5.00033 5.00094C3.61144 6.38982 2.91699 8.05649 2.91699 10.0009C2.91699 11.9454 3.61144 13.612 5.00033 15.0009C6.38921 16.3898 8.05588 17.0843 10.0003 17.0843Z" fill="#3960B4"></path></svg></div><div ><p class="slate-p " >The request limit is 500 requests/minute. </p></div></div><p class="slate-p " ></p><p class="slate-p " ></p><p class="slate-p " ></p><p class="slate-p " ></p><p class="slate-p " ></p>

The Broker API is a versatile API platform designed for various integrations, enabling streamlined management and interaction with multiple services through a single access point. This API supports REST and gRPC protocols, providing flexibility in integration and ensuring compatibility with diverse client systems. It facilitates secure, efficient administrative operations and service management, making it an essential tool for clients looking to optimize their operational workflows.

 assigned. Every operation via this API is performed within that particular partnerID. Since we encode your partnerID in your Authorization token, you don't have to consider this parameter when sending requests, but you will see this parameter across multiple different endpoints. For the Sandbox environment, 

 = 0 and is shared between every account in the system. It means you will have access to test data added by other integrations.

<p class="slate-p " >Our system implements a security mechanism that utilizes token-based authorization to ensure secure resource access. The authentication process involves using an <span style="color:var(--tw-prose-code)"><code class="slate-code"><strong class="slate-bold">Authorization</strong></code></span> header, following the token scheme. This section outlines the steps required for obtaining and using the authentication token to access protected resources.</p><h2 class="slate-h2 " >Obtaining the Token</h2><p class="slate-p " >The authentication token is obtained from our Customer Relationship Management (CRM) system. You must first authenticate yourself within the CRM to receive a token. This token acts as a digital key, granting access to the system&apos;s resources for the duration of the token&apos;s validity. Tokens are valid until revoked.</p><h2 class="slate-h2 " >Using the Token for Access</h2><p class="slate-p " >Once the token is obtained, it must be included in the request to access secured resources within our system. The token is added to the HTTP request&apos;s header as follows:</p><div class="code-block-wrapper"  style="width:100%;min-width:100%" ><div class="code-block-header">Plain text</div><pre class="slate-CodeBlockElement slate-code_block"><textarea id="publishedPageCodeblock" style="display:none !important; visibility: hidden; opacity: 0; width: 1px; height: 1px;" type="hidden"> </textarea><code class="language- keep-markup drop-tokens"><div class="slate-code_line">Authorization: &lt;Your_Token_Here&gt;</div></code></pre></div><h2 class="slate-h2 " >Incorporating Authorization in gRPC Requests</h2><p class="slate-p " >In gRPC, the traditional concept of HTTP headers is abstracted through metadata, allowing for the transmission of key-value pairs alongside RPC calls. To secure gRPC services with token-based authentication, the Authorization metadata must be included with each call. This process is similar to using the Authorization header in HTTP requests but is adapted to fit the gRPC framework.</p><h3 class="slate-h3 " >Adding the Authorization Metadata</h3><p class="slate-p " >To include an authentication token in a gRPC request, the token must be added to the call&apos;s metadata using the &apos;Authorization&apos; key, followed by the token value. This ensures that the server side of the gRPC service can authenticate the request by validating the token.</p><h3 class="slate-h3 " >Code Example (Python)</h3><p class="slate-p " >Below is a generic example of how to add the Authorization metadata in a gRPC client application. The implementation may vary depending on the programming language and gRPC library used.</p><div class="code-block-wrapper"  style="width:100%;min-width:100%" ><div class="code-block-header">Plain text</div><pre class="slate-CodeBlockElement slate-code_block"><textarea id="publishedPageCodeblock" style="display:none !important; visibility: hidden; opacity: 0; width: 1px; height: 1px;" type="hidden"> </textarea><code class="language-python keep-markup drop-tokens"><div class="slate-code_line">pythonCopy codeimport grpc</div><div class="slate-code_line"></div><div class="slate-code_line"># Create a gRPC channel</div><div class="slate-code_line">channel = grpc.insecure_channel(&apos;your_grpc_service_endpoint&apos;)</div><div class="slate-code_line"></div><div class="slate-code_line"># Prepare metadata with the Authorization token</div><div class="slate-code_line">metadata = [(&apos;Authorization&apos;, &apos;&lt;Your_Token_Here&gt;&apos;)]</div><div class="slate-code_line"></div><div class="slate-code_line"># Create a stub (client)</div><div class="slate-code_line">stub = YourServiceStub(channel)</div><div class="slate-code_line"></div><div class="slate-code_line"># Make a call with the Authorization metadata</div><div class="slate-code_line">response = stub.YourRpcMethod(request, metadata=metadata)</div></code></pre></div><p class="slate-p " >Replace <span style="color:var(--tw-prose-code)"><code class="slate-code"><strong class="slate-bold">&lt;Your_Token_Here&gt;</strong></code></span> with the actual token obtained from your CRM system, and adjust <span style="color:var(--tw-prose-code)"><code class="slate-code"><strong class="slate-bold">YourServiceStub</strong></code></span> and <span style="color:var(--tw-prose-code)"><code class="slate-code"><strong class="slate-bold">YourRpcMethod</strong></code></span> to match your gRPC service definition.</p><p class="slate-p " ></p><p class="slate-p " ></p>

Our system implements a security mechanism that utilizes token-based authorization to ensure secure resource access. The authentication process involves using an 

 header, following the token scheme. This section outlines the steps required for obtaining and using the authentication token to access protected resources.

The authentication token is obtained from our Customer Relationship Management (CRM) system. You must first authenticate yourself within the CRM to receive a token. This token acts as a digital key, granting access to the system's resources for the duration of the token's validity. Tokens are valid until revoked.

Once the token is obtained, it must be included in the request to access secured resources within our system. The token is added to the HTTP request's header as follows:

Incorporating Authorization in gRPC Requests

In gRPC, the traditional concept of HTTP headers is abstracted through metadata, allowing for the transmission of key-value pairs alongside RPC calls. To secure gRPC services with token-based authentication, the Authorization metadata must be included with each call. This process is similar to using the Authorization header in HTTP requests but is adapted to fit the gRPC framework.

To include an authentication token in a gRPC request, the token must be added to the call's metadata using the 'Authorization' key, followed by the token value. This ensures that the server side of the gRPC service can authenticate the request by validating the token.

Below is a generic example of how to add the Authorization metadata in a gRPC client application. The implementation may vary depending on the programming language and gRPC library used.

 with the actual token obtained from your CRM system, and adjust 

This gRPC model defines several services within a package designed for the Broker API, focusing on positions, ledgers, trading events, and related data. Below is the complete documentation for all services and their methods.

<p class="slate-p" placeholder="Type / for widgets">We use standard HTTP response codes to state the success or failure of API requests. It means that codes in the range</p><ul class="slate-ul"><li class="slate-li"><div style="position:relative">2xx indicate success and usually have response bodies,</div></li><li class="slate-li"><div style="position:relative">4xx indicate errors with detailed answers to why a particular request failed,</div></li><li class="slate-li"><div style="position:relative">5xx indicate errors on our servers.</div></li></ul><p class="slate-p" placeholder="Type / for widgets"></p>

We use standard HTTP response codes to state the success or failure of API requests. It means that codes in the range

The request was performed successfully. You should receive a response with a body. 200 response bodies are listed in each endpoint's response section.

200 - OK

The request was performed successfully. You should receive a response without a body.

204 - No Content

Invalid request, usually due to missing some required parameter.

400 - Bad Request

Authorization information is missing or invalid.

401 - Unauthorized

Your API token does not have permission to perform the requested operation.

403 - Forbidden

The server understands the content type of the request entity, and the syntax is correct, but it was unable to process the request.

422 - Unprocessable Entity

Something went wrong on our end. You can contact our Product Support to check it.

500 - Internal Server Error

<p class="slate-p " >In our system, there is a distinction between multiple layers of account attributes. In general, the account operates within the frames of a given: Branch, Offer(s), and Role. Each section has an explanation of a particular layer.</p><p class="slate-p " >Via our API you cannot edit Branches, Offers, and Roles configuration (it can be done only by using our CRM), but it's important to know them since you will need them to efficiently manage accounts created in the system. That's why we share GET endpoints, where you can check Branches, Offers, and Roles available in your setup.</p><p class="slate-p " ></p><p class="slate-p " ></p>

In our system, there is a distinction between multiple layers of account attributes. In general, the account operates within the frames of a given: Branch, Offer(s), and Role. Each section has an explanation of a particular layer.

Via our API you cannot edit Branches, Offers, and Roles configuration (it can be done only by using our CRM), but it's important to know them since you will need them to efficiently manage accounts created in the system. That's why we share GET endpoints, where you can check Branches, Offers, and Roles available in your setup.

<p class="slate-p " >In the Accounts section, you will find detailed information about user accounts within the system. With this, you can access and update account details and create new accounts. This section serves as a central hub for overseeing and administering user accounts within the system. You can also find a Trading Accounts sub-section within the section with all relevant endpoints to manage Trading Accounts.</p><p class="slate-p " >An Account represents the user, and a Trading Account is needed to perform trading actions. Under one Account, there might be more than one Trading Account. Some actions are performed only on Accounts, while others are on Trading Accounts.</p><p class="slate-p " >In our system, there is a distinction between Leads and Clients. They are both types of user accounts. The difference between Lead and Client is conversion (first deposit) - the user is a Lead by default and becomes a Client after the first successful deposit.</p><p class="slate-p " ></p><p class="slate-p " ></p><p class="slate-p " ></p>

In the Accounts section, you will find detailed information about user accounts within the system. With this, you can access and update account details and create new accounts. This section serves as a central hub for overseeing and administering user accounts within the system. You can also find a Trading Accounts sub-section within the section with all relevant endpoints to manage Trading Accounts.

An Account represents the user, and a Trading Account is needed to perform trading actions. Under one Account, there might be more than one Trading Account. Some actions are performed only on Accounts, while others are on Trading Accounts.

In our system, there is a distinction between Leads and Clients. They are both types of user accounts. The difference between Lead and Client is conversion (first deposit) - the user is a Lead by default and becomes a Client after the first successful deposit.

<p class="slate-p " >In the Payments section you can find endpoints for:</p><ul class="slate-ul " ><li class="slate-li " ><div style="position:relative">Retrieving Payment Gateways list with details about each Payment Gateway,</div></li><li class="slate-li " ><div style="position:relative">Retrieving Deposits and Withdrawals,</div></li><li class="slate-li " ><div style="position:relative">Making Manual payments,</div></li><li class="slate-li " ><div style="position:relative">Credit in and out.</div></li></ul><p class="slate-p " ></p><p class="slate-p " ></p>

In the Payments section you can find endpoints for:

<p class="slate-p " >The Trading section allows accessing and managing various trading functionalities within the system. With this section, you can place orders and monitor trading activity seamlessly. This section provides the necessary tools for users to efficiently execute trades and stay informed about market conditions.</p><p class="slate-p " ></p><p class="slate-p " ></p>

The Trading section allows accessing and managing various trading functionalities within the system. With this section, you can place orders and monitor trading activity seamlessly. This section provides the necessary tools for users to efficiently execute trades and stay informed about market conditions.

Sections