How to Use GetXAPI Like a Pro — Best Practices for Production

GetXAPI gives you Twitter data at $0.05 per 1,000 tweets — but how you call the API matters just as much as what you pay. Bad retry logic wastes credits. Missing pagination means missing data. Skipping proxies on write endpoints gets requests blocked.

This guide covers the patterns that separate a quick prototype from a production-grade integration. These practices apply not just to GetXAPI, but to any third-party API you work with.

---

1. Always Use Retry Logic with Exponential Backoff

This is rule #1 for any API integration — not just GetXAPI. Network blips, upstream hiccups, and rate limits happen. If you don't retry, you lose data. If you retry too aggressively, you make things worse.

Which errors to retry

Status Code	Meaning	Retry?
200	Success	No (you're done)
400	Bad request (invalid params)	No — fix your request
401	Invalid API key or auth_token	No — fix your credentials
404	User/tweet doesn't exist	No — it's gone
429	Rate limit exceeded	Yes — wait and retry
502	Bad gateway (upstream issue)	Yes — wait and retry
503	Service temporarily unavailable	Yes — wait and retry

Why jitter matters

Without jitter, if 100 clients hit a rate limit at the same time, they all retry at exactly the same moment — creating a "thundering herd" that makes the problem worse. Adding a random 0–1 second delay spreads the retries out.

Don't retry everything

This is a common mistake. Retrying a 401 (bad API key) 3 times just wastes 3 API calls. Retrying a 404 (deleted tweet) won't bring it back. Only retry transient errors: 429, 502, 503, and network timeouts.

---

2. Use Proxy for Write Endpoints

Write endpoints like Create Tweet and DM Send execute actions on Twitter using your auth_token. By default, these requests originate from GetXAPI's servers — which means Twitter sees GetXAPI's IP, not yours.

For higher reliability and to avoid detection patterns, pass your own proxy so the request appears to come from your IP or a residential proxy.

Which endpoint supports proxy

Currently only POST /twitter/tweet/create supports the proxy parameter. Pass your residential proxy URL in the request body so the tweet is posted from your IP instead of GetXAPI's servers.

Proxy best practices

1. Use residential proxies — datacenter IPs get flagged faster
2. Rotate proxies if you're posting from multiple accounts
3. Match geography — if your Twitter account is based in the US, use a US proxy
4. Test before scaling — verify your proxy works with a single tweet before running bulk operations
5. Never share proxies across accounts that shouldn't be linked

When you don't need a proxy

Read endpoints (search, user info, followers, etc.) don't need proxies. They fetch public data and don't write to any account. Save your proxy budget for write operations only.

---

3. Use Cursor-Based Pagination Properly

Most GetXAPI endpoints return ~20 results per call. If you need more, you paginate using cursors. Getting this wrong is the #1 cause of incomplete data.

Which endpoints support pagination

Endpoint	Results per Page	Cursor Field
tweet/advanced_search	~20 tweets	next_cursor
tweet/replies	~20 replies	next_cursor
user/search	~20 users	next_cursor
user/followers	up to 200	next_cursor
user/followers_v2	~70	next_cursor
user/following	up to 200	next_cursor
user/following_v2	~70	next_cursor
user/verified_followers	~20	next_cursor
user/media	~20 posts	next_cursor
user/tweets	~20 tweets	next_cursor
user/tweets_and_replies	~20 tweets	next_cursor
user/likes	~20 tweets	next_cursor
user/home_timeline	~20 tweets	next_cursor
user/bookmark_search	~20 tweets	next_cursor
user/followers_you_know	~20	next_cursor
list/members	~20 members	next_cursor
dm/list	~50 messages	next_cursor

Advanced Search pagination is currently broken

As of 2026, Twitter's own cursor pagination for Advanced Search is broken upstream — next_cursor sometimes returns duplicate results or stops early. This is a Twitter-side issue, not a GetXAPI issue.

The workaround: Split your query into smaller date-range chunks using since: and until: operators instead of relying on deep cursor pagination.

For example, instead of one big query like q=AI lang:en that breaks after a few pages, split it into weekly chunks:

• q=AI lang:en since:2026-01-01 until:2026-01-07
• q=AI lang:en since:2026-01-07 until:2026-01-14
• q=AI lang:en since:2026-01-14 until:2026-01-21
• ...and so on

Each chunk gets its own fresh cursor chain — much more reliable than deep pagination on a single query.

If results are changing by the minute or second (e.g., trending topics, breaking news), add time precision to since: and until::

• q=from:elonmusk since:2026-01-01_12:00:00_UTC until:2026-01-01_18:00:00_UTC

This gives you hourly or even minute-level control over which tweets you fetch.

For a full reference of all Advanced Search operators (from:, to:, min_faves:, filter:, lang:, etc.), see twitter-advanced-search on GitHub.

Pagination mistakes to avoid

1. Don't ignore has_more — always check it. If you just check next_cursor, you might make one extra unnecessary call.
2. Don't hardcode page counts — use has_more as the stop condition, but set a maxPages safety limit.
3. Add a delay between pages if you're paginating aggressively (e.g., 200ms between calls) to avoid hitting rate limits.
4. Store cursors if your job might crash mid-pagination — you can resume from where you left off instead of starting over.

---

4. Use the Right Endpoint for the Job

GetXAPI has 31 endpoints. Some look similar but serve different purposes. Using the wrong one wastes credits and returns incomplete data.

User Info vs User About

	user/info	user/about
Basic profile	Yes	Yes
Extended metadata	No	Yes (creation date, location, username history)
Cost	$0.001	$0.001

Rule of thumb: Use user/info for quick lookups (name, bio, follower count). Use user/about when you need full account history.

---

5. Handle Auth Tokens Correctly

Some endpoints require an auth_token — this is a Twitter session token from your browser cookies or from the GetXAPI login endpoint.

Which endpoints need auth_token

Endpoint	Needs auth_token	Why
tweet/create	Yes	Posts as a specific user
tweet/favorite	Yes	Likes as a specific user
tweet/retweet	Yes	Retweets as a specific user
dm/send	Yes	Sends DM from a specific user
dm/list	Yes	Reads a specific user's DMs
user/home_timeline	Yes	User's personalized timeline
user/bookmark_search	Yes	User's private bookmarks
user/likes	Yes	User's liked tweets
user/followers_you_know	Yes	Mutual followers context

DM endpoints require a Twitter passcode

Before you can use dm/list or dm/send, you need to set a DM passcode on your Twitter/X account first. This is a Twitter security requirement — DM endpoints access private conversations, so Twitter requires an additional verification step.

How to set it up:

1. Go to Twitter/X Settings → Privacy and Safety → Direct Messages
2. Set your DM passcode there

Without a passcode set on Twitter, DM endpoints will return an error. This applies to both dm/list (reading DMs) and dm/send (sending DMs).

Token handling best practices

1. Never log auth tokens — treat them like passwords
2. Store tokens in environment variables, not in code
3. Tokens expire — if you get a 401, re-authenticate
4. One token per account — don't share tokens across different Twitter accounts
5. GetXAPI never stores your tokens — they're used in-flight and discarded

---

6. Cost Optimization Tips

Every API call costs $0.001 (~20 tweets). Here's how to get the most out of your credits:

1. Don't re-fetch data you already have. Cache tweet IDs and user profiles locally. Check your cache before making an API call.

2. Use tweet/detail sparingly. If you already got tweet data from advanced_search, don't call tweet/detail for the same tweet.

3. Use v1 followers for bulk, v2 for DM outreach. v1 returns 200/page vs v2's 70/page — fewer calls for the same follower list.

4. Use search operators to narrow results. min_faves:100 filters out low-engagement tweets before they consume a page slot.

5. Paginate with a purpose. If you only need the first 100 tweets, set maxPages = 5. Don't paginate to the end unless you need everything.

6. Batch your work. Instead of checking one user at a time, design your pipeline to process users in batches with shared pagination state.

Cost math at scale

Volume	API Calls	Cost	What You Get
1K tweets	50 calls	$0.05	Quick analysis
10K tweets	500 calls	$0.50	Small dataset
100K tweets	5,000 calls	$5.00	Research project
1M tweets	50,000 calls	$50.00	Full-scale pipeline

---

Quick Reference Cheat Sheet

Practice	Do	Don't
Retry logic	Retry 429, 502, 503 with backoff	Retry 400, 401, 404
Proxy	Use for write endpoints (create, DM)	Use for read endpoints
Pagination	Check has_more + next_cursor	Hardcode page counts
Auth token	Store in env vars, rotate on 401	Hardcode in source
Cost	Cache results, use search operators	Re-fetch data you already have

---

Start Building

GetXAPI gives you $0.10 in free credits at signup — that's ~100 API calls (~2,000 tweets) with no credit card. Enough to test every pattern in this guide.

1. Sign up at getxapi.com
2. Get your API key from the dashboard
3. Read the full API documentation for endpoint-specific parameters and response schemas