1. Verify ownership
Send POST /api/v1/accounts/{login}/verify with the account login and this body:
password accepts 1–128 characters. Additional fields are not allowed.
The API validates the master password with MT5, checks the account data,
and stores a verification linked to your token. The password is not persisted.
Illustrative success response; the actual expiration date is returned by the service:
Continue only if both valid and verified are true. Save expires_at and verify
again after expiration. Do not assume a fixed duration or automatic renewal.
Verification is not shared with another token.
The default validity period is 90 days from each successful verification.
The service may configure a different duration; always use the returned expires_at.
Changing the default does not extend existing verifications: they keep their
expiration timestamp until the account is verified again.
An incorrect password may produce HTTP 200 with:
This result does not grant a new authorization. Repeated failures may produce 429.
Do not automatically retry passwords; ask the user to check their credentials and
respect the lockout. An investor password does not verify this workflow.
2. Query verifications
GET /api/v1/account-verifications returns an array of your token’s records,
with login, verified_at, expires_at, and revoked_at.
It may include expired or revoked verifications; appearing in the list does not
mean access is active. Check that revoked_at is null and expires_at is in the
future, and keep the token active. A token without records receives [].
3. Remove access
{"revoked":true} means the binding was revoked; {"revoked":false} means
there was no revocable record for that token and login. Revocation does not change
the MT5 password or affect verifications held by other tokens.
Revocation does not close positions or cancel orders. Resolve pending trades before
removing access if you need to keep querying or closing them through the API.
4. Store credentials and verify again
If the partner does not retain the master password, it must ask the customer to
enter it again when account verification is needed. The API does not return the
password or provide a renewal mechanism that works without it.
Store the login, a reference to the token used, and expires_at in your backend.
Query verifications to check revoked_at as well; locally stored records do not
guarantee that access is still active.
To verify again without customer interaction, you may retain the password with
the customer’s authorization in a server-side secrets vault. Use encryption at
rest, limit access to the service that verifies accounts, and exclude passwords
from logs. Delete the stored credential when the customer disconnects the account
or withdraws authorization.
Do not store the password in localStorage, sessionStorage, plaintext files,
or frontend code. Retaining it is optional; if automated reverification is not
needed, ask the customer to enter the password again.
