Service Level Agreement

Last Updated: 11th December 2025

1. Purpose

This Service Level Agreement (“SLA”) describes the availability, performance expectations, and support commitments for Smartix services, including Smartix Studio, Smartix API, Smartix Scan, and related systems (“Service”).

Our goal is to provide a reliable, high-performance platform for creating, issuing, and managing Apple and Google Wallet passes.

This SLA forms part of the Smartix Terms of Service.

2. Service Availability Commitment

Smartix targets 99.9% availability per calendar month for the Smartix platform, excluding scheduled maintenance and events outside our reasonable control.

2.1. What “Service Availability” Covers

Availability applies to:

Smartix API
Smartix Studio
Background processing systems (queues, automated tasks)

2.2. What Availability Does Not Cover

The following are outside the scope of availability calculations:

Apple Wallet or Google Wallet infrastructure outages
Apple or Google notification delivery delays
Failures of Google Wallet API during pass creation
AWS regional incidents or outages
Customer misconfiguration or invalid data
Issues caused by network or device limitations
Scheduled maintenance windows announced in advance

Smartix cannot guarantee delivery timing once passes or updates leave our system and rely on external wallet ecosystems.

3. Definition of Downtime

“Downtime” means a period during which the Smartix API or Smartix Studio is unavailable to all customers due to a Smartix-controlled issue.

The following do not count as downtime:

Planned maintenance
Third-party service failures (AWS, Apple, Google, Stripe)
Partial degradation where core functionality remains operational
Queue processing delays
Customer-side issues or misuse
Degraded delivery speeds caused by Google or Apple infrastructure

Smartix continually monitors system performance and takes immediate action to restore availability.

4. Planned Maintenance

To maintain a secure and reliable platform, Smartix performs maintenance from time to time.

Where possible, Smartix will:

provide advance notice in Smartix Studio or via email
schedule maintenance during off-peak hours
minimise service impact

During maintenance, some parts of the Service may be temporarily unavailable.

5. Scaling and Performance

Smartix is architected with AWS serverless technologies for automatic scaling, including:

AWS Lambda for compute
AWS CloudFront for content distribution
Multi-zone deployment for resilience
RDS autoscaling and capacity monitoring

This design ensures consistent performance during traffic spikes and peak workloads.

6. Queued Operations

Smartix uses background queues to ensure reliable delivery and protect platform stability.

6.1. Single-Pass Operations (Real-Time)

Actions that affect one pass—such as updating, deleting, or regenerating a single pass—are processed immediately.

These operations execute synchronously unless impacted by external services (e.g., Google API downtime).

6.2. Bulk Processing Queue (Smartix-Controlled)

Requests that modify or update multiple passes are processed asynchronously via a bulk processing queue.

Each pass is processed sequentially
Processing time depends on batch size and system load
Bulk operations do not fall under the 99.9% availability target
Smartix provides status visibility where possible

This approach ensures fairness across all customers and avoids performance bottlenecks.

###Google Wallet Delivery Queue (Google API-Dependent)

Issuing Google Wallet passes requires Smartix to make API calls to Google’s Wallet API.

If the Google API is unavailable or returning temporary errors:

Smartix places affected passes into a delivery retry queue
Smartix automatically retries the request at regular intervals
Passes are delivered once the Google API becomes available again
Delays caused by Google do not count against Smartix availability

Google outages are rare but may temporarily delay pass creation or updates.

7. Support and Issue Handling

Support is provided through the dedicated support page in Smartix Studio:
studio.smartix.uk/support

7.1. Response Targets

Smartix aims to:

Respond to non-urgent support requests within 2 business days
Respond to critical service issues as soon as possible, 24/7
Provide updates during major incidents until services are restored

7.2. Issue Categories

Critical: Full platform outage or complete failure of pass generation
High: Partial outage or major degradation
Standard: Routine support questions, non-critical bugs, usability issues

Resolution times vary depending on complexity and severity.

For details, see the Smartix Incident Response Policy.

8. Service Credits

Smartix does not provide financial compensation for downtime.

At our discretion, Smartix may grant account credits for verified service disruptions attributable solely to Smartix-controlled issues.
Credits do not apply to:

free-tier accounts
Pay-As-You-Go usage
incidents caused by third-party services

Service credits are goodwill gestures and not contractual guarantees.

9. Customer Responsibilities

To maintain performance and ensure proper use of the Service, Customers must:

secure API keys and rotate them when appropriate
configure pass templates correctly, including metadata fields
provide valid and complete data when creating passes
use recommended API versions
maintain accurate account contact information
monitor pass counts to avoid unnecessary billing

Misconfiguration or misuse falls outside the scope of this SLA.

10. Limits of Liability

While Smartix aims to maintain the highest levels of availability and data integrity, Smartix cannot be held responsible for interruptions or data loss caused by:

AWS infrastructure failures
Google Wallet API outages
Apple Wallet service disruptions
Internet or device failures
Customer misconfiguration or unexpected usage
Force majeure events or circumstances beyond Smartix’s control

Nothing in this SLA modifies the Smartix Terms of Service.

11. Updates to this SLA

Smartix may update this SLA periodically to reflect changes in technology, infrastructure, or operational practices.
The latest version will always be available at: