> ## Documentation Index
> Fetch the complete documentation index at: https://docs.0xmonaco.com/llms.txt
> Use this file to discover all available pages before exploring further.

# List pending withdrawals

> List the caller's pending withdrawals.

 Authenticated. Returns the caller's withdrawals that are still awaiting
 on-chain root confirmation (status `pending`) — i.e. those for which the
 merkle proof, and therefore the executable calldata from GetWithdrawal, is
 not available yet. Scoped to the authenticated account: only withdrawals
 owned by the caller's user + application are returned. Newest first, paged.



## OpenAPI

````yaml /proto-openapi/api/openapi.yaml get /api/v1/withdrawals
openapi: 3.0.3
info:
  title: Monaco Protocol API
  description: REST API for the Monaco Protocol hybrid CLOB exchange.
  version: 1.0.0
servers:
  - url: https://staging.apimonaco.xyz
    description: Staging server (Testnet)
security: []
tags:
  - name: AccountsService
  - name: ApplicationsService
  - name: AuthService
  - name: BuildercodeRewardsService
  - name: CopyTradingService
  - name: DelegatedAgentsService
  - name: FaucetService
  - name: FeesService
  - name: HealthService
  - name: ManagedMarketsService
    description: |-
      Wallet-authenticated maker assignments. The signed session must match both
       configured maker user and application. Owner IDs are process fences, never auth.
       Only wallet sessions are supported; delegated-agent sessions receive 403.
  - name: MarginAccountsService
    description: |-
      Current public isolated-margin semantics:
       - a user has one parent margin account per application scope
       - opening orders create or reuse isolated position buckets under that parent
       - parent account creation is handled internally by margin workflows
  - name: MarketService
  - name: OrderbookService
  - name: OrdersService
  - name: PositionsService
    description: |-
      Current public isolated-margin semantics:
       - positions link to a parent margin account and, when applicable, a bucket id
       - opening orders create or reuse isolated position buckets under the parent
       - users can open another isolated position by reusing the parent account with a different market bucket
  - name: PulseService
  - name: SweeperService
  - name: TraderCodeService
  - name: TradesService
  - name: WhitelistService
  - name: WithdrawalsService
paths:
  /api/v1/withdrawals:
    get:
      tags:
        - WithdrawalsService
        - Withdrawals
      summary: List pending withdrawals
      description: |-
        List the caller's pending withdrawals.

         Authenticated. Returns the caller's withdrawals that are still awaiting
         on-chain root confirmation (status `pending`) — i.e. those for which the
         merkle proof, and therefore the executable calldata from GetWithdrawal, is
         not available yet. Scoped to the authenticated account: only withdrawals
         owned by the caller's user + application are returned. Newest first, paged.
      operationId: list_pending_withdrawals
      parameters:
        - name: pageSize
          in: query
          schema:
            type: integer
            format: uint32
            minimum: 1
            maximum: 1000
            default: 20
          description: Items per page (max 1000)
        - name: pageToken
          in: query
          description: |-
            Pagination cursor with two states:
              - Omitted or empty string (""): start a cursor walk with no prior
                position, from the newest pending withdrawal.
              - Non-empty: an opaque cursor from a previous response's
                `next_page_token`; results resume immediately after that position.

             The walk seeks on `(created_at, withdrawal_index)` descending — the order
             this listing already read in, served by
             `idx_withdrawals_user_created (user_id, created_at DESC)`. `created_at` is
             NOT NULL and `withdrawal_index` is the table's primary key, assigned by
             the vault in request order, so the key is total and immutable. `total` is
             populated and exact: a user's unexecuted withdrawals are a small bounded
             set.
          schema:
            type: string
      responses:
        '200':
          description: OK
          content:
            application/json:
              schema:
                $ref: '#/components/schemas/ListPendingWithdrawalsResponse'
        '400':
          description: Invalid pagination parameters
        '401':
          description: Authentication required
        '429':
          description: >-
            Read rate limit exceeded — every authenticated read draws one
            request from the account's read budget; retry after the interval in
            details.retryAfter
        '500':
          description: Internal server error
      security:
        - monacoSignature: []
        - monacoHttpSignature: []
