Exchange
polymarket
Drift Type
changed_response
Severity
HIGH — FAK/FOK order flow silently loses transaction hash data; archived CLOB SDK (#1069) will not receive fix automatically
Their Docs
Effective July 24, 2026 (04:00 UTC rollout per status.polymarket.com), successful FAK/FOK fill responses from POST /order and POST /orders no longer populate the transactionHashes field. The field is present in the response schema but always returns an empty array or null on match.
Integrations must now use only the tradeIDs field returned in the response, then poll GET /trades?trade_id={id} until the transaction hash resolves or returns FAILED. WebSocket fill notifications via the user channel are unaffected.
The change was announced in the changelog on July 17 but the actual API behavior changed on July 24 — after the last spec audit.
Source: https://docs.polymarket.com/changelog
Our Cached Spec
POST /order and POST /orders in core/specs/polymarket/PolymarketClobAPI.yaml document a transactionHashes: string[] field in the FAK/FOK success response. The field is now always empty for matched orders.
File: core/specs/polymarket/PolymarketClobAPI.yaml
callApi() References at Risk
Order placement is handled via @polymarket/clob-client-v2 SDK in auth.ts, not via direct callApi(). The archived SDK (see #1069) will not receive the update that resolves hashes from tradeIDs instead of reading transactionHashes directly. Any PMXT code that reads transactionHashes from a POST /order response (or relies on the SDK to do so) will silently receive empty data for matched orders.
Hardcoded URL Bypasses
auth.ts:149 — axios.get('${dataApiUrl}/profiles/${address}') is a separate bypass unrelated to this issue.
Impact
Found by automated spec drift audit — 2026-07-26
Exchange
polymarket
Drift Type
changed_response
Severity
HIGH — FAK/FOK order flow silently loses transaction hash data; archived CLOB SDK (#1069) will not receive fix automatically
Their Docs
Effective July 24, 2026 (04:00 UTC rollout per status.polymarket.com), successful FAK/FOK fill responses from
POST /orderandPOST /ordersno longer populate thetransactionHashesfield. The field is present in the response schema but always returns an empty array or null on match.Integrations must now use only the
tradeIDsfield returned in the response, then pollGET /trades?trade_id={id}until the transaction hash resolves or returnsFAILED. WebSocket fill notifications via the user channel are unaffected.The change was announced in the changelog on July 17 but the actual API behavior changed on July 24 — after the last spec audit.
Source: https://docs.polymarket.com/changelog
Our Cached Spec
POST /orderandPOST /ordersincore/specs/polymarket/PolymarketClobAPI.yamldocument atransactionHashes: string[]field in the FAK/FOK success response. The field is now always empty for matched orders.File:
core/specs/polymarket/PolymarketClobAPI.yamlcallApi() References at Risk
Order placement is handled via
@polymarket/clob-client-v2SDK inauth.ts, not via directcallApi(). The archived SDK (see #1069) will not receive the update that resolves hashes fromtradeIDsinstead of readingtransactionHashesdirectly. Any PMXT code that readstransactionHashesfrom a POST /order response (or relies on the SDK to do so) will silently receive empty data for matched orders.Hardcoded URL Bypasses
auth.ts:149—axios.get('${dataApiUrl}/profiles/${address}')is a separate bypass unrelated to this issue.Impact
transactionHashesis empty@polymarket/clob-client-v2used by PMXT (Spec drift: polymarket — @polymarket/clob-client-v2 SDK archived May 25 2026; all auth and order signing depends on it #1069) will not receive themFound by automated spec drift audit — 2026-07-26