Versioning & deprecation

The short version: we don’t break your integration without warning, and if a render ever fails, you don’t pay for it.

The API is unversioned and stable

There’s no /v1/ to pin and no version header to send. The request and response shapes for /api/generate, /api/custom_generate, and the job/webhook payloads are treated as a stable contract. We add fields; we don’t quietly remove or rename them.

The model is a per-request choice, not a version

You pick the Suno model per request with the model parameter (today: v5.5). New models land as new selectable values — they don’t change the behaviour of a request that named an older one. If a model is ever retired by Suno upstream, that’s in the changelog with as much notice as we get.

Breaking changes get ≥30 days notice

If we ever need to make a genuinely breaking change to the request/response shape, you get at least 30 days notice before it takes effect — posted to the changelog and emailed to every account with an active key. No silent breakage, no “we changed the response last Tuesday.”

Auto-refund is the backstop

Underneath the policy is the guarantee the whole product is built on: you’re billed only on a successful render. When Suno ships a breaking change of its own — it happens — jobs queue and retry, and anything that still fails refunds itself. Your worst case is a delay, not a charge for nothing. See why Tunova for how that works.

This policy describes intent and is not a contractual SLA. For the binding terms, see the Terms.