OpenRally & Setpoint — FAQ

Setpoint is a SaaS platform for managing padel, tennis, and pickleball facilities. It is the software that runs a single club. A facility owner signs up for Setpoint to manage courts, bookings, pricing, memberships, coaching academy, programs, staff, customers, and revenue. Think of it like Square for a restaurant — the club uses Setpoint to run their day-to-day business. It has two apps: Admin (for facility operators) and Web (for players booking courts).

OpenRally is the first open standard for sports facility booking — analogous to how OpenTravel Alliance (OTA) standardized hotel and flight booking. It defines 16 REST endpoints + SSE covering: facility/court discovery, availability queries, time-limited holds, booking CRUD, and real-time events. It is deliberately narrow in scope (v1 = booking lifecycle only) and payment-agnostic. The protocol solves the fragmentation problem: today players must check 3–5 separate apps to find open courts, and every integration between platforms is a custom, expensive, fragile project.

Setpoint is the reference implementation of OpenRally Protocol. The relationship mirrors the hotel industry: Setpoint is the facility's PMS (like Opera for hotels), and OpenRally is the universal booking language (like OTA standards). Setpoint created the protocol so that external apps, aggregators, and channel managers can connect to facilities running Setpoint — or any other booking software that adopts the standard. The Rust/Axum protocol server reads the same Supabase database as the Setpoint admin app, so there is no data duplication.

No. Setpoint is not an aggregator. Setpoint is the back-office software that a single club uses to run their facility. Aggregators are third-party apps that search across many facilities to show players all available courts in one place (like Booking.com does for hotels). No aggregators exist yet for racquet sports — OpenRally makes them possible by providing a standard protocol for any developer to query availability and make bookings across any facility that implements the standard.

No. OpenRally only covers the booking lifecycle — a small slice of what Setpoint does. OpenRally v1 has 16 endpoints: discover facilities/courts, check availability, hold a slot, book/modify/cancel, and real-time events (SSE). Setpoint has 51+ endpoints covering pricing rules, memberships, coaching academy, programs, customer directory, staff management, reports, promo codes, waivers, credit top-ups, and facility settings. OpenRally is only the minimum a third party needs to find a court and book it — it intentionally leaves out everything else.

No. Setpoint and OpenRally are separate products with separate API surfaces. All three connect to the same Supabase Postgres database, but through different paths: • Setpoint Admin → Supabase JS Client → Supabase DB (operator features) • Setpoint Web → Setpoint REST APIs (/api/v1/...) → Supabase DB (player experience) • OpenRally Server → sqlx (direct Postgres) → Supabase DB (standardized external access) The OpenRally Rust server is an adapter — it reads Setpoint's existing tables (facilities, courts, bookings, court_schedules) and presents them through the standardized OpenRally protocol. A booking made through OpenRally writes to the same bookings table and appears instantly in Setpoint Admin's calendar. No data duplication, no sync — same rows, different API surface.

Because OpenRally is an interoperability standard, not an application API. The hotel industry already solved this: no hotel runs its front desk through Booking.com's API. The hotel PMS (Opera) has hundreds of features — housekeeping, billing, loyalty, reports, staff scheduling — that the OTA booking standard doesn't cover. OTA exists purely so external systems (Booking.com, Expedia, channel managers) can search rooms and make reservations. Same here: • Setpoint Admin needs 51+ endpoints — pricing rules, memberships, coaching, programs, reports, customer directory, staff RBAC, promo codes, waivers, credits. OpenRally covers none of that. • Setpoint Web needs memberships, credits, match results, academy enrollment, program registration. OpenRally covers none of that. • OpenRally covers only the booking lifecycle — 16 endpoints. That's the standardized slice that external apps need. Some companies (Stripe, Twilio) dogfood their own APIs — but that's because the API IS their product. Setpoint sells a PMS. OpenRally is an interoperability standard. They are different products with different audiences. Forcing Setpoint to consume OpenRally would add constraints and latency for zero benefit — like forcing a hotel to check guests in through Booking.com.

OpenRally is designed exclusively for external consumers: • Aggregator apps — search across many facilities (like Booking.com for sports) • Channel managers — sync inventory across platforms • Google Reserve / Actions Center — 'Book' buttons on Google Maps • Third-party booking apps and marketplaces • Developer tools and custom integrations A separate application (not Setpoint Web) will be the first consumer of the OpenRally API.

There are three authentication paths: 1. Setpoint Web → Setpoint Admin APIs: JWT (Supabase Auth session). This is the primary auth for Setpoint's own frontend calling its backend. 2. External developer → Setpoint Admin APIs: API Key (X-API-Key header). An alternative auth method for users who want to interact with Setpoint's admin API programmatically (e.g., via curl or custom integrations). Same endpoints, different auth. 3. External app → OpenRally APIs: OpenRally API Key (X-API-Key header). SHA-256 hashed, facility-scoped. Completely separate from Setpoint's admin API keys. The admin API Key and the OpenRally API Key are separate keys for separate systems. JWT is the primary auth for Setpoint's own apps; API Keys are the external/programmatic access on both sides.

The features outside OpenRally v1 fall into two categories: 1. Future OpenRally extensions (open standard, not exclusive): • Pricing/rate management (openrally:ext:pricing) • Player identity / universal player ID (openrally:ext:identity) • Memberships & plans (openrally:ext:members) • Loyalty & credits • Reviews & ratings These are planned as open protocol extensions in the v2 roadmap (month 8–12). Any platform will be able to implement them. 2. Setpoint-exclusive (operator SaaS, not protocol concerns): • Coaching academy (coaches, lessons, packages, commissions) • Programs (clinics, leagues, round robins, camps) • Staff management & RBAC • Revenue reports & analytics • Facility settings & configuration • Promo codes & waivers These are business operations features specific to running a facility. They are Setpoint's product differentiator and not protocol concerns — just like a hotel's housekeeping module is not part of the OTA booking standard.

Recommended demo flow: 1. Show the problem — open 3 different booking apps (Playtomic, CourtReserve, MATCHi), search for padel courts, point out different accounts, fragmented experience, no way to search across all of them. 2. Show Setpoint Admin — operator creates a facility, adds courts, sets schedules and pricing. This is the club's management system. 3. Show the protocol (curl, Postman, or Hoppscotch): • GET /facilities → discover the facility • GET /facilities/{id}/resources → see courts • GET /facilities/{id}/availability?sport=padel&date=2026-03-15 → real-time slots • POST /holds → grab a 5-minute hold on a slot • POST /bookings → confirm the booking from the hold 4. Show bidirectional sync — the booking made through OpenRally appears instantly in Setpoint Admin's calendar view. 5. Show SSE — open an event stream (GET /stream), make a booking or cancellation, watch the event arrive in real-time. 6. The vision — any app, any aggregator, any Google Maps 'Book' button can now plug into any facility running the OpenRally protocol. One standard, every court, everywhere. Key message: 'What OTA did for hotels, OpenRally does for sports facilities — one standard, every court, everywhere.'