openapi: 3.0.3 info: title: WellnessLiving Appointments WebSocket API description: Curated, representative subset of WellnessLiving's official production API (RESTful, JSON-over-HTTPS). WellnessLiving is business-management software for fitness studios, gyms, spas, and salons; this API is the same one its own web and mobile clients (Achieve, Elevate) call, and is published for approved partners via an official OpenAPI document at github.com/wellnessliving/openapi (324 paths across 45+ resource areas as of the 2026-06-20 build). Endpoints below are grounded in that official spec and in the public github.com/wellnessliving/wl-sdk (PHP) and wl-sdk-js SDKs; this file selects roughly four representative endpoints per logical API area rather than reproducing the full catalog. Every WellnessLiving API resource is a `.json`-suffixed endpoint whose path is derived deterministically from the SDK model class's namespace (e.g. the PHP class `WellnessLiving\Wl\Staff\StaffElementModel` serves `/Wl/Staff/StaffElement.json`). Legacy numbered variants of several endpoints exist for backward compatibility (e.g. `Finish47`, `ServiceList52`, `Purchase72`) and are omitted here in favor of their current unsuffixed counterpart. version: 1.1.20260620071011 contact: name: WellnessLiving Support email: support@wellnessliving.com url: https://www.wellnessliving.com/support license: name: Proprietary url: https://www.wellnessliving.com/knowledge-sharing/terms-of-use/ termsOfService: https://www.wellnessliving.com/knowledge-sharing/terms-of-use/ servers: - url: https://us.wellnessliving.com description: Production - United States data center - url: https://au.wellnessliving.com description: Production - Australia data center - url: https://staging.wellnessliving.com description: Staging (pre-release QA branch) - url: https://demo.wellnessliving.com description: Demo/trunk (active development branch) security: - BearerAuth: [] tags: - name: WebSocket paths: /Core/WebSocket/Subscribe.json: post: operationId: post_Core_WebSocket_Subscribe summary: 'Checks whether a listener can subscribe to specified channel. Subscribes in a case of positive result.' description: 'Called by the WebSocket client immediately after a connection is established, to register interest in a specific channel (identified by CID and key fields). If the current user is not permitted to receive events on that channel, the subscription is rejected. On success, any messages already queued for the channel are returned so the client does not miss events that arrived before the subscription was set up.' tags: - WebSocket parameters: - $ref: '#/components/parameters/XErrorRules' requestBody: required: true content: application/x-www-form-urlencoded: schema: type: object properties: a_key: description: The `a_key` field. See WellnessLiving developer portal for full field semantics. type: string cid_channel: description: The `cid_channel` field. See WellnessLiving developer portal for full field semantics. type: string s_password: description: The `s_password` field. See WellnessLiving developer portal for full field semantics. type: string s_token: description: The `s_token` field. See WellnessLiving developer portal for full field semantics. type: string required: - a_key - cid_channel - s_password - s_token responses: '200': description: Successful response. content: application/json: schema: type: object properties: a_message_broadcast: description: The `a_message_broadcast` field. nullable: true '400': $ref: '#/components/responses/BadRequest' '401': $ref: '#/components/responses/Unauthorized' '403': $ref: '#/components/responses/Forbidden' '404': $ref: '#/components/responses/NotFound' '422': $ref: '#/components/responses/ValidationError' '500': $ref: '#/components/responses/ServerError' components: parameters: XErrorRules: name: X-Error-Rules in: header required: false schema: type: string description: Opt in to mapping internal API error statuses to real 4xx HTTP codes. By default the API always answers HTTP 200 even on error, with the failure encoded in the JSON body; setting this header (e.g. to `default`) makes the gateway translate matched error statuses to 400/403/404 responses instead. responses: ServerError: description: Unexpected server error. content: application/json: schema: $ref: '#/components/schemas/ErrorResponse' ValidationError: description: The request payload failed field-level validation. content: application/json: schema: $ref: '#/components/schemas/ErrorResponse' Unauthorized: description: Missing, expired, or invalid Bearer token / session. content: application/json: schema: $ref: '#/components/schemas/ErrorResponse' BadRequest: description: 'Client-side error: invalid input, failed validation, throttling, or other request error (only returned as an HTTP status when `X-Error-Rules` opts in; otherwise encoded in a 200 body).' content: application/json: schema: $ref: '#/components/schemas/ErrorResponse' NotFound: description: The requested resource does not exist. content: application/json: schema: $ref: '#/components/schemas/ErrorResponse' Forbidden: description: Authenticated but not permitted to access this business, location, or resource. content: application/json: schema: $ref: '#/components/schemas/ErrorResponse' schemas: ErrorResponse: type: object description: Standard WellnessLiving API error response shape. properties: status: type: string description: Machine-readable status/error code string (e.g. `access-denied`, `not-found`). text_message: type: string description: Human-readable error message. a_field: type: object additionalProperties: true description: Per-field validation errors, when the failure is a 422-style validation error. securitySchemes: BearerAuth: type: http scheme: bearer bearerFormat: JWT description: 'The officially published OpenAPI declares a JWT Bearer scheme: sign in via `POST /Core/Passport/Login/Enter/Enter.json`, then mint a token with `GET /Core/Passport/Enter/Jwt/JwtToken.json` and send it as `Authorization: Bearer `. The underlying PHP/JS SDKs additionally support the legacy scheme: a registered Application ID + secret code sign a per-request HMAC (SHA3-based) placed in the `Authorization:` header alongside session cookies established by the `Notepad`/`Enter` model pair. Both schemes require WellnessLiving''s Integrations Team to first approve API access, sign an NDA and API Agreement, and issue application credentials.'