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.
• 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 loses $130, the balance will be -$30, while the credit will remain $50.

To change the leverage on a trading account, you need 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, and account type (Demo or Real) are determined by the settings of the group and the corresponding offer in the Match-Trade 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 user account:

 
POST {baseURL}/v1/accounts

For a trading account under an existing 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: Handles 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: Confirms 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 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 CRM-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 applications are generated in the Admin panel under the Special Accounts section. This is where Admin and Manager accounts are created and granted access to the Admin and Manager applications.

The generated token and HMAC serve as authentication credentials (similar to a username and password) and are required to sign in to the backend applications.

Note: Tokens and HMACs created in the Special Accounts section are intended only for authentication to the Admin and Manager applications and must not be used for CRM API requests.

What is an Offer?

An Offer is a trading account template that defines the backend group, currency, leverage, and account type (Real or Demo). It's required every time a trading account is created.

How does it differ from a Challenge?

An Offer applies to standard brokerage — it defines a single account type. A Challenge is a prop trading product: a multi-phase structure with targets, loss limits, an entry fee, and an optional profit split. Challenges use Offers as building blocks for each phase.

How many Offers do I need?

One Offer per account type. If you want both Demo and Real accounts, configure at least two Offers — one with demo: true and one with demo: false

How do Offers work with Prop Trading phases?

Each Challenge phase maps to its own dedicated Offer. Phases 1–4 and Tournament create demo accounts; Funded and Instant Funding create real accounts. A minimal 2-phase challenge requires three Offers: Phase 1, Phase 2, and Funded.

If you're using the Match-Trader Prop CRM, Offers become largely irrelevant at this level. The entire Challenge structure — phases, targets, rules, and fees — is configured directly in the Prop CRM, and the system automatically validates each phase progression through to Funded and the client's withdrawal. You don't need to manage or reference Offers manually in that flow.

Offers matter primarily when integrating via API outside of the Prop CRM, for example when building a custom frontend or automating account creation programmatically.

What system-level roles exist?

These are assigned only via the database, not through the UI. SUPER ADMIN has full permissions across all partners in the environment. FULL ACCESS is a subset — it covers the most critical operations (e.g. deleting offers, confirming withdrawals/deposits). CRM MANAGER has access across all partners but with a restricted permission set (e.g. cannot process payments).

What is the standard admin role?

ADMIN has full permissions scoped to a single broker/partner. It's treated as having all entitlements within that partner.

Can roles be customized?

Yes. Custom roles are configurable in Roles Management in the Back Office. They are limited by entitlements, branch scope, and manager scope. Several predefined templates are available out of the box: Conversion Agent, Retention Agent, Account Manager, Support & CS, KYC, Finance (each also has a Team Leader variant).

What roles exist for end clients?

USER is a standard trader. IB / SUB IB is an Introducing Broker — the role changes automatically when a user becomes an IB. GUEST is a special token-only role for investor access (read-only).

Groups are the core trading configuration unit in Match-Trader Admin - every trading account belongs to a group, which defines its trading conditions (leverage, stop-out level, commissions, swaps, deposit currency, and available instruments). Groups are created in the Admin first, then mapped to CRM Offers or Challenges/Competitions, so that when a client opens a trading account under a given Offer/Challenge/Competition, the system automatically assigns them to the corresponding group.