amber.systems SaaS and API services schedule

Version 2026-08-18 - last updated 18 August 2026

1. When this schedule applies

1.1 This SaaS and API Services Schedule applies where an Order Form incorporates it for hosted software, web applications, control panels, developer platforms, APIs, model endpoints, managed inference, usage-based services or related online functionality (Hosted Services).

1.2 This schedule forms part of the Contract together with the General Terms of Business, Acceptable Use Policy, Data Processing Agreement, and any incorporated Service Level and Support Schedule.

1.3 Infrastructure supplied primarily for the Customer to administer is additionally governed by the Managed Infrastructure and Hosting Schedule. Bespoke development and installed software are governed by their applicable schedules where incorporated.

2. Definitions

In this schedule:

• API means an application programming interface, protocol endpoint, software-development kit or machine-accessible interface supplied as part of a Hosted Service.
• API Client means software developed or controlled by the Customer that accesses an API.
• API Key includes a token, credential, certificate, signing secret or other authentication material for an API.
• Documentation means the then-current user or developer documentation we make available for the Hosted Service.
• End User means a person who uses a Customer Application or feature powered by a Hosted Service but is not directly our customer.
• Input means Customer Content submitted to a Hosted Service for processing.
• Output means a result generated by a Hosted Service from Input, including an API response, classification, transformation, analysis, completion or generated media.
• Stable Interface means an API version or integration surface that the Documentation identifies as generally available and supported, excluding beta, preview, experimental or undocumented functionality.
• Subscription Term means the period for which the Customer is entitled to use the Hosted Service.
• Usage Unit means a request, token, byte, compute unit, user, seat, event, minute or other metering unit stated in the Order Form or Documentation.

3. Access rights

3.1 Subject to the Contract and payment of Fees, we grant the Customer a non-exclusive, non-transferable right during the Subscription Term to:

• allow Authorised Users to access and use the Hosted Service for the Customer’s business purposes;
• use the Documentation;
• develop, test and operate API Clients; and
• where API access is included, incorporate API-powered functionality into the Customer’s own applications, services, workflows and products and make that functionality available to End Users.

3.2 The right in section 3.1 permits commercial use of an API through a Customer Application. It does not permit the Customer to:

• disclose or transfer an API Key to an End User or unauthorised third party;
• sell or expose raw access to the API as a substitute for the Hosted Service;
• misrepresent a third-party model, dataset or service as being owned or operated by the Customer; or
• exceed a reseller, white-label, embedding or redistribution limit stated in the Order Form.

3.3 The Order Form may grant an affiliate, contractor, development, redistribution, OEM, white-label or service-provider entitlement. The Customer remains responsible for anyone using the Hosted Service through its account, API Clients or credentials.

3.4 Rights are limited to the usage, users, environments, regions and other entitlements stated in the Order Form. We may technically enforce those limits.

3.5 No source code or ownership right in the Hosted Service is transferred.

4. Accounts, users and credentials

4.1 The Customer must maintain accurate account, administrator and billing details.

4.2 The Customer is responsible for:

• approving and removing Authorised Users;
• assigning least-privilege permissions;
• protecting API Keys and other credentials;
• separating development, test and production credentials where reasonably appropriate;
• rotating or revoking compromised credentials; and
• notifying us promptly of suspected unauthorised use.

4.3 API Keys must not be embedded in publicly distributed client-side code or public repositories unless they are specifically designed to be public and constrained accordingly.

4.4 We may revoke or rotate a credential where reasonably necessary to protect the Customer, the Hosted Service or another person. Where practicable, we will coordinate a planned rotation.

5. Customer Applications and End Users

5.1 Where the Customer makes API-powered functionality available to End Users, the Customer is responsible for:

• the Customer Application and its security, availability and legal compliance;
• providing End Users with appropriate terms and privacy information;
• obtaining rights and lawful bases for Inputs submitted through the Customer Application;
• first-line support for End Users unless the Order Form says otherwise;
• making clear where an output is generated or assisted by automation where law or context requires; and
• preventing use that breaches the Contract or applicable law.

5.2 The Customer must not state or imply that amber.systems contracts directly with, endorses, certifies or is responsible to an End User unless we agree in writing.

5.3 We may communicate directly with an End User only where reasonably necessary for security, abuse prevention, legal compliance or operation of an agreed end-user feature, and subject to the DPA and privacy notice.

6. Documentation, compatibility and integration

6.1 We will make Documentation reasonably sufficient to use generally available functionality.

6.2 The Customer is responsible for implementing and maintaining its API Clients and integrations, including retries, idempotency, error handling, timeouts, authentication, input validation and safe handling of Outputs.

6.3 Example code and SDKs are provided for convenience and may require review and adaptation before production use.

6.4 We do not warrant compatibility with an undocumented interface, unsupported library, obsolete version or third-party system unless expressly stated.

7. Usage, quotas and metering

7.1 Fees and entitlements may be based on Usage Units. Our metering records are authoritative unless the Customer demonstrates a material error.

7.2 The Customer must monitor usage and configure available budgets, limits and alerts appropriate to its risk tolerance.

7.3 We may apply quotas, concurrency limits, payload limits, rate limits and safety controls reasonably necessary to operate and protect the Hosted Service. Published limits form part of the Documentation.

7.4 Testing a rate limit using accounts and data the Customer controls is not prohibited merely because it attempts to reach or bypass that limit, provided the testing remains non-disruptive, does not access another person’s data and otherwise complies with the security policy and AUP.

7.5 Where a hard limit is not configured, usage above an allowance may incur overage Fees. We will provide reasonable usage information and, where practicable, notice of material unexpected usage, but the absence of an alert does not waive properly measured Fees.

7.6 We may temporarily throttle a request stream that creates a credible risk of material degradation, abusive cost, compromise or harm. We will restore ordinary access when the risk is resolved.

8. Service changes, versioning and deprecation

8.1 We may improve or change the Hosted Service, including interfaces, models, infrastructure, safety controls and user experience.

8.2 For a material breaking change to a Stable Interface, we will use reasonable efforts to provide at least 90 days’ notice and a migration path. A shorter period may apply where necessary to address an urgent security issue, legal requirement, provider withdrawal or material operational risk.

8.3 We may add a new version before retiring an old version and may run versions in parallel. The Customer is responsible for migrating within the announced support period.

8.4 Undocumented, beta, preview, experimental and free functionality may change or end without a migration period and must not be relied upon for critical production use.

8.5 A change does not materially reduce the contracted core functionality where a reasonably equivalent function remains available, unless the Order Form specifically guarantees the affected feature.

9. Customer Content and data rights

9.1 The Customer retains ownership of Customer Content and grants the processing licence in the General Terms.

9.2 We will use Customer Content only to provide, secure, support and administer the Hosted Service, comply with documented instructions and law, and exercise contractual rights.

9.3 We do not use Customer Content to train a general-purpose model unless the Customer expressly opts in through a written agreement or clearly identified product control.

9.4 Where we process personal data on the Customer’s behalf, the DPA applies. The Customer is responsible for the lawfulness and accuracy of Customer Content and for configuring retention and access appropriately.

9.5 The Hosted Service may generate telemetry, usage measurements, performance data and security events. We may use aggregated or de-identified information that does not identify the Customer, an End User or another person to operate, secure, understand and improve our services.

10. Artificial-intelligence and model services

10.1 This section applies where a Hosted Service uses a machine-learning or generative model.

10.2 We may route a request to an amber.systems-operated model or a third-party model provider identified in the Order Form, Documentation or subprocessor list.

10.3 Where Customer Content is sent to a third-party model provider as processor:

• we will use business or API services covered by appropriate contractual data-processing terms;
• for providers and endpoints described as zero-data-retention (ZDR), we will configure routing so that Customer Content is not retained by the model provider after the request except for narrow legal, security or abuse-handling circumstances disclosed by that provider;
• we will not knowingly route ZDR-designated Customer Content to a non-ZDR endpoint or fallback unless the Customer has agreed; and
• limited account, billing, request, token, timing, routing, abuse or security metadata may still be processed or retained.

10.4 Model providers, models and regions may change. A material change affecting data retention, training, processing location or a committed capability will be notified in accordance with the DPA or section 8.

10.5 Outputs may be inaccurate, incomplete, biased, insecure, non-unique or unsuitable for the Customer’s purpose. The Customer must review and test Outputs before relying on them, especially in production, security-sensitive, regulated or high-impact contexts.

