Service Levels

1. Why not — three reasons, stated plainly

This is a deliberate choice, not an oversight. All three reasons below can be verified from the system itself.

First, TexAPI depends on a single infrastructure supplier that TexAPI does not control, and there is no SLA from them that TexAPI could pass on to you. Committing to 99.9% when your own supply chain commits to nothing is a commitment you have no basis to keep.

Second, the current uptime measurement is not reliable enough to base compensation on. The system does record uptime, but the measurement is the system measuring itself. The logical consequence: when the server stops entirely, nothing records the incident — there is no independent external prober. On top of that, the number of minutes of downtime is an estimate: each failed check is counted as 5 minutes of downtime. Using an estimate, produced by the seller, to calculate compensation would require that number to be accurate — and it is not yet.

Third, the infrastructure is not settled. The project has not fixed its infrastructure supplier, has no standby deployment configuration, and has no automated backup whose restorability has been verified.

Committing to a number in those circumstances would be a false statement. This document says no, and says why — which is more honest and, if there is ever a dispute, less risky for both sides.

2. What TexAPI commits to instead

No SLA does not mean no obligations. Consumer-protection law requires a seller to provide the service as described and does not allow that responsibility to be excluded by a blanket clause. So TexAPI commits to what follows, and these commitments are binding.

2.1 Not charging for what could not be done

A request that fails because of a fault at TexAPI or at the infrastructure is not charged. Every error path in the system releases the hold and writes the record with a cost of zero.

A known exception, disclosed honestly: when a streaming request is cut off mid-stream after the model has already produced part of an answer, the part that reached you is charged, even where the cause of the disconnection was a timeout on the infrastructure side. See Balance and Billing section 5 for the mechanism, the ceiling that applies, and how to ask for a review.

2.2 Per-request transparency

Every request has a pricing receipt stored with its record, showing the tokens counted, the rate in force, any discount and the total. You can see it under Dashboard → Usage Logs. No need to ask, no need to wait.

Per-request detail is kept 90 days; daily aggregates are kept longer. If you need it longer for your own reconciliation, export it within that window.

2.3 Publishing status and incidents

TexAPI publishes the status of each component and any incident being worked on. An incident is recorded with its severity, its status, the components affected and when it started. The specific commitments on timing:

For a critical incident lasting more than 4 hours, TexAPI publishes a post-incident report within 5 working days, covering the cause, the scope of the effect, and what is being done to prevent a repeat.

2.4 Notice before planned maintenance

2.5 Refunding your balance when the service can no longer be provided

If TexAPI stops providing the service, or the service is continuously unavailable for more than 72 hours, you are entitled to ask for your entire unspent balance paid with real money back. This commitment is binding and does not depend on an SLA. See the Refund Policy, section 6.

3. Figures for reference, not a commitment

When the status page is running, it shows the measured availability of the last 30 days. That number is information for reference, not a commitment, and it creates no right to compensation.

Four limits of the measurement, stated so you do not read more into the number than is there:

1. The measurement is the system measuring itself, with no independent prober. A total outage may not be recorded at all.
2. Downtime minutes are estimated from the check interval, not measured directly.
3. The measurement checks whether the endpoint responds, not the quality of the model’s answers.
4. The measurement does not reflect an outage at the infrastructure if failover hid it — which makes the number higher than your real experience in some situations.

4. Throughput limits — not a capacity commitment

Per-plan limits are set out in the API Terms, section 4. A distinction worth making:

• A limit is a ceiling TexAPI applies to you, not capacity TexAPI commits to give you.
• When the infrastructure is overloaded, actual throughput can be lower than your plan’s limit without that being a breach.
• If you need guaranteed capacity, contact support — that is a separate agreement, not a general term.

5. What TexAPI would need before offering a real SLA

Written down so you can see what is missing. All four are required:

Until all four are met, this document’s opening statement stands.

6. Complaints

If you believe the service did not meet what was described and that this caused you loss: email support@texapi.dev. TexAPI replies within 5 working days and handles it under the process in the Terms of Service, section 18. TexAPI’s not offering an SLA does not remove your right to complain under consumer-protection law.