Documentation bug: function_call output missing required id field in Interactions API example

Environment

The Interactions API documentation contains an incorrect response example for function calling.

In the documented example, the function_call object inside outputs does not include an id field. However, the actual API always returns an id for function_call outputs.

This results in a documented response schema that does not match actual API behavior and may mislead SDK authors and developers implementing strict models based on documentation.

Steps to Reproduce

Send a function-calling request using the Interactions API:

curl -X POST https://generativelanguage.googleapis.com/v1beta/interactions \
  -H "x-goog-api-key: $GEMINI_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "gemini-3-flash-preview",
    "tools": [
      {
        "type": "function",
        "name": "get_weather",
        "description": "Get the current weather in a given location",
        "parameters": {
          "type": "object",
          "properties": {
            "location": {
              "type": "string"
            }
          },
          "required": ["location"]
        }
      }
    ],
    "input": "What is the weather like in Boston, MA?"
  }'

Observe the API response.

Expected Result (per documentation)

{
  "outputs": [
    {
      "type": "function_call",
      "name": "get_weather",
      "arguments": {
        "location": "Boston, MA"
      }
    }
  ]
}

Actual Result (API response)

```

{
  "outputs": [
    {
      "type": "thought",
      "signature": "..."
    },
    {
      "type": "function_call",
      "id": "46ww9pp1",
      "name": "get_weather",
      "arguments": {
        "location": "Boston, MA"
      }
    }
  ]
}

Impact

Documentation example omits a required field (id)

Developers modeling responses from docs may produce incorrect schemas

SDK authors may incorrectly mark id as optional or absent

Confusing mismatch when comparing real responses to documentation

Hi there! Thanks for flagging this bug. We have since fixed the gap (: