POST /v2/internal_transfers and read it with GET /v2/internal_transfers/{internal_transfer_id}. POST requires an Idempotency-Key header. See Idempotency.
This example is a posted transfer. Acme moved $2,500 from its operating account to its settlement account. Lead debited the operating account’s core balance and credited the settlement account’s. The transfer includes a core transaction for each: one for the debit and one for the credit.
sender_core_transaction_id and receiver_core_transaction_id are set only on a posted transfer, and rejection is set only on a rejected one. On a processing transfer all three are null. See The rejection block for a rejected example.
Fields
The table lists each field on the object.The rejection block
The table lists the fields in the rejection block.
This transfer was accepted, then rejected when Lead went to post it because the operating account’s available balance had dropped below the amount. No money moved and no core transactions were created.
Creating an internal transfer
The create request takes these fields:
Lead checks the following before it accepts the transfer. A failure returns an error and creates no transfer.
Some checks depend on balances at posting time, such as available funds and account number status. They run after Lead accepts the transfer, and their results appear in the
rejection block.
Listing internal transfers
TheGET /v2/internal_transfers endpoint returns a list (objects, has_more) sorted newest first. You can filter it by:
Coming from v1
A v2 internal transfer replaces the v1 internal transfer. Transfers created on/v1/internal_transfer are readable on /v2/internal_transfers. The create request body is unchanged.

