This release adds two new endpoints and enhances CRM status condition capabilities. Clients can now preview discount codes before checkout and retrieve available membership plan change options for customers. Additionally, CRM status conditions now support lead source filtering and an existence check for completed membership packs.

• GET /crm/statuses - CRM statuses can now include lead source conditions to filter by how leads were acquired, and can check whether a customer has completed a specific membership pack
• GET /crm/statuses/{id} - CRM status retrieval now returns lead source conditions and completed membership pack existence checks
• PUT /crm/statuses/{id} - CRM statuses can now be configured with lead source conditions and completed membership pack existence checks when updating
• GET /crm/statuses/{id}/defaults - Default CRM status configurations now include lead source conditions and completed membership pack existence checks
• POST /checkouts/preview-discount-code - Preview and validate discount codes before applying them to a checkout, allowing clients to show discount amounts and eligibility to customers upfront
• GET /customer_memberships/{id}/plan_change_options - Retrieve available membership plan change options for a specific customer membership, enabling clients to present valid upgrade, downgrade, or plan switch choices

GET /crm/statuses

• added subschema #9: LeadSourceCondition to the results/items/conditions/items/ response property oneOf list for the response status 200 (media type: application/json)
• added the optional property results/items/conditions/items/oneOf[subschema #8: CompletedMembershipPackExistsCondition]/exists to the response with the 200 status (media type: application/json)

View updated docs

GET /crm/statuses/{id}

• added subschema #9: LeadSourceCondition to the conditions/items/ response property oneOf list for the response status 200 (media type: application/json)
• added the optional property conditions/items/oneOf[subschema #8: CompletedMembershipPackExistsCondition]/exists to the response with the 200 status (media type: application/json)

View updated docs

PUT /crm/statuses/{id}

• added subschema #9: LeadSourceCondition to the conditions/items/ response property oneOf list for the response status 200 (media type: application/json)
• added the new optional request property conditions/items/oneOf[subschema #8: CompletedMembershipPackExistsCondition]/exists (media type: application/json)
• added subschema #9: LeadSourceCondition to the conditions/items/ request property oneOf list (media type: application/json)
• added the optional property conditions/items/oneOf[subschema #8: CompletedMembershipPackExistsCondition]/exists to the response with the 200 status (media type: application/json)

View updated docs

GET /crm/statuses/{id}/defaults

• added subschema #9: LeadSourceCondition to the conditions/items/ response property oneOf list for the response status 200 (media type: application/json)
• added the optional property conditions/items/oneOf[subschema #8: CompletedMembershipPackExistsCondition]/exists to the response with the 200 status (media type: application/json)

View updated docs

POST /checkouts/preview-discount-code

• endpoint added

View updated docs

GET /customer_memberships/{id}/plan_change_options

• endpoint added

View updated docs

This release adds filtering capabilities to the invoices endpoint, enabling developers to narrow invoice queries by customer membership status. This makes it easier to retrieve invoices for specific customer segments without additional client-side filtering.

• GET /invoices now supports filtering invoices by customer membership status using the customer_membership query parameter

GET /invoices

• added the new optional query request parameter customer_membership

View updated docs

This release adds refresh token expiration information to all authentication endpoints. Clients can now see when refresh tokens will expire, enabling better session management and proactive token renewal before expiration.

• POST /auth/password_login now returns refresh_token_expires_in to indicate when the refresh token will expire, allowing clients to plan token renewal in advance.
• POST /auth/refresh_access_token now includes refresh_token_expires_in in the response, enabling clients to track the new refresh token's expiration time.
• POST /providers/{id}/register_customer now provides refresh_token_expires_in in the credentials object, giving clients visibility into refresh token lifetime for newly registered customers.

POST /auth/password_login

• added the required property oneOf[subschema #2: GetAccessTokenSuccess]/refresh_token_expires_in to the response with the 200 status (media type: application/json)

View updated docs

POST /auth/refresh_access_token

• added the required property refresh_token_expires_in to the response with the 200 status (media type: application/json)

View updated docs

POST /providers/{id}/register_customer

• added the required property credentials/refresh_token_expires_in to the response with the 200 status (media type: application/json)

View updated docs

This release introduces the ability to partially update events, enabling developers to modify specific event fields without sending the entire event payload. This improves efficiency and simplifies workflows where only a subset of event properties need to be changed.

• PATCH /events/{id} — Update specific fields of an existing event without replacing the entire event resource, allowing for more efficient and targeted modifications to event properties such as title, dates, or custom fields.

PATCH /events/{id}

• endpoint added

View updated docs

This release enhances referral program tracking and invoice management capabilities. Developers can now access detailed referral statistics, retrieve invoice receipt URLs, and view enriched currency formatting information for referral rewards. Additionally, account status responses now include referee service fee discount information for billing transparency.

• GET /platform/referral_code now returns referral statistics, enabling developers to track referral performance metrics directly through the API
• GET /invoices now includes receipt URLs for each invoice in the list, allowing clients to provide direct download links to payment receipts
• GET /invoices/{id} now includes a receipt URL, enabling clients to retrieve and display the payment receipt for a specific invoice
• GET /platform/referral_program now provides detailed currency formatting information for reward amounts, including symbol, position, decimal formatting, ISO code, and formatted string representation for proper localized display
• GET /providers/{id}/account_status now exposes referee service fee discounts in the billing information, allowing developers to display discount details for referred providers

GET /platform/referral_code

• the share_url response's property format changed from uri to none for status 200 (media type: application/json)
• added the required property stats to the response with the 200 status (media type: application/json)
• the response required property code became read-only for the status 200 (media type: application/json)
• the response required property share_url became read-only for the status 200 (media type: application/json)

View updated docs

GET /invoices

• added the required property results/items/receipt_url to the response with the 200 status (media type: application/json)

View updated docs

GET /invoices/{id}

• added the required property receipt_url to the response with the 200 status (media type: application/json)

View updated docs

GET /platform/referral_program

• added the optional property reward_amount/currency_symbol to the response with the 200 status (media type: application/json)
• added the optional property reward_amount/currency_symbol_position to the response with the 200 status (media type: application/json)
• added the optional property reward_amount/decimal to the response with the 200 status (media type: application/json)
• added the optional property reward_amount/iso_currency_code to the response with the 200 status (media type: application/json)
• added the optional property reward_amount/string to the response with the 200 status (media type: application/json)

View updated docs

GET /providers/{id}/account_status

• added the required property teamup_billing/allOf[subschema #1: TeamUpBilling]/referee_service_fee_discount to the response with the 200 status (media type: application/json)

View updated docs

This release adds comprehensive support for lead source tracking across customer segments and reporting endpoints, enabling developers to filter and segment customers based on how they were acquired. Additionally, four new referral program endpoints have been introduced, allowing API consumers to programmatically access referral codes, generate QR codes, retrieve program details, and list referrals.

• GET /crm/customer_segments now returns lead source information in customer segment queries, enabling you to see how customers in each segment were acquired
• POST /crm/customer_segments now accepts lead source as a query criterion when creating segments, allowing you to build segments based on customer acquisition channels
• GET /crm/customer_segments/{id} now includes lead source in the segment query details returned
• PATCH /crm/customer_segments/{id} now returns lead source information in the updated segment response
• PUT /crm/customer_segments/{id} now returns lead source information in the updated segment response
• GET /platform/referral_code is a new endpoint that retrieves your referral code for sharing with potential referrals
• GET /platform/referral_code/qr_code is a new endpoint that generates a QR code for your referral link, making it easy to share in print or mobile contexts
• GET /platform/referral_program is a new endpoint that retrieves details about the referral program, including terms and rewards
• GET /platform/referrals is a new endpoint that lists all referrals you've made, allowing you to track referral status and rewards
• GET /reports/customers.grouped/data now supports filtering by lead source, enabling you to analyze grouped customer data by acquisition channel
• POST /reports/customers.grouped/export now accepts lead source as a filter when exporting grouped customer reports
• GET /reports/customers/data now supports filtering by lead source, allowing you to analyze customer data by how they were acquired
• POST /reports/customers/export now accepts lead source as a filter when exporting customer reports

GET /crm/customer_segments

• added the optional property results/items/query/lead_source to the response with the 200 status (media type: application/json)

View updated docs

POST /crm/customer_segments

• added the new optional request property query/lead_source (media type: application/json)
• added the optional property query/lead_source to the response with the 201 status (media type: application/json)

View updated docs

GET /crm/customer_segments/{id}

• added the optional property query/lead_source to the response with the 200 status (media type: application/json)

View updated docs

PATCH /crm/customer_segments/{id}

• added the optional property query/lead_source to the response with the 200 status (media type: application/json)

View updated docs

PUT /crm/customer_segments/{id}

• added the optional property query/lead_source to the response with the 200 status (media type: application/json)

View updated docs

GET /platform/referral_code

• endpoint added

View updated docs

GET /platform/referral_code/qr_code

• endpoint added

View updated docs

GET /platform/referral_program

• endpoint added

View updated docs

GET /platform/referrals

• endpoint added

View updated docs

GET /reports/customers.grouped/data

• added the new optional query request parameter lead_source

View updated docs

POST /reports/customers.grouped/export

• added the new optional request property lead_source (media type: application/json)

View updated docs

GET /reports/customers/data

• added the new optional query request parameter lead_source

View updated docs

POST /reports/customers/export

• added the new optional request property lead_source (media type: application/json)

View updated docs

GET /crm/bulk_status_evaluations

• endpoint added

View updated docs

GET /crm/bulk_status_evaluations/{id}

• endpoint added

View updated docs

GET /crm/customer_segments

• endpoint added

View updated docs

POST /crm/customer_segments

• endpoint added

View updated docs

DELETE /crm/customer_segments/{id}

• endpoint added

View updated docs

GET /crm/customer_segments/{id}

• endpoint added

View updated docs

PATCH /crm/customer_segments/{id}

• endpoint added

View updated docs

PUT /crm/customer_segments/{id}

• endpoint added

View updated docs

GET /crm/interactions

• endpoint added

View updated docs

POST /crm/interactions

• endpoint added

View updated docs

GET /crm/lead_forms

• endpoint added

View updated docs

POST /crm/lead_forms

• endpoint added

View updated docs

DELETE /crm/lead_forms/{id}

• endpoint added

View updated docs

GET /crm/lead_forms/{id}

• endpoint added

View updated docs

PATCH /crm/lead_forms/{id}

• endpoint added

View updated docs

PUT /crm/lead_forms/{id}

• endpoint added

View updated docs

POST /crm/lead_forms/{id}/submit

• endpoint added

View updated docs

GET /crm/lead_sources

• endpoint added

View updated docs

POST /crm/lead_sources

• endpoint added

View updated docs

GET /crm/lead_sources/{id}

• endpoint added

View updated docs

PATCH /crm/lead_sources/{id}

• endpoint added

View updated docs

PUT /crm/lead_sources/{id}

• endpoint added

View updated docs

GET /crm/settings

• endpoint added

View updated docs

PATCH /crm/settings

• endpoint added

View updated docs

GET /crm/status_changes

• endpoint added

View updated docs

GET /crm/status_changes/{id}

• endpoint added

View updated docs

GET /crm/statuses

• endpoint added

View updated docs

GET /crm/statuses/{id}

• endpoint added

View updated docs

PUT /crm/statuses/{id}

• endpoint added

View updated docs

GET /crm/statuses/{id}/defaults

• endpoint added

View updated docs

GET /crm/workflow_action_types/{type}

• endpoint added

View updated docs

GET /crm/workflow_actions

• endpoint added

View updated docs

POST /crm/workflow_actions

• endpoint added

View updated docs

DELETE /crm/workflow_actions/{id}

• endpoint added

View updated docs

GET /crm/workflow_actions/{id}

• endpoint added

View updated docs

PATCH /crm/workflow_actions/{id}

• endpoint added

View updated docs

PUT /crm/workflow_actions/{id}

• endpoint added

View updated docs

GET /crm/workflow_triggers/{trigger}

• endpoint added

View updated docs

GET /crm/workflows

• endpoint added

View updated docs

POST /crm/workflows

• endpoint added

View updated docs

GET /crm/workflows/{id}

• endpoint added

View updated docs

PATCH /crm/workflows/{id}

• endpoint added

View updated docs

PUT /crm/workflows/{id}

• endpoint added

View updated docs

This release improves error handling documentation for the OAuth token refresh endpoint by documenting the 400 Bad Request response. Developers can now better understand and handle failed token refresh attempts in their applications.

• POST /auth/refresh_access_token now documents the 400 Bad Request error response, allowing developers to handle invalid or expired refresh token errors more effectively

POST /auth/refresh_access_token

• added the non-success response with the status 400

View updated docs

All waiver endpoints now return a created_datetime field in their responses, providing timestamp information about when each waiver was originally created. This enhancement applies uniformly across list, retrieve, create, update, and archive operations, giving API consumers consistent access to waiver creation timestamps for auditing and chronological tracking purposes.

• GET /waivers – Each waiver in the results now includes its creation timestamp, enabling chronological sorting and filtering of waivers
• POST /waivers – Newly created waivers now return their creation timestamp in the response
• GET /waivers/{id} – Waiver retrieval now includes the creation timestamp for audit and tracking purposes
• PATCH /waivers/{id} – Partial updates now return the waiver's original creation timestamp in the response
• PUT /waivers/{id} – Full updates now return the waiver's original creation timestamp in the response
• POST /waivers/{id}/archive – Archiving a waiver now returns its creation timestamp for record-keeping
• POST /waivers/{id}/archive-and-copy – Archive-and-copy operations now include the creation timestamp for both the archived waiver and its copy

GET /waivers

• added the required property results/items/created_datetime to the response with the 200 status (media type: application/json)

View updated docs

POST /waivers

• added the required property created_datetime to the response with the 201 status (media type: application/json)

View updated docs

GET /waivers/{id}

• added the required property created_datetime to the response with the 200 status (media type: application/json)

View updated docs

PATCH /waivers/{id}

• added the required property created_datetime to the response with the 200 status (media type: application/json)

View updated docs

PUT /waivers/{id}

• added the required property created_datetime to the response with the 200 status (media type: application/json)

View updated docs

POST /waivers/{id}/archive

• added the required property created_datetime to the response with the 200 status (media type: application/json)

View updated docs

POST /waivers/{id}/archive-and-copy

• added the required property waiver/allOf[subschema #1: WaiverRead]/created_datetime to the response with the 201 status (media type: application/json)
• added the required property waiver/allOf[subschema #1: WaiverRead]/created_datetime to the response with the 202 status (media type: application/json)

View updated docs

This release enhances the customer prerequisites and registration eligibility workflows. The missing requisites endpoint now supports hypothetical scenarios to check requirements before membership changes, and both endpoints have been updated to better distinguish between immediate and deferred form/waiver requirements.

• GET /customers/{id}/missing_requisites now accepts hypothetical membership and offering type parameters, allowing you to check what forms and waivers a customer would need if they were to change memberships or register for different offering types. The response structure for missing forms and waivers has also been simplified.
• POST /registration_eligibility/check now returns separate lists of deferred forms and deferred waivers in prerequisites, enabling you to distinguish between requirements that must be completed immediately versus those that can be completed later.

GET /customers/{id}/missing_requisites

• the missing_forms response's property type changed from array<object> to string for status 200 (media type: application/json)
• the missing_waivers response's property type changed from array<object> to string for status 200 (media type: application/json)
• added the new optional query request parameter hypothetical_membership
• added the new optional query request parameter hypothetical_offering_type

View updated docs

POST /registration_eligibility/check

• added the optional property prerequisites/deferred_forms to the response with the 200 status (media type: application/json)
• added the optional property prerequisites/deferred_waivers to the response with the 200 status (media type: application/json)

View updated docs