PokerWorks APIs

PokerWorks exposes two developer-facing API planes from the same origin. Start with the Management API when you are operating hosted social-poker resources; use the Calculation API when you need stateless poker math or a fast first call.

If you are deciding what to build, start with Choose your API path. This reference hub stays implemented-only.

Never expose product keys or management tokens in browser, mobile, or embedded code.

Product keys and management tokens are both server-side bearer credentials. Use a pw_mgmt_... management token from trusted server code to create short-lived embed or launch sessions; the browser receives the returned launch URL or session payload, which carries only the short-lived runtime credential for that documented flow. A pw_live_... or pw_test_... product key authenticates product-plane API calls such as calculations; it does not mint browser access.

Start with Automate with a service account for the management-token automation loop, or Get started for a quick product-key calculation call.

Route map

Use https://api.pokerworks.io as the API origin.

Resource boundaries

In the Management API, tournament is the host-facing bounded poker object. A published tournament may materialize a runtime tournament or Sit & Go instance. Completed tournament outcomes are tournament results: standings, placements, payouts, and public-safe participant facts. The current result/proof routes are the verification and export layer for those results.

Tournament creation starts from the read-only Management catalog: approved presetKey values, blind schedules, and payout structures. The catalog is discoverable through GET /api/v1/management/tournament-catalog, with resource-level reads at /management/tournament-presets, /management/blind-structures, and /management/payout-structures for integrations that cache or display setup resources separately. Paid-host custom structure authoring is planned as a separate Management write slice once its validation, provenance, versioning, entitlement, and operator-authority contracts are admitted.

The generated reference below remains implemented-only. Room member directory reads, pending player invitation creation, and tournament entry reads are now admitted as server-side Management API projections. Reserved operator surfaces such as member role administration, removals, bulk invites, standings/recap reads, ring-game lifecycle/runtime control, and table protocol are described in their owning guides only after their authority, privacy, and integrity gates are admitted.

Unauthenticated product-runtime endpoints, such as embed-open and public tournament-result verification reads, are documented in their owning guides and recipes. They are not a separate API reference surface unless they are explicitly admitted as one.

Runtime companion routes are browser-safe only for their documented purpose. They are not a self-serve gameplay, table-state, launch-ticket, or action-submission API.

Ring-game catalog reads are Management server-side only. Ring-game lifecycle writes, lobbies, table activity, waitlists, player sessions, and custom-client table protocol remain runtime/read or reserved surfaces until their authority, identity, fairness, and player-protection rules are admitted.

PokerWorks Lab tools can generate blind schedules and payout ladders today. Treat those outputs as planning artifacts until the custom-structure authoring/import slice admits a server-side Management flow that can validate the Lab export, record provenance, and create a reusable PokerDeck structure. The same import contract should survive the planned product maturity rename from PokerWorks Lab to PokerWorks Tools.

Tournament entry reads and room leaderboard reads are Management-only and server-side. Broader standings/recap reads, room stats, and widget-safe summaries remain reserved/read-first surfaces. They belong near the Management/Data boundary, not as client-side credential use. Build beta widgets from trusted server code using room member reads, pending invitation status from your server-side automation, tournament entry reads, room leaderboard reads, webhooks, and tournament result verification reads; do not place pw_mgmt_, pw_test_, or pw_live_ bearer credentials in browser or embedded code. Browser-callable public reads must also satisfy Public read freshness before docs present them as beta-ready.