> ## 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. # Get apiv1marketfundinghistory > Historical funding settlements across all perp markets in one call, so clients don't have to fan out one request per trading pair. ## OpenAPI ````yaml /proto-openapi/api/openapi.yaml get /api/v1/market/funding/history 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/market/funding/history: get: tags: - MarketService description: |- Historical funding settlements across all perp markets in one call, so clients don't have to fan out one request per trading pair. operationId: list_all_funding_history parameters: - name: startTime in: query schema: type: integer minimum: 0 maximum: 4102444800000 format: int64 description: Start time as Unix timestamp (milliseconds) - name: endTime in: query schema: type: integer minimum: 0 maximum: 4102444800000 format: int64 description: End time as Unix timestamp (milliseconds) - name: pageSize in: query schema: type: integer format: uint32 minimum: 1 maximum: 1000 default: 50 description: Items per page (max 1000) - name: orderBy in: query schema: type: string default: DESC enum: - ASC - DESC minLength: 1 description: Sort direction for settledAt - 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 settlement (the oldest when `orderBy` is ASC). - Non-empty: an opaque cursor from a previous response's `nextPageToken`; results resume immediately after that position. The walk seeks on `(settled_at, id)` in the requested direction. `settled_at` is NOT NULL and never changes once a window settles, and the `id` tie-break makes the key total — the removed page-number mode ordered by `(settled_at, trading_pair_id, epoch)` with no tie-break, so a page boundary between two settlements sharing that triple could repeat or drop a row. `total` is populated — bounded by the server count ceiling, see `totalCapped`. Filters and `orderBy` must match the request that produced the token, or the request is rejected 400. schema: type: string responses: '200': description: OK content: application/json: schema: $ref: '#/components/schemas/ListAllFundingHistoryResponse' components: schemas: ListAllFundingHistoryResponse: type: object properties: records: type: array items: $ref: '#/components/schemas/FundingRecord' nullable: true total: type: integer description: >- Settlements matching the filter, bounded by the server count ceiling — see `totalCapped`. A lower bound when `totalCapped` is true. format: uint32 nullable: true pageSize: type: integer 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 `pageSize` proves the walk is exhausted and this is empty. nullable: true totalCapped: type: boolean description: >- True when MORE than the server ceiling matched, so the count stopped at the ceiling and `total` is a lower bound. nullable: true FundingRecord: type: object properties: tradingPairId: type: string nullable: true format: uuid epoch: type: string nullable: true fundingRate: type: string description: |- Final settled rate for the window as a decimal-string fraction per funding interval (e.g. "0.0001" = 0.01%). The ±max-rate cap is applied once to the window average at settlement; this is the capped value that payments used. nullable: true fundingDeltaPerUnit: type: string description: |- Quote currency charged per unit of base position for this window: funding_rate x reference_price. Positive means longs paid shorts. nullable: true cumulativeFundingPerUnit: type: string description: |- Running sum of funding_delta_per_unit across all settled windows; position payments settle against deltas of this value. nullable: true referencePrice: type: string description: |- Mark price at the window boundary — the payment basis for every position settled in this window. nullable: true sampleCount: type: integer format: uint32 nullable: true windowStartedAt: type: string nullable: true windowClosedAt: type: string nullable: true settledAt: type: string nullable: true carried: type: boolean description: >- True when the window held fewer than the minimum accepted samples and settled at the carried last settled rate (zero if no rate was ever settled) instead of a freshly computed average. nullable: true description: >- One settled funding window. Windows are fixed and epoch-aligned (hourly); a boundary the engine was down for is skipped, never settled retroactively, so consecutive records can legitimately be more than one interval apart. ```` This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.