knitr::opts_chunk$set( collapse = TRUE, comment = "#>" )
library(tweetbotornot2)
This vignette provides background and addresses commonissues related to obtaining access (authorization) to Twitter's APIs. It also introduces two authorization methods–the default (user) authorization method and the application-only (bearer) authorization method–and explains some key differences between the two.
Use of {tweetbotornot} typically1 requires, at a minimum, (a) internet connection and (b) an active Twitter account. The latter is needed because Twitter requires authentication prior to use of their REST API. As a result, to use key functions of {tweetbotornot}, users must either approve the embedded {rtweet} rstats2twitter application (this allows {rtweet} to communicate from R to Twitter's APIs) or provide their own application and account credentials. If a user is already signed into Twitter in their default web browser, this can be done with a single click. Otherwise, users must sign-in to Twitter and then click.
If you're working in an interactive R session on a local machine (in the RStudio application, for example), this process should be relatively straight forward.1 However, if you're working on a remote server or in the cloud (in RStudio Server, for example), then it's a bit trickier. The easiest solution is to start a local, interactive session of R and then do the following:
r
rstats <- rtweet::search_tweets("rstats")
.rds
file
r
saveRDS(rtweet::get_token(), "rtweet_token.rds")
r
token <- readRDS("rtweet_token.rds")
predict_bot("jack", token = token)
or set the path to the saved token as an R environment variable. The latter
option (example below) allows you to avoid having to specify the token each time.
r
Sys.setenv(TWITTER_PAT = "/path/to/rtweet_token.rds")
predict_bot("jack")
or set the R environment variable for current and future sessions (on a
given machine), you can also try tfse::set_renv()
.
r
tfse::set_renv(TWITTER_PAT = "/path/to/rtweet_token.rds")
Assuming users haven't made any recent calls to Twitter's API, the predict functions
described earlier should work for up to 900 users at a time. For some users (e.g., those with a Twitter
token created using credentials from their own Twitter application or tokens
created at a time of sufficiently provided permissions by the embedded rtweet app)
it's possible to get estimates for up to 1,500 accounts at a time using Twitter's
application-only (bearer) token. Converting a normal user token into a bearer
token requires an access level of "read-write-directmessages"
. The code below
should print the access level associated with your current token.
## view access level of current token print(rtweet:::api_access_level())
The drawback to the application-only authorization method is that your requests
will contain no information about the authenticating user. The upside to this
kind of token is access to a different set of rate limits. The different rate
limits aren't always desirable (compared to the normal user token), but for the
some endpoints–like users/timelines
(900 vs. 1,500 requests per 15 min.) and
search/tweets
(18,000 vs. 45,000 requests per 15 min.)–the difference is quite
significant.
If the output from the above code was "read-write-directmessages"
, then users
can specify the bearer token via rtweet::bearer_token()
for the token
argument
in bot-predicting calls. The code below, for example, checks the bearer token rate
limit before and after executing predict_bot()
.
## check bearer token rate limit rtweet::rate_limit(rtweet::bearer_token(), "get_timeline") ## get bot estimates for two users predict_bot(c("netflix_bot", "PatrickMahomes"), token = rtweet::bearer_token()) ## re-check bearer token rate limit rtweet::rate_limit(rtweet::bearer_token(), "get_timeline")
Add the following code to your website.
For more information on customizing the embed code, read Embedding Snippets.