AI Music Generation APIs: The License Is the Product

A WAV file can be technically perfect and still be unusable in your product.

The problem is not the codec. It is the contract.

If you are building with a music-generation API, you need to know whether you can put the resulting track into a paid product, whether your customers can use it, and whether they can monetize or redistribute what they generate. Being able to call the API answers none of those questions. Neither does a model page saying “royalty-free.”

There is another distinction worth making early: permission to use a track commercially is not the same thing as owning copyright in it.

Short answer: You can commercially use music from an AI music API only when the agreements governing that generation permit the use you have in mind. Check the underlying model/API agreement, the platform through which you access it, any plan- or account-specific terms, and the rights your application needs to pass to its users.

This is a product-diligence framework for developers, not a substitute for legal review of the agreements that apply to your company.

Four questions that look similar but are not

“Can we use this music?” is usually four questions collapsed into one.

Question	What it actually decides
Can I access the API?	Whether your account and access path can generate the track
Can I use the output commercially?	Whether the applicable agreement permits your intended commercial use
Who owns or licenses the output?	What contractual rights the provider gives you or retains
Is the output copyrightable?	Whether applicable law recognizes some or all of the resulting work as protectable

Those answers do not have to line up.

A provider can permit commercial use without promising copyright protection. It can assign whatever rights it has in an output while warning that similar outputs may go to other users. A model can also remain documented and technically live while access changes for certain plans or accounts.

Copyright law sits outside those contracts. In the United States, the U.S. Copyright Office says generative-AI output can receive protection where a human determines sufficient expressive elements. Human-authored material that remains perceptible in the result, creative arrangement, and creative modification can matter. Prompts alone generally do not provide enough control under its current analysis.

So “the API says I own the output” and “the law gives me copyright in the whole track” are different claims.

Follow the license chain, not the model landing page

With a direct integration, there may be one obvious agreement between your company and the model provider.

Put another API platform in the middle and there is more to inspect:

Underlying model/API agreement
        ↓
API platform or intermediary terms
        ↓
Account, plan, order form or written amendment
        ↓
Your application
        ↓
Your end user's intended use

A commercial-use claim is only useful if it survives the parts of that chain that apply to your product.

Start with the underlying model/API agreement

For a customer-facing product, look for language covering application integration, end-user access, commercial use, output ownership, input obligations, resale or redistribution restrictions, and termination.

Mureka is unusually explicit on several of these points.

Its API Service Agreement permits customers to integrate the service into their own applications, products, websites, or services and make those applications available to end users.

As between Mureka and the API customer, and to the extent permitted by applicable law, the agreement says the customer owns the output and assigns to the customer whatever right, title, and interest Mureka has in it. The customer, meanwhile, is responsible for holding the necessary rights, licenses, and permissions in the inputs it submits. The agreement also warns that outputs may not be unique.

Mureka's API FAQ separately says content generated through paid API calls carries commercial authorization for uses including commercial products, platform distribution, advertising, and video.

That is much more useful to a developer than a generic “royalty-free” badge. It tells you what the agreement is trying to permit and where responsibility still sits with you.

Then read the platform terms through which you call it

A permissive upstream agreement does not automatically erase restrictions in a separate agreement between you and an intermediary.

Current Mureka product surfaces on each::labs contain commercial-use language. The Generate Instrumental page, for example, describes its output as commercially licensed and says full commercial licensing is included.

The current each::labs Terms of Service, Version 2.0 effective September 3, 2026, no longer impose the blanket non-commercial restriction on AI Music Features that appeared in the previous version. Instead, they say customers own Outputs to the extent permitted by law and subject to identified Provider terms, which may restrict use of an Output.

That makes the diligence question more specific: identify which provider usage policy or output license governs the route you are using, and make sure it permits the commercial use your product promises. A model page can be evidence of the intended product permission, but it should not be treated as a substitute for the governing provider terms or any account-specific agreement.

Check your account, plan, and negotiated terms

Public website terms are not always the whole agreement.

The each::labs Terms themselves define the agreement to include Supplemental Terms, notices, policies, Order Forms, and Master Services Agreements. Custom plans may also be governed by a Service Agreement or Order Form.

For production teams, that has a practical consequence:

Record the agreement you are actually relying on, not just the provider name.

If your commercial rights come from a specific paid tier, order form, or written authorization, that context belongs with the generated asset.

Check what your end user needs to do

Suppose your company generates a soundtrack for its own product demo.

Now suppose your SaaS product lets customers generate tracks, download them, put them in paid games, and monetize videos containing them.

Those products do not need the same rights.

The useful question is not just:

Can we use this commercially?

It is:

Can our product generate this for customers, and can those customers use the output in the way we promise?

If your product promises more than your agreement gives you, the generation endpoint can work exactly as documented while the feature remains unshippable.

Turn “commercial use” into actual product requirements

A binary commercial_use = true field hides too much.

Translate the license into the actions your product needs to support.

