Recipes
Recipes show what you can build with PokerWorks, not just which endpoints exist. Each recipe starts with the customer outcome, then names the required Console setup, scopes, environment, security notes, and current availability.
The automation loop
Most server-side recipes follow the same six steps. Each step has its own reference:
- Project setup — create a project and environment, then a service account to act for it.
- Scoped management token — mint a least-privilege
pw_mgmt_…token for that service account. - Webhook endpoint — register a webhook endpoint and subscribe to
tournament.completed. - Playground completion — in test mode, emit the frozen playground completion fixture so your receiver gets a real signed webhook delivery immediately.
- Tournament result verification — when the
tournament.completedwebhook fires, fetch the privacy-safe tournament result verification read for the winner, standings, payout summary, and replay/proof status. - Recipe outcome — post, export, or display the result (Discord, Google Sheets, an embed, or your own surface).
The recipes below are concrete instances of this loop.
Public-clean examples
The export-ready examples live in examples/developer-platform. They are dependency-light Node.js
examples that use documented HTTP contracts only — no private PokerWorks workspace imports, no
first-party product routes, and no browser-exposed management tokens.
Start with examples/developer-platform/tournament-automation when you want the full bounded
PokerDeck tournament loop: create or select a test room, publish a tournament, attach the
playground completion fixture, then print the tournament result and verification evidence.
Run the validation target before copying or publishing them:
Code
The first distribution remains generated from the monorepo so the examples can stay aligned with the public contracts. A separate public GitHub repository should publish from that directory only after the release process is automated.
Ecosystem programs
Recipes and public-clean examples come before marketplace distribution. PokerWorks may later add curated directories for approved recipes, streamers, overlays, coaches, certified bots, or integration examples, but those are discovery programs over admitted API contracts, not new permissions.
Marketplace, revenue-share, embedded third-party apps, certified bot listings, custom clients, and bulk private data programs remain reserved until review, support, certification, billing, data-use, and takedown rules exist.
Launch recipes
| Recipe | Status | Uses |
|---|---|---|
| Demo room provisioning | Beta dogfood | Room setup, custom structures, SNG/MTT tournaments, result/proof, readbacks |
| Embed a club lobby | Beta runnable — configuration required | Embed products, spectator embed sessions, allowed origins, maintained starter |
| Tournament result explorer | Beta runnable | Playground completion, tournament result verification read, browser-safe display |
| Discord tournament announcements | Beta runnable | Webhook endpoint, tournament.completed, result verification read, signed delivery |
| Google Sheets results export | Beta runnable | Webhook endpoint, tournament.completed, result verification read, Google Sheets append |
| Streamer overlay | Design preview | Public-safe read surface, hosted table state, support bundle |
Recipe template
Every maintained recipe should include:
- Outcome — the practical thing a club, creator, operator, or developer is trying to do.
- Audience — who should use the recipe and who should not.
- Status — runnable, beta, first-party-only, or design preview.
- Console setup — project, environment, origins, service account, product key, or webhook endpoint.
- Scopes — management scopes for
pw_mgmt_…tokens and product scopes forpw_test_…/pw_live_…keys. - Steps — the shortest path to a working proof.
- Security notes — where tokens live, which secrets are reveal-once, and what must stay server-side.
- Support bundle — ids to copy when asking for help.
- Limitations — anything not available yet, without hiding it behind optimistic copy.
What not to copy
Do not use recipes to expose first-party-only seams. PokerDeck BFF routes, Drop In anonymous cookies, quick-game host cookies, and raw gameplay action routes are not public developer contracts. If a recipe needs one of those seams, mark that step as first-party-only or wait for the public contract.
Do not use recipes as permission to scrape first-party pages, resell hand histories, train models on private room data, expose support-only evidence, copy PokerWorks/PokerDeck trade dress, or imply unsupported certification. Recipes that display, export, store, or republish PokerWorks output must follow Public Data Use And Brand Rules.