> ## 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.

# X API key authentication for tweets & webhooks

> Authenticate tweets, follower exports, monitors, webhooks, and X writes with Xquik API keys, guest keys, OAuth 2.1, sessions, or MPP. Lists methods per route.

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

Authenticate tweet, follower, monitor, webhook, and write requests with an
Xquik API key. This REST API authentication guide also covers guest keys,
OAuth 2.1, sessions, and MPP.

Xquik keys authenticate Xquik endpoints only. They are not an official Twitter
API key or X API token. Choose the narrowest method that covers the route.

## API key format

Account and guest keys follow this format:

```text theme={null}
xq_your_api_key_here
```

* **Prefix.** `xq_`
* **Body.** 64 hexadecimal characters
* **Storage.** Keep each REST API key in a secret manager. Never log or commit it.

## Using your API key

Send account API requests with the `x-api-key` request header:

<CodeGroup>
  ```bash cURL theme={null}
  curl https://xquik.com/api/v1/account \
    -H "x-api-key: xq_your_api_key_here"
  ```

  ```javascript Node.js theme={null}
  const response = await fetch("https://xquik.com/api/v1/account", {
    headers: { "x-api-key": "xq_your_api_key_here" },
  });
  ```

  ```python Python theme={null}
  import requests

  response = requests.get(
      "https://xquik.com/api/v1/account",
      headers={"x-api-key": "xq_your_api_key_here"},
  )
  ```

  ```go Go theme={null}
  package main

  import (
  	"fmt"
  	"io"
  	"net/http"
  )

  func main() {
  	req, _ := http.NewRequest("GET", "https://xquik.com/api/v1/account", nil)
  	req.Header.Set("x-api-key", "xq_your_api_key_here")

  	resp, err := http.DefaultClient.Do(req)
  	if err != nil {
  		panic(err)
  	}
  	defer resp.Body.Close()

  	body, _ := io.ReadAll(resp.Body)
  	fmt.Println(string(body))
  }
  ```
</CodeGroup>

For Bearer tokens, send the same key in the authorization header:

```text theme={null}
Authorization: Bearer xq_your_api_key_here
```

Use Bearer authentication for guest keys. An `xq_` value remains an Xquik API
key. OAuth 2.1 access tokens omit the `xq_` prefix.

## Auth methods by endpoint

The cards below list the auth method each endpoint accepts. Most
routes accept an API key or dashboard session cookie.

<CardGroup cols={2}>
  <Card title="API key only" icon="key-round">
    `GET /account` accepts `x-api-key`. Use it to check plan, credit balance, and monitor billing from server-side integrations.
  </Card>

  <Card title="Session cookie only" icon="shield">
    `POST /api-keys`, `GET /api-keys`, and `DELETE /api-keys/{id}` require a dashboard session cookie. The session identifies the authenticated user.
  </Card>

  <Card title="Account and billing" icon="user-cog">
    `PATCH /account`, `PUT /account/x-identity`, and `POST /subscribe` accept either `x-api-key` or a dashboard session cookie.
  </Card>

  <Card title="Events and webhooks" icon="radio">
    `* /monitors/*`, `GET /events/*`, `* /webhooks/*`, and `GET /webhooks/{id}/deliveries` accept either auth method.
  </Card>

  <Card title="Tweets, exports, and X actions" icon="database">
    `* /draws/*`, `* /extractions/*`, `* /x/*`, `POST /x/media/download`, `* /x-accounts/*`, and `* /x-write/*` accept either auth method.
  </Card>

  <Card title="Content tools and support" icon="sparkles">
    `GET /trends`, `GET /radar`, `* /styles/*`, `* /drafts/*`, `POST /compose`, and `* /support/*` accept either auth method.
  </Card>

  <Card title="Guest paid reads" icon="wallet-cards">
    A guest key has scope `paid_reads`. It authenticates only the prepaid paid-read routes plus guest status and top-up. It never grants account, write, automation, account credential, or OAuth access.
  </Card>
</CardGroup>

<Info>
  API key creation, listing, and revocation require a same-origin dashboard
  session. API keys and OAuth bearer tokens cannot manage API keys.
</Info>

<Info>
  The MCP server also supports OAuth 2.1 with PKCE for browser-based clients.
  See [OAuth 2.1](/oauth/overview) for current client compatibility and setup.
</Info>

## Accountless guest keys

After the user confirms USD 10 to 250, `POST /api/v1/guest-wallets` returns
a one-use hosted checkout, a guest key, and a status URL without charging.

