Home / DialogFlow ES / Quick tips for Dialogflow REST API users
DialogFlow ES | REST API

Quick tips for Dialogflow REST API users

This website contains affiliate links. See the disclosure page for more details. 

If you are using Dialogflow’s REST API, these tips can help speed up your development.

Use the Postman app

If you hadn’t used it already, Postman calls itself “the complete toolchain of API developers”.

For our case, Postman allows you to take the various API calls you see in the Dialogflow documentation and test these requests.

For example, here is a request I created as I was working on the Chatfuel integration tutorial.

But here is the best part. Once you confirm that the request is constructed properly, you can simply use the Code link at the top right and get auto-generated code for the request you just made.

And the Postman app supports many programming languages:

Understand what a Dialogflow session is

When you send a request to the /query endpoint, you need to specify the sessionID.

While I haven’t seen a good definition of a session (as it relates to Dialogflow) in the documentation, you can think of HTTP sessions as a reasonable starting point.

But there are a few things you need to know about the Dialogflow sessions. I wrote about this on Dialogflow’s old forum:

  1. I don’t think there is a good, published documentation of best practices
  2. The sessionID duration depends on the channel (web, FB, Slack etc)
  3. The Facebook integration seems to change the sessionID somewhat unpredictably midway through a conversation. I don’t know if this is still an issue. See here: SessionId consistency

Understand how contexts work inside a session

Now this is really important.

If your app takes the responsibility of managing the sessionID (as it should), you don’t have to worry about managing the context for the conversation. Said another way, as long as you are making sure that you are sending the correct sessionID in each /query request, Dialogflow will automatically do the context management for that particular session.

This point may seem somewhat obvious. But I am not so sure.

Here is a good example of what not to do and how people sometimes get confused:

If you didn’t know, there is a chatbot building framework called Chatfuel. And someone wrote a piece of code which integrates Chatfuel and Dialogflow. It was the only solution which was available when I went looking for some sample code, so I need to give this person their due.

However, the solution was created by a Chatfuel expert who doesn’t fully understand how contexts work inside Dialogflow’s API-managed sessions. By API managed, I mean that the session starts as a result of sending API requests to Dialogflow and further session actions – a technical way of saying that the conversation goes on 🙂 – are performed by sending more API requests.

As a result the solution which is currently doing the rounds cannot work for intents which set and use contexts (the NLP portion will work though).

The recently released Zoho SalesIQ v2 allows non-programmers to build chatbots using an easy-to-use code less bot builder. What is really unique about Zoho SalesIQ is the fact that you can also integrate AI into their code less bot builder. In my Zoho SalesIQ chatbots course, I explain how to use Zoho SalesIQ to add a chatbot to your website.

"The magic key I needed as a non-programmer"

The custom payload generator was the magic key I needed (as a non-programmer) to build a good demo with rich responses in DialogFlow Messenger. I've only used it for 30 minutes and am thrilled. I've spent hours trying to figure out some of the intricacies of DialogFlow on my own. Over and over, I kept coming back to Aravind's tutorials available on-line. I trust the other functionalities I learn to use in the app will save me additional time and heartburn.

- Kathleen R
Cofounder, gathrHealth

Similar Posts