Fitness_Memberships

API Endpoint: {api_url}/v1/organizations/settings/membership_advance_booking_rules
Scenario: API to get all Membership Advanced Booking Rules
API method: GET
Earlier behavior: New API. No earlier behavior.
New behavior: Returns the full list of membership-based advance booking rules configured for the organization. Used by the "Advance Booking Windows" admin settings page to populate the "Previously Added Rules" table.

Fitness_Memberships

API Endpoint: {api_url}/v1/services
Scenario: API to get all Services (Amenities Filter)
API method: GET
Earlier behavior: New API. No earlier behavior.
New behavior: Added a new API to fetch all membership advance booking rules, including associated memberships, booking days, and mapped classes/amenities.

Fitness_Memberships

API Endpoint: {api_url}/v1/organizations/settings/membership_advance_booking_rules
Scenario: API to create Membership Advanced Booking Rules
API method: POST
Earlier behavior: New API. No earlier behavior.
New behavior: Creates one or more membership advance booking rules for the organization. Each rule maps a membership to a specific class or amenity with a configured number of days in advance that the member can book. When multiple item_ids are supplied, one DB row is created per item_id in a single request.

Fitness_Memberships

API Endpoint: {api_url}/v1/organizations/settings/membership_advance_booking_rules/{rule_id}
Scenario: API to delete Membership Advanced Booking Rule
API method: DELETE
Earlier behavior: New API. No earlier behavior.
New behavior: Soft-deletes a single membership advance booking rule by its rule_id, setting Void = 1 in tblMembershipAdvancedBookingRules. Triggered by the delete icon on each row in the "Previously Added Rules" table on the Advance Booking Windows admin settings page.

Treatment Hub

API Endpoint: {api_url}/v1/procedures/{procedure_id}/timeline
Scenario: GET Timeline
API method: GET
Earlier behavior: New API. No earlier behavior.
New behavior: Returns a paginated audit timeline for a treatment procedure. Each event captures who did what, when, from which device, and event-specific structured meta_data (vitals summary, rectification reason, etc.). Events include submissions, resubmissions, Treatment Hub opened, and other workflow actions. Pass is_all_events_included=true to include compliance/HIPAA-only events alongside visible timeline events. Results are sorted newest-first with pagination.

Treatment Hub

API Endpoint: {api_url}/v1/procedures/{procedure_id}/change_log
Scenario: GET Change Log
API method: GET
Earlier behavior: New API. No earlier behavior.
New behavior: Returns a paginated flat list of field-level changes for a treatment procedure. Each entry captures a single field change ” what changed, from what value to what value, who changed it, when, and from which device. Optionally filter by section (sub-entity type) and section_id to scope changes to a specific sub-entity such as a treatment chart. Currently supported sections: treatment_chart. The section field is included in each response entry so consumers can distinguish entries from different sub-entity types. Results are sorted newest-first with pagination.

Treatment Hub

API Endpoint: {api_url}/v1/procedures/{procedure_id}/vitals
Scenario: [Procedure] get vitals for the procedure
API method: GET
Earlier behavior: Returns the latest vital information for the guest of a given procedure, filtered to only the vitals configured for the procedure's service (via ServiceVitalConfiguration). This allows therapists to view relevant vitals during a treatment procedure without needing to know the guest ID or service ID.
New behavior: Create an API to fetch the vital information for the procedure

Treatment Hub

API Endpoint: {api_url}/v1/procedures/{procedure_id}/vitals
Scenario: [Procedure] get vitals for the procedure
API method: GET
Earlier behavior: New API. No earlier behavior.
New behavior: Returns the latest vital information for the guest of a given procedure, filtered to only the vitals configured for the procedure's service (via ServiceVitalConfiguration). This allows therapists to view relevant vitals during a treatment procedure without needing to know the guest ID or service ID.

Treatment Hub

