How Xquik works. Architecture, security model, data isolation, rate limits, and platform limitations
Xquik is a hosted SaaS platform for X (Twitter) data. All data processing happens server-side. There is no infrastructure to deploy, no workers to manage, and no X API credentials to configure. You interact with Xquik through the REST API, MCP server, or dashboard.
Xquik uses API key authentication for all API and MCP access. The MCP server also supports OAuth 2.1 for platforms that require it (Claude.ai, ChatGPT Developer Mode).
Aspect
Detail
Header
x-api-key (lowercase, required on every request)
Key format
xq_ prefix + 64 hex characters
Storage
Keys are hashed at rest. Xquik never stores plaintext keys
Revocation
Instant via dashboard or API. Revoked keys return 401 immediately
Last used
Tracked per key for audit purposes
OAuth 2.1
MCP server supports OAuth 2.1 with PKCE for Claude.ai and ChatGPT Developer Mode
Session auth
Dashboard uses session cookies (magic link login)
API keys are shown once at creation. Store them securely. There is no way to retrieve a key after creation.
Xquik uses a flat permission model: no roles, no RBAC, no team workspaces.
One user, one account: Each account has full access to all its own resources
API key = full access: Any valid API key for an account can perform all operations that account is authorized for
Session-only endpoints: API key management (/api/v1/api-keys/*) requires session auth (dashboard login), not API key auth. You cannot create or revoke API keys using an API key.
Subscription gates: Metered endpoints (extractions, draws, X lookups) require an active subscription. Management endpoints (monitors, webhooks, events) work without a subscription.
Rate limits are enforced per user account using a fixed-window counter algorithm. Each tier has an independent counter that resets every 60 seconds.
Tier
Methods
Limit
Read
GET, HEAD, OPTIONS
120 per 60s
Write
POST, PUT, PATCH
30 per 60s
Delete
DELETE
15 per 60s
When the limit is reached, requests return 429 Too Many Requests with a Retry-After: 60 header.See the Rate Limits guide for detailed explanations, backoff strategies, and client-side rate limiter code examples.