Product behavior	What to verify
Put generated music in your paid application	Commercial-use permission
Use it in advertising or branded media	Advertising/media-use rights
Generate tracks for customers	Customer-facing application rights
Let users download tracks	Distribution rights
Let users monetize tracks	Downstream commercial rights
Deliver output to clients or white-label partners	Redistribution/sublicensing rules
Sell the generated track itself	Standalone resale restrictions
Keep using old generations after cancellation	What accrued output rights survive termination

This is also why royalty-free is not the same as commercially unrestricted.

Royalty-free describes part of a licensing or payment arrangement. On its own, it tells you nothing conclusive about output ownership, sublicensing, copyright status, or permission for every commercial use.

Mureka and MiniMax: what the current terms actually establish

Terms and product documentation checked: September 4, 2026.

This is not a quality ranking. The point is to separate what the current sources actually establish from what still needs clarification.

Access path	What is established	What remains unresolved
Mureka paid API, direct	Paid calls have explicit commercial authorization; the API Agreement permits customer applications and end users and assigns Mureka's interest in output to the customer	Copyrightability is a separate legal question; the customer remains responsible for input rights
Mureka through each::labs	The current mureka-generate-song wrapper is live; its example uses Mureka 8 and returns MP3, WAV, and FLAC URLs	Current each::labs Terms defer Output restrictions to identified Provider terms; verify the provider license or usage policy identified for the route and account
MiniMax Open Platform	Current Open Platform Terms say the customer retains ownership rights in generated content to the extent permitted by applicable law	We did not find music-API commercial authorization as explicit as Mureka's paid-API FAQ
MiniMax Music through each::labs	The current wrapper is live as minimax-music-03, version 0.0.1; its example requests URL-delivered MP3 at 256 kbps/44.1 kHz	The current each::labs Terms do not add a blanket music restriction, but the provider terms still need to establish the commercial rights required for this route

Mureka

On each::labs, the current Mureka V8 generation example uses:

model slug: mureka-generate-song
each::labs version: 0.0.1
underlying selector: mureka-8

The request passes n, lyrics, and prompt. The current example output contains MP3, WAV, and FLAC URLs.

The direct Mureka API has continued to move and now documents newer models alongside Mureka 8. That does not invalidate the each::labs V8 wrapper. It does mean “Mureka” and “Mureka V8” should not be used as if they describe the provider's entire current catalog.

For this article, the more important difference is contractual. Mureka's direct paid API terms are comparatively explicit. Through each::labs, the current Terms defer Output restrictions to identified Provider terms, so the remaining diligence is to confirm which provider license applies to the route and whether it covers the product's intended commercial use.

MiniMax Music

The current each::labs Music 3.0 wrapper uses:

model slug: minimax-music-03
version: 0.0.1

Its example accepts lyrics, prompt, output_format, audio_settings, and is_instrumental, and requests an MP3 URL at 256 kbps and 44.1 kHz.

MiniMax's Open Platform Terms add an important contractual detail: as between the customer and MiniMax, the customer retains ownership rights in generated content to the extent permitted by applicable law. They also put responsibility for customer-supplied content and end-user use on the customer.

Access is less tidy.

MiniMax's current subscription surface says Music-series models stopped being available through Token Plan starting August 20, 2026. At the same time, currently indexed API documentation still presents the Music Generation endpoint, while a MiniMax-hosted community report reproduces an HTTP 410 service response saying the Music API is no longer available to new users while existing paying customers may continue.

Taken together, those sources do not describe one clean entitlement policy.

For a production integration, the safe conclusion is narrower: MiniMax changed music access on August 20, and its current official surfaces are not fully consistent about who retains direct API access. Verify the entitlement of the account you intend to deploy.

Canberk Sinangil, Co-founder & CTO: “A catalog gets you into development. Reliability gets you into production.”

Catalog presence tells you an integration path exists. It does not prove that a newly provisioned account has a stable production entitlement.

Commercial permission is not copyright protection

Suppose an API agreement says you own its output.

That tells you something about your contractual relationship with the provider. It does not decide whether copyright law protects the whole generated work.

The U.S. Copyright Office currently treats human authorship as the key issue. Purely AI-generated material is not protected under its analysis; human-authored expression that remains perceptible in the result, sufficiently creative selection or arrangement, and creative modification can be protected. Prompts alone generally do not supply sufficient control with today's generally available technology.

That leaves three separate claims:

• the contract permits commercial use;
• the provider gives or assigns contractual rights in the output;
• applicable copyright law protects some or all of the work.

Do not compress them into one green checkmark.

The U.S. position is also not a universal rule. Copyrightability can differ by jurisdiction.

Your input can create a rights problem even when the output license is clear

Output permission does not cure an input you were never entitled to provide.

Mureka's API agreement requires customers to hold the necessary rights, licenses, and permissions for inputs submitted to the service. MiniMax's Open Platform Terms likewise make the customer responsible for the legality and rights status of supplied content.

That matters when the person providing the input is your end user.