API Endpoint: {api_url}/v1/procedures/{procedure_id}/treatment_charts_data
Scenario: GET procedure treatment chart data
API method: GET
Earlier behavior: The API returned treatment chart data as a single template_json and data_json payload for each chart.
New behavior: The API response was enhanced to return component-level treatment chart data, including component metadata, versioning, submitted data, and optional prefill data from previous visits.

Treatment Hub

API Endpoint: {api_url}/v1/treatment_hub/treatment_charts
Scenario: Create new Treatment chart
API method: POST
Earlier behavior: The Create Treatment Chart API used the legacy endpoint and TreatmentChart(Add) permission model.
New behavior: The API endpoint was updated to v1/treatment_hub/treatment_charts and now requires TreatmentHubSetup(EditTreatmentChart) permission for creating treatment charts with components.

Treatment Hub

API Endpoint: {api_url}/v1/treatment_hub/treatment_charts/{chart_id}
Scenario: Upsert Treatment chart
API method: PUT
Earlier behavior: Each chart returned a single template_json (entire form structure) and data_json (entire submission) at the chart level. Chart data identifier was treatment_chart_data_id.
New behavior: Chart-level template_json and data_json are removed. Each chart now exposes a components array — template and submission live per component. New per-component fields: component_id, version_number, component_name, component_type (new ChartComponentType enum: datagrid, datatable, dropdown, form, predefined_table, radio, select, signature, textarea, zenAnnotationPad), display_order, is_required, component_template_json, data_json, and prefill_data_json (populated only when data_json is null, prefill is enabled on the component, and previous-visit data exists). Chart data identifier renamed treatment_chart_data_id → treatment_charts_data_id.

Treatment Hub

API Endpoint: {api_url}/v1/guests/{guest_id}/treatment_charts_history
Scenario: API to Get Treatment Chart History
API method: GET
Earlier behavior: New API. No earlier behavior.
New behavior: Returns historical treatment chart data for a guest across multiple appointments. Supports optional filtering using treatment_chart_id, service_id, and component_id, and allows limiting results using the top parameter. Response includes appointment details, therapist information, treatment chart metadata, component templates, and submitted component data.

Treatment Hub

API Endpoint: {api_url}/v1/appointments/{appointment_id}/treatment_charts_data
Scenario: API to Save Treatment Chart Data
API method: POST
Earlier behavior: The API saved the entire treatment chart submission as a single data_json payload for the chart.
New behavior: The API saves treatment chart data component-wise using a components collection containing individual component_id and data_json entries.

Reports - Core V2

API Endpoint: {api_url}/v1/reports/organizations/kpi/flat_file
Scenario: Business KPI Report API
API method: POST
Earlier behavior: The Business KPI Report API returned KPI metrics without membership revenue recognition fields such as IRR, MRR, and SCR.
New behavior: The Business KPI Report API now includes initial_revenue_recognition, monthly_revenue_recognition, and service_credit_revenue fields in the response to provide membership revenue recognition metrics.

Reports - Core V2

API Endpoint: {api_url}/v1/reports/sales/accrual_basis/flat_file
Scenario: Sales Accrual Report API
API method: POST
Earlier behavior: The Sales Accrual Report API returned sales accrual data without membership revenue recognition metrics such as IRR, MRR, and SCR.
New behavior: The Sales Accrual Report API now includes initial_revenue_recognition, monthly_revenue_recognition, and service_credit_revenue fields in the response to provide membership revenue recognition details.

Reports - Core V2

API Endpoint: {api_url}/v1/reports/collections/flat_file
Scenario: Get Collections report
API method: POST
Earlier behavior: The Collections Report API returned collection, payment, surcharge, tax, and guest-related details for invoices within the selected date range.
New behavior: The API response now additionally includes membership revenue recognition fields: initial_revenue_recognition, monthly_revenue_recognition, and service_credit_revenue, along with a new response scenario 10.

Reports - Core V2