10.6 The Customer must not use a Hosted Service as the sole basis for a decision that produces legal or similarly significant effects on a person unless the Order Form expressly permits that use and the Customer has implemented appropriate legal, human-review, accuracy and contestability safeguards.

10.7 Unless expressly agreed, Hosted Services are not designed as medical devices, emergency systems, autonomous weapons, life-safety controls or the sole control plane for critical infrastructure.

10.8 Subject to the Contract and applicable third-party rights, the Customer may use Outputs for its business purposes and in Customer Applications. We do not warrant that an Output is capable of exclusive ownership or does not resemble content produced for another user.

11. Intellectual property and feedback

11.1 We and our licensors retain rights in the Hosted Service, APIs, Documentation, Provider Materials and service improvements.

11.2 The Customer may benchmark, test, observe and analyse the Hosted Service for lawful internal, comparative, interoperability, security and research purposes, provided it does not access another person’s data, materially disrupt the Service, or falsely describe the results. There is no blanket prohibition on reverse engineering or competitive analysis.

11.3 If the Customer voluntarily provides feedback, it grants us a perpetual, worldwide, royalty-free right to use that feedback without identifying the Customer or disclosing its Confidential Information. The Customer is not required to provide feedback.

11.4 Open-source components remain governed by their applicable licences.

12. Availability, maintenance and support

12.1 Availability commitments, support windows, response targets and service credits apply only where stated in the Order Form or incorporated SLA.

12.2 We may perform scheduled and emergency maintenance. The Customer should design API Clients to tolerate ordinary transient failures and maintenance.

12.3 Support covers the Hosted Service, not the Customer Application, Customer network or third-party systems unless expressly included.

12.4 A Service Credit under an incorporated SLA is the Customer’s financial remedy for failure to meet an availability target, without limiting termination rights for chronic failure or liability that cannot lawfully be limited.

13. Security and testing

13.1 We will maintain technical and organisational measures appropriate to the Hosted Service and processing risk.

13.2 The Customer may test the Hosted Service using accounts, tenants, resources and data it controls in accordance with our security research and vulnerability disclosure policy. That policy expressly includes console.amber.systems and documented first-party APIs unless an asset is excluded there.

13.3 The Customer must not intentionally access another customer’s or another person’s account, data, resources, credentials or non-public interface. If such data is displayed unexpectedly, the Customer must follow the accidental-access steps in the security policy.

13.4 Report vulnerabilities to security@amber.systems.

14. Beta, preview and experimental functions

14.1 A beta, preview, experimental or evaluation function may be incomplete, change without notice, have lower security or availability, and be discontinued at any time.

14.2 Unless the Order Form expressly says otherwise, beta functions have no SLA, warranty or support commitment and must not be used for production, regulated or high-impact processing.

14.3 We will identify known material data-retention or confidentiality differences before permitting Customer Content in a beta function.

15. Suspension

15.1 In addition to the General Terms, we may suspend a credential, API Client, feature or account where reasonably necessary to:

• contain suspected compromise or leakage of an API Key;
• prevent material harm, unlawful processing or abuse;
• protect availability or unexpected cost;
• comply with an upstream provider restriction or lawful requirement; or
• investigate a material breach of the AUP.

15.2 Where practicable, we will limit suspension to the affected credential, workload or function and will explain the steps needed for restoration.

16. Export, termination and deletion

16.1 The Customer may export Customer Content using available self-service functions during the Subscription Term.

16.2 Unless another period is stated, the Customer may request a standard export within 30 days after termination. Custom conversion, bulk migration, prolonged access and provider egress are chargeable unless included.

16.3 After the export period, we may delete active Customer Content and release accounts, identifiers and reserved capacity. Backup copies expire through ordinary cycles under the DPA and retention schedule.

16.4 API Keys and access rights end on termination. The Customer must stop making requests and remove keys from its systems.

16.5 Termination does not require us to provide source code, model weights, internal prompts, orchestration logic, Provider Materials or third-party systems unless the Order Form expressly states otherwise.

17. Contact

• Service and commercial enquiries: hello@amber.systems
• Security reports: security@amber.systems
• Abuse reports: abuse@amber.systems