> ## Documentation Index > Fetch the complete documentation index at: https://partners.docs.polymarket.us/llms.txt > Use this file to discover all available pages before exploring further. # ISV: start here > The four things that break most ISV integrations, the responsibility split, and the gate sequence to production traffic. 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](/ib/start) 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](#path-to-production) is how you get them. See [Getting help](#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](/identity) 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](/instruments#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](/outcomes#order-outcomes) 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-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](/environments#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, 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](/funding#move-cash). ### Responsibility table | Area | You own | We own | | ------------------------------------------- | ------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------ | | End-user app, UX, order entry | Everything the user sees and every order you submit | Nothing | | KYC payload collection | Collecting and submitting the payload | Running the Socure check | | **KYC decision** | Nothing. You cannot override, appeal or re-run it | **The decision.** `decision`, `status` and `subStatus` are informational, not control flow | | KYC decline reasons | Communicating *something* to your user | Not exposed to you at all — retrieving one needs a human to open a Socure thread | | Participant identity | Recording the `participantId` we hand you | Issuing it, and owning the SSN → account mapping | | **Holding customer funds** | Nothing. ISVs do not hold customer funds | Custody of all participant balances | | Pooled balance | Keeping it funded ahead of demand | `GetFundingAccountBalance` as its source of truth | | Vendor fees | Tracking your own accruals. The platform never knows your fee basis and accrued fees are not on the API | The daily Vendor Fees report | | **Market resolution and settlement credit** | Reading settlement values and reconciling | Resolving the market and crediting the participant account | | **Erroneous orders, busts, refunds** | Your own user communications | See the warning below | | **End-user support** | First line, all of it. Every end-user question reaches us through you, in your shared Slack channel | Partner-facing support only | | **Payment capture branding** | The GUI | The requirement that the user knows funds go to Polymarket Exchange | | Legal agreements to the end user | Presenting the four QCX LLC / QC Clearing LLC documents from `polymarketexchange.com` | Issuing and versioning them | **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](/who-you-are#the-six-differences) 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 **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` **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` **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` **You submit:** the **public** half of an RSA 2048 keypair you generate yourself. See [Generate your keys](/authentication#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](/identity). **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` **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](/authentication#scopes-and-entitlements). **We return:** the grants, on your client, in that environment. **Owner:** us. **Turnaround:** `VERIFY` **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.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` **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` **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` 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 | Where | Symptom | Cause | What you do | | ------------------------- | -------------------------------------------------------- | ----------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------- | | What you own, what we own | Your user is paid twice on a settled market | You credited from your own ledger and we credited the participant account | Disable independent settlement crediting; read [Who pays at settlement](/settlement#who-credits-the-user) | | What you own, what we own | Your balance sheet cannot reach zero | Transfers accept at most 2 decimal places, balances carry more (`172.395`, `1377.57275` observed) | There is no sanctioned handling for the residue. Track it as a known reconciliation difference and raise it | | What you own, what we own | You verified a user yourself and they are still declined | Your KYC does not substitute for ours | Submit the payload; we decide | | What you own, what we own | A user cannot be re-verified | One SSN maps to exactly one exchange account platform-wide, and there is no re-KYC or PII-update path | Raise it in Slack; it needs manual work on our side | | What you own, what we own | `403 method not permitted` on checkout or Aeropay | Those surfaces are not entitled for ISVs | Use wire deposits | `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](/environments)