Using Messenger Handover protocol I can pass the control to inbox when user requests to talk to a human. I want the bot to listen on standby in order to take the control back when user requests it. The problem seems that the bot doesn't listen on standby.
My Facebook page is subscribed to Standby event and Webhooks integration is enabled in my Messenger app. In DialogFlow the Facebook Messenger integration is set. In the fulfillment code I don't receive requests after handing the conversation thread control over to inbox.
Please help!
I have an idea for this, but actually I'm not sure if it wil work, I'll just post it to see if anyone maybe has tried it.
I think you should create an own webhook, this is going to be subscribed in the Facebook App Messenger Webhook in Facebook Developers Portal.
You will have to set your this webhook to receive all the corresponding events from Facebook, like 'messaging', 'standby, 'messaging_handovers', etc (currently 'messaging' event is used to send the messages from users, and 'messaging_handovers' and 'standby' are used to switch control from bot (DialogFlow in your case) to another app (could be inbox page).
Then, you will have to set up your webhook, depending on the callback received, like this:
- If request_thread_control callback is send: the webhook should send a pass_thread_control to the second reciver
- you will have to set up a protocol to activate take_thread_control, to return the ownership of the conversation to the bot
- In any other callbacks (asuming the rest are for the messages send to the bot), the webhook should send them to Dialogflow using a client of it inside your webhook, evaluating if the bot has the ownership of the conversation or another app has (again could be another app or inbox)
As I said, it's just an idea, I'm not sure if it will work. Hope it helps somone!
References:
https://developers.facebook.com/docs/messenger-platform/handover-protocol/pass-thread-control (Passing Thread Control to the Page Inbox (Live Chat))
https://developers.facebook.com/docs/messenger-platform/handover-protocol/request-thread-control#page_inbox (Requesting Thread Control From the Page Inbox)
*This is an idea to make passing the ownership avoiding to create an intent that do that. Specially if you want to switch between bot and inbox page just moving a conversation from Done to Inbox or from Inbox to Done
Related
Facebook recently released an optional Recurring Notifications feature for Messenger.
My group has attempted to use this feature in our app; in our chatbot flow, we present the user with the opt-in message, and when they click on the opt-in button, we are supposed to get a webhook event notification. Unfortunately, no request is coming to our webhook when the user clicks the button.
We've done some sanity checks:
The app is subscribed to messaging_optins notifications feed (v11).
I'm certain the webhook itself is configured properly, because our server is receiving other notification feeds (e.g. messages).
The problem also doesn't seem to be with our opt-in request button configuration, because even the Test button in the Facebook Developers dashboard (which is supposed to send a sample messaging_optins payload to our server) does not result in a call to our webhook.
Possibly irrelevant details: the page connected to this app is registered in Kenya and the webhook server is running on an AWS instance in Germany. We have another page registered in India connected to AWS in India, and that connection is working fine despite identical configuration.
What other things should we troubleshoot to identify the problem here?
I'm testing a facebook instant games app and want my bot to collect messaging_game_plays events to log user data at the end of a play session.
I've set up an app page, app, and uploaded a build that I have moved to the testing stage. I also have a bot with a public webhook that I have successfully verified. The webhook is currently subscribed to messaging_game_plays as well as messages. I have simple echo functionality built into the bot and can spin up the messenger app on my phone, message the page, and receive an echo perfectly.
The problem arises when I go to the games section of my messenger app, play the game, and then exit the game. I expect my bot to receive a messaging_game_plays event per https://developers.facebook.com/docs/messenger-platform/reference/webhook-events/messaging_game_plays/, but I don't receive any indication in the logs of the bot server that anything has called the webhook (even after waiting a significant amount of time).
So my question is/questions are: am I missing something that is required for the messaging_game_plays to be sent to my bot? Is there anything that I need to add to my app-build specifically for this event to trigger? Is launching the game on my phone and exiting the game sufficient for testing this event?
I've searched forums and documentation with no luck but maybe I've missed something along the way. I have checked this question: Facebook Messenger webhook setup, but not triggered, and that helped me successfully trigger messages events which I am getting, I just can't seem to collect messaging_game_plays events.
I am rather new to this process so I may be missing something small, any help would be greatly appreciated!
For reference:
app webhook subscriptions
What does your fbapp-config.json file say? If your bot opt-in parameter is 'opt_in_dev' or 'opt_in_public' you will need to call the subscribeBotAsync method to subscribe your user to the bot before any webhooks will be sent.
Messenger bots will need to be opt-in only from January 19th (see here: https://www.facebook.com/fbgaminghome/blog/important-game-bots-update).
We're making this change to ensure a better player experience.
If you want to transfer player data without requiring the bot to be opted-in, you can use standard JavaScript fetch/XMLHttpRequest with getSignedPlayerInfoAsync to avoid tampering.
We've setup a messenger webhook for one of our chat bots. The same is successfully verified and saved:
The subscription events seems to be set correctly:
However, often we notice that no matter how many times we send message to the subscribed FB page, the POST webhook to handle users' input is never called.
The call starts when we do re-configure the events subscription for the app.
Our servers are running on DigitalOcean India region
Many other people are also experiencing this issue:
Messenger bot: delay in message reception
Random delays with receiving Messenger Webhooks requests
No Messenger Webhook sent at all on some page
Is there any temporary work-around for this bug atleast?
I read the documentation for facebook messenger bot but I can't find anywhere if it is possible to make two different FB bots(one test bot) and connect to the same Facebook Page(to use the same webhook. Does someone know if this is possible and is it aginst FB rules?
You're going to want to investigate the Handover Protocol (Beta). This will allow you to subscribe two or more apps to the same Facebook page. One of the apps will be configured as the "Primary Receiver", which will have control of any new conversation thread by default. All other apps will be configured as "Secondary Receivers". Any app can pass thread control to another app, but only the Primary Receiver can forcibly take control from another app.
When an app is in control of the thread, it will receive messages on the standard messaging channel. When an app is not in control, it will instead receive them on the standby channel. Standby messages look just like regular messages, except that their entry items contain a "standby" field rather than a "messaging" field.
Here's the kicker: apps are allowed to send messages whether or not they have thread control. This means that you cannot rely on the handover protocol to automatically sort out when your bot can and cannot talk. Instead, your bot will need to keep track of whether or not it has control and only respond at the appropriate times. To accomplish this, the messaging_handovers webhook will be helpful.
Facebook has provided a new version of their page Inbox which supports the Handover Protocol. When configured as a Secondary Receiver, new conversation threads will automatically be filed into the "Done" folder. If one of your apps passes thread control to the Inbox app, the conversation thread will be moved to the "Inbox" folder. When a human page manager clicks the "Done" checkbox on that conversation, the thread is moved back to the "Done" folder, and thread control is passed to the Primary Receiver.
One thing to be aware of, at least as of November 2017, is that the interaction of postback messages with the Handover protocol is a bit unintuitive and possibly even buggy. The postback documentation indicates that an app will always receive its own postbacks on the standard messaging channel, even if it does not have thread control. From the description of the "title" field of a postback event:
Title for the CTA that was clicked on. This is sent to all apps subscribed to the page. For apps other than the original CTA sender, the postback event will be delivered via the standby channel.
As the description of the "payload" field indicates though, the standby version of a postback message omits the payload:
payload parameter that was defined with the button. This is only visible to the app that send the original template message.
I suggest that this is unintuitive because it seems to me "standby" has a different meaning for regular messages than for postback messages. I mention that it might be buggy because I have found my apps often receive their own postbacks on both the messaging and standby channels. (I have taken to ignoring postback messages on the standby channel for this reason.)
Hope this helps.
Yes you can subscribe more than one app to the same Page. You will need to designate one as the Primary Receiver role in the page settings, then use the Platform's handover protocol to pass control of the conversation between that apps.
I am learning the facebook api and I am curious how to do this.
On this website(https://botacademy.com/), they use manychat and you can click the opt in button (on web) and it automatically accesses your messenger inbox without prompts or auth.
It then sends you a programatic message. All of the tutorials I follow require the user to send a message first..
Do you know what endpoint of the API they are using to accomplish this?
Obviously I do not know what their code looks like, but:
that is a send to messenger button, which allows you to authenticate with a bot and an app, and sends your information to the webhook.
This counts as interacting with the bot, because you clicked the button and opted into the experience.
FBM Platform Policies have this to say about opting into messages and send to messenger:
How messaging is triggered:
...
Person requests a message from a business via a plugin, such as Send to Messenger