Skip to main content
The channel integration lets a partner booking platform (for example a padel community app with court booking, player ratings, and matchmaking) sell your courts and push the resulting bookings into 1Club. 1Club stays the single source of truth for court inventory, so the same court can be booked from your own tools and the partner channel without double-booking. This is a channel-manager model: the partner is one sales channel, and 1Club is the hub that owns the inventory and the booking record. The API is generic - any integration with an API key can use it.
In 1Club a bookable court is an area (areas are typed by sport, e.g. padel). The API uses the term areas throughout, so the padel courts you sell are areas of a padel type.

​
How it fits together

1Club is the hub that owns court inventory; your platform is one sales channel alongside the club’s own tools, classes, and events. Everything a partner does maps to three things it holds in 1Club:

Areas & availability

Your bookable courts and their computed open slots - the shared inventory, changed by every channel.

Bookings & revenue

Each booking you create, recorded against revenue on your chosen payment status.

Contacts (CRM)

The customer on each booking, matched to (or created as) a CRM contact by email.
1

Read availability

Fetch computed slots for one court or a whole-club grid. See Areas and availability.
2

Create a booking

Send the slot and a contactId (or an inline customer, matched to a contact by email). 1Club records the booking and its revenue. See Contacts.
3

Stay in sync

Any change on any channel emits a signed availability.changed webhook; you re-pull the affected window and reconcile against the change feed so your calendar never drifts. See Webhooks.

​
What syncs

  • Bookings - the partner creates, cancels, and lists bookings through the API, optionally with a coach attached and extra players on them.
  • Contacts - the customer on each booking. Resolve them yourself by name, email, or phone through Contacts and book against a contactId, or send an inline customer and let 1Club match by email as a by-product of booking sync - see How contacts sync for matching rules, guarantees, and the full flow diagram.
  • Instructors - read-only. Look up the gym’s coaches to attach one to a coached session. See Instructors.

​
How money is recorded

You collect payment on your side; 1Club records the booking so it counts for revenue. On each booking you tell us the payment status:
  • paid - 1Club records a paid booking transaction, settled against a dedicated External / API payment method (on the manual channel, so no card is charged). It shows in revenue as paid.
  • unpaid - 1Club records the transaction as outstanding. It shows in revenue as accrued, with nothing paid yet.
amount is optional and defaults to the computed price for the slot: the area’s price, plus the coach’s hourly rate when the booking names one. A booking that carries no charge at all comes back as no_charge rather than paid or unpaid. Refund handling and collection stay on your side - cancelling a booking releases the area and issues no refund from 1Club. Amounts are bare numbers in the gym’s own currency. Read it once from organization.currency on GET /me and store it with the connection: nothing else on this API repeats it, so an integration that assumes its own currency misprices every booking without ever erroring.

​
How it works

  1. Create an API key under Settings > Organization > APIs & webhooks with the areas:read, bookings:read, and bookings:write scopes, adding contacts:read, contacts:write, and instructors:read if you resolve customers or coaches by name. See Authentication.
  2. Discover areas (your courts) and read their availability - per court or as a club-wide grid of computed slots. See Areas and availability.
  3. Create bookings with a payment status and optional amount, optionally naming the coach leading the session. Send an Idempotency-Key so a retry is safe. See Bookings and Idempotency.
  4. Cancel or look up a booking by the 1Club booking id returned on create, or list a window to reconcile against every channel.
  5. Stay in sync by registering a webhook endpoint under Settings > Organization > APIs & webhooks and reconciling with the change feed. See Webhooks.

​
Staying in sync

1Club is a shared inventory: the same court can be booked from your app, the club’s own tools, another channel, a class, or an event. To keep your calendar live you need to know when availability changes - not just discover it at booking time. Three mechanisms work together:
  • Availability change webhooks (push). Register an HTTPS endpoint and 1Club sends a signed availability.changed event whenever a court’s bookable availability changes on any channel, typically within half a minute - see Delivery timing. The event is a thin invalidation - it tells you which area and window changed, and you re-pull the authoritative availability for that window. See Webhooks.
  • The read API is the source of truth (pull). Webhooks tell you when to read; GET /availability tells you what’s true. Every read carries a version/cursor so you can tell whether it already reflects a webhook you’re holding. Booking creation still re-checks atomically and rejects conflicts - including a court the gym has blocked - so a stale calendar can never cause a double-booking. It is a backstop, not a substitute for honouring bookable and remaining yourself.
  • The change feed is the backstop (reconcile). Webhooks are delivered at-least-once but can be missed (your endpoint is down, a deploy, a network blip). GET /availability/changes?since=<cursor> returns every change since a cursor, so you can catch up exactly and never drift. Poll it periodically (e.g. every few minutes) and after any downtime.
Treat webhooks as a latency optimization and the change feed as the correctness guarantee. A calendar that pushes on webhooks and reconciles on the feed stays correct even if individual webhooks are lost.