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: v6). The existing v5.5 name is a compatibility alias: both values generate Suno v6 at the same token cost. Omitted-model requests keep their existing default, and historical job results are not rewritten. Model availability is published in GET /api/models and the changelog.

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.