Skip to main content
Guest wallets provide prepaid access to 33 eligible X read routes without an account. Here, account means an Xquik account. No connected X account is required. Use one funded guest key to search tweets. Read profiles, followers, replies, timelines, communities, or lists. No email address or dashboard is required. This is accountless access, not anonymous access. Every guest-wallet paid read requires the active guest key returned during wallet creation. Direct MPP reads use a per-request payment credential.
A 401 or 402 response never creates a checkout. Show the payment choices and amount first. Create a hosted checkout only after the user explicitly confirms. Never submit payment for the user.

​
Accountless Twitter Scraper API Questions

​
What Twitter APIs Work Without Connecting an X Account?

Xquik guest wallets cover 33 documented GET routes. They read tweets, replies, threads, profiles, followers, following, and timelines. Other routes cover communities, lists, trends, relationships, and articles. They do not require a connected X account. The caller still needs one active guest key. Create the wallet, let the user complete checkout, then poll its status. Start reads only when the response reports usable: true. Eligible routes cover tweet lookups, search, replies, threads, and profiles. They also cover followers, following, timelines, communities, lists, and trends. Relationship and article routes are also eligible. Guest access excludes posts, likes, reposts, follows, and messages. It also excludes monitors, webhooks, extractions, draws, and account management. Check the 33-route list below before building the request.

​
Can I Scrape Twitter Without an API Account?

You can read eligible X content without an Xquik account. No email address, dashboard login, or OAuth connection is required. This accountless Twitter scraper uses a prepaid guest key for authentication and credit tracking. Accountless does not mean anonymous. Keep the guest key secret. Send it as a Bearer credential on each eligible read. A missing or inactive key returns the documented 401 or 402 response. Create a wallet only after the user confirms the amount. The hosted checkout does not prove activation. Poll the status route and require usable: true. Store the guest key in a secret manager. Never place it in a URL, log, prompt, or shared export. Use full account credentials for writes, monitors, and webhooks. They also cover extraction jobs, draws, and management routes.

​
Twitter API No Account Required

It means no Xquik account and no connected X account are required. It does not remove authentication, payment confirmation, route scope, or rate limits. The guest key proves access to its funded wallet. Guest access excludes tweet posting, replies, likes, reposts, and follows. It also excludes messages, monitors, webhooks, extractions, draws, and management. Use a full account key or OAuth token for those operations. The guest wallet remains prepaid. The user chooses and confirms a supported amount. They complete hosted checkout and await verified activation. Each eligible read consumes credits under its documented route contract. A 401 or 402 response only presents recovery choices. It does not authorize wallet creation or payment.

​
Accountless Twitter Scraper

Use an accountless Twitter scraper for read-only searches and public profiles. It does not require an Xquik account. A funded guest key can call 33 listed GET routes. It can retrieve tweets, replies, threads, profiles, followers, and following. It can also read timelines, communities, lists, trends, relationships, and articles. This path still uses authentication, credits, route limits, and rate limits. It cannot post, like, repost, follow, or send messages. It cannot create monitors, webhooks, extraction jobs, draws, or account changes. Use stable Tweet and user IDs in stored results. Keep the guest key secret. Poll wallet status before the first paid read.

​
Guest Key Twitter API

Use a guest key for prepaid read-only workflows. It fits tweet search, profile lookup, follower pages, and reply pages. It also fits timelines, community reads, and list reads. Use direct MPP when one supported request carries its own payment. Use a full account credential when the workflow needs broader API coverage. Choose the access method before coding retries. Each method returns different payment and authentication recovery actions. Create the wallet after the user confirms the amount. Send a unique UUID v4 idempotency key. Store both secrets securely. Give only the hosted checkout URL to the user. Poll status until usable: true. Reuse the same guest key after an approved top-up. Do not create a new wallet when one paid read returns insufficient_credits.

​
Choose an access method

Guest wallets do not grant write actions, connected-account reads, monitors, webhooks, extractions, draws, account management, billing management, API-key management, or OAuth access. Full account keys and OAuth behavior remain unchanged.

​
Create and activate a wallet

1

Confirm the amount

Ask the user to choose and explicitly confirm a USD amount from 10through10 through 250. Represent it in cents as amount_minor.
2

Create Hosted Checkout

Call POST /api/v1/guest-wallets with Content-Type: application/json, a cryptographically random UUID v4 Idempotency-Key, and the confirmed amount.
This request creates a one-use hosted checkout. It does not charge the user.
3

Store the credentials

Store the returned api_key and the original Idempotency-Key in a secret manager. The key appears only in the initial response and an exact idempotent replay. No email recovery is available.
4

