> ## Documentation Index
> Fetch the complete documentation index at: https://docs.xquik.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Accountless Twitter scraper API with guest wallets

> Read tweets, profiles, followers, replies, timelines, and communities without an Xquik account. No connected X account is required. Fund one guest key.

<blockquote className="agent-llms-directive">
  For the complete documentation index, see <a href="/llms.txt">llms.txt</a>.
</blockquote>

Guest wallets provide prepaid access to the eligible X read routes without an account. Here, account means an Xquik account. You need no connected X account. Use one funded guest key to search tweets. Read profiles, followers, replies, timelines, communities, or lists. You need no email address or dashboard.

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.

<Warning>
  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.
</Warning>

## Accountless Twitter scraper API questions

### What Twitter APIs work without connecting an X account?

Xquik guest wallets cover the documented paid-read routes below. They read
tweets, replies, threads, profiles, followers, following, and timelines. Other
routes cover communities, lists, trends, relationships, articles, and AI
analysis. 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
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. You need no email address,
dashboard login, or OAuth connection. 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 you need no Xquik account and no connected X account. 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 the listed
paid-read routes. It can retrieve tweets, replies, threads, profiles, followers, and
following. It can also read timelines, communities, lists, trends,
relationships, articles, and job listings.

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

| Access method | Account | Credential | Coverage | Payment |
| - | - | - | - | - |
| Account API key | Required | Full-scope API key | Full authenticated API | Available account credits. Plans add monthly credits. |
| OAuth 2.1 | Required | OAuth Bearer token | Same account capabilities granted by OAuth | Available account credits. Plans add monthly credits. |
| Guest wallet | Not required | `paid_reads` API key | Only the prepaid paid-read routes | USD 10 to 250 hosted checkout |
| MPP | Not required | Per-request payment credential | Fixed-price GET operations | Per-request payment |

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

<Steps>
  <Step title="Confirm the amount">
    Ask the user to choose and explicitly confirm an amount from USD 10 through USD 250. Represent it in cents as `amount_minor`.
  </Step>

  <Step title="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.

    ```bash theme={null}
    idempotency_key=$(uuidgen | tr '[:upper:]' '[:lower:]')
    response=$(curl -sS -X POST https://xquik.com/api/v1/guest-wallets \
      -H "Content-Type: application/json" \
      -H "Idempotency-Key: $idempotency_key" \
      -d '{"amount_minor": 1000, "currency": "usd"}')
    api_key=$(jq -r '.api_key' <<<"$response")
    checkout_url=$(jq -r '.checkout_url' <<<"$response")
    # Store $api_key and $idempotency_key as secrets. Give only $checkout_url to the user.
    ```

    This request creates a one-use hosted checkout. It does not charge the user.
  </Step>

  <Step title="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.
  </Step>

  <Step title="Give the user the checkout URL">
    Give only `checkout_url` to the user. The user completes hosted checkout. Pending checkouts expire after 60 minutes.
  </Step>

  <Step title="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`.

    ```bash theme={null}
    curl https://xquik.com/api/v1/guest-wallets/status \
      -H "Authorization: Bearer xq_your_guest_key_here" | jq
    ```

    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 it verifies payment.
  </Step>
</Steps>

## Call paid read routes

Send an active guest key as a Bearer credential:

```bash theme={null}
curl "https://xquik.com/api/v1/x/tweets?ids=1893456789012345678,1893456789012345679" \
  -H "Authorization: Bearer xq_your_guest_key_here" | jq
```

The `paid_reads` scope permits exactly the routes listed below: GET reads and the 6 POST analysis routes. 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 prepaid routes. All are GET routes except the 6 POST analysis routes:

