Check if a user is following another user
This endpoint provides a convenient way to check if a user is following another user. This will recursively retrieve all recent followers of target_user_id
(up to max_count
total results) and check if the source_user_id
is present among the retrieved followers.
This endpoint may fail to determine if the source user is following the target user if the follow action did not happen recently. For a more accurate approach we recommend that you export all users who are following the target user (use User's followers endpoint), regularly update this list and verify if the follow action occured against your local cache of followers.
SocialData has an alternative endpoint that verifies is there is a follow relationship between 2 users with 100% accuracy without scraping follower lists.
Due to limited capacity this endpoint is only available to our enterprise customers. Please reach out to support@socialdata.tools to get access.
Endpoint
Endpoint parameters
Name | Description | Example |
---|---|---|
source_user_id (Required) | The numeric ID of the desired follower. | 1625802236571033602 |
target_user_id (Required) | The numeric ID of the desired user being followed. | 1489552236571048124 |
max_count (optional) | Maximum number of followers for target_user to look through Min: 20 Default: 100 Max: 5000 | 100 |
Common Issues and Best Practices
In languages where the
user_id
value exceeds the default Integer type limit (e.g., Node.js), storesource_user_id
andtarget_user_id
as strings. Use theid_str
property returned by the API for these values
Pricing Considerations
Since there is no way of confirming the relationship between source & target users directly, we need to recursively retrieve followers of target user and check if source_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 source user is following target user before reading all the max_count followers - you will only be charged for the actual number of followers retrieved by SocialData API (see field [followers_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, when source user is following target user, but the response you get from the API is FALSE.
Caching
To minimize your costs, optimize response time, and avoid repeated requests, we cache all ids of users who follow target user for a period of 30 minutes. If the requested [source_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 source_user_id is not found in cache - SocialData API will proceed to getting the most recent list of followers for target user, 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 user 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 support@socialdata.tools if you need to raise your rate limit.
Example request
Example response
Last updated