API Endpoint: {api_url}/v1/reports/center/metrics/flat_file
Scenario: API to Get Center Metrics Report Data
API method: POST
Earlier behavior: Membership revenue recognition metrics were not available in the response.
New behavior: Added initial_revenue_recognition, monthly_revenue_recognition, and service_credit_revenue metrics in the response.

Reports - Core V2

API Endpoint: {api_url}/v1/reports/employee/metrics/flat_file
Scenario: API to get employee metrics report
API method: POST
Earlier behavior: API did not include KPI fixes and naming updates.
New behavior: Added new response properties and updated KPI names/values in Master Employee Metrics.

Fitness

API Endpoint: {api_url}/v1/classes/instructors/sessions/l3m_utilization
Scenario: Session L3M Utilization API
API method: GET
Earlier behavior: New API. No earlier behavior.
New behavior: Returns the rolling Last-3-Months (L3M) utilization percentage for every session in the requested week. The result set mirrors the session set shown in the Fitness Weekly View scheduler grid (group classes with at least one assigned instructor). Recurring sessions receive a true L3M value computed as SUM(attended) / SUM(capacity) Ã— 100 over the 90-day window immediately preceding the requested week. Single (non-recurring) sessions receive their own current-week attended/capacity ratio. A NULL utilization percentage is returned for recurring sessions that have no qualifying historical data (e.g. newly created recurrences). The is_last_three_months_utilization flag distinguishes the two cases.

Medical Record

API Endpoint: {api_url}/v1/emr/allergies
Scenario: Get allergies from Master List - Supporting status-based filtering
API method: GET
Earlier behavior: The API retrieved allergy master records without support for filtering by active or inactive status.
New behavior: Added a new status query parameter to filter allergies by active, inactive, or all states while retrieving master allergy records.

Medical Record

API Endpoint: {api_url}/v1/procedures/{procedure_id}/clinical_rules/emr
Scenario: [Procedure] GET medical records used for the clinical rules
API method: GET
Earlier behavior: New API. No earlier behavior.
New behavior: Retrieves all EMR data (allergies, medications, medical histories, social history, vitals) for the guest associated with a procedure, filtered to only the EMR entity types and IDs referenced by the clinical rules configured for that procedure's service. Sections with no clinical rules are omitted from the response.

Medical Record

API Endpoint: {api_url}/v1/emr/guests/{guest_id}
Scenario: EMR update guest EMR data
API method: PUT
Earlier behavior: New API. No earlier behavior.
New behavior: Upsert (add or update) multiple EMR data sections for a guest in a single API call. Supports allergies, medications, medical histories, social history, and vitals ” each section is optional and processed independently in parallel, with per-section error reporting.

POS V2, Zenoti Mobile - iOS

API Endpoint: {api_url}/v1/invoices/{invoice_id}/logs
Scenario: API to add invoice log for an invoice
API method: POST
Earlier behavior: New API. No earlier behavior.
New behavior: To fetch Invoice logs

Zenoti Mobile - iOS

API Endpoint: {api_url}/api/Packages/{packageId}?centerId={centerId}
Scenario: GET: GetPackageDetail
API method: GET
Earlier behavior: Returns the details of a specific package by package ID and center ID, including services, items, and product associations.
New behavior: Expose ScheduledInstallment in Packages for Sale

Zenoti Mobile - iOS

API Endpoint: {api_url}/api/Catalog/Packages
Scenario: GET: GetCatalogPackages
API method: GET
Earlier behavior: Returns the list of packages available for sale in the catalog for a given center, filtered by package type, appointment date, and service inclusion.
New behavior: Expose ScheduledInstallment in Packaages for Sale

Zenoti Mobile - iOS

API Endpoint: {api_url}/api/Packages
Scenario: GET: GetPackages
API method: GET
Earlier behavior: Returns the list of packages available for sale at a given center, filtered by package type (Day, Promo, Series).
New behavior: Expose ScheduledInstallment in Packaages for Sale

Zenoti Mobile - iOS

