Vuch Platform API — public documentation
The Vuch Platform API is the external interface of the platform: REST endpoints behind a single API gateway, webhooks for asynchronous events, and WebSocket streams for real-time state. This page is the public overview an engineering team needs to assess an integration; full endpoint-level specifications and a sandbox tenant are available on request.
The gateway model
All external traffic enters through the API gateway — the platform's single entry point — which authenticates requests and routes them to the service domains behind it. Integrators build against one consistent surface; the internal topology of the twelve-service deployment (ports, routing, layout) is intentionally not part of the public contract and is shared during technical evaluation.
Service domains
| Domain | Responsibility |
|---|---|
| Identity | Authentication, authorization, roles, sessions |
| Market | Prediction market logic: catalog, trading, positions, resolution |
| Wallet | The unified balance and the atomic financial ledger |
| Payment | USDT deposits/withdrawals, provider webhook processing, moderation queue |
| Casino | Game catalog, provider adapters, seamless wallet callbacks |
| Realtime | WebSocket connections and push events |
| Content | CMS articles, market-linked content, static pages |
| Notification | User-facing notifications |
The risk domain and the admin backend operate behind the same architecture but are not part of the public integration surface.
REST endpoint groups
| Group | Typical operations | Typical use |
|---|---|---|
| Players | Create account, fetch profile, manage state | Registration and identity flows |
| Wallets | Read balance, list transactions | Displaying the unified balance and full history |
| Markets | List markets, buy/sell shares, read positions | Prediction market trading front ends |
| Game sessions | Create session, launch game | Serving casino content against the seamless wallet |
| Payments | Initiate deposit/withdrawal, read status | Cashier flows on USDT rails |
Conventions across the surface: HTTPS-only, JSON request/response bodies, authenticated server-to-server calls with scoped credentials, and idempotent handling of financially significant operations — retries are safe by design, because duplicate credits are the failure mode that costs real money.
Two semantics worth noting before you design against the API. First, the wallet is unified: one balance per user across prediction markets and casino, so there are no transfer endpoints between product purses — none are needed. Second, every financial operation is an atomic ledger entry; the transaction history you can read back is the same record the admin panel and finance reporting are built on.
Webhooks
The platform both consumes and emits webhooks:
- Inbound — payment provider callbacks. Provider notifications for deposits and withdrawals are received by the payment domain, verified, and processed idempotently; the ledger is credited only on confirmed events. Withdrawals pass a manual moderation queue with a status model before funds move.
- Outbound — platform events to your systems. Your backend can subscribe to signed event callbacks, including payment status changes and market resolution events — the moment a market resolves and positions settle, your systems know.
Outbound deliveries are signed and retried; consumers should verify signatures and deduplicate on event identifiers.
WebSocket streams
The realtime domain pushes live state to connected clients:
| Stream | Content |
|---|---|
| Balance updates | The unified balance, pushed the moment the ledger commits |
| Live trade feed | Trades across prediction markets as they execute |
| Resolution notifications | Market resolution and settlement events |
These streams ride the platform's internal event backbone — 47 event types — so real-time client state and back-office state are views of the same stream, never reconciliations of two.
Sandbox and full documentation
Endpoint-level specifications, schema detail and a sandbox tenant with test wallets are provided on request. The sandbox lets your engineers exercise the flows that decide an integration — registration, deposit webhook, market trade, game session, withdrawal moderation — before any commercial commitment. Request access with a note on your integration scope, and see the integration solution page for how a typical project is sequenced.