Spec drift: polymarket — GET /data/orders response changed to paginated envelope; fetcher silently returns no orders

[realfishsam]

Exchange

polymarket

Drift Type

changed_response

Severity

HIGH — callApi('getDataOrders') returns an object instead of an array; fetcher silently returns zero orders

Their Docs

The live Polymarket Data API GET /data/orders now returns a paginated envelope:

{
  "limit": 100,
  "next_cursor": "LTE=",
  "count": 42,
  "data": [
    { ...order... },
    { ...order... }
  ]
}

Additionally, the endpoint now accepts a next_cursor query parameter for keyset pagination (replacing any prior offset-based approach).

Source: https://docs.polymarket.com/api-reference/introduction (Data API — Orders)

Our Cached Spec

core/specs/polymarket/Polymarket_Data_API.yaml — GET /data/orders response schema is documented as an array of OpenOrder objects (bare array, no wrapper).

core/src/exchanges/polymarket/api-data.ts — generated from cached YAML, response typed as array.

File: core/specs/polymarket/Polymarket_Data_API.yaml

callApi() References at Risk

The fetcher does not currently call getDataOrders directly — checking fetcher.ts: callApi('getDataOrders') is defined in the spec but the fetcher may use a different code path. However, if any code calls callApi('getDataOrders') and iterates the result as an array (e.g. result.map(...)), it will get zero results since an object is not iterable the same way.

Hardcoded URL Bypasses

None for this endpoint.

Impact

Any call to GET /data/orders that expects a bare array will receive an object. The actual orders are nested in data[...]. Without reading .data, the result appears as an empty or broken response. Pagination via next_cursor is also impossible since that query param is not in the cached spec.

---

Found by automated spec drift audit