X API key authentication for tweets & webhooks

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:

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:

curl https://xquik.com/api/v1/account \
  -H "x-api-key: xq_your_api_key_here"

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

import requests

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

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))
}

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

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.

API key only

GET /account accepts x-api-key. Use it to check plan, credit balance, and monitor billing from server-side integrations.

Session cookie only

POST /api-keys, GET /api-keys, and DELETE /api-keys/{id} require a dashboard session cookie. The session identifies the authenticated user.

Account and billing

PATCH /account, PUT /account/x-identity, and POST /subscribe accept either x-api-key or a dashboard session cookie.

Events and webhooks

* /monitors/*, GET /events/*, * /webhooks/*, and GET /webhooks/{id}/deliveries accept either auth method.

Tweets, exports, and X actions

* /draws/*, * /extractions/*, * /x/*, POST /x/media/download, * /x-accounts/*, and * /x-write/* accept either auth method.

Content tools and support

GET /trends, GET /radar, * /styles/*, * /drafts/*, POST /compose, and * /support/* accept either auth method.

Guest paid reads

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.

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

The MCP server also supports OAuth 2.1 with PKCE for browser-based clients. See OAuth 2.1 for current client compatibility and setup.

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.

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.

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 for the complete flow.

Machine Payments Protocol

Direct MPP 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

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:

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:

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 for every direct MPP operation and fixed prices.

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.

Key management

Create a key

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

Create API Key

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

Revoke API Key

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:

{
  "error": "unauthenticated"
}

Status. 401 Unauthorized Replace the credential before retrying.

Security best practices

Apply these API security controls to every environment.

Store keys in environment variables

Never hardcode API keys in your source code. Use environment variables to keep keys separate from your codebase:

.env

XQUIK_API_KEY=xq_your_api_key_here

Access the key in your application:

const apiKey = process.env.XQUIK_API_KEY;

import os

api_key = os.environ["XQUIK_API_KEY"]

apiKey := os.Getenv("XQUIK_API_KEY")

Never commit keys to version control

Add .env to your .gitignore to prevent accidental commits:

.gitignore

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

Rotate keys on a schedule

Rotate API keys on a schedule to limit the damage from a leak:

Create a new key from the dashboard
Update the key in all your environments
Verify all services work with the new key
Revoke the old key

Xquik supports multiple active keys, so you can rotate without downtime.

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:

.env.local

# Development
XQUIK_API_KEY=xq_dev_key_here

.env.production

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

Next steps. Quickstart for a complete setup walkthrough, or OAuth Overview for OAuth 2.1 integration.

​API key format

​Using your API key

​Auth methods by endpoint

API key only

Session cookie only

Account and billing

Events and webhooks

Tweets, exports, and X actions

Content tools and support

Guest paid reads

​Accountless guest keys

​Machine Payments Protocol

​Challenge header

​Credential header

​Receipt header

​Eligible endpoints

​Key management

​Create a key

​Revoke a key

​Error response

​Security best practices

API key format

Using your API key

Auth methods by endpoint

Accountless guest keys

Machine Payments Protocol

Challenge header

Credential header

Receipt header

Eligible endpoints

Key management

Create a key

Revoke a key

Error response

Security best practices