Polymarket & Kalshi API Dev Brief: April 9–16, 2026

Polymarket and Kalshi developers faced a concentrated week of breaking API changes, live regulatory fallout, and an active supply-chain threat from April 9 through April 16, 2026. Polymarket shipped three documented changelog updates, launched an audit of its Builders Program, and kept its MLB–Sportradar data integration in the spotlight, while Kalshi developers continued fighting through the fixed-point migration and a federal restraining order against Arizona’s criminal case.

Polymarket: Three Breaking Changes in Five Days

Polymarket’s documented changelog landed three updates that any integration using the CLOB API needs to audit.

April 9 — GET /markets Default Behavior Changed

The closed query parameter on GET /markets now defaults to false. Closed markets are excluded from results unless you explicitly pass closed=true. Any existing scraper, analytics pipeline, or market discovery tool that relied on closed markets appearing in the default response is now silently filtering them out.

# Before April 9, 2026 — returned all markets including closed
GET /markets

# After April 9, 2026 — returns only open markets
GET /markets

# To replicate previous behavior
GET /markets?closed=true

If you’re building market discovery around the Polymarket Gamma API or the CLOB /markets endpoint, diff your response counts against last week’s baseline and patch your query string.

April 10 — Keyset Pagination Endpoints Launched

Two new endpoints shipped to replace the offset-based paging pattern:

Response shape changes from a flat array to a wrapper:

{
  "markets": [...],
  "next_cursor": "eyJpZCI6IjB4YWJjIn0..."
}

The keyset variants reject offset entirely. Filters and per-item response shape are identical to the legacy endpoints. The offset-based routes remain live for now but are flagged for deprecation.

For anyone following the full Polymarket API architecture, the Polymarket API Guide covers where this fits in the CLOB + Gamma + Data split.

April 13 — Bridge API Support Contact Added

The Bridge API docs added a direct support link to Fun.xyz (Polymarket’s bridge infrastructure provider) for failed, stuck, or compliance-held transactions. This is a docs-only change, but it signals that bridge-related errors are frequent enough to warrant a named escalation path. Teams doing cross-chain USDC deposits via the Bridge API should save the contact before the next stuck transaction, not during one.

Builders Program Under Audit (April 14)

On April 14, 2026, The Information reported that Polymarket — now raising at a roughly $20 billion valuation — launched an audit of third-party startups in its Builders Program over copy-trading apps that flagged and mirrored accounts suspected of insider trading.

Two startups are named:

• Polycool — published a “guide to Polymarket insider trading” on its public site, explicitly framing prediction markets as outside traditional securities rules.
• Kreo (KreoPoly) — Telegram bot that mirrors trades from “smart money” wallets, marketed as helping users “find insiders before the rest.”

Both reportedly drove hundreds of millions of dollars in incremental volume. The Builders Program was only launched in November 2025. The audit follows March 2026 reporting from Bubblemaps that identified a Polymarket trader who won 93% of bets on U.S. and Israeli military strikes against Iran, several placed hours before public announcements.

The direct developer consequence: if your application is registered in the Builders Program and your product surface involves surfacing, ranking, or automating trades from accounts flagged for suspected insider activity, expect review. For broader compliance context, see the KYC and Compliance Identity guide.

Ongoing Threat: dev-protocol Supply-Chain Attack

StepSecurity’s threat intelligence team previously disclosed that the dev-protocol GitHub organization — a verified account with 568 followers originally belonging to a legitimate Japanese DeFi project — was hijacked and is now distributing malicious Polymarket copy-trading bots. The repo dev-protocol/polymarket-copytrading-bot-sport has a polished README, hundreds of stars, and a bot that genuinely connects to Polymarket APIs. The hostile payload lives in typosquatted npm dependencies.

Packages to scan your node_modules for:

levex-refa
lint-builder
ts-bign
big-nunber

Confirmed behaviors when the bot runs:

• Reads wallet private keys from .env, id.json, or config.toml.
• Exfiltrates files to attacker-controlled Vercel endpoints.
• IP fingerprints the host.
• Reconfigures ufw to open port 22 and writes attacker keys to ~/.ssh/authorized_keys.

Every wallet whose private key was ever in a .env on a machine that ran this bot should be rotated and drained. API keys on the same machine should be considered compromised. Operators building production agents should not be putting raw private keys in .env files for third-party tools in the first place — Coinbase Agentic Wallets, hardware-backed signers, or a separate signing service address the same problem. The Polymarket + Coinbase Agentic Wallet quickstart walks through the setup.

CLOB Error Codes Worth Knowing

Polymarket’s CLOB API returns structured errors that are easy to handle once you’ve seen them. The ones most likely to surface during volatile windows:

The CLOB has an internal override worth knowing: any error string containing "not found" surfaces as 404, "unauthorized" as 401, and "context canceled" as 400, regardless of the underlying status. If your retry logic branches on status codes alone, this quirk will surprise you.

Kalshi: Fixed-Point Migration Keeps Biting

Kalshi’s fixed-point migration — underway since early 2026 — continues to generate the largest share of integration breakage, now layered on top of the weekly FIX maintenance ritual and the Arizona criminal case reversal.

The Migration, Plainly

Kalshi is replacing two categories of fields across REST, WebSocket, and FIX:

1. Integer cents price fields → fixed-point dollar strings (_dollars suffix)
2. Integer contract counts → fixed-point strings (_fp suffix)

The deprecation of legacy cents price fields (yes_bid, no_ask, last_price, etc.) shipped March 5, 2026. Their _dollars equivalents (yes_bid_dollars, no_ask_dollars, last_price_dollars) are already live.

{
  "yes_bid": 45,                   // legacy — DEPRECATED
  "yes_bid_dollars": "0.4500",     // current — use this
  "last_price_dollars": "0.4200"
}

Orderbook responses are now wrapped in an orderbook_fp object:

{
  "orderbook_fp": {
    "yes_dollars": [["0.4200", "13.00"]],
    "no_dollars":  [["0.5700", "27.00"]]
  }
}

Each level is a two-element string array: [price_dollars, count_fp]. Both values are strings to support subpenny pricing and fractional contract sizes. Note: Kalshi’s orderbook only returns bids — a YES bid at $X is equivalent to a NO ask at $(1.00 − X), so showing bids on both sides gives complete book information.

Settlements expose yes_total_cost_dollars and no_total_cost_dollars. The legacy yes_total_cost/no_total_cost cent fields remain available for now (they were added late in the migration) but are on the deprecation path.

Fractional Trading and the 6-Decimal Fee Problem

Fractional trading rolled out per-market starting the week of March 9, 2026. Check the fractional_trading_enabled flag on Market responses before assuming integer contracts. On fractional-enabled markets, legacy integer count fields may be truncated entirely — migrate to _fp to avoid silent data loss.

The underreported consequence: when fractional contract sizes combine with subpenny pricing, intermediate calculations in fee rounding can reach up to 6 decimal places. Bots that round at 2–4 decimals will generate off-by-one cent errors that compound over thousands of fills. Round once, at the final dollar amount, using the exchange’s documented rounding rules — not at every intermediate step.

The Kalshi API Guide covers the auth layer (RSA-PSS with KALSHI-ACCESS-KEY, KALSHI-ACCESS-SIGNATURE, and KALSHI-ACCESS-TIMESTAMP headers) and the Prediction Market API Reference tracks the exact endpoint shapes Polymarket and Kalshi ship week over week.

The Thursday FIX Reset

Kalshi’s FIX 4.4 gateway at fix.elections.kalshi.com drops sessions during the weekly maintenance window — Thursdays 3:00–5:00 AM ET — and expects all clients to restart their sessions and reset sequence numbers to zero.