The guest key stays inactive for paid reads until Xquik verifies payment. It can authenticate `GET /api/v1/guest-wallets/status` while pending. Once active, it can call exactly the [eligible paid-read routes](/guides/guest-wallets#eligible-paid-read-routes).

<Warning>
  Never create a guest wallet or top-up automatically after a `401` or `402`. Ask the user to choose an amount and confirm it. The user must open and complete the hosted checkout.
</Warning>

Guest credential routes are direct REST only. The API MCP server never exposes wallet creation, status, or top-up as executable operations. See [Accountless guest wallets](/guides/guest-wallets) for the complete flow.

## Machine Payments Protocol

Direct [MPP](/mpp/machine-payments-protocol) payments also cover 7
fixed-price reads. This replaces API key
authentication for those reads. Without credentials, the API server returns a
402 payment challenge.

### Challenge header

```text theme={null}
WWW-Authenticate: Payment id="challenge_id_here", realm="xquik.com", method="tempo", intent="charge", request="payment_request_here"
```

| Parameter | Description |
| - | - |
| `id` | Unique challenge identifier |
| `realm` | Protection space (`xquik.com`) |
| `method` | Payment method (`tempo`) |
| `intent` | Payment intent (`charge`) |
| `request` | Base64url-encoded JSON with amount, currency, and recipient |

### Credential header

After completing the payment, retry the request with a payment credential:

```text theme={null}
Authorization: Payment <base64url-encoded JSON>
```

The credential contains the original challenge parameters and a method-specific payload proving payment.

### Receipt header

Settled responses include a receipt:

```text theme={null}
Payment-Receipt: <base64url-encoded JSON>
```

The receipt confirms settlement with a reference ID and timestamp. Every
response after accepted payment includes this header, including non-2xx
responses. Check the HTTP status and response body. Confirm application
success before processing the result.

### Eligible endpoints

See the [MPP overview](/mpp/machine-payments-protocol#eligible-endpoints) for every direct MPP operation and fixed prices.

<Info>
  The non-MPP paid reads return `401` with `WWW-Authenticate: Bearer` and the optional guest wallet action. The direct MPP operations return `402` with `WWW-Authenticate: Payment` and the same guest action. A failed read never creates checkout.
</Info>

## Key management

### Create a key

Generate keys from the **API Keys** page in your dashboard or via the API (session auth only):

```bash Create API Key theme={null}
curl -X POST https://xquik.com/api/v1/api-keys \
  -H "Cookie: session_token=your_session_token_here" \
  -H "Content-Type: application/json" \
  -d '{"name": "Production"}'
```

The creation response returns the full key (`fullKey`) once. Store it in a secret manager.

### Revoke a key

```bash Revoke API Key theme={null}
curl -X DELETE https://xquik.com/api/v1/api-keys/123 \
  -H "Cookie: session_token=your_session_token_here"
```

Xquik deactivates revoked keys immediately. You cannot reactivate them.

## Error response

Invalid or missing API key returns:

```json theme={null}
{
  "error": "unauthenticated"
}
```

**Status.** `401 Unauthorized`

Replace the credential before retrying.

## Security best practices

Apply these API security controls to every environment.

<AccordionGroup>
  <Accordion title="Store keys in environment variables">
    Never hardcode API keys in your source code. Use environment variables to keep keys separate from your codebase:

    ```bash .env theme={null}
    XQUIK_API_KEY=xq_your_api_key_here
    ```

    Access the key in your application:

    <CodeGroup>
      ```javascript Node.js theme={null}
      const apiKey = process.env.XQUIK_API_KEY;
      ```

      ```python Python theme={null}
      import os

      api_key = os.environ["XQUIK_API_KEY"]
      ```

      ```go Go theme={null}
      apiKey := os.Getenv("XQUIK_API_KEY")
      ```
    </CodeGroup>
  </Accordion>

  <Accordion title="Never commit keys to version control">
    Add `.env` to your `.gitignore` to prevent accidental commits:

    ```bash .gitignore theme={null}
    # Environment variables
    .env
    .env.local
    .env.production
    ```

    If you commit a key by accident, revoke it immediately from your dashboard and generate a new one. Treat the exposed key as compromised even if you force-push to remove it from history.
  </Accordion>

  <Accordion title="Rotate keys on a schedule">
    Rotate API keys on a schedule to limit the damage from a leak:

    1. Create a new key from the dashboard
    2. Update the key in all your environments
    3. Verify all services work with the new key
    4. Revoke the old key

    Xquik supports multiple active keys, so you can rotate without downtime.
  </Accordion>

  <Accordion title="Use separate keys for development & production">
    Create distinct API keys for each environment. A leaked development key then cannot reach production. Each key also records usage for its environment:

    ```bash .env.local theme={null}
    # Development
    XQUIK_API_KEY=xq_dev_key_here
    ```

    ```bash .env.production theme={null}
    # Production
    XQUIK_API_KEY=xq_prod_key_here
    ```

    Give each key a descriptive name, such as "Production Backend", "Staging", or "Local Dev". The name identifies the key in the dashboard.
  </Accordion>
</AccordionGroup>

<Note>
  **Next steps.** [Quickstart](/x-api-quickstart) for a complete setup walkthrough, or [OAuth Overview](/oauth/overview) for OAuth 2.1 integration.
</Note>


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