Object
Mutation
Fields
createAccountRequestAuthCodeResult!Request an email containing a 6-digit code to confirm a new account. Always returns success regardless of whether the email is already in use (anti-enumeration). If an account already exists for the email, a sign-in code is sent instead.
When businessHandle is set, the issued code is pinned to that business and the resulting token is scoped to it (does not set a cross-account cookie). Used by the business-pinned embed sign-in flow.
When name is set and the email resolves to a brand-new account at redemption time, that name is applied to the inserted user row. Ignored for emails that already have an account.
signInRequestAuthCodeResult!Request a sign-in email containing a 6-digit code. Always returns success regardless of whether the email matches an existing account (anti-enumeration).
When businessHandle is set, the issued code is pinned to that business and the resulting token is scoped to it (does not set a cross-account cookie). Used by the business-pinned embed sign-in flow.
redeemAuthCodeSignInResult!Redeem a 6-digit auth code and sign the user in. Returns the created or signed-in user, the JWT token, and the redirect URL stored on the code. Sets the auth cookie on success — except for codes that were issued with a business pin, which return a business-scoped token without touching the cookie session.
bookActivityTimeAppointmentBookingResult!Books an open time range on a structure: booking activity. Validates [startAt, endAt) is a contiguous run of the activity's open increments whose increment count is within [minIncrements, maxIncrements], then creates the booking — an activityId-tied appointment session + registration. Free bookings confirm immediately; activities set to request mode create a pending request the business approves or declines. Paid bookings charge bookingPricePerIncrement × increments and create the booking only once payment succeeds (via completeCheckout). buyer supplies guest details when the caller is not signed in.
productPurchase redeems one of the caller's passes/memberships (as surfaced by Activity.bookingPaymentResolution) against the booking: a pass spends the activity's creditCost (default 1) per booked increment, so a covering purchase settles the whole booking for creditCost × increments, confirming immediately via the free path — no charge, no checkout. It's all-or-nothing — the purchase must belong to the buyer, be active, cover the activity, and (for a finite session count) have enough sessions for the whole booking; otherwise it's rejected and the caller pays by card.
formData carries answers to the activity's registration blocks — intake questionnaires and consent/waiver signatures collected before the appointment — persisted as block metadata + an agreement PDF on the resulting registration, exactly like registerForActivity.
tipAmount adds an optional gratuity (cents) on top of a paid booking's service price; it is added after tax, ignored for free / package-covered bookings, and excluded from both the tax base and the platform-fee base.
emailMarketingConsent records the participant's optional opt-in to the business's marketing email, exactly like registerForActivity — honoured only when the booked activity carries an emailMarketing registration block and the business has consent collection enabled.
Arguments (9)
activityEntityRef!startAtDateTime!endAtDateTime!buyerBuyerInputformData[RegistrationDataInput!]productPurchaseEntityReftipAmountIntemailMarketingConsentBooleanattributionAttributionInputMarketing attribution captured client-side. See registerForActivity.
cancelActivityRegistrationCancelActivityRegistrationResult!Cancel an existing activity registration.
Arguments (1)
idID!completeCheckoutCompleteCheckoutResult!Complete a checkout after Stripe confirmation, then fulfill the underlying entity (pass purchase or registration). Idempotent — safe to call multiple times.
Two flows converge here:
- Guest (pay-only): the client already confirmed a PaymentIntent on the
business's connected account; this verifies it succeeded.
- Signed-in (save-and-pay): the client confirmed a SetupIntent that
vaulted the card on the viewer's platform wallet and passes the resulting paymentMethod; the server clones it onto the connected account and runs the (off-session) direct charge here, so the card joins the unified wallet and the business is merchant of record.
addFavoriteAddFavoriteResult!Add a business, staff member (instructor), or activity to the authenticated user's favorites. Idempotent — adding an existing favorite is a no-op.
Arguments (1)
favoriteFavoriteTargetInput!removeFavoriteRemoveFavoriteResult!Remove a business, staff member, or activity from the authenticated user's favorites. Idempotent — removing a favorite that isn't set is a no-op.
Arguments (1)
favoriteFavoriteTargetInput!