Japan Appointments Free: buyer-level API confirmation, hidden services, edit restrictions, and shared capacity

Questions
1

We are evaluating Square as the shared booking system for a gym in Japan. General customers must keep using the existing Square booking site. Corporate members would use a LINE interface for booking, rescheduling, cancellation, and remaining allowances. The application must enforce each company’s monthly limits before confirmation: 12 personal-training bookings and 20 self-training bookings.

The current subscription is Appointments Free, and automatic acceptance is enabled in the Dashboard. Routine reservations must not require staff approval. Existing general-customer booking behavior must remain unchanged.

Square Japan support has confirmed that customers cannot book an online-booking-disabled service through the standard booking site, and that there is no service-specific setting to disable customer rescheduling/cancellation only for corporate services. We are asking about any supported API-specific distinctions, rather than asking for the same Dashboard setting again.

Could you clarify these four points?

  1. Corporate services hidden from the standard booking site

Can buyer-level APPOINTMENTS_WRITE create, reschedule, and cancel bookings for a service with online booking disabled, while that service remains unavailable on the standard site? The guide describes bookable variations as available_for_booking=true. Please distinguish the Dashboard visibility setting from this API field, if they differ.

If this is unsupported, which setting, permission level, or subscription is required? Is there any documented way to keep the service unavailable to ordinary online bookings without making general services unavailable?

  1. Automatic confirmation with buyer-level permissions

BusinessBookingProfile describes booking_policy=ACCEPT_ALL as automatic acceptance. However, the webhook guide describes buyer-created bookings as PENDING until the seller accepts them.

With ACCEPT_ALL and a valid buyer-level CreateBooking request, is the booking automatically accepted without any staff action? Please clarify the initial response status, any subsequent automatic status transition, and whether an application must wait for ACCEPTED before telling the member that the reservation is confirmed. Are there relevant differences between Sandbox and Japanese production accounts, or settings that prevent automatic acceptance?

  1. Preventing corporate bookings from bypassing the LINE allowance check

For API-created corporate bookings only, is there any supported way to prevent customer rescheduling/cancellation through the Square site, customer account, and email/SMS links, while preserving those paths for ordinary customers?

This is particularly important for moves into another month: a booking must not become confirmed in that month without our allowance check. Not sending a notification alone would not be sufficient if the booking remains editable elsewhere. Please identify any API-specific distinction, or explicitly confirm that this separation is unsupported, including on paid plans.

  1. Atomic enforcement of shared capacity across both entry points

We need capacity for up to three simultaneous self-training participants and a defined compatibility rule for personal training. The exact allowed PT/self-training combinations are still being finalized; for example, if personal training must be exclusive, a PT booking would need all shared gym capacity.

Can Square enforce the configured compatibility rule at booking confirmation for both standard-site and API reservations, including concurrent requests and rescheduling? We need to avoid a gap between checking availability and reserving capacity. Three separate staff calendars alone would not meet an exclusive-PT rule if they allow one PT plus two self-training bookings.

Please identify the supported staff/resource configuration, APIs, plan requirements, and any atomic multi-resource reservation guarantees. If new-slot reservation fails during a change, can the original booking remain intact? We do not treat an external lock, booking version, or idempotency key as a cross-channel facility lock.

Please distinguish supported behavior, limitations, and items requiring a controlled Sandbox test. If any requirement cannot be met, an explicit statement of that limitation and the minimum supported alternative would help us make a final design decision. Manual confirmation and cancelling an over-limit booking after confirmation are not acceptable substitutes.

Thank you.

Reference: Bookings API

3

1. Corporate services hidden from the standard site

The creation guide explicitly connects the Dashboard’s Bookable by Customers Online option with CatalogItemVariation.available_for_booking=true. These are not documented as independent “public-site visibility” and “API eligibility” controls.

An online-disabled variation is rejected by the availability-search path. I would recommend testing it as I can’t confirm this right now.

Seller-level writes require Plus or Premium, APPOINTMENTS_WRITE and APPOINTMENTS_ALL_WRITE, and support_seller_level_writes=true. That is a different permission model see permissions and subscriptions.

2. Automatic confirmation

booking_policy=ACCEPT_ALL represents automatic acceptance. The current implementation initializes a buyer-created booking as accepted when that policy is enabled, rather than requiring a mandatory PENDING → ACCEPTEDasynchronous transition. The webhook guide describes buyer-created bookings too broadly when it says they remain pending until seller acceptance.

Use the actual booking status: if creation returns ACCEPTED, the application can report confirmation. If it returns PENDING, do not report it as confirmed; retrieve the booking or process subsequent updates until acceptance is established. Booking status is read-only.

3. Preventing corporate bookings from bypassing LINE

There is no per-booking or API-origin-only switch to disable customer rescheduling/cancellation while leaving those paths enabled for ordinary bookings. The exposed allow_user_cancel setting is business-level and a paid plan does not add a corresponding per-booking API field.

Consequently, the required corporate-only separation is not a supported configuration exposed by the current public API.

4. Shared capacity and exclusive PT

Resource management is available on Premium in Japan, not Free or Plus. Importantly, assigning several resources to a service means Square reserves one available resource from that list, not all listed resources together.

For ordinary rescheduling, use UpdateBooking on the existing booking rather than cancel-and-recreate. The buyer update path checks availability before saving, supporting preservation of the original booking when that validation fails.