Skip to main content

Create a transfer

POST 
/v1/transfers

Creates a transfer from one of your accounts to the destination you choose with destination_type:

  • own_account — another of your own accounts
  • another_client — an account of another Exness client; available to partners whose API key has the Partner transfers scope, and the money is always sent from your Partner Reward Wallet

Provide only the accounts and the amount, in the currency of the source account. You do not need to specify the currency, payment method, or conversion details — the service determines them from the accounts.

destination_type must match the destination account: if you pass own_account with an account that is not yours, or another_client with your own account, the API responds with ACCOUNT_NOT_FOUND — the same answer as for an account that does not exist.

The request is processed synchronously: the response contains either the created transfer — its transfer_id plus the transfer amount in the source account currency (source) and in the destination account currency (destination) — or an error. A created transfer can still be in the processing status; check its final status with GET /v1/transfers/{transfer_id}.

A created transfer cannot be cancelled or reversed through the API. Check the destination account before sending. If a transfer was sent to a wrong account, contact Customer Support.

The operation is idempotent. Reuse the same EXN-IDEMPOTENCY-KEY when retrying the same request.

Recovery rules:

  • after TRANSFER_OUTCOME_UNKNOWN, SYSTEM_INTERNAL_ERROR, SYSTEM_TEMPORARY_UNAVAILABLE, a non-API response, or no response, the outcome is unknown: resend the same request with the same idempotency key. A 201 returns the existing transfer without executing it again, or the transfer created by the retry
  • before each request, record durably that it is being sent; if your system stops before it records the answer, the outcome is unknown
  • after AUTH_INVALID_API_KEY, AUTH_INVALID_SIGNATURE, AUTH_PERMISSION_DENIED, or REQUEST_RATE_LIMIT on a retry, fix the cause and resend the same request with the same key
  • any other error on a retry leaves the outcome unknown, because the source account, funds, limits, and eligibility are checked before the key is looked up. Do not change the request or the key
  • if you stop resending without a 201, retire the key first: record durably that it is never sent again. Then check Transaction History, and use a new key only after Customer Support confirms that no transfer was created
  • TRANSFER_OUTCOME_UNKNOWN and lost responses do not return a transfer_id; GET /v1/transfers/{transfer_id} shows the status of a transfer whose transfer_id you received in a 201 response
  • to try again after a transfer is rejected, send a new request with a new idempotency key; the old key stays bound to the rejected transfer
  • transfers are also visible in Transaction History in the Payments & wallet section of your Personal Area

Possible public error codes:

  • REQUEST_INVALID (400)
  • AUTH_INVALID_API_KEY, AUTH_INVALID_SIGNATURE (401)
  • AUTH_PERMISSION_DENIED (403), including a destination_type not covered by the scopes of your API key
  • TRANSFER_SOURCE_NOT_ALLOWED (403, destination_type: another_client only)
  • ACCOUNT_NOT_FOUND (404)
  • REQUEST_IDEMPOTENCY_KEY_REUSED, TRANSFER_INSUFFICIENT_FUNDS (409)
  • REQUEST_INVALID_PARAMETERS, TRANSFER_NOT_SUPPORTED, TRANSFER_DESTINATION_NOT_SUPPORTED, OPERATION_NOT_ALLOWED, TRANSFER_AMOUNT_TOO_SMALL, TRANSFER_AMOUNT_TOO_LARGE, TRANSFER_LIMIT_REACHED, TRANSFER_MT_ACCOUNT_NOT_SUPPORTED (422)
  • REQUEST_RATE_LIMIT (429)
  • SYSTEM_INTERNAL_ERROR, TRANSFER_OUTCOME_UNKNOWN (500)
  • SYSTEM_TEMPORARY_UNAVAILABLE (503)

Request​

Responses​

Transfer created. The transfer can still be processing; get its final status (done or rejected) with GET /v1/transfers/{transfer_id}.