One API for Copy Trading, PAMM, and MAM

Yes. All three are product families inside the same Broker contract rather than three integrations. Copy Trading uses copier subscriptions; PAMM has its own subscription methods plus deal and closed-position reads; MAM masters are served through the copier methods — a master registered as a MAM master takes investors through the same calls. The product family is a field on the account, so your CRM reads and filters all three the same way.

MetaTrader 4, MetaTrader 5, cTrader, and B2Trader. A B2COPY account is created for an existing trading-platform login, and the platform is a property of that account, so your integration calls the same endpoints regardless of which server the login lives on. PAMM deal and position reads additionally carry platform-specific identifiers — an MT4 order ID or an MT5 deal ID — plus the trading server name.

You create a service admin in the Admin panel, and your CRM signs its own JWT with an EC private key using ES256. The token carries admin_id, device_ip, and key_id claims. You send the public key and its key identifier to B2COPY support along with the IP addresses your CRM will call from, and it is recommended to restrict the service admin to that list. Your CRM then exchanges a signed token for a B2COPY access and refresh token pair and passes the access token as a bearer token on later calls.

Back-office sign-in, side-auth URL and user-id resolve, creating and listing accounts and users, the full copier and PAMM subscription lifecycle, on-demand fee processing with PENDING / SUCCESS / ERROR, PAMM deal and position lists, and the account.created and fee.charged webhook payloads. Legacy /api/v2 and standalone routes still exist for older clients; the paths on this page are the canonical Broker API.

Yes. The documented set covers common scenarios, and extending it for a specific CRM is routine rather than an exception. Describe the operation and the data you need and we will agree the contract with you — we would rather scope it properly than name a date before understanding your model.

Yes. The Broker API contract defines two notification triggers with canonical JSON payloads: account.created when a new B2COPY account appears, and fee.charged when a fee is durably charged or accrued. Sample endpoints return an example batch so you can see the schema your CRM route receives when fields map 1:1. Additional triggers can be scoped with the team. Where a call is asynchronous by design, polling is also documented — fee processing can return PENDING, and your CRM re-checks with the same request_id until it settles as SUCCESS or ERROR.

Yes. Hosts are environment-specific and issued with your credentials, which is why the paths on this page are shown without one. The service admin, the public-key registration, and the IP list are set up together with the B2COPY team.

This page is about the API itself — its two transports, the documented flows, the authorization model, and how far the contract can be extended. The integration page is about choosing how deep to go overall: an embedded widget with SSO, a pre-built CRM connector, or an API-led build.

In the B2COPY API documentation, maintained outside this marketing site. It carries the parameter tables, request examples, and response shapes for each documented flow.