* **Tweets.** `/api/v1/x/tweets`, `/api/v1/x/tweets/{id}`, `/api/v1/x/tweets/{id}/hidden-replies`, `/api/v1/x/tweets/{id}/retweeters/check`, `/api/v1/x/tweets/search`, `/api/v1/x/tweets/{id}/quotes`, `/api/v1/x/tweets/{id}/replies`, `/api/v1/x/tweets/{id}/retweeters`, `/api/v1/x/tweets/{id}/thread`, `/api/v1/x/tweets/{id}/translation`, `/api/v1/x/tweets/{id}/embed`, `/api/v1/x/tweets/{id}/subtitles`, `/api/v1/x/links/resolve`
* **Users.** `/api/v1/x/users/batch`, `/api/v1/x/users/batch/tweets`, `/api/v1/x/users/search`, `/api/v1/x/users/{id}`, `/api/v1/x/users/{id}/articles`, `/api/v1/x/users/{id}/follower-ids`, `/api/v1/x/users/{id}/followers`, `/api/v1/x/users/{id}/following`, `/api/v1/x/users/{id}/following-ids`, `/api/v1/x/users/{id}/subscriptions`, `/api/v1/x/users/{id}/affiliates`, `/api/v1/x/users/{id}/similar`, `/api/v1/x/users/{id}/highlights`, `/api/v1/x/users/{id}/list-memberships`, `/api/v1/x/users/{id}/lists`, `/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`
* **Search.** `/api/v1/x/search/autocomplete`
* **Spaces.** `/api/v1/x/spaces/search`, `/api/v1/x/spaces/{id}`, `/api/v1/x/spaces/{id}/replay`
* **Broadcasts.** `/api/v1/x/broadcasts/{id}`
* **Communities.** `/api/v1/x/communities/find`, `/api/v1/x/communities/popular`, `/api/v1/x/communities/suggested`, `/api/v1/x/communities/topics`, `/api/v1/x/communities/{id}/info`, `/api/v1/x/communities/{id}/media`, `/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/search`, `/api/v1/x/lists/{id}/followers`, `/api/v1/x/lists/{id}/members`, `/api/v1/x/lists/{id}/tweets`
* **Jobs.** `/api/v1/x/jobs/search`, `/api/v1/x/jobs/{id}`, `/api/v1/x/jobs/locations`
* **Trends.** `/api/v1/trends`, `/api/v1/x/trends`, `/api/v1/x/trends/locations`, `/api/v1/x/hashflags`
* **Places.** `/api/v1/x/places/search`
* **Relationships.** `/api/v1/x/followers/check`
* **Articles.** `/api/v1/x/articles/{tweetId}`
* **Analysis (POST).** `/api/v1/x/analysis/sentiment`, `/api/v1/x/analysis/brand`, `/api/v1/x/analysis/news`, `/api/v1/x/analysis/market-signals`, `/api/v1/x/analysis/viral-score`, `/api/v1/x/analysis/classify`

Some of these routes also accept [direct MPP payment](/mpp/machine-payments-protocol#eligible-endpoints). The others require a guest or full account credential.

`/favoriters`, `/likes` & `/followers-you-know` read through your own connected X account. They are not guest routes. Guest keys get `403 forbidden` on them.

## 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 USD 10 to 250. 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](/api-reference/guest-wallets/topup) for the request and response contract.

## Handle anonymous 401 and 402 responses

The non-MPP paid reads return `401` with a Bearer authentication challenge and a guest wallet creation action:

```text theme={null}
HTTP/2 401
WWW-Authenticate: Bearer realm="xquik"
Content-Type: application/json
```

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 [direct MPP operations](/mpp/machine-payments-protocol#eligible-endpoints) 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 `search` and `execute` tools expose only the eligible paid-read routes. The `docs` tool remains available. Writes and all other 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](/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

* [Create guest wallet](/api-reference/guest-wallets/create)
* [Get guest wallet status](/api-reference/guest-wallets/status)
* [Top up guest wallet](/api-reference/guest-wallets/topup)
* [MPP overview](/mpp/machine-payments-protocol)
* [Authentication](/api-reference/authentication)


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.