When should I use a hosted poker solver API instead of a desktop solver?
Use a hosted solver API when your product needs a documented, stateless strategy request it can make repeatedly. Use a desktop solver when your research depends on designing and inspecting a custom local solve workflow.
Comparable facts
| Hosted API interface | Bearer-authenticated, stateless JSON requests and responses documented in the public OpenAPI contract |
|---|---|
| Hosted strategy access | Presolved preflop and flop lookups, plus on-demand custom flop, turn, and river solves through documented endpoints |
| Desktop solver workflow | A local research workflow for constructing a tree, choosing abstractions and sizings, running a solve, and inspecting its outputs |
| Repeatability boundary | An API request is repeatable only when the caller preserves the complete request, API version or strategy version where supported, and the returned response |
| Permitted use | Training, coaching, hand review, study, and research — never real-time assistance at real-money tables |
When is a hosted solver API the better fit?
Choose a hosted API when software needs strategy inside a product rather than inside a researcher’s desktop session: for example, a trainer that grades a hand, a hand-review queue, a range visualizer, a backend service, or an AI agent with human review. The product can call one documented endpoint and render the returned mixed frequencies, ranges, nodes, or EVs.
The integration boundary is explicit. Your application owns authentication, input validation, storage of its own study records, and presentation. Pokerai API receives a stateless spot and returns JSON; it does not require your application to distribute a solver binary or operate a local solver tree.
When is a desktop solver the better fit?
Choose a desktop solver when the main work is research: defining a novel game tree, selecting abstractions and bet sizes, running local experiments, and inspecting the resulting tree in detail. Those choices are inputs to a solve, not assumptions a hosted API can infer from a short product request.
A desktop workflow is also the appropriate place to compare research configurations before publishing a fixed study workflow. Do not describe a hosted response as equivalent to a separately configured local solve unless the full configuration and outputs have been preserved and compared.
Integration and reproducibility boundaries
For a reproducible API-backed study, record the endpoint, complete request body, strategy or API version when the endpoint exposes one, request time, and returned response. Replaying only a natural-language description of a spot is not enough: positions, stacks, board, action line, sizing choices, and version can change the result.
For an on-demand solve, retain the solve handle and the original configuration while reading its tree, nodes, and EVs. Polling or node reads inspect that solve; a new submission is a separate solve request. If you need a durable research artifact, retain the exported inputs and outputs in your own study system.
Safe use and no-RTA
Pokerai API is for offline training, coaching, hand review, study, and research. Real-time assistance at real-money tables is prohibited.
Build product controls around that boundary: keep strategy features in study and review contexts, require human review for agent-generated explanations, and do not turn an API or desktop workflow into live play advice.
Integration map
Use the public contract to select an API request; use a desktop solver when your task is to design the research configuration itself.
| Surface | Product task | Boundary |
|---|---|---|
POST /v1/gto/preflop | Grade or display one preflop spot | A documented request for a hand, position, and action line; not a custom local tree editor. |
POST /v1/gto/flop/tree | Render a presolved flop workflow | Read the returned tree and node tokens for the requested formation and board. |
POST /v1/gto/solver | Submit an on-demand custom spot | Submit a documented configuration, then retain its handle and inputs while inspecting that solve. |
POST /v1/gto/solver/tree | Inspect a completed solve | Poll and read the submitted solve; it is not a substitute for designing a new research tree. |
Official integration resources
- Developer docs — authentication, SDKs, quotas, errors, and endpoint behavior
- Interactive API reference — request and response schemas for the public endpoints
- OpenAPI specification — the machine-readable English API contract
- GTO solver API guide — what the hosted strategy API returns
- Python SDK — the official typed Python client
- JavaScript / TypeScript SDK — the official typed JavaScript and TypeScript client
- MCP server — the official Pokerai API tool server for compatible agents
- llms.txt — the concise LLM entry point for Pokerai API