Give the user the checkout URL

Give only checkout_url to the user. The user completes hosted checkout. Pending checkouts expire after 60 minutes.
5

Poll for verified payment

After payment, poll GET /api/v1/guest-wallets/status every poll_after_seconds with the guest key. Stop when latest_purchase.status is no longer pending.
The key remains inactive for paid reads until status reports usable: true. Checkout completion alone is not proof of activation. Xquik activates credits only after payment is verified.

​
Call paid read routes

Send an active guest key as a Bearer credential:
The paid_reads scope permits exactly the 33 GET routes listed below. It includes batch GET /api/v1/x/tweets, which accepts up to 100 tweet IDs. Every other route is unavailable.

​
Eligible paid-read routes

Guest wallets cover these 33 prepaid GET routes:
  • Tweets: /api/v1/x/tweets, /api/v1/x/tweets/{id}, /api/v1/x/tweets/search, /api/v1/x/tweets/{id}/favoriters, /api/v1/x/tweets/{id}/quotes, /api/v1/x/tweets/{id}/replies, /api/v1/x/tweets/{id}/retweeters, /api/v1/x/tweets/{id}/thread
  • Users: /api/v1/x/users/batch, /api/v1/x/users/search, /api/v1/x/users/{id}, /api/v1/x/users/{id}/followers, /api/v1/x/users/{id}/followers-you-know, /api/v1/x/users/{id}/following, /api/v1/x/users/{id}/likes, /api/v1/x/users/{id}/media, /api/v1/x/users/{id}/mentions, /api/v1/x/users/{id}/replies, /api/v1/x/users/{id}/tweets, /api/v1/x/users/{id}/verified-followers
  • Communities: /api/v1/x/communities/{id}/info, /api/v1/x/communities/{id}/members, /api/v1/x/communities/{id}/moderators, /api/v1/x/communities/{id}/tweets, /api/v1/x/communities/search, /api/v1/x/communities/tweets
  • Lists: /api/v1/x/lists/{id}/followers, /api/v1/x/lists/{id}/members, /api/v1/x/lists/{id}/tweets
  • Trends: /api/v1/trends, /api/v1/x/trends
  • Relationships: /api/v1/x/followers/check
  • Articles: /api/v1/x/articles/{tweetId}
Seven routes also accept direct MPP payment. The other 26 routes require a guest or full account credential.

​
Top up an active wallet

When a guest read returns 402 insufficient_credits, its payment_options advertises only POST /api/v1/guest-wallets/topups. Ask the user to choose and confirm 10−10-250 USD. Then create a new one-use hosted checkout with the existing guest key and a new UUID v4 Idempotency-Key. The top-up response keeps the same wallet and key. It never returns a new key. After payment, poll the same status URL every poll_after_seconds until latest_purchase.status is no longer pending. See Top up guest wallet for the request and response contract.

​
Handle anonymous 401 and 402 responses

The 26 non-MPP paid reads return 401 with a Bearer authentication challenge and a guest wallet creation action:
The JSON body includes payment_options.guest_wallet.create_checkout. That action describes the guest wallet route, amount bounds, required UUID v4 header, and returned fields. The Bearer header requests authentication. It is not a Payment challenge. The 7 direct MPP operations return 402 application/problem+json with WWW-Authenticate: Payment and the same guest wallet action. Complete the MPP challenge or ask the user to confirm a guest wallet amount. Do not create a guest wallet because a request returned 401 or 402. The guest wallet action is an offer, not authorization.

​
Use guest keys with MCP

An active guest key can authenticate the API MCP server. Its explore and xquik tools expose only the 33 eligible GET read routes. Mutations and noneligible routes are unavailable. The 3 guest credential routes remain direct REST only:
  • POST /api/v1/guest-wallets
  • POST /api/v1/guest-wallets/topups
  • GET /api/v1/guest-wallets/status
MCP cannot execute these routes. It may explain the direct REST flow, but the caller must wait for user confirmation before using it. See MCP tools for the scope-specific catalog.

​
Protect wallet access

  • Keep api_key and Idempotency-Key out of URLs, logs, prompts, and shared output.
  • Respect Cache-Control: no-store, private on create, top-up, and status responses.
  • Reuse an idempotency key only for the exact same request.
  • Use usable and the returned status instead of inferring access from checkout state.
  • Refunds and disputes reconcile only affected-purchase credits. Unrelated credits remain usable.
  • Access pauses only during unresolved settlement risk or unrecovered liability. It resumes after resolution.

​
Next steps