I have created Twitter bots for many geographic locations. I want to allow users to #-reply to the Twitter bot with commands and then have the bot respond with the results. I would like to have the bot reply to the user as quickly as possible (realtime).
Apparently, Twitter used to have an XMPP/Jabber interface that would provide this type of realtime feed of replies but it was shut down.
As I see it my options are to use one of the following:
REST API
This would involve polling every X minutes for each bot. The problem with this is that it is not realtime and each Twitter account would have to be polled.
Search API
The search API does allow specifying a "-to" parameter in the search and replies to all bots could be aggregated in a search such as "-to bot1 OR -to bot2...". Though if you have hundreds of bots then the search string would get very long and probably exceed the maximum length of a GET request.
Streaming API
The streaming API looks very promising as it provides realtime results. The API allows you to specify a follow and track parameters. follow is not useful as the bot does not know who will be sending it commands. track allows you to specify keywords to track. This could possibly work by creating a daemon process that connects to the Streaming API and tracks all references to the bot's names. Once again since there are lots of bots to track the length and complexity of the query may be an issue. Another idea would be to track a special hashtag such as #botcommand and then a user could send a command using this syntax #bot1 weather #botcommand. Then by using the Streaming API to track all references to #botcommand would give you a realtime stream of all the commands. Further parsing could then be done to determine which bot to send the command to. This blog post has more details on the Streaming API
Third-party service
Are there any third-party companies that have access to the Twitter firehouse and offer realtime data?
I haven't investigated these, but here are a few that I have found:
Gnip
Tweet.IM
excla.im
TwitterSpy - seems to use polling, not realtime
tweethook
I'm leaning towards using the Streaming API. Is there a better way to get near realtime #-replies for many (hundreds) of Twitter accounts?
UPDATE: Twitter just announced that in the future they will have User Streams which expands upon the Streaming API. User Streams Preview
Either track or follow will work for the cases you describe. See http://apiwiki.twitter.com/Streaming-API-Documentation#track for details on what track actually does. The doc on follow is on the same page.
There are rate limits of sorts on the streaming API, but they have to do with how big a slice of the total tweet stream you're consuming. For writing a bot like this you won't hit these limits without a pretty big user base. And when you get that user base you can apply for elevated access levels that increase the rate limets.
There's the twitter firehose but you're probably best off using the Streaming API. The firehose is open to Google (try googling your twitter name) and as the link says they're opening it up to all soon enough.
You'll want to get your IP whitelist too.
If your not already, you want to check out the GoogleGroup for twitter devs.
The track predicate for the streaming api would actually be useful because if you follow your bot's user IDs, you'll get all the messages made by your bots and all the other messages that mention your bots #usernames (including #replies). It really does track everything public on twitter relating to the user IDs you follow with it, give it a shot.
REST API:
The most comprehensive results with the least amount of false positives. Will include protected statuses if the bot is following the protected account. If you poll every thirty seconds it is pretty close to realtime and you will be well under your rate limit (350/hour) if you are using api.twitter.com/1 with OAuth.
Streaming API:
You will want to avoid the Search API. It is trending more and more towards popular results and not complete results.
Streaming API
The fastest but also likely to miss some statuses as well as include false positives. Protected statuses for example are not included. Track for a screen_name will return statuses with that screen_name in it but will also include tweets that just have the screen_name as a string without the # so be sure to filter on your side.
Related
I was previously using the Messenger Broadcast API to send regular updates to ALL users on my Facebook chat bot. These updates include daily news, feature updates etc. However now that the API is deprecated, I can't find any alternative API to do the same thing.
One possible alternative to this is to iterate through all the user's of my app and manually send them messages using the SEND API. However this is quite inefficient and you can easily hit maximum rate limits as mentioned in the documentation. So I would have to send out this manual update over a long period of time slowly to avoid hitting the rate limits. This feels like a hacky fix when the Broadcast API provided such a simple solution.
I can't seem to find any obvious alternative to the Broadcast API in Facebook's documentation. Is there any alternative API/technique I can use for my use-case?
I have a bot over Facebook which people are subscribing for sports updates.
I have 1,000 - 10,000 users I want to send out an update to.
Currently, in small scales like 20 messages , I would use a Facebook Batch request.
But, i'm not sure what would be the best way to send my messages in a large scale.
My two options are:
Batch - limited to 50 requests per batch request.
I don't really know if I should expect a delay in the execution of the request.
Regular calls - I will iterate through my receivers and send each of them a message separately.
I'm afraid Facebook might block me for thinking i'm spamming, or I will exceed the rate limits.
I have to say I was expecting a more generic method coming from Facebook since they are allowing users to subscribe for update through my bot, hence, I was expecting them to provide a guide on what are the best practices for sending the update users subscribed for.
You should definitely use Facebook Messenger Broadcast API for this. This will broadcast your message to all user subscribed to the bot.
Caveats:
You have to apply for this permission. (pages_messaging and pages_messaging_subscriptions.Takes about 1-2 days, but
can test on Admin/Test users of the app)
Each broadcast has to be a separate broadcast. (e.g. you can't send image and a text together, each has to be its own individual broadcast).
Have some kind of un-subscription option as well. FB user might think you are spamming even if you clearly say in the messages that your bot will send updates.
Use custom labels to create targetted sends. So you can either subdivide who you will send updates to about specific issues or just label people if they unsubscribe to your broadcast or not.
Basic workflow:
Get permission to broadcast.
Create message_creative_id via POST to endpoint
Use message_creative_id to POST a broadcast_messages
On a successful send you will get back broadcast_id
I'm building an application for my personal use that saves all my facebook messages in a database on my computer.
But I have a problem as it seems only few messages can be accessed through the Graph API.
I created a token with all the possible permissions.
When issuing a call:
/me/inbox
I get all the threads in my inbox but for some of them the comments field which contains the actual messages is missing. It's mostly for conversation with people that are not friend with me on facebook.
For those threads, when I try to get more information by /<id_of_the_thread>
I get an error (code 100) Unsupported get request. from the graph api.
Is it a normal behaviour of the API?
What am I missing here?
Don't hesitate if you know a better way of saving all my messages.
Another, somewhat inferior, but much more accessible way of obtaining one's Facebook messages is by downloading a copy of your Facebook data through https://www.facebook.com/settings. This way you can download an archive with all your FB data, including your messages. They are however capped to 10,000 messages per conversation, and are all stored in one .htm file, which is not very practical if you want to do further operation on them.
No i think, we can't specified the Thread by using ID, but commonly i'm sorting the threads by its sender. CMIIW
Now i am able to get "Received Direct messages" from twitter and "Sent Direct messages" from twitter.
But i saw an iPhone application Seesmic where direct messages showing as original twitter messages page (Messages). In that iPhone application they showing both sent and received messages in single page.
I could do this by calling both webservices (http://api.twitter.com/version/direct_messages/sent.json,http://api.twitter.com/version/direct_messages.json) and merging both responses and showing it like original twitter inbox (means showing messages to each user as a separate page).
There are only four methods in Twitter Direct Messages
I want to know any other way of getting complete "Direct messages" from twitter in a single request.Is Streaming api is capable of that. There is no enough support in web for streaming api. Please answer me.Thanks in advance.
There is no single API method that provides this. You will have to make two requests and merge them locally. You could use the User Streams API but the streaming API does not provide any historical data. You would start with no DMs and slowly build up a local cache as DMs are sent/received by the user.
Does Facebook provide access to any real time APIs so that you can respond to events as soon as they happen? If not, what alternatives are there and what are their limitations? For example, if I use polling instead, will they limit my api calls? And if I try using RSS feeds, about how much delay can I expect? Or maybe it would be possible to receive and process email notifications (if I could convince a user to forward mail to another email address), as they seem to be dispatched pretty promptly.
I've never tried polling user data, but I think it will work without issues. As far as I know there are no restrictions on the number of API calls you can make on facebook.
As far as the Queries are concerned, what I have seen and I think this is how they implement it. If your query asks for too much data(takes too much time to process is how they measure this I think) - the query will just fail.
eg: I had this app that would pull all the status messages of all the friends of the user and display it in one place. I first queried for all the friends of the user - this worked okay. But at the same time if I ran a loop to get all the status messages for each friend - it would just fail.
I think you can call individual queries without issues, just be careful you query only data you need, cause, if the queries are too big or too many they will just fail. Best way to findout is running tests yourself.
The Facebook Graph API will allow you to subscribe to real time changes. You can currently only subscribe to users, permissions and errors, but they promise to allow subscribing to more objects in the future.