Create transfer
Move funds between accounts. Three directions are supported:
| Direction | fromAccountId | toAccountId |
|---|---|---|
| Company → User | (omit) | User account |
| User → Company | User account | (omit) |
| User → User | Source account | Destination account |
Funding behavior: Transfers use the source SideShift wallet first. If a source user is short in SideShift wallet but has enough withdrawal-ready balance, SideShift automatically moves the needed funds through the supported child-to-platform path first, then completes the transfer.
Settlement behavior: Company→User and User→User transfers settle into the destination withdrawal-ready balance by default. Pass destinationBalance: wallet to settle those transfers into the destination SideShift wallet instead. User→Company transfers always settle into your company SideShift wallet.
Idempotency: An idempotencyKey is required. A replay returns the original successful transfer result.
Commercial evidence: New live integrations require string metadata for obligationType, obligationReference, description, and approvalReference. Campaign transfers also require programId or contractId. Allowed obligation types are campaign, creator_agreement, subscription, refund, wallet_reconciliation, platform_correction, and other_approved. Existing authorizations created before this requirement remain backward-compatible during migration; new authorizations enforce it automatically. This metadata is optional in sandbox.
Sandbox: Company→User transfers are simulated — no real payout is executed but the internal ledger is updated normally.
Authorizations
Your SideShift Connect API key (sk_live_* or sk_test_*). Generate from Settings → Connect.
Body
Amount in cents
x >= 15000
Unique key for safe retries
"payout-order-12345"
Source account (omit for company→user)
Destination account (omit for user→company)
Settlement target for company→user and user→user transfers. Use wallet to keep funds in the destination SideShift wallet.
withdrawal, wallet Required for newly created live integrations. Include obligationType, obligationReference, description, and approvalReference; campaign transfers also need programId or contractId. Existing integrations remain compatible during migration.