Skip to main content
This space is the implementation reference for ISVs connecting to Polymarket US: your own users, your own app, our exchange, clearing and KYC.
If you are an introducing broker, read Start here — IB instead. The technical surface in this space is the same for you, but the responsibility split, the path to production, KYC ownership and funds handling all differ, and that page carries your versions of them.
Prerequisites: a shared Slack channel with us and a named integration lead. Everything on this page moves through that channel. If you do not have both yet, the first gate in Path to production is how you get them. See Getting help.

​
Who this is for

Engineers building against CreateVendorOrder, Transfer, the KYC API and the gRPC streams as an ISV. If you are an IB or an FCM, your account structure, KYC ownership and order surface differ — see the IB space.

​
The four things that break most ISV integrations

Every one of these has cost a partner weeks. Read all four before you write code.
  1. The identity model. You get two firms, not one. GET /v1/whoami returns the wrong one for addressing your users, and building a participant ID from it raises a security alert against your own account. → Firms, participants and accounts
  2. Scales. priceScale and fractionalQtyScale are multipliers read per instrument, and they multiply together. A hard-coded divisor is right on most markets and wrong by 10× on the rest. → Money on the wire
  3. PENDING. PENDING means the outcome is unknown to us, not that the order is queued. Recovery is a byte-identical resubmit with the same idempotency_key; a new key places a second order. → Order lifecycle
  4. Settlement ownership. We credit the participant’s clearing account at resolution. If you also credit your user from your own ledger, every settled position pays out twice. → What you own, what we own

​
What “beta” means here

Concretely: RPCs have been removed without a changelog entry before. CreateFundedOrder, PreviewFundedOrder and OdfSweep were removed on 2026-08-06 and a partner found out through reflection when their money path broke. Subscribe to the changelog and pin the proto bundle you build against — see Protos and SDKs.

​
What you own, what we own

Read this before you design your ledger. Two of the rows below have caused partners to ship code switched off in production rather than risk a double payout.

​
You never hold participant funds

You hold one pooled balance with us. You move cash into a participant account with a Transfer call, and it stays there: fills, realized profit, released collateral and settlement credits all land in the participant’s clearing account and become buying power. Nothing needs sweeping after a fill or a settlement. We credit the participant’s clearing account at resolution. Winning contracts settle at 1.00,losingcontractsat1.00, losing contracts at 0.00, and the credit is applied by us.
Do not pay your user from your own ledger at resolution. If you credit your user and we credit the participant account, every settled position pays out twice.This is being confirmed in writing. Until your integration lead confirms it, do not enable independent settlement crediting.
Transfers are structurally one-directional: you name only the participant account, we resolve your funding account from your configured relationship, and direction is fixed by the reason (DEPOSIT, WITHDRAWAL, VENDOR_FEES). Transfers to your own firm, between participants, or to an external destination are impossible. See Transfers.

​
Responsibility table

No correction, bust or refund policy is published. There is also no statement of whether institutional participants are in scope when retail positions are refunded after an outage. Do not promise your users a busted-trade process. Raise any erroneous order in your shared Slack channel immediately and say it moves money.
R-3 of the end-user agreement requirements forbids hosting modified, excerpted or re-rendered copies of the four legal documents. Link to the copies on polymarketexchange.com. Do not serve them from your own storage or a Drive folder.

​
Payment capture branding

You own the deposit and withdrawal GUI. We are the DCM, and both the NFA and the CFTC care what that screen says: the user must know funds are going to Polymarket Exchange.
The branding rules are not yet published. Send screenshots of your deposit and withdrawal screens to your integration lead before launch. This has never been written down, so a self-review is not possible.
Production deposit rails are wire only as of August 2026. CheckoutAPI and Aeropay return 403 method not permitted for ISVs — those surfaces are not entitled for you.

​
Where an ISV differs from an IB

Six things differ between an ISV and an IB: who owns end-user KYC, whether you can rely on your own, holding customer funds, the omnibus account, the account structure and the agreements you sign. Who you are has the table, and lists every page in this space where the IB implementation diverges.

​
Path to production

The sequence below is the whole path. ISV provisioning is fully manual on our side today — the institutional portal’s self-service API keys are built for market makers and its upload forms do not apply to you.
Preprod access does not require a signed agreement. One partner lost roughly three weeks believing it did. Start Gate 1 and Gate 2 in parallel.
No turnaround is published for any gate below.
Turnarounds are not yet published. Every gate below is marked VERIFY for turnaround. Ask your integration lead for a date per gate and hold the plan to it; do not assume same-day.

​
The gates

1

Intake

You submit: legal name, email address, phone number, business address, and the legal name of your funding entity (Wallet Co).
The exact intake form is not yet published. There is no published route for a prospective partner, which has produced inbound from entities claiming agreements that do not exist. Confirm the current field list with your integration lead.
We return: a shared Slack channel and a named integration lead. Owner: you. Turnaround: VERIFY
2

Agreements

You submit: an executed Vendor Connectivity Agreement (VCA) and Fee Agreement. The Fee Agreement is not public and is sent to you during discussions.Agreement completion is a repeated rejection loop. Before you send it back, check:
  • signature pages 8, 10, 11 and 15 are all signed,
  • the W9 TIN matches the entry in the portal exactly,
  • CP575 is attached as EIN confirmation.
We return: countersigned agreements. Owner: shared — your legal team and ours. Turnaround: VERIFY
3

Funding entity (Wallet Co)

