> ## 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 the open positions of a followed lead trader

> List the open positions of the leader one of your follows copies.

 The leader comes from the follow, so this works even after the leader
 releases their handle. 404 unless the follow is yours; 403 unless it is
 live (ACTIVE or CLOSE_ONLY).



## OpenAPI

````yaml /proto-openapi/api/openapi.yaml get /api/v1/copy-trading/follows/{followId}/leader-positions
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/copy-trading/follows/{followId}/leader-positions:
    get:
      tags:
        - CopyTradingService
        - Copy Trading
      summary: List the open positions of a followed lead trader
      description: |-
        List the open positions of the leader one of your follows copies.

         The leader comes from the follow, so this works even after the leader
         releases their handle. 404 unless the follow is yours; 403 unless it is
         live (ACTIVE or CLOSE_ONLY).
      operationId: list_follow_leader_positions
      parameters:
        - name: followId
          in: path
          required: true
          schema:
            type: string
      responses:
        '200':
          description: OK
          content:
            application/json:
              schema:
                $ref: '#/components/schemas/ListFollowLeaderPositionsResponse'
        '400':
          description: Invalid follow id
        '401':
          description: Authentication required
        '403':
          description: The follow is stopped
        '404':
          description: Follow not found
        '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
        '503':
          description: Matching engine unavailable; retry
      security:
        - monacoSignature: []
        - monacoHttpSignature: []
components:
  schemas:
    ListFollowLeaderPositionsResponse:
      type: object
      properties:
        positions:
          type: array
          items:
            $ref: '#/components/schemas/LeadTraderOpenPosition'
          nullable: true
    LeadTraderOpenPosition:
      type: object
      properties:
        tradingPairId:
          type: string
          description: Trading pair UUID
          format: uuid
          nullable: true
        side:
          type: string
          description: LONG or SHORT
          nullable: true
        size:
          type: string
          description: Position size in base units
          nullable: true
        entryPrice:
          type: string
          description: Average entry price
          nullable: true
        markPrice:
          type: string
          description: Current mark price
          nullable: true
        unrealizedPnl:
          type: string
          description: Unrealized PnL at the mark, in quote units
          nullable: true
        leverage:
          type: string
          description: Position leverage
          nullable: true
        marginMode:
          type: string
          description: CROSS or ISOLATED
          nullable: true
  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

````