Skip to main content
ParlayX connects to Kalshi and Polymarket. You integrate once and reach both. New venues are added on customer request, typically in one to two weeks.

​
Two shapes of venue

Venues differ in a way that matters more than their APIs do: what identity you trade under.

Wallet venues

PolymarketYou trade under a wallet. Wallets can be created freely. Each pod is tied to its own wallet and its own set of permissions. 

Account venues

KalshiYou trade under a KYC’d account belonging to your entity. Accounts cannot be created freely.
That difference determines how each venue reaches a pod, and how strong the separation between pods is.

​
Connecting a wallet venue

Nothing to connect. Each pod is created with its own wallet, and on-chain venues execute through it. The wallet belongs to the pod permanently. Separation between pods is enforced by the chain. One pod cannot spend another pod’s balance, regardless of configuration.

​
Connecting an account venue

Three steps, done once per account:
1

Connect the account at the organization

An admin supplies the venue API credential. It is verified on intake and stored encrypted, with the signing key held in a hardware module.
2

Tie it to a pod

An explicit grant that lets that pod trade through that account. Untied pods cannot reach it.
3

Actors trade through the tie

Actors in the pod place orders. They never see or handle the credential.
You can connect a different account per pod, or tie one account to several pods. The choice has consequences.

​
Separation between pods, stated plainly

Tying one venue account to several pods gives you correct per-pod attribution in ParlayX, but the venue still sees one balance. If a strategy in one pod draws the account down, the other pods tied to it feel it. Use one account per pod when the separation needs to be real.
We are direct about this because the alternative — implying every pod is a hard boundary everywhere — would not survive contact with your first margin call.

​
Order sizing rules per venue

Each venue quantizes order sizes to its own grid and enforces its own minimum. We reject a size the venue cannot execute rather than sending it and letting the venue round it down silently. Polymarket A share-denominated size finer than 2 decimal places is rejected, and the error names the size that does execute. This applies to the shares on a sell and the size on a limit order of either side; a market buy is sized in dollars and is not affected.
Closing a position can leave a residue, and the residue cannot be sold. Selling 14.28 of a 14.285713-share position leaves 0.005713 shares behind. That remainder rounds to zero on the size grid and sits under the venue’s minimum order size, so no further sell order can ever clear it — retrying will only be rejected.The remainder is not lost. It is redeemed with the rest of the position once the market resolves, at which point it pays out or expires worthless like any other holding. Treat a sub-share leftover as awaiting resolution, not as a failed close.

​
Connection health

Venue credentials are monitored and surfaced in the console: Revoked and invalid are terminal — they are resolved by supplying a new credential, not by retrying.
A credential that has expired or been rotated at the venue cannot be detected until a call fails. If you rotate a key on the venue side, update it here at the same time.