The critical detail: on the first Logon after maintenance, you must set ResetSeqNumFlag=Y (FIX tag 141). For sessions without retransmission support (KalshiNR, KalshiDC, KalshiPT), ResetSeqNumFlag must always be Y or the Logon will be rejected.

A minimal Logon body (fields only, SOH-separated in the wire message):

35=A          (MsgType=Logon)
141=Y         (ResetSeqNumFlag)
98=0          (EncryptMethod=None; TLS handled at transport)
108=30        (HeartBtInt=30)
96=<RawData>  (PSS RSA signature over PreHashString)

The RawData field must contain a PSS RSA signature of:

PreHashString = SendingTime + SOH + MsgType + SOH + MsgSeqNum + SOH + SenderCompID + SOH + TargetCompID

The most common post-maintenance failure: the SendingTime value used to compute the PSS signature does not exactly match the SendingTime in tag 52 of the actual Logon message. Most FIX libraries auto-populate SendingTime; use that library-generated value when computing the pre-hash string, don’t generate a second timestamp manually.

Arizona Prosecution Halted (April 10, Relevant This Week)

On March 17, 2026, Arizona Attorney General Kris Mayes filed 20 misdemeanor criminal counts against KalshiEx LLC — the first criminal prosecution of a CFTC-registered prediction market in the U.S. On April 10, 2026, U.S. District Judge Michael Liburdi granted a CFTC-requested temporary restraining order, blocking Arizona from pursuing the criminal case. The Monday arraignment was called off.

This doesn’t resolve the broader state-by-state patchwork — Kalshi is still contesting civil actions in Massachusetts, Nevada, and Michigan — but it removes the most acute near-term escalation and signals that federal courts are, for now, prepared to treat CFTC jurisdiction as preemptive. For bot operators: no immediate operational change, but the compliance architecture underneath U.S. prediction markets remains unsettled enough that multi-jurisdiction routing should not be a design assumption.

MLB, Sportradar, and Official League Data

A reminder for anyone building sports-facing Polymarket products: since March 19, 2026, Polymarket is MLB’s Official Prediction Market Exchange, with exclusive access to MLB marks and Sportradar’s official league data feed. Markets resolving against Sportradar’s ultra-low-latency official data stream will settle faster and more authoritatively than prior community-resolved markets.

The integrity-framework side of the deal restricts certain markets (individual pitches, manager decisions, umpire performance) that Polymarket and MLB have agreed present integrity risk. Your market scraper should expect these categories to simply not exist going forward rather than treat their absence as a bug.

Developer Friction Summary

Action Items for the Weekend

1. Polymarket integrations — diff GET /markets response counts against last week; explicitly pass closed=true anywhere closed markets were implicitly included. Begin migrating pagination to /markets/keyset before the offset-based endpoints are formally deprecated.
2. Any team that installed a GitHub-sourced Polymarket bot — grep -r "levex-refa\|lint-builder\|ts-bign\|big-nunber" node_modules across every machine the bot touched. Rotate wallet keys and API credentials if any hit. Inspect ~/.ssh/authorized_keys and ufw status for unexpected changes.
3. Kalshi integrations — audit every place your code reads yes_bid, no_ask, last_price, or any integer count field. Migrate reads to _dollars and _fp equivalents. If you bot fractional-enabled markets, raise your intermediate calculation precision to at least 6 decimals in fee rounding math.
4. FIX clients — confirm ResetSeqNumFlag=Y is set on the post-maintenance Logon. For KalshiNR, KalshiDC, or KalshiPT sessions, confirm it is set on every Logon. Verify that your library-generated SendingTime is what you’re signing, not a separately generated timestamp.
5. Builders Program applicants — review how your product surfaces accounts with winning streaks. The audit targets apps that operationalized surfacing suspected insider accounts. Structural positioning matters; “we surface public on-chain data” is not automatically sufficient cover if the product workflow explicitly routes users toward flagged wallets.

Next week: expect the first Kalshi markets to fully reject integer contract count fields in request bodies, and for Polymarket to publish the Builders Program audit’s first outcomes.