Original lyrics, copied lyrics from a released song, a reference track the user composed, and someone else's recording may all fit into an API field. They do not create the same rights position.

If your product accepts user-supplied music, lyrics, or reference media, your own terms and upload flow need to reflect the obligations you inherit from the model agreement.

License suitability and API availability are separate production risks

A model comparison usually starts with price, latency, and quality.

For music, add two questions:

Can this account access it?

Can we ship what comes back?

Commercial terms	API available to your account?	Product decision
Suitable	Yes	Candidate
Suitable	No	Cannot form the intended integration
Unclear	Yes	Diligence required before launch
Restrictive	Yes	Technically usable, commercially unsuitable

MiniMax makes the access problem visible. The license chain makes the second problem visible: a technically callable route still needs provider terms that cover the commercial rights your product promises.

Neither problem is fixed by a better demo.

Save license provenance with the generated asset

For a commercially important generation, this is not enough:

model = mureka-8

You want enough information to reconstruct both the generation and the rights decision:

generation_id
provider
model
model_version
generated_at
account_or_plan
application_or_user_id
input_provenance
output_storage_reference
terms_or_agreement_version
commercial_rights_status

This gives you traceability. It does not create legal protection.

Canberk Sinangil, Co-founder & CTO: “Coming from enterprise and maritime software, the most striking thing about AI APIs is that changing critical behaviour without telling anyone is considered normal.”

That is why the agreement context belongs beside the model version for a commercially important asset: later, you may need to reconstruct what was true when the asset was generated.

Mureka's current agreement, for example, says termination or expiration does not affect rights or obligations already accrued and that provisions intended by their nature to survive continue according to their terms.

That is useful evidence for Mureka. It is not a reason to assume every provider treats termination the same way.

Delivery format matters, but it does not change the license

Once the rights question is settled, the API call is fairly ordinary.

Current each::api documentation uses the https://api.eachlabs.ai base URL, Bearer authentication, and asynchronous predictions through POST /v1/prediction. The dependable direct-prediction completion path in this example is polling GET /v1/prediction/{id}. Current first-party webhook pages are internally inconsistent about direct-prediction webhook availability, while workflow webhooks are explicitly supported.

A current Mureka V8 request looks like this:

curl -X POST https://api.eachlabs.ai/v1/prediction \
  -H "Authorization: Bearer $EACHLABS_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "mureka-generate-song",
    "input": {
      "model": "mureka-8",
      "n": 1,
      "lyrics": "[Verse]\nCity lights fade into morning\n[Chorus]\nKeep the signal running",
      "prompt": "Warm electronic pop, restrained drums, bright synths, clear vocals"
    }
  }'

The slug and input fields match the current model card. The top-level version field is omitted because the current machine-readable prediction contract marks it deprecated and ignored.

That wrapper currently demonstrates downloadable MP3, WAV, and FLAC output URLs. MiniMax Music 3.0's each::labs example requests an MP3 URL with explicit bitrate and sample-rate settings.

Those formats affect what you can do in the media pipeline. They do not alter the commercial rights attached to the work.

A pre-launch license checklist for AI music APIs

Before launch, answer these questions in writing:

1. Can the production account actually access the API?
2. Which agreements govern the generation?
3. Does the agreement cover the exact commercial use you intend?
4. Can you expose the service in a customer-facing application?
5. Can customers download generated tracks?
6. Can they monetize or redistribute them?
7. What rights does the provider give or assign in the output?
8. What rights must you and your users hold in the inputs?
9. Are advertising, client delivery, sublicensing, or standalone resale restricted separately?
10. What happens to rights already accrued if the service or agreement ends?
11. Which version or date of the terms did you review?
12. What file or output reference does the API actually deliver?
13. Is any part of the license chain unclear enough to require written confirmation?

The last question is better than forcing uncertainty into a yes/no field.

If two relevant agreements contradict one another, “commercial use: unresolved” is a valid production state.

FAQ

Can I use AI-generated music commercially?

Sometimes. A working generation endpoint does not grant commercial rights on its own. Check the underlying provider agreement, the terms of the platform through which you access it, account- or plan-specific agreements, and whether those terms cover what your application and its users will actually do.

Does a commercial license mean I own the copyright?

No. Commercial-use permission, contractual output rights, and statutory copyright protection are separate questions.

Can users of my app monetize the music they generate?

Only if the agreements governing your integration support that downstream use. Permission for your company to use an output commercially does not automatically establish permission for customers to download, redistribute, sublicense, or monetize it.

Is royalty-free the same as copyright-free?

No. Royalty-free describes a licensing or payment arrangement. It does not tell you by itself whether a work has copyright protection, who owns contractual rights in it, or whether every commercial use is permitted.

What should I save when using AI-generated music in production?

Keep enough provenance to reconstruct the generation and the rights decision: provider, model and version, generation date, account or plan, input provenance, output reference, and the agreement or terms version you relied on. If permission depends on written authorization, retain that authorization with the same record.