Five Music Engines, One Adapter

A prospective client recently asked me to scope adding AI music generation to their product. Two generators, user picks a style, song comes out. On the surface it is one POST request to a provider and a play button. I ended up mapping most of the market to answer their questions, and the landscape turned out to be interesting enough that I built the integration five times over, against five different engines, to show what it really takes. The result is a small working proof of concept: one adapter layer, five providers, a CLI, and a dockerized studio UI where switching engines is a dropdown.

Here is what that exercise teaches.

The API call is the easy part

Music generation is not request and response. A track takes 30 seconds to a few minutes to render, so the real engineering is everything around the call: a job model, webhooks or polling with backoff, retries that tolerate a flaky status endpoint, timeouts that fail loudly, and storage. Especially storage. Provider URLs expire: one deletes files after 14 days, another after a week, a third kills the link after 24 hours. If your product stores the provider's URL instead of the audio, your users' library quietly rots. The first rule of building on these APIs is to download the file the moment a job succeeds and put it in storage you own.

Five providers, five different shapes

The five engines I integrated, and the shape each one turned out to have:

• Suno, resold. Suno has no public first-party API, so the market's favorite sound arrives through unofficial resellers. The one I integrated requires a callback URL even if you poll, answers polls in camelCase and webhooks in snake_case for the same data, and returns two track variations per request.
• MiniMax. Officially supported and, surprisingly, synchronous: the HTTP response of the create call already contains the finished track. Simplest possible integration, and the returned link dies within 24 hours.
• ACE-Step. An Apache licensed open-weights model served through a queue API. The auth scheme word is literally "Key" instead of "Bearer", and there is no prompt field: it wants style tags and lyrics, where "[inst]" means instrumental.
• Treblo. A first-party API whose status endpoint returns a bare JSON string, whose default output format is ogg, and which requires visible attribution in any user-facing product. It also rebranded from Sonauto and moved endpoints mid-way through my research, which felt like the universe underlining the point of this article.
• Eleven Music. Synchronous like MiniMax, but the response body is the raw audio bytes. No job id, no URL, nothing to poll. Catch the bytes or lose them.

Five providers, five auth schemes, three async models, two response casings, and one rebrand in a single week. None of this belongs anywhere near your product code.

The adapter is the product decision

The fix is old and boring and works: put every engine behind one contract. Mine is two functions, create a job and refresh a job, both returning the same normalized shape. The orchestration, the storage, the UI, and the billing never learn which engine ran. Adding a provider is one file; swapping providers is a config string; and when a reseller dies overnight, rebrands, or an official API finally appears, you reconfigure instead of rewriting.

That last sentence is not hypothetical. Unofficial wrappers sit on legally contested ground while the labels' lawsuits against the model makers run their course, and the wrapper you integrate today may not exist under the same name next quarter. I watched it happen mid-project. The adapter is not an architecture flourish, it is the insurance policy.

What the lawyers will ask

The questions that actually decide which engine you can use have nothing to do with sound quality:

• Commercial rights. One provider assigns you ownership of outputs in its terms. Another grants commercial use only through marketing copy, with no contractual license behind it. A third is silent for API customers entirely. These are three very different risk positions that all look identical in a feature demo.
• Watermarks. One engine reserves the right to watermark at its discretion. Another offers opt-in content credentials. The open-weights model has none. If your client's brand cannot carry a watermark, this is a filter, not a preference.
• Attribution. One engine requires a visible "Powered by" credit in your UI. That is a product design constraint hiding inside a terms page.
• Indemnity. None of the five will defend you if a generated track lands too close to someone's song. That risk stays with you, which in practice means your terms of service pass it to your users. Worth a lawyer's hour before launch, not after.

I keep all of this in a comparison table in the repo, next to the code, because the table changes which adapter you enable far more often than any benchmark does.

Hear it

One prompt, straight through the adapter: a song about a husband and wife in Banff, walking the shore of Lake Louise, snow on the peaks, falling in love all over again. What follows is exactly what came back, one generation, no picking the best of several.

Treblo (Melodia v3), 2 minutes 50:

A footnote from these two generations: the prompt asked for warm male vocals, and Treblo sang take one as a woman. Take two, below, moved the male voice to the very first words of the prompt, and a woman sang that one too. This engine exposes no vocal gender parameter (Suno via kie.ai has a literal vocalGender flag), which turns a one-word requirement into a lottery. That is a lesson worth the credits: when a control matters to your product, pick an engine that exposes it as a parameter, not a prompt hint.

This section grows as I run the same prompt through the other engines; their takes will sit here side by side. Every output is AI generated, and the rights over it are governed by the provider's terms.

See it running

The build behind this article is real and running: a zero-dependency Node CLI edition of the adapter, and a dockerized FastAPI plus React studio where the engines and their models are dropdowns, a mock engine demos the entire pipeline with no API keys, and every finished track lands in local storage the moment it succeeds, because by now you know why. I keep it as a private working blueprint, and the point of a blueprint is that the next one, yours, gets built much faster.

If you are scoping music generation, or any generative feature that runs on someone else's model, the shape of the answer is the same: the provider is a plugin, the contract is yours, and the boring parts, the queue, the storage, the terms, are where the project actually lives. That is also exactly the kind of build I help teams ship.