Limits, capacity and metering

Request rate

Per API key: 600 requests/minute and 25 requests/second for ordinary requests, and a separate 600 session opens/minute for realtime sessions. Exceeding any of them returns 429 with Retry-After.

Opening a realtime session is budgeted separately on purpose. A burst rule exists to stop a client hammering an endpoint; opening fifty streams at once is not hammering anything, it is the product working. The ceiling on simultaneous sessions is the concurrency limit below, which is the right control for that.

Frames inside an open session are not counted as requests.

Concurrency

The service admits a bounded number of simultaneous requests and refuses the rest with 429 and Retry-After, rather than queueing them. A queue would convert a capacity problem into a latency problem for the requests that did get in.

Two different things can refuse you, and they need different responses, so they have different error codes:

The first is a commercial conversation, the second is a retry.

{"error":{"code":"tts.plan_limit_reached",
          "message":"This plan's limit for simultaneous requests is reached. A higher limit is available on request.",
          "detail":"Limit 2 simultaneous requests. Contact your account manager to raise the concurrent-request limit.",
          "request_id":"req_…"}}

On a WebSocket the handshake has no body, so the same information arrives as an X-Suisse-Capacity-Reason header on the 429 before the socket closes.

Your own ceiling is in your_plan in GET /capabilities:

"your_plan": { "concurrent_requests": 2, "source": "plan",
               "upgrade": "Contact your account manager to raise the concurrent-request limit." }

source is plan when a limit has been agreed for your account, and service_default when you are on the standard allowance.

GET /capabilities reports the current ceilings under capacity. These are what the deployment enforces today, not a contractual entitlement. If you need a higher figure, it has to be agreed and provisioned, not discovered by pushing until you see 429s. Back off properly on 429 rather than retrying tightly: the limit is there to protect the latency of the sessions that did get in.

Metering

Both directions are metered in audio seconds, measured to the second, with no minimum per request: the length of the recording you send for recognition, or of the speech we produce. Requests that fail are not billed, and sandbox traffic never is.

GET /v1/usage returns what this key has consumed, read from the billing ledger rather than from the rate limiter’s expiring counters: the same numbers an invoice is built from, in the same unit.

curl -H "X-API-Key: $SUISSE_SPEECH_KEY" \
  'https://api.suisse-speech.ch/v1/usage?from=2026-09-01&granularity=day'

It reports the window total, a breakdown by direction and mode, an optional daily series, and any allowance in force.

Free minutes and prepaid credit

• Free minutes. A new account’s 60 free minutes are an evaluation allowance: a hard cap that returns 429 *.entitlement_exhausted when it is spent.
• Prepaid credit. An account with credit sees an entry of kind credit: a balance stated in credits that all services draw on, each at its own rate per hour of audio (listed in the console under Credit & alerts). The entry reports granted_credits, used_credits, remaining_credits and used_percent. When the credit is used up, new requests are refused with 429 *.entitlement_exhausted until it is topped up; requests in progress are completed. Every user of the account is notified by e-mail when 80 % and when 95 % of the credit is used.

A daily budget also applies per key; usage_today in GET /capabilities shows where you stand. Exhausting it returns 429 with a rate_limited code.

Latency

Expected figures on a warm service:

Measured on 3 September 2026 on production. Realtime Swiss German dialect synthesis starts slightly later, typically 0.6 to 0.7 s to first audio. Measure on your own traffic before you commit to a latency budget.