1club Admin

Cancel a booking by its 1club booking ID. Over an OAuth connection this covers any of the organization's bookings, whichever channel created it; a developer-managed API key can only cancel the bookings it created itself. Requires the 'bookings:write' scope. Refunds follow the money: on a booking this API created the caller collected it, so 1club moves nothing but records what was given back - with a developer-managed API key everything collected unless refund.amount says otherwise (send what was actually returned when the partner kept a share, 0 when it kept it all); over an OAuth connection nothing is recorded unless refund is sent. On a booking taken through 1club the club is cancelling: an unpaid booking owes nothing, and a paid one needs keepCancellationCharge (refund in full, or apply the cancellation terms) - ask the user. A seat of a class enrolment or event registration made with guests (book_class, book_event) cancels the whole of it - every place - and a refund amount is what came back for all of them. A booking that has already been checked in cannot be cancelled. The customer is told unless you set notifyCustomer false - except on a booking this API created, where they are not told unless you set it true. Idempotent.

cancel_booking

Cancel an event. This CANCELS EVERY ACTIVE BOOKING for it (and any tournament played at it) and cannot be undone - a cancelled event cannot be published again. Nobody is refunded automatically; refunds stay with staff in the 1club admin portal. Tell the user how many bookings it has (bookedCount from get_event) and get their explicit confirmation first. Requires the 'events:write' scope.

cancel_event

Take a coach off one shift. It stays on the staff roster as cancelled, so regenerating the rotation does not put it back, and update_instructor_shift with status scheduled restores it. Bookings already inside the shift are not cancelled - check list_bookings for the coach and that window. For a day or more off, create_instructor_time_off is usually what the user means. Requires the 'instructors:write' scope.

cancel_instructor_shift

Change one member's role in a household or company account. Roles are owner, adult or dependent in a household and admin or employee in a company. An admin can act for every other member from the member apps (book, buy and see them), so grant it only when asked. Requires the 'contacts:write' scope.

update_member_account_member

Charge what a charge still owes to the member's saved card, from the account of the company the charge belongs to (a guardian's card pays a dependent's charge). Money moves now, so confirm the charge (member, amount, what it is for) with the user before calling. A refused card is an answer, not an error: payment.status is failed with Stripe's reason in payment.failureCode (insufficient_funds, expired_card, authentication_required, ...); say it to the user plainly and do not retry the same card without being asked. The charge is merchant-initiated, so a card that needs 3D Secure is declined with authentication_required. A payment Stripe has not finished, or could not confirm either way (the card may have been charged), is pending or processing, not failed: tell the user not to take the money another way until it settles. Refused when the charge owes nothing (409 CHARGE_NOT_OWED), a payment for it is already pending (409 PAYMENT_IN_PROGRESS), or the member has no saved card (409 NO_SAVED_CARD). To record money taken at the desk instead, use record_payment. A developer-managed API key can only charge for the charges of bookings it created itself. For a member of staff it needs the billing manage permission. Requires the 'payments:write' scope.

charge_saved_card

Create the club's own editable copy of a system email, seeded with the built-in subject and body. From then on the copy is what gets sent, so edit it with update_template right after; deleting it restores the built-in email. One copy per email: if one exists the call fails with its id (also shown as overrideTemplateId by list_system_templates) - edit that one instead. Not available on Free. Requires the 'templates:write' scope. Pass idempotencyKey so a retry cannot fail on the copy it just made.

copy_system_template

Add a bookable area - a court, a studio, a lane - to one of the organization's clubs. Resolve clubId with get_club and areaTypeId with list_area_types first; both must belong to this organization, and the area type is what makes the new area bookable for a sport, so never guess it. A new area defaults to active and publicly visible and appears in availability immediately. Requires the 'areas:write' scope, the same one that blocks and unblocks areas - an OAuth connection made before this tool shipped will not have it until the user reconnects. Pass idempotencyKey so a retry cannot create the area twice.

create_area

Close a court, or a whole club, for a time range. Requires the 'areas:write' scope. Send areaId to close one court (its club is derived), or clubId with areaId omitted to close every court in that club with a single record - use the club-wide form for holidays and camps rather than creating one block per court. Existing bookings in the window are NOT cancelled; the block only stops new ones. Pass idempotencyKey so a retry cannot create the block twice.

create_area_block

