Rasa: CR: RASA Core REST API /webhook: Add intent/action names attributes to any answer payload

[solyarisoftware]

Hi all!

Now

The RASA Core REST API /webhook endpoint return just 2 attributes:

• recipient_id
• text / other media

as this example shows:

$ curl -s localhost:5005/webhooks/rest/webhook \
          -d '{ "sender": "Giorgio", "message": "I am a bit sad"}' | json
[
    {
        "recipient_id": "Giorgio",
        "text": "Here is something to cheer you up:"
    },
    {
        "image": "https://i.imgur.com/nGF1K8f.jpg",
        "recipient_id": "Giorgio"
    },
    {
        "recipient_id": "Giorgio",
        "text": "Are you feeling better?"
    }
]

---

Change request

It could be great if this endpoint could also return, for each answer block:

• intent, the name of the intent that produced that specific "output" template,
• action, the name of action triggered by the above intent

Here a possible modification I'm proposing:

   [
            {
               "intent": "mood_unhappy",
                "action": "utter_cheer_up",
                "recipient_id": "Giorgio",
                "text": "Here is something to cheer you up:"
            },
            {
               "intent": "mood_unhappy",
                "action": "utter_cheer_up",
                "image": "https://i.imgur.com/nGF1K8f.jpg",
                "recipient_id": "Giorgio"
            },
            {

               "intent": "mood_unhappy",
               "action":  "utter_did_that_help",
                "recipient_id": "Giorgio",
                "text": "Are you feeling better?"
            }
      ]

minor request: about naming

The sender attribute in JSON payload request seems to me also returned back in JSON answer but with different name recipient_id. That's also related to the other old issue: https://github.com/RasaHQ/rasa/issues/4683

In general, I propose to unify naming. In this case: sender === recipient_id. Why don't use the same name? But I know that now is a pain because renaming will broke backward compatibility.

---

Why?

One reason is to have, at run-time RASA Core call, an "explanation" of the bot reply (also in terms of intent/actions triggered, for possible online post-processing/filtering. A scenario I'd wish to explore is to manage dialogs through e-mails (letters exchanges). That's a deepened in my stackoverflow question: using rasa to build an email bot - in general about email bots dialog management:

---

Maybe additional attributes have to be added in source code at:
https://github.com/RasaHQ/rasa/blob/master/rasa/core/channels/channel.py#L280 ?
(I'm not a python developer so I'm not sure).

Thanks/giorgio

[sara-tagger]

Thanks for submitting this feature request 🚀 @tabergma will get back to you about it soon! ✨

[tabergma]

Thanks @solyarisoftware for the feature request.

Just to check can't you receive the information from the endpoint /conversations/{conversation_id}/tracker? This should have a list of events and the information about the latest message.

[solyarisoftware]

Thanks a lot @tabergma,

Yes, calling the endpoint you specified I got the intent of the last user message:

   curl -s localhost:5005/webhooks/rest/webhook -d '{ "sender": "Giorgio", "message": "hi" }'
   curl -s localhost:5005/conversations/Giorgio/tracker
    ...
    latest_message: {
        entities: [],
        intent: {
            confidence: 0.9912492037,
            name: greet
        },
    ...

So the intent of last message is latest_message.intent.name of the JSON payload, That solves my problem!

---

Digression: that has to be considered maybe a workaround because I need to call 2 HTTP requests ( before: /webhook and afterward /tracker) for any message, slowing down performances.

/tracker is great to have all details, but I'd prefer /webhook would reply all attributes in the single request payload, just adding intent name and action name info:

     [
            {
               "intent": "...",
                "action": "...",
                "recipient_id": "...",
                "text": "..."
            },
        ...
    ]

That's arguable, I admit :)
Thanks again/giorgio

[kwatog]

anyone can guide us on how to subclass the Rest? i'm with @solyarisoftware here.

I'm also trying to avoid the second API call.

[wochinge]

I'll close this as this should be done via a subclassed channel.
@kwatog Do these docs help you? Otherwise I'd ask you to please ask the question in the Rasa Forum