How to Check an X Account's account_based_in Location
The location written in an X bio is easy to edit and often playful. For vetting creators, reviewing partners, checking regional exposure, or investigating suspicious accounts, you usually need a more structured signal than free-form profile text.
TwexAPI's User About endpoint returns account_based_in, location_accurate, and related account metadata for a given screen name. Treat these fields as evidence for review, not as a live GPS location or a complete identity check.
What This Endpoint Answers
Use this endpoint when you need to answer questions like:
- Which country or region does this X account appear to be based in?
- Does the response mark the location signal as accurate?
- Is the account affiliated with an organization or verification label?
- Has the account changed usernames often enough to deserve extra review?
This is useful in workflows such as influencer vetting, partner onboarding, regional campaign review, account-risk scoring, and compliance triage.
API Endpoint
GET https://api.twexapi.io/twitter/{screen_name}/about
Authorization: Bearer <your_token>Path parameter:
| Parameter | Description |
|---|---|
screen_name | X username to inspect, without the @ symbol |
Example request:
curl --request GET \
--url https://api.twexapi.io/twitter/elonmusk/about \
--header 'Authorization: Bearer <your_token>'Response Fields To Use
The response is wrapped in a standard object with code, msg, and data. The data object contains the account details.
1{
2 "code": 200,
3 "msg": "success",
4 "data": {
5 "user_id": "44196397",
6 "name": "Elon Musk",
7 "screen_name": "elonmusk",
8 "account_based_in": "United States",
9 "location_accurate": true,
10 "source": "United States App Store",
11 "username_changes_count": 0,
12 "is_blue_verified": true,
13 "userLabelType": "BusinessLabel",
14 "affiliate_username": "X"
15 }
16}| Field | How to interpret it |
|---|---|
account_based_in | Country or region signal for the account |
location_accurate | Whether the response marks the location signal as accurate |
source | Source information associated with the account, when available |
username_changes_count | Useful for review queues when a handle has changed repeatedly |
userLabelType / affiliate_username | Organization or affiliation context |
is_blue_verified / verification | Verification signals, not proof of identity by themselves |
Python Example
The example below fetches one account and returns a compact review record. Keep the raw response too if the result will be used for audits.
1import os
2import requests
3
4API_BASE = "https://api.twexapi.io"
5TOKEN = os.environ["TWEXAPI_TOKEN"]
6
7def get_account_location(screen_name: str) -> dict:
8 response = requests.get(
9 f"{API_BASE}/twitter/{screen_name}/about",
10 headers={"Authorization": f"Bearer {TOKEN}"},
11 timeout=30,
12 )
13 response.raise_for_status()
14
15 payload = response.json()
16 if payload.get("code") not in (None, 200):
17 raise RuntimeError(payload.get("msg", "TwexAPI request failed"))
18
19 data = payload.get("data") or {}
20 return {
21 "screen_name": data.get("screen_name") or screen_name,
22 "user_id": data.get("user_id"),
23 "account_based_in": data.get("account_based_in"),
24 "location_accurate": data.get("location_accurate"),
25 "source": data.get("source"),
26 "username_changes_count": data.get("username_changes_count"),
27 "is_blue_verified": data.get("is_blue_verified"),
28 "user_label_type": data.get("userLabelType"),
29 "affiliate_username": data.get("affiliate_username"),
30 "raw": data,
31 }
32
33if __name__ == "__main__":
34 result = get_account_location("elonmusk")
35 print(result)Run it with:
TWEXAPI_TOKEN="your_twexapi_bearer_token" python check-account-based-in.pyBatch Review Pattern
The endpoint checks one screen name per request, so batch jobs should loop through a list and write each result as it arrives.
For production use:
- keep a
screen_nameinput file or database table - store
checked_atwith every result - save the raw
dataobject for auditability - normalize
account_based_ininto your own country or region taxonomy - flag missing, unexpected, or low-confidence location results for manual review
- avoid making automatic approval decisions from this field alone
Common Misreads
account_based_in is not the same as the free-form profile location field. It is also not proof that the account owner is physically in that country right now.
location_accurate: true should still be treated as a signal, not a final verdict. For high-impact decisions, combine it with other evidence such as account age, username-change history, organization affiliation, post language, campaign records, and manual review.
Where To Use It
Good places to add this lookup:
- creator and influencer onboarding
- partner or affiliate review
- regional campaign eligibility checks
- suspicious account triage
- market research segmentation
- compliance workflows where account geography matters
The safest pattern is to store the result and show it to reviewers with context. Let the field support decisions instead of making the whole decision.