You submit: your Wallet Co legal entity details.Your funding entity must exist and be active before your firm’s API credentials are enabled. This gate blocks credential issue, not just funding.We return: confirmation that the funding relationship is configured. We resolve your funding account from that relationship on every Transfer; you never name it. Owner: you. Turnaround: VERIFY
4

Preprod keypair and credentials

You submit: the public half of an RSA 2048 keypair you generate yourself. See Generate your keys.Keys are per environment. A preprod keypair does not work in production. You generate a second keypair for production at Gate 7.We return: your Client ID and your two firm names — the participant firm and the clearing-member firm. Record both; see Firms, participants and accounts.
How credentials reach you is being confirmed. Two channels are in use today and we are consolidating to one. Ask your integration lead which one applies to you rather than waiting on the other.
Owner: shared — you generate, we register. Turnaround: VERIFY
5

Scopes and entitlements

You submit: the list of surfaces you need — market data, positions, reports, cash movements, KYC, gRPC reflection.Scopes are granted server-side against your client. Do not request them on the token exchange. After we add a grant you must re-mint your access token or you will keep getting PERMISSION_DENIED. Six of eight ISVs discovered their scope set by hitting that error. See Scopes and entitlements.We return: the grants, on your client, in that environment. Owner: us. Turnaround: VERIFY
6

Preprod build and UAT

You submit: a completed UAT test plan.Two things you cannot test in preprod, so plan around them now:
  • Markets do not resolve in preprod. Instruments reach INSTRUMENT_STATE_EXPIRED in large batches — 363, 455, 544 and 549 in a single session — and none resolve. One partner asked six times over 40 days to test a settlement flow and never could.
  • Books are thin and intermittent. pmsim is the only liquidity provider, coverage runs from ~48% of astatc- symbols down to ~0.1% of aec-atp, and depth sits at the edges (0.98offer,0.98 offer, 0.06 bid). Because your order surface is fill-or-kill only, a thin book blocks you completely while market makers are unaffected.
How to manufacture a preprod fill is unresolved. The only way to rest an order in a thin preprod book is the legacy OrderEntryAPI/InsertOrder path, and UAT §0 asks you to disavow exactly that. These two requirements contradict each other and you cannot resolve it alone — raise it with your integration lead.
Preprod pool funding is done manually by us on a Slack request; there is no self-service test funding.We return: UAT sign-off. Owner: you, with our review. Turnaround: VERIFY
7

Production keypair and credentials

You submit: a separate production keypair’s public half, generated fresh. Never reuse the preprod key.We return: production Client ID and production firm names.
At the account and user level the legal name must be a physical person’s name, or NFA reports error. One partner’s production record was entered as the company name. Check your production records before first traffic.
Owner: shared. Turnaround: VERIFY
8

Fund the production pool

You submit: a wire. Production deposit rails are wire only as of August 2026.We return: the balance on GetFundingAccountBalance, which is the pool’s source of truth.Owner: you. Turnaround: VERIFY
9

Production traffic

Start with one real participant through the full loop: KYC submit → kyc.approved webhook → Transfer → CreateVendorOrder → drop copy fill → balance check.Production has a status page at status.polymarketexchange.com. Preprod has none.Owner: you. Turnaround: n/a.

​
Participant type casing

If you are creating participants through an administrative path, the spelling of the type matters and differs by path: one path validates against a vocabulary spelling ISV uppercase and compares case-sensitively, while adopt and provision endpoints normalize with strings.ToLower. The registry’s canonical lowercase isv has been rejected with HTTP 400 on the case-sensitive path. introducing_broker is spelled identically in both vocabularies, so only the ISV path is affected.
Which casing applies to which path is being corrected. If you get an HTTP 400 naming the participant type, try the other casing and report it.

​
Go-live checklist

Copy this into your own tracker.
  • Shared Slack channel open, integration lead named
  • Intake submitted: legal name, email, phone, address, Wallet Co legal name
  • VCA executed — signature pages 8, 10, 11, 15 signed
  • Fee Agreement executed
  • W9 TIN matches the portal entry; CP575 attached
  • Wallet Co exists and is active
  • Preprod RSA 2048 keypair generated; public half sent; private half never left your infrastructure
  • Preprod Client ID received
  • Both firm names recorded: ...-api-participant and ...-api-clearing-member
  • Scope list agreed and granted; token re-minted after the grant
  • Token client honours expires_in minus 30 s, with no hardcoded 180
  • Both scales read per instrument from reference data; no hard-coded divisor
  • PENDING recovery path resubmits the same idempotency_key with a byte-identical body
  • kyc.approved webhook registered, signing secret stored, dedupe on event_id
  • participantId recorded against your user row from the webhook, never constructed
  • No production SSN reuse; test SSNs never shared across users
  • Drop copy consumer running with resume_token persistence
  • Settlement crediting from your own ledger is off
  • Deposit and withdrawal screens reviewed with your integration lead
  • Legal agreements linked from polymarketexchange.com, not re-hosted
  • UAT test plan signed off
  • Production keypair generated separately; production Client ID received
  • Production account and user records use a physical person’s legal name
  • Production pool funded by wire
  • One end-to-end participant loop completed in production
institutional@polymarket.us is the published route for new enquiries. It is not the right route once you are live on preprod — use your shared Slack channel.

​
What can go wrong

institutional@polymarket.us is the published route for new enquiries. It is not the right route once you are live on preprod — use your shared Slack channel.

​
Next

Connect