Check if a user retweeted a specific tweet

This endpoint provides a convenient way to check if a user retweeted a tweet identified by [tweet_id]. This will recursively retrieve all users who recently retweeted a tweet (up to [max_count] total results) and check if the [user_id] is present among the retrieved users.

IMPORTANT: This endpoint may fail to determine if the source user retweeted the target tweet if this action did not happen recently.

For a more accurate approach we recommend that you export all users who retweeted the target tweet, regularly update this list and verify if the source user_id is present on this list

Endpoint

GET https://api.socialdata.tools/twitter/tweets/[tweet_id]/retweeted_by/[user_id]?max_count=?

Endpoint parameters

Name	Description	Example
tweet_id (Required)	The numeric ID of the desired tweet.	1625802236571033602
user_id (Required)	The numeric ID of the desired user.	1489552236571048124
max_count (optional)	Maximum number of retweeters of [tweet_id] to look through Min: 20 Default: 100 Max: 200	100

Common Issues and Best Practices

• In languages where the tweet_id or user_id value exceeds the default Integer type limit (e.g., Node.js), store tweet_id and user_id as strings. Use the id_str property returned by the API for these values

Pricing Considerations

Since there is no way of confirming if a user retweeted a tweet directly, we need to recursively retrieve retweeters of target tweet and check if user_id is present. SocialData API pricing per request is based on the number of user objects you retrieve, therefore the cost of each request is going to depend on the value of max_count.

Setting higher max_count will give you more precise results, but will also result in higher cost per request.

If you set a high max_count, but we are able to determine that the user retweeted the target tweet before reading all the max_count retweeters - you will only be charged for the actual number of users retrieved by SocialData API (see field [retweeters_checked_count] in the response).

If you perform this check relatively frequently for each target user - we recommend keeping max_count low to maintain a lower cost. 100 seems like a sensible default. This may, however, result in occasional false negatives.

Caching

To minimize your costs, optimize response time, and avoid repeated requests we cache all ids of users who retweeted a tweet for a period of 30 minutes. If the requested [user_id] is found in cached values - you will receive a response immediately. Responses that used cached values incur a charge equivalent to 20 user objects by default.

If the target user_id is not found in cache - SocialData API will proceed to getting the most recent list of users who retweeted a tweet, and cache their ids again.

Response codes

• HTTP 200 OK - succeeded

• HTTP 402 Payment Required - not enough credits to perform this request

• HTTP 404 Not Found - requested target tweet does not exist

• HTTP 422 Unprocessable Content - validation failed (e.g. one of the required parameters was not provided)

• HTTP 500 Internal Server Error - other error, typically means that SocialData API failed to obtain the requested information and you should try again later

Rate limits

By default each user has a limit of 120 requests per minute shared across all endpoints. Please reach out to [e-mail] if you need to raise your rate limit.

Example request

curl "https://api.socialdata.tools/twitter/tweet/456456456/retweeted_by/123123123?max_count=100"
-H 'Authorization: Bearer API_KEY'
-H 'Accept: application/json'

Example response

// If succeeded: 
{
    "status": "success",
    "source_user_id": "123123123...",
    "target_tweet_id": "456456456...",
    "is_retweeted": true,
    "retweeters_checked_count": 100
}

// If failed:
{
    "status":"error",
    "message":"User not found"
}