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.
No reviews yetBe the first to leave a review for Tunova
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?
Report
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?
Report
Maker
@glzar67449 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.
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?
@glzar67449 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.