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

This access control matrix maps each API endpoint to its accepted method. 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 33 prepaid GET 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

10-

250 USD, POST /api/v1/guest-wallets returns a one-use hosted checkout, a guest key, and a status URL without charging. The guest key remains inactive for paid reads until payment is verified. It can authenticate GET /api/v1/guest-wallets/status while pending. Once active, it can call exactly the 33 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 explicitly confirm. 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

Seven fixed-price reads also accept direct MPP payments. 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 all 7 direct MPP operations and fixed prices.

The 26 non-MPP paid reads return 401 with WWW-Authenticate: Bearer and the optional guest wallet action. The 7 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 full key (fullKey) is returned once in the creation response. Store it securely.

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"

Revoked keys are deactivated immediately and cannot be reactivated.

Error response

Invalid or missing API key returns:

{
  "error": "unauthenticated"
}

Status. 401 Unauthorized The API blocks unauthorized access. Replace the credential before retrying API access.

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 a key is accidentally committed, revoke it immediately from your dashboard and generate a new one. Consider the exposed key compromised even if you force-push to remove it from history.

Rotate keys regularly

Rotate API keys periodically to limit the impact of a potential 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. This limits blast radius if a development key is compromised and records usage per environment:

.env.local

# Development
XQUIK_API_KEY=xq_dev_key_here

.env.production

# Production
XQUIK_API_KEY=xq_prod_key_here

Name your keys descriptively (e.g., “Production - Backend”, “Staging”, “Local Dev”) so you can identify them 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