Add a kind of space the organization books, so create_area has a type to hang courts on. Call list_area_types first and only create one if nothing fits - a second "Padel court" splits inventory that should be one group. Give it sports: a type with none produces areas nobody can book for anything. Requires the 'areas:write' scope, the same one that creates areas. Pass idempotencyKey so a retry cannot create the type twice.

create_area_type

Create a booking on an area (e.g. a padel court), optionally with an instructor leading the session, or with an instructor alone and no area (a private lesson where no court is booked): pass areaId, instructorId, or both. A booking with no area is placed at the instructor's club; for an instructor who works across clubs in an organization with several, pass clubId (from list_clubs) - ask which club when the user did not say. Identify the customer either with contactId - resolve it first via search_contacts, or create them with create_contact - or with an inline customer object matched to a contact by email and created if new. Pass exactly one of the two; prefer contactId whenever the contact can be resolved. payment.status is 'paid' (money already collected, recorded against a payment method named after the API key so the club can reconcile it) or 'unpaid' (outstanding); amount is the price the customer paid, before any fee the caller kept, and defaults to the area's price for the slot plus the instructor's hourly rate when an instructor is attached. With 'unpaid' and no amount, a membership or pass of the customer's that covers the booking is used (one session is spent, nothing is owed); otherwise the price is recorded as owed. Over a Platform API key that needs the customer passed as contactId - an inline customer never spends a membership. With 'paid', payment.reference carries the caller's own payment id and payment.fee its commission - the sale is recorded at amount, the fee is for reconciliation. 1club's member-facing booking policy (minimum notice, maximum days in advance, operating hours, slots already in the past) is not enforced for this API, so an existing or historical schedule can be recorded as-is - but a real double-booking, the area's capacity, and instructor bookability are always enforced. Requires the 'bookings:write' scope. Pass idempotencyKey so a retry cannot create the booking twice.

create_booking

Create a booking policy. name and clubIds are required; everything else defaults to free cancellation, no forced payment and every flag off, governing every booking for everyone. A policy is scoped on WHAT it governs (validFor: classes, areas and/or instructors, optionally narrowed to types; empty = every booking) and WHO (audience: contact types, tags, plans held; null = everyone), and narrowed to clubIds (empty = every club). When several apply, the most specific wins - club-specific first, then what+who, what, who, then the unscoped default; a tie goes to the newest. So a new policy can take over bookings another policy governed - check get_effective_booking_policy before and after. Every id must belong to the organization. Policies are live as soon as they are written: new bookings follow them at once (existing bookings keep the cancellation terms they were made under). Confirm with the user first, and check the outcome with get_effective_booking_policy. Requires the 'booking-policies:write' scope. Pass idempotencyKey so a retry cannot create the policy twice.

create_booking_policy

Record attendance, in one of two ways - send exactly one of bookingId or contactId. (1) An existing booking: pass bookingId (resolve it with list_bookings or list_class_bookings first). The booking must be confirmed or pending, inside its configured check-in window, paid when policy requires it, and not already checked in. (2) A member walking in with no booking: pass contactId and clubId, and the member is checked in at that club on their membership, the way the front desk's direct check-in does, spending one session from it. Leave out membershipId and externalProgramId to use the member's own covering membership (one with nothing owed is preferred), name the membership with membershipId (from list_memberships), or record the visit against a zero-fee external program with externalProgramId - at most one of the two. The membership must not be limited to particular classes, areas or instructors, must have sessions left, and must have nothing owed on it: a membership that still owes money is refused, so tell the user to check the member in at the front desk where staff can see what is owed. Nothing is charged. To check someone into a class or onto a court, book it first (book_class or create_booking) and check that booking in. Pass idempotencyKey so a retry cannot record attendance twice. Requires the 'checkins:write' scope.

create_checkin

Create a class: its club, time, capacity, area, and instructors. Use list_areas and search_instructors to resolve IDs first. Times need an explicit offset. For a class that repeats, pass `recurrence` - one call then creates the whole series, so do NOT call this once per occurrence. Requires the 'classes:write' scope. Pass idempotencyKey so a retry cannot create the class twice.

create_class

Add a kind of class the organization runs. Call list_class_types first: a gym rarely wants two types meaning the same thing, and this tool will happily create a duplicate name, after which half its classes are filed under one and half under the other. Only name is required - leave the rest out unless the user described that behaviour, since the defaults (one person per booking, no self-cancellation, the default revenue account) are what most types want. Requires the 'classes:write' scope. Pass idempotencyKey so a retry cannot create the type twice.

create_class_type

