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.
Related
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 have created my messenger bot and I am sending optedin user messages.
However I would like also to handle their reactions to my messages.
My callback url is working ok, for messages sent by them, for read events etc, but no reaction information.
Does anybody know if this is possible at all?
Currently there is no webhook event sent for reactions, and no way to detect them.
Today there is a webhook to handle reactions
https://developers.facebook.com/docs/messenger-platform/reference/webhook-events/message-reactions/
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.
Is it possible to send a message to a user without the user interacting with the bot first?
I'm using the following guide to retrieve psids from users that have already connected their profile to an app that I own.
https://developers.facebook.com/docs/messenger-platform/connecting-accounts.
For users that have at least one interaction with a page that I also own, I'm able to get their id. For all other users the endpoint returns an empty array.
Im aware of customer matching but is that the only way to achieve this?
You can't send a message by bot before the user initializes the conversation.
Facebook Messanger Bot permits a standard messages, with a 24-hour interval
to reply to a message initiated by a user. In Some specific cases, Facebook permits to send a message after this time.
A message are triggerd when the user either sends a message to a company or clicks a call button for action in Messenger, or when the user requests a message from a company through a plugin, such as send to Messenger.
Check out the policies here : https://developers.facebook.com/docs/messenger-platform/policy-overview
You are correct, customer matching is your only option for this.
Just learned this today, if you have a user's phone number, you can message them unprompted. You also need the pages_messaging_phone_number permission, which you can only get by paying the $99 customer matching fee.
Check the docs on sending to phone numbers here. Customer matching docs here
I have a facebook app that needs to allow a user to send a message to multiple friends (potentially all their friends) at once. This isn't any kind of spam, and I don't need the app to send the message incognito (behind the scenes), I just need to open a dialog with specific friends pre-populated (that the user has selected within my app in a prior step) and then send them a custom message. Is this possible? I see the api for sending a message to a single friend, and I see the API for inviting users to my app (but that's limited to some very small number of invitations per day)... what I need is a dialog that lets me send messages to as many of the user's friends as they want, but for me to control *which friends are selected... I don't want to give them control to add/remove from the friends list.
Is this possible?
No, the Send Dialog allows prefilling only a single friend, but would otherwise be the best option here if you need a custom message displayed to the recipient. You could get the user to send to several friends in a loop by prefilling this - or fire the dialog without prefilling and let the user chose who to send to - your app won't receive a callback with the recipient IDs but you could put a referrer param in the URL sent?
Failing that, the Requests dialog / 'invites' are the only thing you can prefill with multiple recipients without the expectation that your app will be shut down for spam shortly thereafter - there's no limit per day on the number of requests sent, but you don't get to set the message shown to the recipient.
In case this is helpful to anyone else, I just found this... it's a relatively new API (still in beta) that allows for (just about) exactly what I was asking for. I've tested it and it appears to work...
https://developers.facebook.com/blog/post/2012/08/31/reach-users-1-1-with-the-notifications-api/