Successful Google Lyria Interactions API responses contain inline audio but no top-level id

Gemini API Documentation
1

Successful Google Lyria Interactions API responses contain inline audio but no top-level id

Summary

We made two non-streaming, non-background music-generation requests through the Gemini Interactions API, using Lyria 3.5 and Lyria 3 Pro Preview.

Both requests returned HTTP 200 responses containing apparently complete inline audio output, but neither response contained a top-level id.

The Interactions API reference says that POST /v1beta/interactions returns an Interaction resource. Its examples contain a top-level id, and the description of Interaction.id says:

Required. Output only. A unique identifier for the interaction completion.

However, the generated schema on the same page also labels the field as (optional). We would like to clarify the actual response contract, particularly when store=false is used with Lyria.

Official documentation:

Endpoint and request shape

POST https://generativelanguage.googleapis.com/v1beta/interactions
Content-Type: application/json
x-goog-api-key: [REDACTED]

Request 1:

{
  "model": "lyria-3.5",
  "input": "<non-sensitive instrumental music prompt>",
  "store": false
}

Request 2:

{
  "model": "lyria-3-pro-preview",
  "input": "<non-sensitive instrumental music prompt>",
  "store": false
}

These were synchronous requests. Each configuration was submitted exactly once, with no retry or resubmission. The client timeout was 600 seconds.

Observed responses

Lyria 3.5

  • HTTP status: 200

  • Media type: application/json

  • Response body size: approximately 5.67 MB

  • Top-level id: absent

  • model_output step count: 2

  • Audio block count: 1

  • Audio was returned as inline base64 data in steps[].content[]

Lyria 3 Pro Preview

  • HTTP status: 200

  • Media type: application/json

  • Response body size: approximately 4.10 MB

  • Top-level id: absent

  • model_output step count: 2

  • Audio block count: 1

  • Audio was returned as inline base64 data in steps[].content[]

No API key, full response payload, base64 audio, or complete prompt has been included in our logs.

We understand that multiple model_output steps are normal for Lyria because the response may contain text describing lyrics or song structure in addition to the audio block. The unexpected part is specifically the missing top-level interaction id.

Questions

  1. Is a top-level id guaranteed in a successful, non-streaming interactions.create response?

  2. Does setting store=false intentionally cause the response to omit id?

  3. If omission with store=false is expected, why is Interaction.id described as “Required. Output only” in the API reference?

  4. Is this response shape specific to Lyria 3.5 or Lyria 3 Pro Preview?

  5. If successful Lyria responses may omit id, which official field should clients use as the unique provider-side generation/request identifier?

  6. Is there a stable response header—such as a request ID, trace ID, or generation ID—that Google recommends retaining for billing reconciliation, debugging, and support cases?

  7. Should clients accept an otherwise complete response containing valid status, steps, and inline audio when the top-level id is absent?

  8. Would setting store=true guarantee that id is returned? Apart from retention and previous_interaction_id, would that change pricing, generation behavior, or any other semantics?

  9. Is this a documentation discrepancy, a preview-model limitation, or a backend response bug?

  10. If no provider-side ID is available, is it reasonable for a client to create a clearly labeled local content-addressed receipt such as:

local-google-audio-sha256-<SHA-256 of decoded audio bytes>

We would preserve the distinction explicitly:

provider_interaction_id = null
local_receipt_origin = LOCAL_AUDIO_SHA256
provider_contract_deviation = MISSING_INTERACTION_ID

The locally generated receipt would be used only for internal evidence integrity and deduplication. It would never be passed to interactions.get, cancel, or previous_interaction_id.

We mainly need confirmation of whether the missing id is expected behavior, a Lyria-specific contract, or a service defect, and what official identifier Google recommends clients retain in this situation.