API Endpoint: {api_url}/api/Catalog/SeriesPackages
Scenario: GET: GetCatalogSeriesPackages
API method: GET
Earlier behavior: Returns the list of series packages available in the catalog for a given center.
New behavior: The API response was enhanced with new fields (orientation, item_ids, item_type, and appointment_status) and updated filter type logic for appointment views.

Appointment, MyZen, Zenoti Mobile - Android, Zenoti Mobile - iOS

API Endpoint: {api_url}/v1/employees/{employee_id}/appointment_service_details
Scenario: Get Employee Service Details
API method: GET
Earlier behavior: New API. No earlier behavior.
New behavior: Retrieve service details for a specific therapist (employee), including service name, length, time, segments, and profile notes for a given center and appointment date.

Marketing

API Endpoint: {api_url}/v1/discounts/{discount_id}/item_discounts
Scenario: Save Item Discounts
API method: POST
Earlier behavior: New API. No earlier behavior.
New behavior: To save item-level discount configurations for an existing discount. This API handles saving discount rules for services, providers, products, packages, memberships, classes, and workshops in a single request. It replaces existing item discounts for each provided category.

Marketing

API Endpoint: {api_url}/v1/discounts/{discount_id}/prereq_discounts
Scenario: Save Prerequisite Discounts
API method: POST
Earlier behavior: New API. No earlier behavior.
New behavior: To save prerequisite (Buy X Get Y ” "Item X") discount associations for an existing discount. This API handles saving prerequisite rules for services, products, and packages that a guest must purchase to qualify for the discount.

Marketing

API Endpoint: {api_url}/v1/discounts/{discount_id}
Scenario: Edit Discount
API method: PUT
Earlier behavior: New API. No earlier behavior.
New behavior: The API supports partial updates of discount configuration using PUT semantics, updating only non-null fields.

Marketing

API Endpoint: {api_url}/v1/discounts/name_availability?discount_name={name}&discount_id={id}
Scenario: Validate Discount Name
API method: GET
Earlier behavior: New API. No earlier behavior.
New behavior: To check if a discount name already exists within the organization. Used during discount creation and editing to prevent duplicate names. Supports an optional discount_id parameter to exclude the current discount from the check (for edit mode).

Digital Forms V3

API Endpoint: {api_url}/v1/invoices/{invoice_id}/invoice_items/{invoice_item_id}/forms/{type}
Scenario: Get Package form details
API method: GET
Earlier behavior:This API was internal/private and could be accessed without requiring center_id when using an API key.
New behavior: This API is now public, and center_id is mandatory when accessing it using an API key.

Digital Forms V3

API Endpoint: {api_url}/v1/memberships/{membership_id}/forms/{action_type}
Scenario: Get Guest Membership Forms
API method: GET
Earlier behavior: This API lists of guest ™s membership forms based on the Action Type provided.
New behavior: No changes were made to the request or response. The API has been made public, allowing external callers with a valid API key or guest token to access membership form details.

Digital Forms V3

API Endpoint: {api_url}/v1/guests/{guest_id}/guest_forms
Scenario: Get Guest Form Details
API method: GET
Earlier behavior: New API. No earlier behavior.
New behavior: The GET endpoint returns form details for the specified guest, including form fill status (NoForm, NotFilled, Saved, Submitted). An optional expand query parameter can be passed with the value history to retrieve additional form fill history. Note that version_date and last_filled_date are returned in the context center's timezone, except when accessed via API key, in which case the guest's associated center timezone is used instead.

Digital Forms V3

API Endpoint: {api_url}/v1/appointments/{appointment_id}/forms
Scenario: Gets the list of forms details available for an appointment
API method: GET
Earlier behavior: The response returned form details without any indication of whether a form had a shareable URL or whether it should be displayed in guest-facing applications.
New behavior: The response now additionally returns form_url, which contains the form's URL if it is a V3 form (null otherwise), and send_link_in_notifications, which indicates whether the form should be displayed in guest-facing applications.