Financial safety

Operate without blind retries and keep the CRM ledger aligned with PAMM and MT5.

Deposit and withdrawal endpoints do not accept a CRM idempotency key. Your CRM must prevent duplicate requests and reconcile uncertain results before retrying.

Safe withdrawal sequence

1. Create a durable operation

   Generate a unique CRM reference and store the withdrawal as PENDING before sending the request.

2. Send the request once

   Call /investor/withdraw with the CRM reference in comment.

3. Persist the full outcome

   Store requested and effective amounts, pending fee, available balance, and mt5_deal_id.

4. Reconcile uncertainty

   If the HTTP outcome is unknown, inspect the MT5 balance and fee records before considering another request.

5. Complete locally

   Mark the CRM operation COMPLETED only after the executed result is known.

Safe unassignment sequence

1. Resolve the active relationship with /info/investor/{login}/master.
2. Send /subscriptions/unassign once.
3. If the response is PAUSED, poll /info/subscriptions; do not repeat the command.
4. Complete the CRM workflow only when the subscription is CANCELLED and ended_at is populated.

Critical rules

Rule	Required behavior
Investor funds	Use only /investor/deposit and /investor/withdraw.
Master funds	Never send direct external deposits.
Payment account	Receive fees only; do not treat it as Investor capital.
Fee rate	Validate a decimal from 0 to 1 in both backend and UI.
Open positions	Expect assignment, withdrawal, or unassignment to be blocked when applicable.
Credentials	Keep API keys and MT5 passwords out of frontend clients and logs.
Compatibility	Ignore unknown response properties and depend only on documented fields.

Previous: Asynchronous operations

Review polling and completion conditions.

Next: Errors

Handle HTTP failures without creating inconsistent state.