Tunova - The Suno music API that only bills you on success

byβ€’
Tunova is a hosted API for generating music with Suno β€” built for developers and AI agents. It's billed on success: if a generation fails, you're auto-refunded, so you only pay for tracks you actually get. Works as an MCP server inside Claude Code, Cursor, Windsurf and n8n, plus Python/Node SDKs and plain REST. Free tokens on signup, no card required.

Add a comment

Replies

Best
Maker
πŸ“Œ
Hey Product Hunt πŸ‘‹ I built Tunova because generating Suno music from code was surprisingly painful: flaky endpoints, paying for failed jobs, and nothing that plugs into the AI tools developers actually use. Tunova fixes three things: 🎯 Bill-on-success β€” every generation is auto-refunded if it fails. You pay for tracks you get, not attempts. Your effective cost = list price Γ· success rate, and we publish the methodology to compute it. πŸ€– Agent-native β€” Tunova is an MCP server, so you can generate music straight from Claude Code, Cursor, Windsurf or n8n with one config. Tools: generate_song / wait_for_song / check_song. Also Python & Node SDKs and a clean REST API. 🧾 Trust-first DX β€” request IDs on every job, an honest error taxonomy, and a status/reliability guide instead of marketing fluff. Free tokens on signup, no card. I'd love your feedback β€” what would make this a no-brainer for your stack?

How does the auto-refund actually work if a generation hits Suno's rate limits or returns a partial clip, do you guys flag those as failed automatically or is it up to the caller to decide?

Maker

Β Great question β€” it's automatic and server-side, never up to the caller.

Two kinds of "rate limit": if you hit OUR per-key limit you get a 429 up front β€” no generation runs, so nothing is ever reserved or charged. If a render fails downstream (a Suno hiccup, a transient error), the job settles as failed and the held tokens are auto-refunded to your ledger as their own line, tagged with the request id β€” no ticket, no flag needed on your side.

Partial clips are the nuance: a request usually returns 2 clips. If at least one renders cleanly you get the good one(s) and it's billed as a success (you got a track). If all clips error, we auto-retry the generation a couple of times first, and only if it still produces nothing do we mark it failed β†’ a full refund. So "you only pay for tracks you actually get" holds right down to the partial-clip case.