Skip to main content
An internal transfer moves money between two account numbers on different core accounts at Lead. You create one with 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.
A transfer is either posted or rejected, never both. 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

The GET /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.