Liveness Detection API Service
SLA (Service Level Agreement)

This SLA forms part of the Liveness Detection API Service Terms of Service and sets forth the conditions concerning the uptime target and Service Credits (compensation).

1. Scope

This Service Level Agreement (this “SLA”) sets forth the conditions concerning the uptime target and the Service Credits (compensation) for the “Liveness Detection API Service” (the “Service”) provided by Swallow Incubate Co., Ltd. (the “Company”). This SLA forms part of the Terms of Service for the Service (the “Terms of Service”).

2. Definitions

The terms used in this SLA shall, in addition to those defined in the Terms of Service, have the meanings set forth in this Section.

1. “Covered Endpoints” The endpoints of the Service covered by this SLA, specifically as follows:

Health-check endpoints such as /v1/health, the Marketplace onboarding endpoints under /aws-mkt/*, the customer dashboard under /console/*, and the administrative console are excluded from this SLA.

2. “Downtime” With respect to a Covered Endpoint, where any of the following states (each, an “Error State”) is first detected by the Company’s uptime monitoring (CloudWatch Synthetics) and the Error State continues for five (5) consecutive minutes or longer, the aggregate time (in minutes) from the start of detection of such Error State until recovery (the point at which a normal response is detected):

• returning HTTP status codes 500, 502, 503, or 504;
• response timeout (failing to respond within 30 seconds); or
• a state in which an HTTP connection itself cannot be established in response to the Company’s uptime monitoring request.

1. Momentary interruptions of less than five (5) minutes in duration are, in principle, not counted as Downtime. However, even for momentary interruptions of less than five (5) minutes in duration, where such interruptions occur three (3) or more times in total on the same Covered Endpoint on the same day (UTC) and the interval between each interruption is in each case within 10 minutes, such a series of failures shall be aggregated and counted as a single period of Downtime, the duration of which shall be the aggregate minutes of such Error States from the point of detection of the first Error State to the point of the last recovery. (b) An independent failure that occurs again 15 minutes or more after a prior recovery (limited to failures each of which is less than five (5) minutes in duration) is not counted as Downtime. Furthermore, HTTP status codes in the 400 range (401 / 403 / 404 / 429, etc.) are not included in Downtime, as being attributable to the Customer’s operations, settings, or implementation.

3. “Monthly Uptime” The uptime of the Covered Endpoints in a calendar month (UTC), calculated by the following formula:

Monthly Uptime (%) = (1 - total Downtime minutes / total minutes in the month) × 100

Example: in a 30-day month (43,200 minutes), if the total Downtime is 60 minutes, the Monthly Uptime is 99.86%.

4. “Service Credit” The discount amount on the fees for the following month or later that the Company grants to the relevant Customer where the Monthly Uptime falls below the Target Uptime set forth below.

5. “Target Month” The calendar month (UTC) that is the subject of the calculation of a Service Credit.

3. Uptime Target and Service Credits

3.1 Target Level of Monthly Uptime

The Company shall operate the Service with the goal of a Monthly Uptime of the Covered Endpoints of 99.5% (the “Target Uptime”). Where the Monthly Uptime falls below the Target Uptime, the Company shall grant the Service Credit set forth in Section 3.2 of this SLA. The Customer may not, solely on the ground that the Monthly Uptime has fallen below the Target Uptime, claim damages, terminate the Service Agreement (including this SLA), or make any other claim, except to the extent directly caused by the Company’s willful misconduct or gross negligence.

3.2 Tiered Service Credits

Where the Monthly Uptime falls below the Target Uptime set forth in the preceding Section, the relevant Customer may claim the Service Credit set forth in the following table in accordance with the procedure in Section 5 of this SLA.

3.3 Cap on Service Credits

The total amount of Service Credits shall be capped at 50% of the relevant Customer’s fees for the Service in the Target Month.

4. Measurement Method

4.1 Measuring Party

The measurement of the Monthly Uptime shall be conducted by the Company based on the records of the uptime monitoring system independently operated by the Company (AWS CloudWatch Synthetics). The Company shall retain the records forming the basis of the measurement for a reasonable period, and where the Customer makes an inquiry based on reasonable grounds, the Company shall confirm such records and respond in good faith.

4.2 Measurement Frequency

CloudWatch Synthetics performs a health check on the Covered Endpoints every minute.

4.3 Measurement Point

Monitoring requests are issued from the AWS Tokyo region (ap-northeast-1). Communication conditions at the Customer’s location or along its route, ISP failures, and the like are not subject to measurement.

4.4 Publication of Measurement Results

The Company shall endeavor to publish the aggregate value of the Monthly Uptime on the customer dashboard by the 15th day (UTC) of the month following the relevant month.

5. Procedure for Claiming Service Credits

5.1 Method of Claim

A Customer wishing to claim a Service Credit shall, by the last day of the month following the Target Month, send a claim by email to liveness-api@swallow-incubate.com stating the following items:

5.2 Effect of Lapse of the Deadline

Where a claim is not made within the deadline set forth in the preceding Section, the right to claim a Service Credit for the relevant Target Month shall lapse.

5.3 The Company’s Review

After receiving the Customer’s claim, the Company shall reconcile it against its uptime monitoring records and, in principle, respond as to whether the claim is approved within 30 days.

5.4 Method of Granting Service Credits

Service Credits shall be granted by one of the following methods. The Company shall determine which method to adopt, in accordance with operational constraints such as the AWS Marketplace Terms:

1. a discount from the billed amount for the following month or later;
2. a refund through AWS Marketplace (where permitted by the AWS Marketplace Terms); or
3. another method agreed upon by the Company and the Customer.

5.5 Cap and Nature of Service Credits

Except in the case of the Company’s willful misconduct or gross negligence, the Service Credit shall be the Customer’s Sole and Exclusive Remedy for any and all damages, losses, and disadvantages incurred by the Customer arising from or in connection with the Monthly Uptime falling below the Target Uptime or the occurrence of Downtime in the Service. Except in the case of the Company’s willful misconduct or gross negligence, the Customer may not, for any reason whatsoever, make any claim for damages, compensation, reduction or refund of fees, or any other claim in excess of the amount of the Service Credit. In no event shall the Company be liable for any lost profits, lost revenue, business interruption, loss of data, loss of goodwill, cost of procurement of substitute goods or services, or any other indirect, special, incidental, or consequential damages, and Article 19 of the Terms of Service (Limitation of Liability) shall apply to the Company’s liability for damages.

6. Exclusions

Downtime arising from any of the following causes shall be excluded from the calculation of the Monthly Uptime:

1. causes attributable to the Customer’s operations, settings, or implementation (incorrect use of API Keys, invalid requests, exceeding rate limits, failures of the Customer’s own systems, the Customer’s network failures, etc.);

2. causes attributable to a system failure of AWS Marketplace, an infrastructure failure affecting the AWS Tokyo region on a wide-area basis, or the suspension or restriction of services of a third party beyond the Company’s reasonable management or control, such as a CDN, DNS, or telecommunications carrier; provided, however, that this exclusion shall apply only to failures that could not be avoided despite the Company having taken commercially reasonable defensive measures in light of the scale of provision, technical level, and operational structure of the Service at the relevant time; provided, further, that where part of the Service’s infrastructure (including, without limitation, the database) is configured in a single availability zone, any unavoidable outage or degradation arising from a failure of or issue within that specific availability zone shall be deemed a permitted exclusion under this item;

3. planned maintenance notified in advance by the Company. The Company shall notify the Customer at least 48 hours prior to the start of such maintenance by posting on the customer dashboard or sending to the registered email address. However, maintenance requiring urgency, such as fixing security vulnerabilities (the “Emergency Maintenance”), may be performed without prior notice, and the time required for such Emergency Maintenance shall likewise be excluded from Downtime as in the case of maintenance under this item;

4. causes attributable to force majeure (natural disasters, war, conflict, terrorism, DDoS attacks, ransomware attacks, zero-day attacks, supply chain attacks, and other cyberattacks that are difficult to reasonably prevent, epidemics, orders or requests of governmental agencies, suspension of telecommunications carrier services, power outages, etc.);

5. causes attributable to the Customer’s breach of the Terms of Service;

6. causes attributable to measures such as suspension of use, termination, or invalidation of API Keys taken by the Company pursuant to the Terms of Service;

7. causes attributable to service suspension, communication blocking, function restriction, invalidation of API Keys, or other reasonable emergency measures taken by the Company upon detecting an information security threat in order to prevent the spread of damage to the Customer or third parties;

8. causes attributable to the time period notified in advance by the Company for planned changes to or discontinuation of the Service (based on Article 13, Paragraph 1 of the Terms of Service);

9. responses with HTTP status codes in the 400 range (401 / 403 / 404 / 429, etc.); and

10. causes attributable to DDoS attacks or other intentional interference against the Company’s systems.

7. Amendment of This SLA

The Company may amend the content of this SLA in response to improvements in the level of provision of the Service, changes in the technical environment, amendments to relevant laws and regulations, or other causes. The Company will notify the amended content at least 30 days prior to the effective date via the customer dashboard or email. Where a change is unfavorable to the Customer, the Customer may cancel the Service by the effective date of such change.

8. Effective Date of This SLA

This SLA takes effect from the commencement date of the production operation of the Service. Beta versions, trial versions, free plans, and the like of the Service are excluded from this SLA.

9. Related Documents

This SLA is operated as an integral part of the following documents:

• Liveness Detection API Service — Terms of Service
• Liveness Detection API Service — Privacy Policy
• Security Whitepaper

Enacted on June 3, 2026
Swallow Incubate Co., Ltd.
Tsukuba Center Institute B-5, 2-1-6 Sengen, Tsukuba, Ibaraki 305-0047, Japan
Toshikazu Ohno, Representative Director

Top