> ## Documentation Index
> Fetch the complete documentation index at: https://api-trading-docs.vexprofx.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Verify and revoke accounts

> The account authorization lifecycle for a partner token.

## 1. Verify ownership

Send `POST /api/v1/accounts/{login}/verify` with the account login and this body:

```json theme={"theme":{"light":"github-light","dark":"github-dark"}}
{"password": "CUSTOMER_MASTER_PASSWORD"}
```

`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:

```json theme={"theme":{"light":"github-light","dark":"github-dark"}}
{
  "valid": true,
  "verified": true,
  "login": 123456,
  "expires_at": "2026-10-01T12:00:00+00:00",
  "retcode": "0"
}
```

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:

```json theme={"theme":{"light":"github-light","dark":"github-dark"}}
{"valid": false, "retcode": "3006"}
```

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

```bash theme={"theme":{"light":"github-light","dark":"github-dark"}}
curl --fail-with-body -X DELETE \
  "$API_BASE/api/v1/account-verifications/123456" \
  -H "Authorization: Bearer $MT5_API_TOKEN"
```

`{"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.

<Warning>
  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.
</Warning>

After revocation or expiration, operations requiring that account are rejected.
To regain access, verify it again with its master password.

## 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.

<Warning>
  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.
</Warning>

After expiration, verify again only while the customer continues to authorize the
integration. After deliberate revocation, stop automation and obtain renewed
authorization before verifying again. If the stored password fails, ask the
customer for the current password and avoid automatic retries. Verifying an account
does not reactivate an expired or revoked partner token.

See the [OWASP secrets management guidance](https://cheatsheetseries.owasp.org/cheatsheets/Secrets_Management_Cheat_Sheet.html)
for implementing protected storage.