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.
Related
I have a bot running well receiving messages through the Facebook message webhook event. Everything works well when the user sends messages through the messenger app.
But When a user replies to the page story, it generates an incoming message as if it was a standard one and it's not possible to handle this context which is completely different form a user initiated conversation.
Any idea how to receive to differentiate a "standard" message from a "reply to page story" one ? Thx
There is no way to differentiate between these two entry points/sources. Both will trigger a regular message event with no specific attributes added that would allow you to differentiate the source/entry point.
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
I'm looking for a way to detect if links have been shared in an iMessage conversation. I'm not sure if this can be done with MSMessage, as it looks like it only receives events from messages created by your iMessage app.
Does this mean there is no way to access the conversation outside of the scope of messages created by your iMessage app? Any help is very much appreciated!
Your suspicion is correct. You can only access your own extension's messages.
Quote from the documentation for MSMessagesAppViewController.didReceive(_:conversation:):
You only receive notifications about messages sent using
your extension. You cannot interact with messages from other
extensions.
At the moment you can only access messages that come from your app AND :
that were selected by the user. Meaning that any previous message
sent via your app won't be accessible unless the user tap it.
that were received during the app runs
Note that we are only at the third beta test (at the moment I'm writing) of that new feature. As an "enhancement" were open for this feature, apple developers may allow an app to access messages (of course messages sent via this app, Apple is really worry about all that confidentiality stuff ;) ) in the future
so this is something I've been trying to think through for about 16 hours. I am coding with PHP / CuRl / etc - the bot works and everything is fine. My current issue is figuring out how to disable the bot and allow a human to begin chatting with the customer/sender.
Has anyone successfully, created a route for this ? I mean it's pretty hard from what I see, you'd have to disable etc etc. A lot of effort for my clients.
Thanks for any input.
Facebook has rolled out a "Handover Protocol" which is supposed to facilitate a combined human/bot Messenger implementation.
https://developers.facebook.com/docs/messenger-platform/handover-protocol
It is a little unclear what actually occurs in step 5:
Pass thread control: At some point in the conversation, a user may choose to do something like interact with a live agent. To handle this, pass thread control from the Primary Receiver to the Secondary Receiver. The Secondary Receiver will receive a messaging_handovers webhook event to notify it that is now controls the conversation.
This doesn't actually disable the bot (as the OP requested), and isn't in the control of the Page owner but rather of the user. It seems FB envisions the user typing something like 'I would like to chat with a human' triggering the bot to pass control...but it would be nice to let the page owner simply put the app in standby and handle the messages herself.
Once you recognize someone wants to speak to a human, set a flag that disables all actions of your bot to on.
Then, have your bot message you, or whoever will respond, that a user ID needs responding to. Have your bot continue to send all messages received from them back to you until you enable the bot again.
Create some sort of way for your bot to interact with you that allows you to send a message to a specific user, and a way to once again enable the bot interaction with the user.
Probably something like "sendMessage104012301230'Hi, sorry you couldn't find [etc]', and enableUser104012301230
There may be a better way, but those are some thoughts on how I'd do it
If you enable messages echo, whenever a human respond using the page, a echo post is sent, and inside entry->messaging->message there's no app_id.
You can use that information to disable bot replies for a certain period, or disable indefinitely until you enabled is with some admin command (that's how I'm doing)
I thought a solution could be to label the message as "unsolved". Another solution could be to have the bot mark the conversation as unread. Does anyone know if it is possibile to add a label to a conversation or mark as unread through API?
I’d like to implement an “out of office” app for Facebook messages but it doesn’t seem technically possible. The idea is simple, let the user define some dates they won’t be reading Facebook messages (i.e.: they're off-line camping) so that when they get a new message we can notify the friend/sender they won’t be able to respond quickly.
I’ve been reading Facebook’s API and, although I can read user’s messages with proper authorization (read_mailbox), I cannot send messages on their behalf.
A workaround would be to get the email address of the sender, and answer with a plan email instead of a Facebook message. But getting the sender's email also requires extended permissions on a per user basis.
I could present the Send Dialog, but logically we want this to work automatically without any user interaction. Also, we could post a private status only visible to the sender, but that doesn’t seem very effective.
This is where I hit the wall. Can you think of a way to implement such functionality?
You can email to username#facebook.com (getting the username from the user id does not require any permissions) – but Facebook’s policies forbid apps from using that in general, because they say these addresses are intended for user-to-user communication.
You could make a point saying, that this was essentially user-to-user communication – but use at own risk. You’re app may be blocked if there’s spam complaints or if Facebook sees you sending a massive amount of messages this way.