FAQ

To change a trading account's group, you need to update its associated offer. Use the following endpoint:

 
curl --location --request PATCH '{{baseURL}}/v1/trading-account?systemUuid={{systemUuid}}&login={{login}}' \
--header 'Content-Type: application/json' \
--header 'Authorization: {{APIkey}}' \
--data '{
  "offerUuid": "{{offer_uuid}}"
}'

This will move the trading account to the new offer (and consequently to the new group).

Passwords are associated with the user account (not with individual trading accounts). To change a password, use:

 
POST /v1/change-password

The system will automatically encrypt the new password. Neither you nor the Match-Trade system will have access to the plain text password after this change.

To get all trading accounts associated with a specific user account:

 
GET /v1/trading-accounts?query={{email}}

This will return all trading accounts linked to the specified account email.

To check the current balance and equity of a trading account:

 
GET /v1/trading-account?systemUuid={{systemUuid}}&login={{tradingAccountLogin}}

This will return the current balance, equity, and other financial information for the specified trading account.

• Branch is used in our CRM, e.g., for organizing clients by country. For external integrations, the "Default" branch should be used, which is always set up by Match-Trade.
• The system is an internal service that connects the platform to the backend. There is only one, and it is unchangeable per server. The Match-Trade team configures it.
• Operation is an internal service responsible for the proper creation of accounts. There is only one and it is unchangeable, set up during the client’s setup by Match-Trade.

Some endpoints require the UUIDs of these services (systemUuid, branchUuid, operationUuid), which can be obtained, for example, from the endpoint:

 
GET /v1/offers

Equity = Balance + Credit

• Balance includes deposits and closed trade results. 
• Credit is extra funds (e.g., bonuses) that cannot be withdrawn.

Credit allows an account to have a negative balance if it has been granted. For example, if an account has a balance of $100 and a credit of $50, and will lose $130, the balance will be -$30, while the credit will remain $50.

To change the leverage on a trading account, you need to retrieve the systemUuid and the trading account login. Then, send the following request:

 
curl --location --request PUT '{{baseURL}}/v1/trading-account/leverage?systemUuid={{systemUuid}}&login={{login}}' \
--header 'Authorization: {{APIkey}}' \
--header 'Content-Type: application/json' \
--data '{
  "leverage": "100"
}'

A 204 status indicates that the leverage has been successfully changed.

The trading account parameters such as currency, leverage, account type (Demo or Real) and more, are determined by the settings of the group and the corresponding offer in the Match-Trader system. If you want to create, for example, a Demo trading account with 1:30 leverage and currency set to EUR, you first need to:

1. Create a group in the admin panel (backend) with the desired parameters.
2. Create an offer assigned to that group, with EUR as the currency, leverage set to 30, and the Demo type enabled.

Once the group and offer are configured, you can send a request to create the account: For a usser account:

 
POST {{baseURL}}/v1/accounts

For a trading account under an exsiting user account:

 
POST {{baseURL}}/v1/accounts/{{accountUuid}}/trading-accounts 

Make sure to include the offerUuid in the request body. The system will then create the trading account using the parameters defined in the selected offer.

An Offer is a trading account configuration created and managed manually in the CRM. It cannot be created or modified via API - the API allows read-only access (GET) to Offer data.

An Offer maps to a specific trading group configured in the trading system backend (admin). That group defines all detailed trading conditions for the trader, such as commissions, markups, symbols, execution rules, and other broker-specific settings.

For the end user (trader):

• the Offer name is displayed in the top-left corner of the trading platform,
• the Offer type (e.g. Demo or Real) is clearly indicated.

From a functional perspective, an Offer defines:

• what type of trading account will be created for the client,
• with which basic parameters, such as: real or demo account, trading system (e.g. MTT / MT5), account currency, initial leverage and more.

An Offer must exist in order to create a trading account correctly. It is mandatory when creating a trading account via API - the request must include a valid offerUUID.

Based on the provided offerUUID, the system automatically creates the trading account using the configuration defined in the Offer and its mapped trading group.

The "Fixed Amount Book" mechanism for Prop Trading was introduced to handle cryptocurrency payments where the user must pay a precise, fixed amount (e.g., for a challenge fee). The statuses FULLY_PAID and PARTIALLY_PAID were created to handle scenarios where the amount sent to the blockchain wallet does not exactly match the declared amount.

Purpose: Designed for Prop Trading challenges where users must pay a specific, fixed fee (e.g., $100 for a challenge) using cryptocurrency.

Functionality:

• It "freezes" the exchange rate for a set time (default 5 minutes) to ensure the user pays the exact required amount in crypto.
• It allows only one open "Fixed Amount" transaction per trading account at a time.
• It introduces a "Declared Amount" field to track what the user should pay versus what was actually received.

Why new statuses were created?

PARTIALLY_PAID: Created to handle cases where the user sends less crypto than required (e.g., due to network fees or user error). The system marks it as partially paid, and the funds are not fully booked until the remainder is sent. It is considered a final status (like DONE) but indicates incomplete payment. FULLY_PAID: Created to confirm that the user sent the exact or greater amount than declared. It is equivalent to DONE but specifically signals that the fixed amount condition has been met, triggering actions like account activation or challenge start.

The difference between FAILED and FAILED_PAYMENT lies in the stage of the process where the error occurred. FAILED is a general status indicating that the transaction failed within the internal system (e.g., due to a timeout, validation error, or rejection by the broker), while FAILED_PAYMENT specifically indicates a failure on the payment provider's side (e.g., declined card, payment gateway error).

FAILED:

• Indicates a general failure of the transaction within the broker's system.
• Can be caused by internal validation errors, timeouts (e.g., trading API timeout), manual rejection by an admin, or system errors.
• Often used when the transaction logic itself fails or is cancelled internally.

FAILED_PAYMENT:

• Specifically indicates that the payment process failed at the Payment Service Provider (PSP) level.
• Used when the payment gateway returns an error, declines the transaction, or fails to process the funds.
• In the CRM/MTR interface, this status informs the user that the issue lies with the payment method rather than the broker's internal logic.

The API key is the key that authorizes the user and must be sent in the request headers of each Broker API request. It is assigned to a specific CRM user account and inherits the same permissions as that account. For example, if an API key is generated for an Admin CRM user, it will have Admin-level rights.

Additional permission layers and request limits can be configured in CRM Back Office → API Access. This is also where API keys are generated and managed.

Tokens and HMACs for the MTR Broker Management application are generated in the Admin panel under the Special Accounts section. There, Admin and Manager accounts are created and granted access to the Admin and Manager applications. The token and HMAC generated in Special Accounts should not be used in Broker API queries

These tokens act as login credentials (similar to a username and password) and are used to authenticate.