Endpoint Coverage

Audited against Polymarket/py-clob-client-v2 commit a2ec069fb66096e2b80ff0b7fdf628fc41d6352c.

This file tracks CLOB HTTP endpoint coverage in polymarket_clob. It intentionally does not cover WebSockets, bot integration, the higher-level SDK, or strategy code.

Private GET requests in this package sign the base endpoint path and send query params only on the URL. This matches the audited Python client behavior for L2-authenticated GETs.

Coverage Summary

Scope

This document covers the CLOB HTTP endpoint surface wrapped by the Elixir API modules under PolymarketClob.API.*. Each implemented row maps a Python method on Polymarket/py-clob-client-v2 to the Elixir wrapper that calls the same path with the same authentication scope.

Out of Scope For This Document

• WebSockets — neither the CLOB market channel (wss://ws-subscriptions-clob.polymarket.com/ws/market), the user channel, nor the RTDS feed (wss://ws-live-data.polymarket.com) are HTTP endpoints, and py-clob-client-v2 does not own them. WebSocket coverage will be tracked separately when those modules land.
• L1 (EIP-712 ClobAuth) endpoints — /auth/api-key (POST), /auth/derive-api-key (GET), and the readonly-API-key family are listed under "Not Yet Implemented" but require Auth.L1 to grow request-side helpers and a credential-lifecycle decision before they can be wrapped. The L1 auth primitive itself is implemented and fixture-backed; only the endpoint wrappers built on top of it are missing.
• Signing and order-building primitives — Auth.L1 (ClobAuth with nonce), Auth.L2 (HMAC), EIP712, Order.Builder (limit + market amounts, signed-order construction), Order.Signing (EIP-712 domain, hashing, signature), and Order.Rounding (price/size/amount decimal config) are documented in README.md, AGENTS.md, and PACKAGE_PLAN.md, and are validated by parity fixtures under test/fixtures/parity/. They are listed here only as cross-reference; correctness changes for them belong in those files.
• Higher-level SDK behavior (polymarket package) — Gamma, Data API, RTDS, CTF redeem/merge/split, pUSD wrap/unwrap, P&L helpers, activity normalization. The audited Python client does not own these either.

Implemented Endpoints

Public status and market data

Private account and user data

Private order management

Not Yet Implemented

These endpoints exist in the audited Python client and are plausible future polymarket_clob work, but they have not been wrapped yet.

Private account/key management

Intentionally Skipped For Now

These are deliberately outside the current low-level endpoint-wrapper slices.

Local helper/composed behavior

Rewards

Builder surface

RFQ

Product/Domain Decisions Needed

• API key lifecycle: decide whether polymarket_clob should create/delete user API keys, or only consume provided credentials. These endpoints mutate credentials and use both L1 and L2 auth.
• Readonly API keys: decide whether readonly key management belongs in the low-level CLOB package or a higher-level administration surface.
• Reward reporting: decide whether rewards are low-level CLOB data or part of the higher-level Polymarket SDK.
• Builder surface: decide how builder codes, builder API keys, builder trades, fee lookup, and heartbeat should be modeled before wrapping these endpoints.
• RFQ: decide whether RFQ should be a separate module/package boundary. Python RFQ accept/approve paths build V1 orders internally, which conflicts with the current endpoint-wrapper-only design.
• Pagination shape: decide whether Elixir should add Python-style auto-pagination helpers in addition to direct page wrappers for open orders, trades, rewards, and market lists.

Pagination Policy

Wrappers that the Python client auto-paginates by default — get_open_orders, get_trades, get_pre_migration_orders, and the cursored market-list endpoints — are exposed in Elixir as direct page wrappers. The caller passes :next_cursor (and any filter params) and receives the raw page body. Auto-pagination is intentionally not provided yet because:

• The streaming consumer pattern in Elixir is typically a Stream.resource/3, not a loop that accumulates a list. Adding Enumerable-friendly cursors is a design choice that may belong in the higher-level polymarket SDK.
• Bot/SDK callers may want the cursor exposed for state persistence (resumable backfills), which an opaque auto-paginator would hide.

If/when auto-pagination is added, the direct page wrappers should remain so callers that need cursor visibility are not forced through a wrapper.

Maintenance

When Polymarket/py-clob-client-v2 advances:

1. Update the audited commit hash in this document's header.
2. Diff the new commit against the audited commit, focusing on client.py, endpoints.py, and any new modules under py_clob_client/.
3. For each new public method, add a row to Implemented, Not Yet Implemented, or Intentionally Skipped with a one-sentence rationale.
4. For each removed/renamed method, update both this document and the corresponding Elixir wrapper.
5. Re-run mix test to verify parity fixtures still match (test/fixtures/parity/{clob_auth,l2_hmac,order_builder,orders}.json are the load-bearing ones; regenerate via scripts/generate_parity_fixtures.py if the Python client's signing/auth output changed).
6. Update the Coverage Summary counts at the top of this document.

This document is the single source of truth for HTTP endpoint coverage. Anything beyond that — auth primitives, signing, order building, WebSockets, higher-level SDK — is documented in README.md, AGENTS.md, PACKAGE_PLAN.md, or the relevant module moduledoc.