Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.ttapi.io/llms.txt

Use this file to discover all available pages before exploring further.

​
Google Lyria 3 / Producer API

The naming here can be confusing the first time through. People usually search for Google Lyria 3 API, but on TTAPI the actual endpoint family lives under Producer. This page is here to make that translation explicit so you do not have to infer it from the sidebar. If your goal is “generate music with Google Lyria 3 on TTAPI,” the practical starting point is usually Producer Music plus Producer Fetch. Everything else in the Producer family exists to support the workflows that happen before or after that core path.

​
Get Started

​
Key Features

​
Prompt-first and lyrics-first workflows

Some teams start from a sound idea. Others start from lyrics, chorus structure, or a rough song concept. The Producer family supports both patterns. Use Producer Music when you are ready to generate a track. Use Producer Lyrics first when the writing step needs its own pass before audio generation begins.

​
Async job flow that is simple to reason about

Producer generation is asynchronous. Submit the job, keep the returned jobId, and use Producer Fetch as the source of truth for job state and result retrieval. In practice, this is the endpoint your backend will end up calling the most once traffic becomes real.

​
Post-processing without leaving the product family

After the first result is ready, you can stay in the same Producer surface for common next steps: Extend to continue a track, Cover or Variation to reinterpret it, Replace to change sections, and Stems to split the output for editing or remix use cases.

​
Model routing when you specifically want Google Lyria 3

The broader Producer family supports more than one model line. If you want Google Lyria 3 specifically, choose supported mv values such as Lyria 3 preview or Lyria 3 Pro where the endpoint allows them. That is the detail that matters when you are mapping product requirements to a real request body.

​
Product Mapping

On TTAPI, Google Lyria 3 workflows map to the Producer API family: That mapping is the main reason this page exists. It gives search traffic and implementation traffic the same landing point.

​
Authentication And Base URL

All Producer requests use the TTAPI music gateway.
  • Base URL: https://api.ttapi.io
  • Header: TT-API-KEY: YOUR_API_KEY
  • Content-Type: application/json
For most apps, the cleanest path is:
  1. Decide whether the workflow is lyric-first or prompt-first.
  2. If needed, generate lyrics through Producer Lyrics.
  3. Submit music creation through POST /producer/v1/music.
  4. Store the returned jobId immediately.
  5. Poll GET /producer/v1/fetch?jobId=....
  6. Once the result is stable, branch into Extend, Cover, Variation, or Stems depending on the product.
One subtle but useful point from the endpoint docs: the music endpoint is designed around one generated song per request. That keeps job handling simpler, but it also means teams usually build batching above the API instead of expecting one call to return a large set of tracks.

​
Example Request

curl --request POST 'https://api.ttapi.io/producer/v1/music' \
  --header 'Content-Type: application/json' \
  --header 'TT-API-KEY: YOUR_TTAPI_KEY' \
  --data-raw '{
    "sound_prompt": "warm indie pop with shimmering guitars and soft female vocals",
    "title": "City Lights",
    "mv": "Lyria 3 Pro",
    "instrumental": false
  }'

​
Example Fetch

curl --request GET 'https://api.ttapi.io/producer/v1/fetch?jobId=xxxxxxxxxxxxxxxx' \
  --header 'TT-API-KEY: YOUR_TTAPI_KEY'
When Fetch succeeds, the response can include action, progress, mv, and a musics array with fields such as musicId, title, lyrics, audioUrl, and videoUrl. In most production systems, this is the payload that gets persisted and fan-outs to downstream services.

​
Use Cases

  • Music products that start with a text prompt, generate a full track, then extend or restyle the strongest result
  • Lyric-focused tools that want a separate writing step before they commit quota to full audio generation
  • Brand, jingle, or creator workflows that need stems after generation so the result can be edited outside TTAPI
  • Backend pipelines that need stable async polling and explicit job tracking rather than one long blocking request
  • Teams experimenting with Google Lyria 3 routing while keeping the rest of the workflow under one Producer API surface

​
Core Endpoints

Use caseBest page
Generate a new songProducer Music API
Generate or refine lyrics firstProducer Lyrics API
Continue a completed trackProducer Extend API
Reinterpret the trackProducer Cover API
Create alternate versionsProducer Variation API
Rewrite a sectionProducer Replace API
Split the result into stemsProducer Stems API
Upload source materialProducer Upload API
Poll job status and retrieve outputsProducer Fetch API
Generate downstream video outputsProducer Generate Video API

​
FAQ

​
Is Google Lyria 3 the same as Producer on TTAPI?

Google Lyria 3 capabilities are exposed through the Producer API on TTAPI. The product name users search for is Google Lyria 3, but the endpoint family you integrate against is Producer.

​
Should I start with Lyrics or Music?

Start with Producer Lyrics when the writing step needs to happen first. Start with Producer Music when you already know the song direction and want to generate audio immediately.

​
Which endpoint handles async status and final outputs?

Use Producer Fetch. It is the endpoint that ties the workflow together after submission.

​
Which model values map to Google Lyria 3?

If you specifically want Google Lyria 3 routing, use supported mv values such as Lyria 3 preview or Lyria 3 Pro where the endpoint supports them.

​
Some people search for “Google Lyrics 3 API.” Is that the same thing?

The correct product name is Google Lyria 3. On TTAPI, those requests still belong to the Producer API documentation family.
Last modified on April 20, 2026