Register a consumer project

A consumer project is a website, application, or service that integrates the Booking SaaS API. It is not a separate Booking SaaS domain object. Register the business represented by that codebase as a top-level account, then keep the mapping in the consumer's operational documentation.

The reference implementation is the React application compiled into this repository and served at /demo. It is registered as the canonical Harbour Yoga account in the dedicated demo database.

Registration sequence

1. Create the account with POST /api/auth/signup.
2. Consume the owner magic link and verify /api/me returns the intended account.
3. Store the resulting session in the consumer's server-side secret manager.
4. Store the API origin as non-secret runtime configuration.
5. Create events, instances, products, and a payment connection for the account.
6. Verify the consumer through /api/health/ready and its own integration health endpoint.

Server-side credential boundary

The current API authenticates people with bearer sessions. Until scoped service credentials are introduced, a server-rendered consumer may use a dedicated owner session for trusted server-to-server reads. It must never expose that session in browser JavaScript, HTML, logs, screenshots, or a NEXT_PUBLIC_ environment variable.

Do not use one server session to claim that browser visitors are distinct authenticated Booking SaaS users. A persona switcher may demonstrate role-based interface design, but actual authorization tests require separate memberships and sessions.

Safe demonstrations

• Use deterministic adapters and fixtures in CI.
• Keep production demonstrations read-only unless a visitor explicitly starts a real purchase or booking flow.
• Clearly label simulated interactions that do not call the production API.
• Use a dedicated test MobilePay connection and disposable attendee data.
• Rotate the project session if it is disclosed or appears in client output.

The reference demo calls the API for attendee bookings, teacher rosters, class and product administration, and payment transitions. Pull-request databases are reset on each deployment. Production routes /demo and /demo/api to a second application container and separate database; deployment replaces only the canonical demo account so independently-created integration sandboxes survive.

Its MobilePay test simulator models the merchant order, hosted provider handoff, approval, return URL, webhook reconciliation, paid payment, entitlement, and booking confirmation. It is deliberately labelled as simulated and never contacts MobilePay or charges money. A consumer using real MobilePay must treat the signed provider callback—not the browser redirect—as the authoritative payment result.

The repository documents its account slug, configuration names, JSON fixture strategy, and verification commands without storing any database credential.