The v2 API is in open beta on the sandbox, and there are SDKs for it

Two things shipped on our side that change how much code you have to own when you integrate with MT4 or MT5 through us. I would rather tell you directly, including the parts that are not finished, than let you find them in a changelog.

The v2 API is in open beta — on the sandbox

Start with where it runs, because that determines whether any of this is useful to you yet.

v2 is deployed to the sandbox only. It answers on pre.mywebapi.com; production (cloud.mywebapi.com) still serves v1 and nothing else. So v2 is something to build and evaluate against today, not something to move a live integration onto. When it reaches production, that will be its own announcement.

v1 stays stable and fully supported. Everything running today keeps running, and there is no deadline attached to any of this.

What changes in v2

The response shape is the part worth knowing first. Every v2 call returns the same envelope — data, error, meta — with a plain HTTP 200. You read the error field instead of juggling status codes across endpoints that historically disagreed about which code meant what.

The version sits in the path, so there is no api-version parameter to remember and no header to forget. Serialization is source-generated, which means lower latency and fewer allocations per response — this matters more than it sounds when you are pulling position snapshots on a schedule.

Real-time streaming for ticks, margins and trade events runs over SignalR, with automatic reconnection handled inside the clients rather than left to you.

What v2 covers today, and what it does not

This is the part most likely to matter to you, so here are the actual numbers rather than a claim of completeness.

For MT4, v2 is a genuine expansion: configuration, management and reporting surfaces that v1 never exposed.

For MT5, v2 is not there yet. The twelve endpoints are read-only basics — server time, user and group lookups, symbol lookups, positions, orders and deals by group. There are no writes and no configuration calls. If your integration is MT5, stay on v1: it has more of what you need, and it is the version running in production anyway.

There are SDKs now

Three of them, open source, covering the full v2 surface as it stands:

A Python SDK is in progress and not published yet — I would rather say that than list it and have you go looking.

What is already inside them

The parts people normally spend a week building are done:

• OAuth2 token handling. You pass a client ID and secret once. The SDK discovers the token endpoint, acquires a token lazily on the first call, caches it with an expiry margin, refreshes it single-flight so concurrent calls do not stampede, and retries once on a 401. There is nothing for you to schedule.
• Cursor pagination, built in rather than reimplemented per endpoint.
• Real-time over the same client — the SignalR connection and its reconnection logic live behind the same object as the REST calls, not a second thing to wire up.
• Typed errors, so a failed call surfaces as a typed ApiError instead of a shape you have to guess at.
• One entry point — a CPluginWebApiClient with mt4 and mt5 namespaces. Credentials and environment are configured at construction; after that you call methods on the namespace you need.

In the TypeScript SDK the types are regenerated from the OpenAPI specification, so they cannot quietly drift away from what the API actually returns.

One caveat, stated plainly

All three are at 0.x. The API shape is stable, but minor package releases may still break compatibility, so pin a version. That is not boilerplate — it is the actual state of these packages today.

Where to start

Client credentials for the sandbox are managed in the sandbox Toolbox, under WebAPI → Clients: pre.toolbox.cplugin.com/webapi/clients. Point the SDK at the staging environment — CPluginEnvironment.Staging in .NET, env: 'staging' in TypeScript, -Environment Staging in PowerShell — and it will use pre.mywebapi.com for you.

The sandbox is free and fully functional with no time limit, and billing starts only when you connect a production platform. So evaluating whether v2 and the SDKs actually save you work costs nothing but an evening.

If you already have an integration

One thing to be clear about: the SDKs target v2 only. Every generated call goes to a /api/v2/… path, so an existing v1 integration cannot simply swap a package in and keep working — this is something to evaluate against the sandbox, not a drop-in upgrade.

That said, if you wrote your own token refresh, your own pagination loop, or your own reconnect logic around our API, that is precisely the work these packages remove once you do move. If it would help, our engineers can look at how you are calling us today and tell you specifically what the SDK would replace — and, honestly, whether v2 is worth your attention yet given which platform you run. If you are on MT5, the answer today is probably not. No obligation either way; write to us and say what you are building.