I am creating a facebook chatbot and i can get different kinds of JSON format for persistent menu, quick replies and simple messages. Is there any way that i can differentiate what functionality (i.e. either persistent menu, quick reply, button template) is triggering the webhook call?
Here is the list of actions, that can trigger webhook by the date 10th Sept 2017. You can differentiate the calls by parsing JSON format. Each one has its own structure encapsulated with a general structure.
Message
Message Delivered
Message Read
Message Echo
Postback
Plugin Opt-in
Referral
Payment (beta)
Checkout Update (beta)
Pre-Checkout (beta)
Account Linking Event
Policy Enforcement Event
App Roles (beta)
Standby (beta)
Pass Thread Control (beta)
Take Thread Control (beta)
To find out more check out the related dev docs:
https://developers.facebook.com/docs/messenger-platform/webhook-reference
Related
Do we have webhook available for SAP successfactor?
Do we have any webhook available where I can get the notification if any operation happened in the entity like any object is inserted in the entity then I will get notification?
Yes, it is an inplace functionality called Intelligent Services (can be found in Successfactors within transaction "Intelligent Service Center (ISC)".
There you can subscribe to different events (only the one's provided in the standard, no custom hooks possible). The subscription results in an integration center flow, where data can be passed via different protocolls to a webservice of your choice.
You can also configure a "business rule" with an intelligent service as a starting point.
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.
If any user changes or creates new page in Atlassian Confluence, I would like to automatically send a REST request. I want to use it for pushing auto-messages in messenger (in some public channel). It is useful to see any new changes on wiki.
I found info about REST API for Atlassian Confluence:
https://developer.atlassian.com/server/confluence/confluence-rest-api-examples/
But it is about how to sent requests to Confluence.
Is it possible to generate auto requests from Atlassian Confluence?
Update: I found some information - looks like it is impossible.
https://jira.atlassian.com/browse/CONFSERVER-52487
Am I right?
You are right, unfortunately this functionality does not exist at the moment. The best way would be to write your own Confluence Plugin that binds to certain events. See https://developer.atlassian.com/server/confluence/event-listener-module/ for more information about this. Then you can send the desired requests to your messenger every time the event occurs.
Another option, but unfortunately not free, would be the "Script Runner for Confluence" plugin. This plugin provides at least a simpler way for the above solution. You only have to implement the "send request" part, as the event handling is done by the plugin and can be configured via UI. See http://scriptrunner-docs.connect.adaptavist.com/confluencecloud/script-listeners.html#_set_a_watcher_for_new_blog_posts for more information.
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'd like to use the endpoint '{conversation-id}/messages' to send bulk messages. According to the latest update on policies i can send 1 message to each user (says nothing about the users count) outside the 24 hours window ( when i can send multiple messages ).
Can anyone confirm to me that "The restriction on promotional content has been removed for standard messaging." includes the Api endpoint i stated above? is it standard as in non-'bot-like'? or standard as in using the web app ?
Also, if i break the policies in this regard, do they ban the app, the developer or the page?:D