API uptime SLA: what it promises, and Sume's terms

An API uptime SLA is a contract promise: the provider commits to a monthly availability percentage and owes you service credits if it misses it. Sume's public Terms make no uptime commitment. They provide the services "as is" and "as available", and say they may be unavailable, delayed, rate limited or degraded.

The Sume wording is quoted from its Terms of Service (last updated August 10, 2026). The retry advice comes from Errors and credits and Generation admission, all read 2026-09-29. This is what the pages say, not legal advice.

What does an uptime SLA actually promise?

Four things, and the percentage is only one of them. An SLA defines how uptime is measured, the percentage per month, what is excluded (for example planned maintenance), and the remedy, such as a credit against a future bill. It does not make outages impossible. It prices them.

The percentage turns into a monthly downtime budget:

Does Sume have an API uptime SLA?

Not in its public Terms. What they say instead:

• The Services may be unavailable, delayed, rate limited, degraded, or changed from time to time.
• Agent runs and generation workflows depend on infrastructure and third-party services outside Sume's control.
• Sume does not guarantee that every request will be accepted, completed, or produce a usable result.
• The Services are provided "as is" and "as available", and Sume does not guarantee uninterrupted availability, error-free operation or provider availability.

Can an enterprise contract include one?

Sume's Terms say Enterprise services may be governed by a signed Order Form, and that where its commercial terms conflict with the Terms, the signed agreement controls. No public page says what availability terms an Order Form offers, so ask in writing. AI video generator for enterprise covers the rest of that process.

How do I build on an API without an SLA?

Assume individual requests will sometimes be refused, and make every refusal safe to retry. For Sume's generation API:

• Send an Idempotency-Key on every create. On a Format call, same key and same body return the original receipt: no second run, no second charge.
• On 429, back off and use retry-after when present. 429 queue_full means your workspace's concurrency plus queue is full, not that the service is down.
• On 503 provider_capacity_exceeded, retry later. The docs say to reuse the same key, but in current code a same-key retry after queue_full or provider_capacity_exceeded replays the refusal. Use a new key once the cause clears.
• On provider_not_configured, don't retry aggressively.
• Keep the Sume request id from the response body or headers and include it when you report an issue.

What does a 429 or 503 tell me about uptime?

A 429 is about your limits, a 503 is about Sume's side. Neither is an outage by itself, and a submission accepted as queued is working as designed: Sume accepts valid jobs as queued while queue capacity remains. 429 vs 503: rate limit or server overload? explains the difference in detail.