Create a contact (customer) in the organization. Search first with search_contacts (by name and by phone) - creating a contact whose email already exists fails, as does one with the same name and phone number as an existing contact (the error names that contact's id - use it), and duplicate people are hard to merge afterwards. At least one of email or phone is required. Requires the 'contacts:write' scope. Pass idempotencyKey to make a retry safe.

create_contact

Create a content item - a blog post, an FAQ entry, a reusable website block, a signable document, or a how-to guide. Requires the 'content:write' scope. Send the body as contentBlocks (preferred) or contentHtml, not both. The returned `slug` may differ from one you asked for, since a clash gets a numeric suffix - use what comes back, especially when pointing a website `block` section at it. To publish the same item in another language, create it again with the slug that came back and a `language` - same slug, different language, and the site serves each visitor the right one. When a user asks for a waiver or agreement and gives no wording, write sensible default clauses rather than refusing.

create_content

Add a custom field to the organization's contacts. Pick the type that fits (select with options for a fixed list). It is staff-only unless the user wants members to see it; a field the sign-up form must ask needs requireOnSignup and a member-visible visibility. Requires the 'contacts:write' scope. Pass idempotencyKey so a retry cannot create it twice.

create_custom_field

Make one or more documents something matching members are asked to read and accept. documentIds are content items of type "document" (find or create them with list_content / create_content). Leaving filters out asks EVERY member. A mandatory rule (the default) blocks members from finishing account setup until they accept; set mandatoryToAccept false for an optional one such as a marketing consent. requiresTypedNameAcceptance and requiredForEntry only exist on a mandatory rule, consentChannel only on an optional one - asking for the wrong combination is refused rather than silently dropped. requiredForEntry stops unsigned members checking themselves in as soon as the rule is saved, so confirm it with the user first. Requires the 'document-rules:write' scope. Pass idempotencyKey so a retry cannot create the rule twice.

create_document_rule

Create an event. It is always created as a DRAFT that members cannot see; call publish_event afterwards, once the user has confirmed it. The club, coaches, areas and each ticket's revenue account must belong to the organization, and the club must still be taking events. To sell places, add tickets. Requires the 'events:write' scope. Pass idempotencyKey so a retry cannot create the event twice.

create_event

Add an external program members can use to pay for visits. It starts active. Leave coveredAmountPerVisit out when the program pays for the whole visit; set it when it pays a fixed amount and the member pays the rest. Set validFor.scopes to what it may be booked for, or leave it empty for a check-in-only program. A code already used, or a knownProgram the organization already has, is refused (409). Requires the 'external-programs:write' scope. Pass idempotencyKey so a retry cannot create the program twice.

create_external_program

Create a form. IMPORTANT: it is LIVE immediately at the returned publicUrl - there is no draft - so show the user what you are about to create and get their go-ahead first. createsAccount is required and can never be changed: true makes a sign-up form, which registers whoever completes it and sells what it offers (completing one with a plan creates a real membership, or takes payment for a plan paid up front); false makes a fill-in form that only collects answers and turns an unknown visitor into a lead. Resolve plans with search_plans and products with search_products first; only active, publicly visible ones are accepted. After creating a fill-in form, add its questions with set_form_questions. Read slug and publicUrl from the result; a null publicUrl means the club has no member portal or live website switched on, so tell the user nobody can open the form until they turn one on. To send people to a sign-up form from the website's header or footer button, set signupFormSlug with update_website_layout. Requires the 'forms:write' scope, which is new: an OAuth connection made before it shipped has to be reconnected. Pass idempotencyKey so a retry cannot create the form twice.

create_form

Add an instructor (a coach) to the organization. They must already exist as a contact, so call search_contacts first and create_contact if they are new, then pass that contactId here. IMPORTANT: this does NOT invite them to the staff portal - it creates a bookable coach with no login, no role and no invitation email, and sending sendInvitation, organizationUserId, role or color is rejected. If the user wants their coach to be able to sign in, tell them to invite them from the 1club admin portal. hourlyRate here is what a MEMBER pays for an hour with them; what the gym pays the coach is a separate thing, set with create_pay_rate_policy. A contact who already has an instructor profile is a conflict naming that profile - use update_instructor on it, including to bring an inactive coach back. Requires the 'instructors:write' scope, which is new: an OAuth connection made before it shipped has to be reconnected before this works. Pass idempotencyKey so a retry cannot create the instructor twice.

create_instructor

Add one extra shift for a coach, outside any rotation - covering for someone, an extra day. The coach becomes bookable inside it. For a recurring pattern use a rotation instead. Requires the 'instructors:write' scope. Pass idempotencyKey so a retry cannot add it twice.

create_instructor_shift

Book a coach off for a time range, so nobody can book them inside it. Bookings and classes already on their diary in that window are NOT moved or cancelled: they come back as conflicts - tell the user about each, and offer to reassign it (update_booking, update_class) or cancel it (cancel_booking). A conflict with a seasonId is a week of a contracted season: move it to another coach, never cancel it. For a whole day, send the club's midnight to midnight. Requires the 'instructors:write' scope. Pass idempotencyKey so a retry cannot book them off twice.

create_instructor_time_off

Add a kind of coach. Call list_instructor_types first and only create one if nothing there fits - most organizations already have a type per sport, and a near-duplicate splits the roster. Only name is required. Requires the 'instructors:write' scope. Pass idempotencyKey so a retry cannot create the type twice.

create_instructor_type

Add an already-hosted image or video to the organization's media library so a website section or content item can use it. Requires the 'media:write' scope. This does NOT upload a file - the file must already be reachable at a public https URL; if the user has a file on their computer, tell them to upload it in the admin dashboard instead. Give it a descriptive `name`, since that is what list_media searches. Registering a URL the library already has updates its details and returns the existing item.

create_media

Create a household or company account with its first member, who becomes the primary contact; add the rest with add_member_account_member. A company needs a name; a household without one is named after its first member. The first member is owner of a household and employee of a company unless role says otherwise. Roles are owner, adult or dependent in a household and admin or employee in a company. An admin can act for every other member from the member apps (book, buy and see them), so grant it only when asked. Check list_member_accounts first so the same family or employer is not created twice. Requires the 'contacts:write' scope.

create_member_account

Put a customer on a plan. Resolve the customer with search_contacts and the plan with search_plans first. The plan is snapshotted onto the membership exactly as it is when sold in 1club, so allowance and coverage behave identically. payment.status is 'paid' (money already collected, recorded against a payment method named after the API key with no card charged; payment.reference and payment.fee carry the caller's own payment id and commission for reconciliation) or 'unpaid' (left outstanding). The plan supplies the price, joining fee, billing frequency, session allowance and minimum term, so a normal sale sends nothing but the customer, the plan and the payment status. How long it runs follows from the plan too: it starts at startDate and its end date cannot be set here. Use overrides only for a negotiated sale or when migrating a partly-used pass. Collection and refunds stay with you. Requires the 'memberships:write' scope. Pass idempotencyKey so a retry cannot create the membership twice.

create_membership

Create a membership plan. A normal plan needs a name, price, billing frequency, and validFor scopes describing which bookings it covers. Set validFor.scopes to classes, areas, and/or instructors; an empty validFor creates a generic direct-entry plan. A plan with separate counts per kind of session (e.g. 5 Yoga + 4 Pilates) takes allowances instead. Requires the 'plans:write' scope. Pass idempotencyKey so retries cannot create duplicates.

create_plan

Add a membership plan category. Omit sortOrder and it goes to the end of the list, which is what you want unless the user is rebuilding the whole ordering. Check list_plan_categories first - a gym rarely wants two headings meaning the same thing, and this tool will happily create a duplicate name. Requires the 'plans:write' scope.

create_plan_category

Write a DRAFT email, SMS or WhatsApp Message. It is NOT sent: there is no way to send through this tool set. The draft waits in the 1club admin app (Messages, drafts) for a member of staff to review and send it - tell the user that. type is email, sms or whatsapp (push notifications cannot be drafted). An email needs a subject. Name the audience with exactly one of contactIds or segment. With an API key the draft is attributed to the person who created the key. Requires the 'messages:write' scope. Pass idempotencyKey so a retry cannot write the draft twice.

create_message_draft

Create a rule for what the club pays its coaches. A pay rate is what the GYM PAYS THE COACH. An instructor's hourlyRate is what a MEMBER PAYS for an hour with them. Never set one when the user meant the other. Set earnings.kind to "individual" for one-to-one sessions or "class" for group classes; the rate fields differ and the wrong ones are rejected. instructorIds is required: name the coaches, and send an empty list only when the user genuinely means every coach - that makes this the gym-wide default and re-prices everyone. Two policies cannot claim the same coach for overlapping work: that comes back as a conflict listing which coaches are already on which policy, and the fix is to change one of them, not to retry. Requires the 'instructors:write' scope, which is new - an OAuth connection made before it shipped has to be reconnected. Pass idempotencyKey so a retry cannot create the policy twice.

create_pay_rate_policy

Add a payment method staff can record payments with, e.g. "Bank transfer" or "Voucher". Call list_payment_methods first: Cash and POS Terminal already exist for every organization, so do not add them again. It is staff-only (Private) unless the user wants members to pick it when paying for a booking. Requires the 'payment-methods:write' scope. Pass idempotencyKey so a retry cannot create it twice.

create_payment_method

Add a rule to the club's price list. adjustmentType and scopes are required: say what the rule does to the price and which resources it prices (an empty scopes list means EVERY area, coach and class - only when the user means that). Send only the amount field the type reads: percentageAdjustment for percentage, fixedAmountAdjustment for fixed and absolute. Every id must belong to the organization. A member rate is a "plan" condition naming the plan; a peak band is a "weekdays-time" condition. Rules are live as soon as they are written: every new quote and booking uses them (existing bookings keep their price). Confirm the change with the user first, then check it with quote_booking_price. Requires the 'pricing-rules:write' scope. Pass idempotencyKey so a retry cannot create the rule twice.

create_pricing_rule

Add a product to the catalogue. Only name and price are required. Resolve categoryId with list_product_categories first if the user named a category - a category from another organization is rejected, and so are clubId, brandId, taxRateId and revenueAccountId that do not belong to this one. A barcode or SKU already used by another product, package, plan or access card is refused, because a scanned code has to mean exactly one thing. Creating a product does not give it stock; putting units on the shelf is done in the 1club dashboard, so tell the user to do that there. Requires the 'products:write' scope. Pass idempotencyKey so a retry cannot create the product twice.

create_product

Add a product category. Omit sortOrder and it goes to the end of the list, which is what you want unless the user is rebuilding the whole ordering. Check list_product_categories first - a gym rarely wants two categories meaning the same thing, and this tool will happily create a duplicate name. Requires the 'products:write' scope.

create_product_category

Add a program. Call list_programs first: a club rarely wants two programs meaning the same thing. Then put class types in it with update_class_type's programId. Only name is required. Requires the 'classes:write' scope. Pass idempotencyKey so a retry cannot create the program twice.

create_program

Add an account to the organization's chart of accounts. This is bookkeeping, not configuration: the code and name are what the club's accountant reconciles against, so call list_revenue_accounts first and only add one the user actually asked for, with the code they gave you. A duplicate code is refused. Requires the 'revenue-accounts:write' scope, which nothing else grants - an OAuth connection made before this tool shipped will not have it until the user reconnects. Pass idempotencyKey so a retry cannot create the account twice.

create_revenue_account

Create a shift rotation: which shift template is worked on which weekday, over a cycle of 1-12 weeks. The staff roster has four layers: shift templates (a named slot like "Morning 06:00-14:00"), rotations (which template falls on which weekday of a 1-12 week cycle), rotation assignments (a coach on a rotation from a date, which generates their shifts) and the shifts themselves (the concrete staff roster). A coach on a rotation is bookable only inside their shifts, less breaks, and never inside their time off. Nobody works it until a coach is assigned with create_shift_rotation_assignment. Example: a one-week Monday-Friday morning pattern is cycleWeeks 1 with five slots, weekIndex 0, each pointing at the "Morning" template. Requires the 'instructors:write' scope. Pass idempotencyKey so a retry cannot create it twice.

create_shift_rotation

Put a coach on a shift rotation from a date, which generates their shifts on the staff roster - to effectiveTo, or eight weeks ahead for an open-ended assignment (extended nightly). The staff roster has four layers: shift templates (a named slot like "Morning 06:00-14:00"), rotations (which template falls on which weekday of a 1-12 week cycle), rotation assignments (a coach on a rotation from a date, which generates their shifts) and the shifts themselves (the concrete staff roster). A coach on a rotation is bookable only inside their shifts, less breaks, and never inside their time off. From then on the coach is bookable only within those shifts, so assigning a coach who was bookable all day narrows their availability. A coach can be on one rotation at a time: a range overlapping another of their assignments is refused, naming it - end that one first (update_shift_rotation_assignment with effectiveTo), or change it instead of adding another. Returns the assignment and how many shifts were generated. Requires the 'instructors:write' scope. Pass idempotencyKey so a retry cannot assign twice.

create_shift_rotation_assignment