Public clubs
Verified public club catalog data.
- GET /api/v1/public/clubs
- Returns public-safe club listing data when available.
- Unavailable upstream data should return a degraded or empty state, not mock clubs.
Platform
Public API boundaries
This page now documents the supported public catalog boundary instead of advertising stale or private endpoints. External catalog consumers should use public-safe routes only.
Supported namespace
Public catalog consumers should use /api/v1/public/* routes. Direct private paths may require authentication, return supported-path errors, or change without public compatibility guarantees.
Public tournaments
Public tournament discovery with stale-event filtering.
- GET /api/v1/public/tournaments
- Past events should not appear as upcoming.
- Tournament detail routes should not be advertised unless real detail pages exist.
Public tables
Public table availability where participating clubs publish it.
- GET /api/v1/public/tables
- Data can be empty when a club has not published live public table state.
- Waitlist writes should go through supported public-web self-service routes, not undocumented table URLs.
Authentication boundary
Account, Club Wallet, payments, social, and operator APIs require authenticated flows.
- Do not call private /api/v1/clubs, /api/v1/payments, /api/v1/social, or admin endpoints as public catalog APIs.
- Public-web BFF routes normalize browser errors and protect token details.
- API keys or partner access are evaluated through partnership review.
Advertising data
Public advertising surfaces use safe ad-space and auction contracts.
- GET /api/ads/spaces through public web shows public-safe spaces or an honest empty state.
- GET /api/ads/auctions shows auction inventory where available.
- Bid placement and creative activation follow billing and review rules.
Reliability standard
Public integrations should be conservative until contracted.
- Do not assume private fields, internal IDs, or club operational records are stable public contracts.
- Use request IDs and support intake for integration issues.
- Partnership/API access belongs in a written integration scope.