Response drift: polymarket — end_date_iso fallback uses snake_case but live API field is camelCase endDateIso

[realfishsam]

Exchange

polymarket

Severity

LOW

What Our Normalizer Expects

utils.ts:99 reads market.end_date_iso as the secondary fallback for resolution date when market.endDate is absent:

resolutionDate: market.endDate
    ? new Date(market.endDate)
    : (market.end_date_iso ? new Date(market.end_date_iso) : new Date()),

What The Live API Returns

The GET https://gamma-api.polymarket.com/markets?limit=1 response includes:

[].endDate: str        ← primary field (present, camelCase)
[].endDateIso: str     ← secondary field (present, camelCase)

The fallback field is named endDateIso (camelCase) in the live response, not end_date_iso (snake_case) as the normalizer reads.

Endpoint tested: GET https://gamma-api.polymarket.com/markets?limit=1

Impact

LOW: The primary endDate field is present in the live response, so the fallback is not normally triggered. However, if any market has a null/missing endDate (e.g., newly created markets, markets pending settlement, or markets with misconfigured dates), the fallback market.end_date_iso evaluates to undefined (wrong field name), and the final fallback new Date() fires — setting resolutionDate to today's date instead of the actual expiry. Markets with null endDate will silently display incorrect resolution dates.

Suggested Fix

Update the fallback to use the correct camelCase field name:

resolutionDate: market.endDate
    ? new Date(market.endDate)
    : market.endDateIso
    ? new Date(market.endDateIso)
    : new Date(),

---

Found by automated response shape drift audit