Dialogflow Messenger missing toolCall data in API response

[John_Clever]

I’m working with Vertex AI Agent Builder and trying to implement Function Tools. The documentation shows that when an agent identifies a tool invocation, it should return a toolCall object in the response.

{
  "result": {
    "userMessage": "check temperature in Seattle",
    "language": "en-US",
    "messages": [
      {
        "type": "BOT",
        "functionCall": {
          "resource": "<function-resource-id>",
          "name": "fetch-temperature",
          "params": {
            "city": "Seattle"
          }
        }
      }
    ]
  }
}

Testing in the Agent Builder playground works fine. When I ask about weather conditions, the network call to dialogflow.clients6.google.com/v3alpha1/ shows the toolCall correctly:

{
  "result": {
    "userMessage": "what's the temperature in Paris?",
    "language": "en-US",
    "messages": [
      {
        "type": "BOT",
        "functionCall": {
          "resource": "projects/myproject/locations/us/agents/12345/tools/67890",
          "name": "fetchTemperature",
          "params": {
            "city": "Paris, France",
            "scale": "fahrenheit"
          }
        }
      }
    ]
  }
}

However, when using Dialogflow Messenger integration, the API calls dialogflow.googleapis.com/v3/ and the toolCall is missing:

{
  "result": {
    "userMessage": "what's the temperature in Paris?",
    "language": "en-US",
    "messages": [
      {}
    ]
  }
}

This causes subsequent requests to fail with “Session is waiting for tool call result” error. Why do these two interfaces behave differently and how can I get the toolCall data in Messenger?

[Ethan_19Chess]

I encountered the same issue while transitioning from the playground to production. The discrepancy arises from differences in API versions—the playground utilizes v3alpha1, whereas Dialogflow Messenger defaults to the stable v3 version. The stable version processes tool calls differently and omits the toolCall object from the response. To address this, I implemented a custom webhook that intercepts the conversation flow before reaching the messenger. I configured my agent to route tool call requests to the webhook first, manage function executions on the server, and then send the results back to Dialogflow. This approach effectively resolves the missing toolCall data problem. An alternative would be to abandon the messenger widget in favor of the Conversational AI API, allowing greater control over the conversation flow and full access to all response data, including toolCall objects.

[Alex_Brave]

Ugh, this drove me crazy for hours! The messenger widget strips toolCall data on purpose for security. Dialogflow wants you handling function calls through backend webhooks, not exposing them to the client. Check if your fulfillment webhook is set up to catch these calls.

[amelial]

same problem happened to me too! the messenger API endpoint seems to leave out toolCall data. you might wanna manage tool calls on your server and send the results back. also, check your webhook settings for the messenger integration.

[jackw]

This is actually a feature, not a bug. Dialogflow Messenger strips out toolCall data on purpose - it’s built to handle function calls automatically through fulfillment webhooks.

I hit this same issue when moving from prototype to production. The messenger widget assumes you want server-side processing for security. Raw function calls shouldn’t reach the client anyway.

Here’s what you need to do:

1. Enable webhook fulfillment in your agent console
2. Point it to your server endpoint
3. Your webhook gets the function call data
4. Process the function and send results back to Dialogflow

The webhook payload will have the function details even though the messenger response doesn’t. Your server becomes the middleman handling all tool executions.

If you absolutely need client-side access to toolCall data, you’ll have to ditch the messenger widget and use the Conversational AI API directly. But honestly, keeping function calls server-side is the right move for most production apps.

[Neo_Stars]

This caught me completely off guard on my last project. The Dialogflow Messenger widget handles tool calls totally differently than the playground. The playground shows you the raw toolCall data, but the messenger hides all that and expects everything to happen server-side through webhooks. When I hit this issue, I found out the messenger automatically triggers webhook fulfillment for tool calls instead of showing them in the client response. You’ve got to set up a fulfillment webhook in your agent settings that can catch and process these tool calls. The webhook gets the function call details and has to send the results back to Dialogflow, which then picks up the conversation. Without the webhook configured properly, your session just hangs waiting for tool results that never come.