Skip to main content
COMING SOON — NOT YET AVAILABLE. This page describes the planned sweep API so you can design your integration ahead of release. The contract below is directional and may change before launch; nothing on this page is callable today. Contact institutional@polymarket.us for availability.
After a funded order reaches a terminal state, any residual cash in the participant’s account — excess collateral, unconsumed fee reserve, realized profit, released margin — must be swept back to your partner funding account by you. The funding overview covers the concept; this page describes the planned API for executing it.

When you sweep — and when Polymarket US does

The automatic reversal covers only pre-book failures. Everything after durable creation follows the same residual-sweep path.

The safe-sweep precondition

Create a sweep only when both are true:
  1. Your execution/position processing (from the Drop Copy streams) indicates funds may have been released, and
  2. An authoritative balance read (PositionAPI/GetAccountBalance) confirms the amount — see Reconciliation for the read APIs.
Never sweep on stream events alone: quantities may be estimates until fee collection and settlement post to the ledger.

Planned service

Service: polymarket.us.cashmovement.v1.CashMovementService Cash movement is firm-scoped — do not send x-participant-id. The source account is explicit in the request, and the destination (your funding account) is resolved from your firm’s configured funding relationship; you cannot direct funds anywhere else.

CreateCashMovement

Sweep reasons: VENDOR_FEE, EXCESS_COLLATERAL, RELEASED_MARGIN, REALIZED_PNL, SETTLEMENT_CREDIT, CANCEL_EXPIRE_CLEANUP. Populate order_id, execution_id, market_id, and external_reference whenever available — they tie the sweep to its cause on the audit trail.

GetCashMovement

Idempotency and recovery

The same discipline as funded orders:
  • Use a distinct, durable idempotency key per logical sweep, persisted before the call.
  • A transport timeout or an AMBIGUOUS status is not permission to create a second workflow — replay the same create request with the same key, or read the original workflow by workflow_id.
  • Use bounded recovery for PENDING workflows rather than a permanent polling scheduler.
  • Persist workflow_id and all correlation fields through a terminal result.

Correlating sweeps to orders

For funded orders, the execution stream’s clord_id equals the funding_request_id returned by CreateFundedOrder, and the create response carries prefund_transfer_id. Persist all of these at placement time so your sweep pipeline can join stream events → order → prefund → sweep without guesswork.

On-Demand Funding Overview

The model — including the sweep lifecycle and directional guarantees.

Reconciliation

The ledger reads that back the safe-sweep precondition.