Appmixer Support and Maintenance Terms

For Appmixer Cloud and Self-Hosted Edition

Version 1.0 · 16 November 2026

These Support and Maintenance Terms (“Support Terms”) govern the provision of technical support and maintenance services by the Provider to the Customer pursuant to an executed Order Form.

These Support Terms are ancillary to, and form an integral part of, either the Cloud-Based (SaaS) Agreement or the Self-Hosted License Agreement (EULA) executed between the Parties (the applicable agreement hereinafter referred to as the “Master Agreement”).

These Support Terms apply to both the Cloud (SaaS) and Self-Hosted (EULA) deployment models of the Appmixer Software.

1. Support Tiers and Commercial Packages

1.1 Support Tier Classification. The Provider offers four distinct tiers of technical support and maintenance services under these Support Terms: Basic Support, Standard Support, Premium Support, and Platinum Support.

1.2 Self-Hosted (EULA) Support Allocation. Unless agreed otherwise in writing or set forth in the Order, the License Fee includes access to the Standard tier of Support and Maintenance Services only. Acquisition of higher support tiers (including, but not limited to, Premium or Platinum support packages) shall be strictly subject to additional support and maintenance fees. Such premium tiers must be explicitly agreed upon between the Parties and compensated in accordance with these Support Terms, the Provider’s current Price List, or as agreed in the Order.

1.3 Cloud-Based (SaaS) Support Allocation. Unless agreed otherwise in writing or set forth in the Order, the Subscription Fees include access to the baseline tier of Support and Maintenance Services corresponding to the Customer’s Cloud-Based (SaaS) plan as follows:

  • 1.3.1 Starter Plan: Community Support;
  • 1.3.2 Professional Plan: Standard Support;
  • 1.3.3 Enterprise Plan: Premium Support.

Acquisition of a support tier higher than the allocated baseline specified above shall be strictly subject to additional support and maintenance fees. Such upgraded tiers must be explicitly agreed upon between the Parties and compensated in accordance with these Support Terms, the Provider’s current Price List, or the applicable Order.

2. Included Basic Services and Tier-Specific Services

2.1 Baseline Services for Community Support (Included Across All Support Tiers). Regardless of the chosen Support tier, all tiers explicitly include the following baseline services and features:

  • 2.1.1 Access to Documentation: Access to the then-current Documentation for the Software, including standard code architecture examples, usage tutorials, and configuration guides.
  • 2.1.2 GitHub Discussions: Unlimited, 24Ă—7 access to the GitHub Discussions platform.

2.2 Tier-Specific Services. All other support services, features, operational tools, and collaborative access channels (including, but not limited to, incident resolution and access to the Provider’s member-only issue and incident tracking system (the “Support Portal”), dedicated Slack Hotlines, Shared Microsoft Teams channels, or specialized Community/Developer Support forums) are support tier-specific (Standard, Premium, or Platinum). Such tier-specific services are provided strictly according to the specific support tier selected in the Order Form, are governed by and detailed in the Provider’s live Price List or elsewhere on Provider’s website dedicated to support services, and may be subject to additional fees (as set forth in the Price List).

3. Incident Notification, Classification and Response Times

3.1 Incident Notification. All technical malfunctions, operational failures, or errors (each an “Incident”) must be formally notified by the Customer to the Provider exclusively through the designated web-based Support Portal (support.appmixer.com). The Provider is under no obligation to log, track, or trigger response metrics for communications received via alternative channels (such as generic emails, direct Slack messages, or phone calls) unless an elevated support tier explicitly modifying this notification rule is active under the applicable Order Form.

3.2 Assessment of Incidents by Severity. Reported Incidents will be systematically categorized by the Provider into one of two severity tiers:

  • 3.2.1 Critical Incident: An Incident where the production environment of the Software is completely non-operational, severely degraded, or fundamentally locked. The core automation engine is entirely non-responsive, zero data messages are being processed, or a serious security vulnerability is verified, and no immediate operational workaround or bypass is available.
  • 3.2.2 Standard Incident: An Incident where features, modules, or non-essential workflows within the Software are malfunctioning or displaying unexpected errors, but the baseline platform remains functional. This includes general usage questions, minor bugs, documentation clarifications, environment layout questions, or any errors occurring in non-production, staging, or test environments.

3.3 Authority for Severity Assessment. The final assessment and designation of an Incident’s severity level rests entirely in the sole, good-faith discretion of the Provider. In the event that the initial details, log payloads, or diagnostic information notified by the Customer are insufficient for the Provider to accurately assess the operational impact or determine the severity level (see, for example, Section 5.3), the Provider may request additional information, system logs, or a reproducible test case from the Customer. The Customer shall provide such requested data without undue delay. The Provider’s target response time metrics under Sections 3.5 and 3.6 shall be automatically suspended and shall not run during the period from which the Provider requests such additional details until the Customer delivers the complete information necessary for the Provider to conduct the assessment.

3.4 Escalation. Upon completing its evaluation of the diagnostic data submitted through the Support Portal, the Provider shall, without undue delay, notify the Customer of the severity level assigned to the Incident, being either a Standard Incident or a Critical Incident. If the Customer reasonably disagrees with the severity level assigned by the Provider, the Customer may escalate the matter to the Provider and request that the Incident be assigned a higher severity level. The Parties shall cooperate in good faith and work collaboratively to resolve the escalation. Following such escalation, the Provider shall make the final determination regarding the severity level of the Incident.

3.5 Target Response Time Matrix. The response times listed below represent the maximum elapsed time between the electronic receipt of a proper and complete support request (e.g. Incident notification) via the Support Portal (“clock starts running”) and the precise time when the Provider initiates the support service by delivering the severity assessment to the Customer (“clock stops running”), subject to any suspension periods applied pursuant to Section 3.3.

3.6 Response Times. Unless agreed otherwise in the Order Form, the response times are calculated in hours according to the specific support package and severity tier as follows:

Incident Severity Standard Tier Premium Tier Platinum Tier
Critical Incident 6 hours 2 hours Custom
Standard Incident 72 hours 48 hours Custom

3.7 No Resolution Time Guarantees. While target response times measure how quickly technical assistance begins, the Customer acknowledges that the time required to fully resolve, patch, or work around an Incident (the “Resolution Time”) depends on the technical complexity and nature of the issue. The Provider will deploy commercially reasonable efforts to diagnose, troubleshoot, and assist the Customer in addressing Incidents promptly. However, because Software performance may be influenced by external environment variables, system configurations, or third-party dependencies, the Provider does not commit to fixed resolution timeframes or guarantee that every specific Incident can be fully remedied. Except as explicitly set forth in the Master Agreement, no additional warranties regarding Incident resolution are provided.

4. Availability and Software Version Support

4.1 Support Portal Availability. Access to the Support Portal is generally available 24 hours per day, 7 days a week, 365 days a year, barring unforeseen interruptions in regional Internet services, critical hosting provider infrastructure failures, or planned exceptions scheduled by the Provider. Notwithstanding anything to the contrary in these Support Terms, the Provider does not guarantee uninterrupted system availability.

4.2 Lifecycle Software Version Support. The Provider will provide Support and Maintenance Services for the then-current major version of the Software and for a period of not less than twelve (12) months from the formal general release date of said then-current version. The Provider is under no obligation to support legacy builds or versions that have passed this 12-month support window.

5. Support Provision, Customer Cooperation, and Other Prerequisites

5.1 General Provisions (Applicable to Both Models).

  • 5.1.1 Customer’s Cooperation. To receive effective Support Services, the Customer shall:
    • (a) Qualified Personnel. Appoint qualified technical personnel as primary support contacts and maintain a reasonable level of training. The Customer is responsible for ensuring that its internal operations personnel have received sufficient technical training to attain and maintain standard professional competence in the management and operation of the Software;
    • (b) Incident Notification: submit all Incidents via the Support Portal with complete, accurate data.
  • 5.1.2 Public Sources: If the Provider determines, in its sole professional discretion, while responding to a Customer request for support, that the appropriate solution is already clearly provided in publicly available instructional media (including, but not limited to, core source code documentation, online tutorials, standard examples, public websites, or accessible support forums), the Provider may immediately direct the Customer’s personnel to the appropriate media. The resolution of a support request via redirection to existing educational media fully satisfies the Provider’s support obligations.

5.2 Specific Cooperation Scope for Cloud-Based (SaaS) Deployments. For SaaS deployments, the Customer’s cooperation shall be focused on functional integration parameters. The Customer shall, upon request, provide the Provider with detailed description logs of custom integration payloads, specific webhook configurations, user permission contexts, and replication steps. The Customer is not required, nor permitted, to grant or manage any infrastructure-level access to the hosting servers.

