SX Bet

Step zero — from nothing to your first trade

SX Bet is client-side only: your key and API key go to sx.bet directly and never transit Predictefy, so the last step here is the venue-direct SDK rather than a hosted lane.

1. Register the trading wallet with sx.bet. Start at sx.bet. A key-only wallet is not enough — an unregistered wallet is rejected with INSUFFICIENT_KYC even when its signature is perfectly valid.
2. Enable betting for each token and network you intend to trade.
3. Deploy and pre-fund the account proxy wallet. V3 will not accept a resting order without it. This catches people out: the wallet can be registered and still be refused at this step.
4. Generate an API key for the registered trading account. V3 requires it on every trading and cancellation request, not just at sign-in.
5. Fund the proxy. Six-decimal SX Network USDC. SX Network is not on LI.FI, so funding routes through Glide — POST /v1/bridge/session, then client.accounts.sxbet.depositToProxy moves funds from the EOA into the proxy. The V3 minimum order size is 5 USDC.
6. Trade venue-direct. Use client.accounts.sxbet. There is no hosted lane: every /v1/exec/sxbet/… route answers 404 VENUE_NOT_SUPPORTED, and SX Bet never appears in GET /v1/exec/venues.

What you need first

• Production status: Client-side only. There is no hosted SX Bet execution lane, so GET /v1/exec/venues never lists it and every /v1/exec/sxbet/… route answers 404 VENUE_NOT_SUPPORTED. The venue-direct SDK integration at client.accounts.sxbet has been live since 2026-07-27.
• Wallet and chain: An EVM wallet on SX Network (chain 4162). The private key stays in your process and signs every order locally; V3 cancellation uses the caller’s API key instead.
• Venue account: Yes, and the preconditions are hard. The trading wallet must have a registered sx.bet account — a key-only wallet is rejected with INSUFFICIENT_KYC even when its signature is correct. V3 also requires the account’s proxy wallet to be deployed and pre-funded before the venue accepts an order. The retired V2 TokenTransferProxy approval is not a V3 precondition.
• Credentials: The wallet private key and an SX Bet API key. V3 requires the API key on every trading and cancellation request. Both stay in your process and go only to sx.bet; neither transits Predictefy.
• Funding: Six-decimal SX Network USDC in the account proxy. SX Network is not on LI.FI, so the funding lane routes through Glide: POST /v1/bridge/session; then client.accounts.sxbet.depositToProxy moves funds from the EOA into the proxy. V3’s minimum order size is 5 USDC (live orderSizeMinimum, obv3 metadata).

The client-side write surface

import Predictefy from '@predictefy/sdk';

const client = new Predictefy({
  apiKey: process.env.PREDICTEFY_API_KEY,
  venueCredentials: {
    sxbet: {
      privateKey: process.env.SXBET_WALLET_KEY!,
      apiKey: process.env.SXBET_API_KEY, // required on V3; optional on V2
    },
  },
});

• Limit and market orders: Both sign one EIP-712 order and post to POST /orders-v3. A limit order uses GTC; a market order uses IOC, where percentageOdds is the worst accepted price.
• Cancellation: cancelOrder / cancelOrders, cancelOrdersByEvent, and cancelAllOrders use API-key-authenticated DELETE /orders-v3, /orders-v3/event, and /orders-v3/all. By-id cancellation reports its outcome synchronously. Event/all acknowledge asynchronous batches, and the SDK drains them while hasMore remains true.
• Proxy funding: client.accounts.sxbet.depositToProxy builds, signs, and submits the V3 transfer permit. client.funding.buildPermitRequest and POST /orders/approve are V2-only and refuse under V3.
• Dead-man switch: armHeartbeat and disarmHeartbeat use /heartbeat/v3. The same x-sx-api-key credential is mandatory for V3 trading.

The V3 API cutover

SX Bet retired its V2 order-book and trading API on 2026-08-26 14:00 UTC. The SDK ships both implementations and defaults to v3.

Select a version with the SXBET_API_VERSION environment variable (v2 or v3), or pin one explicitly through SxbetAccountClient’s apiVersion option. SXBET_API_VERSION=v2 is the only way back and works only against a V2 sandbox.

Three V3 differences remain load-bearing, and each one is a hard rejection rather than a soft fallback:

• Routes move. Order create, cancel, cancel-by-event, cancel-all, metadata, and heartbeat all move to their -v3 paths.
• The API-key header is renamed. V3 reads x-sx-api-key and rejects the V2 spelling.
• An API key becomes mandatory for trading. V2 order placement was signature-only; V3 requires the key as well.

Disarming the heartbeat also changes shape: V2 has a separate cancel route, while V3 disarms by posting timeoutSeconds: 0 to the same heartbeat route. The SDK handles that difference for you.

Venue properties, not gaps

• No hosted lane, no hosted relay. This client-side integration does not imply hosted execution or unlisted verb coverage. Signing keys and venue credentials never leave your process.
• No withdrawal route. SX Bet publishes none, so withdrawFromProxy() throws NOT_SUPPORTED by design. Withdrawals and proxy-to-proxy transfers are Safe-authorised in the sx.bet app, and this lane will not emulate a route the venue does not offer. See Accounts & funding.
• Order books. SX Bet has a real CLOB. An earlier Railway-egress incident that returned honest empty books healed on 2026-08-15; production fetchOrderBook returned real two-sided depth. That healing changed book availability only — the execution boundary above is unchanged.

Venue and jurisdiction eligibility remain the operator’s and integrator’s compliance responsibility.