components:
  schemas:
    ListPendingWithdrawalsResponse:
      type: object
      properties:
        withdrawals:
          type: array
          items:
            $ref: '#/components/schemas/PendingWithdrawal'
          nullable: true
        total:
          example: 3
          type: integer
          description: Total number of pending withdrawals for the caller
          format: uint32
          nullable: true
        pageSize:
          example: 20
          type: integer
          description: Items per page
          format: uint32
          nullable: true
        totalPages:
          example: 1
          type: integer
          description: Total number of pages
          format: uint32
          nullable: true
        nextPageToken:
          type: string
          description: >-
            Cursor for the next page, minted from the last row of an
            over-fetched
             page: this listing is one ordered read, so a page shorter than
             `page_size` proves the walk is exhausted and this is empty.
          nullable: true
    PendingWithdrawal:
      type: object
      properties:
        withdrawalIndex:
          example: '42'
          type: string
          description: >-
            Allocated withdrawal index — matches executeWithdrawal.index
            on-chain
          nullable: true
        assetId:
          example: 123e4567-e89b-12d3-a456-426614174000
          type: string
          description: UUID of the withdrawn asset
          format: uuid
          nullable: true
        assetSymbol:
          example: USDC
          type: string
          description: Ticker symbol of the withdrawn asset
          nullable: true
        amount:
          example: '1000000000000000000'
          type: string
          description: >-
            Raw token amount in the smallest unit (e.g. wei) as a stringified
            positive integer
          nullable: true
        destination:
          example: '0x742d35cc6634c0532925a3b8d4060f31e2c3d8b5'
          type: string
          description: >-
            On-chain address that will receive the withdrawal (EVM, 42 chars
            including 0x)
          nullable: true
        status:
          example: pending
          type: string
          description: >-
            Withdrawal lifecycle status; always "pending" for entries in this
            response
          nullable: true
        createdAt:
          example: '2026-07-01T12:00:00Z'
          type: string
          description: RFC 3339 timestamp of when the withdrawal was initiated
          nullable: true
      description: >-
        A single pending withdrawal in a list response. A lightweight summary —
        the
         executable calldata is not included (it does not exist until the withdrawal
         is confirmed on-chain; fetch it from GetWithdrawal once it becomes ready).
  securitySchemes:
    monacoSignature:
      type: apiKey
      description: >-
        Ed25519 session-key request signing. Every authenticated request carries
        three headers: `X-Monaco-PublicKey` (64-char lowercase-hex session
        public key), `X-Monaco-Timestamp` (Unix milliseconds, within 30s of
        server time), and `X-Monaco-Signature` (hex ed25519 signature). The
        signature is over `METHOD\npath?query\ntimestamp_ms\nSHA256_hex(body)`,
        where the body hash is the SHA-256 of the empty byte string when there
        is no body. Obtain the session keypair from `POST
        /api/v1/auth/challenge` followed by `POST /api/v1/auth/verify`.
      name: X-Monaco-Signature
      in: header
    monacoHttpSignature:
      type: apiKey
      description: >-
        RFC 9421 Ed25519 session-key request signatures. Send Signature-Input,
        Signature, and Content-Digest together; never combine them with
        X-Monaco-* credentials. The monaco signature covers @method, @path,
        @query, and content-digest in that order, with created (Unix seconds
        within 30s of server time), keyid (registered lowercase-hex session
        public key), and alg=ed25519 parameters. Content-Digest uses RFC 9530
        sha-256 over the exact body bytes, including the empty body. Query
        coverage retains ordering and percent encoding. Timestamp freshness does
        not reject repeated identical requests; use endpoint idempotency where
        supported. Existing legacy signing remains supported during server-first
        migration; SDK RFC 9421 signing is opt-in. See
        https://docs.0xmonaco.com/reference/http-message-signatures for the
        complete profile and trust model.
      name: Signature
      in: header

````

This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.