5.3 Specific Cooperation Scope for Self-Hosted (EULA) Deployments. Because Self-Hosted deployments operate entirely within the Customer’s proprietary infrastructure, the level of cooperation required from the Customer is substantially higher; failure to deliver requested cooperation shall automatically suspend all response times under these Support Terms. The Customer shall strictly comply with the following infrastructure-level prerequisites:

  • 5.3.1 Environmental Responsibility: The Customer is solely responsible for all hardware scaling, operating system compliance, server nodes, database maintenance, network configurations, and firewall rules required to run the Software.
  • 5.3.2 Mandatory Log Provision: In the event of an Incident notification, and where required, the Customer must proactively extract and deliver full application logs, container environment variables, and database connection metrics to the Provider via the Support Portal.
  • 5.3.3 Reproducible Test Cases: If requested by the Provider, the Customer must provide an isolated, sanitized, and reproducible test case duplicating the reported error in a staging environment.
  • 5.3.4 Secure Remote Access: For complex or deep-tier troubleshooting where log analysis is insufficient, the Customer may be required to grant the Provider restricted, monitored, and secure remote access (e.g., via a secure VPN or screen-share session) to the local deployment environment.

6. Deployment and Delivery of Updates and Incident Resolutions

6.1 For Cloud-Based (SaaS) Deployments. Because the Software is hosted and operated entirely within the Provider’s cloud infrastructure, the deployment of updates and incident remedies is fully controlled by the Provider:

  • 6.1.1 Automated Rollouts: All Software updates, patches, security fixes, and incident resolutions will be deployed by the Provider directly to the cloud platform. The Customer is not required to perform any manual installations or technical configuration steps to receive updates.
  • 6.1.2 Maintenance Windows: The Provider will use commercially reasonable efforts to perform non-emergency updates and deployment fixes during scheduled maintenance windows to minimize operational disruption.
  • 6.1.3 Uptime Dependencies: System availability during deployments is strictly governed by Schedule No. 1 (SLA) of the SaaS Terms and Conditions.

6.2 For Self-Hosted (EULA) Deployments. Because the Software is deployed locally within the Customer’s private environment, firewalls, and infrastructure, the deployment mechanism shifts entirely to a delivery model:

  • 6.2.1 Delivery via Electronic Access: The Provider fulfills its update and incident remediation obligations solely by making the container images, binaries, object codes, or deployment scripts available to the Customer via a secure electronic repository (e.g., a private image registry or download portal).
  • 6.2.2 Customer Installation Mandate: The Customer is exclusively responsible for downloading, pulling, and executing the deployment scripts or images within its own infrastructure.
  • 6.2.3 Crucial Updates: As set forth in the EULA, the Customer must deploy Crucial Updates without undue delay.

7. Term, Extension, and Downgrade Automation

7.1 Duration of Standard Support. For Customers utilizing the Standard Support level, these Support Terms remain valid and active for the entire duration of the underlying Cloud-Based (SaaS) Agreement or the Self-Hosted License (EULA) Agreement.

7.2 Duration of Premium Tiers. For Customers subscribing to elevated support tiers (e.g. Premium Support or Platinum Support), the premium service levels will remain active only as long as the additional support fees for such higher levels are fully and timely paid by the Customer.

7.3 Automatic Downgrade of Premium Tiers. If the Customer fails to pay the required premium support fees when due, or fails to renew them, the Customer’s support tier shall automatically, without further notice, convert and downgrade back to the Standard Support tier, and all associated priority response targets, custom communication channels, and premium entitlements shall immediately cease.

8. Final Provisions

8.1 Modifications. The Provider reserves the right to revise or modify these Support Terms. In such instances, the Provider will provide notice to the Customer regarding the availability of new versions of the Support Terms at least 30 days prior to their effective date. It is the Customer’s responsibility to review and become familiar with updated Support Terms. Once timely notified, the new versions of the Support Terms will become binding and effective for the Customer on its effective date. Provided that the Customer objects in writing to the updated Support Terms prior to their designated effective date, it shall have the right to terminate premium support tiers and downgrade back to the Standard Support tier as its sole remedy.

8.2 Governing Law and Jurisdiction. These Support Terms shall be governed by, construed, and enforced in accordance with the exact same governing law and choice-of-law principles set forth in the underlying Master Agreement, and any disputes arising out of or in connection with these Support Terms shall be subject to the exclusive jurisdiction of the same courts designated in said Master Agreement.

8.3 Limitation of Liability. For the avoidance of doubt, any financial caps, exclusions, or limitations of liability established in the Master Agreement shall comprehensively apply to all claims, damages, or remedies arising under these Support Terms.