API Terms of Use

This document supplements the Terms of Service and covers programmatic access specifically. Where they differ, the Terms of Service is the governing text.

1. The API surface

TexAPI exposes wire formats compatible with three widely used industry standards, so that you can reuse the libraries and tools you already have:

Compatibility is not affiliation. That TexAPI accepts the same shape of data as OpenAI, Anthropic or Google does not mean TexAPI is those companies, is authorised by them, or is affiliated with them.

Format conversion. If the model you chose does not support the format you sent, TexAPI converts it. Conversion is lossy in some cases — not every field in one format has an equivalent in another. Specifically, for a converted Anthropic request your system prompt may be moved to the start of the first user message; the instruction still reaches the model, but its position changes and that can affect the result. If you need a format’s exact behaviour, choose a model that supports that format natively.

2. The model catalogue

The catalogue is dynamic — synchronised automatically from the infrastructure supplier roughly every 30 minutes. Which means: new models can appear; models can be withdrawn or switched off with no advance notice to TexAPI; and prices can change.

Always take the current list from GET /v1/models or GET /api/models, and do not hard-code a model list into your application. If you need a specific model guaranteed available, that is a separate agreement — contact support.

TexAPI does not commit that a specific model will exist in future, and does not commit that a model’s behaviour will not change. Both are outside TexAPI’s control.

3. Authentication

Use an API key of the form sk-texapi-…, sent in the Authorization: Bearer … or x-api-key: … header.

A third way is accepted but not recommended: the query parameter ?key=…, which exists for compatibility with some Gemini REST clients.

Rules about keys:

• A key belongs to your organisation, not to an individual.
• The key’s plaintext is shown once, at creation. TexAPI does not store it and cannot send it again. If you lose a key, revoke it and create a new one.
• You are responsible for everything done under your key — including where the key was exposed by you. If you suspect a key is exposed: revoke it immediately at Dashboard → API Keys and tell support.
• Sharing a key with a third party is reselling the service and is not permitted unless there is a separate written agreement.
• Creating a key requires a verified email address.

TexAPI may revoke a key without notice when: the organisation is suspended, a key is found to be exposed, or there is evidence of abuse.

4. Throughput limits

How the limits work, precisely:

• Requests per minute use a fixed 60-second window. The boundary between two windows can allow twice the traffic for a very short moment — that is a property of the mechanism, not a bug.
• Tokens per minute use a token bucket, not a fixed window. Each key has a bucket holding the plan's burst allowance (1,000,000 tokens on PAYG and Dev, 2,000,000 on Studio, 4,000,000 on Scale) and refills at the plan's tokens-per-minute rate. A single large prompt — 900,000 tokens on Dev, for example — therefore succeeds while the bucket still holds enough tokens.
• A request larger than the burst allowance is refused with HTTP 400 and a message naming the limit, not 429: waiting cannot make it fit.
• Limits are counted per API key, not per organisation.
• Tokens per minute are counted from the estimated input plus output at the moment the request arrives, not from the actual token count after the answer. Output counts for at most 4,096 tokens toward throughput.
• Exceeding a limit returns HTTP 429 with the time needed for the bucket to refill. Retry after that interval.
• A limit is a ceiling, not guaranteed capacity. See Service Levels, section 4.

You must not work around a limit by: creating several organisations, creating several accounts, spreading traffic across several keys to multiply the limit, or using proxies to distribute it.

5. Per-key spend caps

You set your own calendar-month spend cap for each API key. This is the most important damage-limiting tool you have, and TexAPI recommends using it.

1. The cap is checked before a call, against an estimated cost. Because the actual cost can exceed the estimate, the cap can be overshot slightly. It is a limiting measure, not an absolute barrier.
2. The cap applies per key, and there is no organisation-level cap. An organisation with N keys has N independent caps; the final organisation-level limit is your wallet balance.
3. Exceeding the cap returns HTTP 429 with its own error code, not a 402.

6. How tokens are counted and charged

One request has four kinds of token at four different rates:

The token counts are reported by the infrastructure supplier, not counted by TexAPI. TexAPI charges using exactly those numbers. When the infrastructure does not report them — typically when a stream is cut off mid-way — TexAPI reconstructs them by the rules published in Balance and Billing section 5, and every request has a pricing receipt stating which basis it used.

Rounding occurs first in canonical USD: to the micro-dollar ($0.000001), rounded up. The settled non-streaming JSON response retains usage.cost_usd as that canonical amount and adds usage.cost_credits, derived after settlement at the fixed rate reported by texapi.credits_per_usd (currently 100). One micro-dollar equals 0.0001 credit, so the maximum rounding increment per request is 0.0001 credit.

7. Streaming

• Enable it with stream: true, or use :streamGenerateContent with the Gemini format.
• Server-Sent Events, in the shape the format you are using specifies.
• Only models that declare streaming support accept stream: true.
• Settled cost_usd, cost_credits and credits_per_usd fields are currently added only to non-streaming JSON responses; use the request id and pricing receipt to reconcile a streamed request after settlement.

The most important thing about streaming, stated plainly: if a stream is cut off part-way after the model has generated part of an answer, the part that reached you is charged — including where the cause was a timeout on the infrastructure side, and including where you disconnected.

The reason: the model did the work and TexAPI has paid for that work. The limit that protects you: the amount charged in this case does not exceed the sum held when the request began. If no part reached you, you are not charged.

8. Timeouts, retries and failover

Failover is transparent to you: you do not know, and do not need to know, which route served a request.

Your obligation on retries: use increasing backoff. Do not retry immediately in a tight loop — that is classed as abuse under the Acceptable Use Policy, and on a timed-out request it can make you pay twice for the same work.

9. Prompt caching

On models that support it, input repeated between calls can be remembered, and from the next call is charged at roughly 10% of the input rate. The mechanism is decided by the infrastructure and the model vendor, not by TexAPI.

Consequently: TexAPI does not commit that a particular piece of input will be remembered, does not commit to how long it stays cached, and does not commit to how much you will save. The actual cache read/write token counts appear in each request’s pricing receipt.

TexAPI has no response cache of its own. The same question sent twice is sent to the infrastructure twice and charged twice.

10. The content of your requests

Repeated here because it is the most easily misunderstood point:

• TexAPI does not store the content of your requests or of the responses.
• TexAPI forwards the entire request content to the infrastructure supplier, outside Vietnam.
• TexAPI scans the text you wrote with a keyword filter running locally; when a request is blocked, an excerpt of at most 500 characters is stored as evidence.
• TexAPI does not forward your IP address and attaches no customer identifier when calling the infrastructure.

11. Changes to the API

Changes are announced through in-product announcements and by email to the account address.

12. What must not be sent through the API

A summary; the full version is in the Acceptable Use Policy.

Do not send through TexAPI: content intended for unlawful purposes; content that harms children; instructions for making weapons or dangerous substances; malware; content intended for fraud, deception or impersonating someone; content that infringes intellectual property; or another person’s personal data that you have no legal basis to process.

Do not send through TexAPI, for data-protection reasons rather than because it is forbidden: sensitive personal data, health data, biometric data, payment account details, or data you are legally obliged not to transfer abroad.

If your application shows AI output to end users, you must tell them it is AI-generated.

13. The limits of AI output

Output a model generates can be wrong, incomplete, out of date or misleading, even when stated with great confidence. That is a property of the technology, not a defect in TexAPI or in any particular model.

Your obligation: do not use output as the sole basis for a decision affecting a person’s rights, health, finances, employment, housing, education or legal status without a qualified person reviewing it first. In these domains the infrastructure supplier’s terms require human review and require the use of AI to be disclosed at the start of each session. That obligation flows down to you through the Terms of Service.

14. Technical documentation

The OpenAPI specification: GET /openapi.json, GET /openapi.yaml. The specification is technical documentation, not a contractual commitment; where they differ, this document and the Terms of Service are the governing texts.