Skip to main content
Use Xquik in Make when a scenario needs X (Twitter) search, account lookups, trends, publishing, extraction jobs, monitors, or webhook automation without an X Developer app. Make discontinued its native X app in 2025. Start with a private Make custom app so your team can keep scenarios focused, test auth safely, and decide later whether to request public app review.

​
Prerequisites

  • Xquik API key
  • Make organization with Custom Apps access
  • HTTPS Make webhook URL for instant monitor-event scenarios
  • Optional Slack, Sheets, Airtable, or CRM module for downstream steps

​
App Shape

Connection

Use an API key parameter named apiKey and inject it as x-api-key.

Base URL

Call Xquik REST modules from https://xquik.com/api/v1.

Modules

Start with Search Tweets, Get Tweet, Get User, Get Trends, Create Tweet, Create Extraction, Create Monitor, Create Webhook, and Make an API Call.

Triggers

Support Monitor Event instant webhooks and Extraction Completed polling.

Error handling

Map 401, 402, 429, and 5xx to short scenario messages.
Make custom apps split this into a connection, base request settings, modules, and optional webhook components. Use Xquik’s /account endpoint as the connection test because it validates the API key without mutating data.

​
Connection

Create a connection parameter that stores the API key as a password field: 
[
  {
    "name": "apiKey",
    "label": "Xquik API Key",
    "type": "password",
    "required": true,
    "editable": true,
    "help": "Create an API key in the Xquik dashboard."
  }
]
Use GET /account to validate the connection: 
{
  "url": "https://xquik.com/api/v1/account",
  "method": "GET",
  "headers": {
    "x-api-key": "{{parameters.apiKey}}"
  },
  "response": {
    "metadata": {
      "type": "email",
      "value": "{{body.email}}"
    },
    "error": {
      "message": "{{body.message || body.error || 'Xquik authentication failed.'}}"
    }
  },
  "log": {
    "sanitize": ["request.headers.x-api-key"]
  }
}

​
Base Request Pattern

Use one base request pattern for JSON modules: 
{
  "baseUrl": "https://xquik.com/api/v1",
  "headers": {
    "x-api-key": "{{connection.apiKey}}",
    "content-type": "application/json"
  },
  "response": {
    "error": {
      "message": "{{body.message || body.error || 'Xquik request failed.'}}"
    }
  },
  "log": {
    "sanitize": ["request.headers.x-api-key"]
  }
}
Handle status codes consistently:

401 authentication

Authentication failed. Check the Xquik API key.

402 billing state

Subscription or credits required. Update billing in Xquik.

429 rate limit

Rate limited. Respect the Retry-After header before retrying.

5xx transient

Xquik service unavailable. Retry with exponential backoff.

​
Starter Modules

Search Tweets

Search module. Call GET /x/tweets/search with q; use cursor for page loops and keep limit on bounded resumes.

Get Tweet

Action module. Call GET /x/tweets/{id} with a tweet ID.

Get User

Action module. Call GET /x/users/{id} with a user ID or username.

Get Trends

Search module. Call GET /x/trends with optional woeid and count.

Create Tweet

Action module. Call POST /x/tweets with account, text, and optional public media URLs.

Create Extraction

Action module. Call POST /extractions with toolType, query fields, and result limit.

Create Monitor

Action module. Call POST /monitors with username and event types.

Create Webhook

Action module. Call POST /webhooks with callback URL and event types.

Make an API Call

Universal module. Accept any /api/v1 path as an escape hatch for endpoints not yet modeled.
Example Search Tweets module communication: 
{
  "url": "/x/tweets/search",
  "method": "GET",
  "qs": {
    "q": "{{parameters.q}}",
    "cursor": "{{parameters.cursor}}"
  },
  "response": {
    "iterate": "{{body.tweets}}",
    "output": {
      "id": "{{item.id}}",
      "text": "{{item.text}}",
      "authorUsername": "{{item.author.username}}",
      "url": "{{item.url}}"
    }
  }
}
Add a bounded-pull variant that sends limit. If body.has_next_page is true, send body.next_cursor as cursor with the same q, filters, and limit.

​
Output Handoff

Make response handling lets search modules iterate over body.tweets while body stays available for output, wrapper, and pagination fields. Emit tweet bundles from item, then carry setup IDs, write status, and page cursors in scenario state when downstream modules need another request. Use snake_case keys for data-store rows even when the API response uses camelCase.

Tweet search page

Store q, each tweet_id, text, author_username, created_at, has_next_page, and next_cursor.

User profile rows

Store source id as user_id, plus username, name, followers, verified, and profile_picture. For user-list modules, carry has_next_page and next_cursor.

Trend rows

Store each trend name, rank, query, and description; keep body.count, body.woeid, and the selected region in scenario state.

Tweet or reply write

Store tweet_id, charged, and charged_credits on a 200 response. For 202 x_write_unconfirmed, store write_action_id, status, charged, and charged_credits, then poll GET /x/write-actions/{id} before retrying.

Media attachments

For tweets or replies, pass public URLs in media and store tweet_id or write_action_id. For DMs, upload first, pass one media_id in media_ids, store message_id, and leave reply_to_message_id unset.

Monitor and webhook setup

Store monitor id, username, xUserId, eventTypes, isActive, nextBillingAt, webhook id, url, eventTypes, and the one-time secret. For Make storage rows, map production deliveryId to delivery_id for receiver retry de-dupe and streamEventId to stream_event_id when one monitor event should process once across endpoint changes.

Extraction jobs

Store id, tool_type, and status from POST /extractions; poll GET /extractions/{id}, then carry has_more and next_cursor.

Webhook event dedupe

Store deliveryId for endpoint-level retry dedupe and streamEventId when one monitor event must process once across receiver changes.

Stored Event Replay

Call GET /api/v1/events with after when a scenario needs replay. Map id, monitorId, monitorType, occurredAt, hasMore, and nextCursor to event_id, monitor_id, monitor_type, occurred_at, has_more, and next_cursor.

Receiver acceptance

Return 2xx after accepting duplicate deliveryId or streamEventId; keep endpoint signing values, raw request body, raw signature, and full headers out of scenario logs, data stores, Slack messages, CRM rows, and retry queues.

​
Instant Trigger: Monitor Events

Use a dedicated Make webhook for monitor events. Register that webhook URL in Xquik: 
{
  "url": "https://xquik.com/api/v1/webhooks",
  "method": "POST",
  "body": {
    "url": "{{webhook.url}}",
    "eventTypes": ["tweet.new", "tweet.reply", "tweet.quote", "tweet.retweet"]
  }
}
Then create or confirm the monitor: 
{
  "url": "https://xquik.com/api/v1/monitors",
  "method": "POST",
  "body": {
    "username": "xquikcom",
    "eventTypes": ["tweet.new", "tweet.reply", "tweet.quote", "tweet.retweet"]
  }
}
Map webhook output fields for downstream modules:

Event type

Map eventType to route tweet.new, tweet.reply, tweet.quote, and tweet.retweet events.

Delivery ID

Map deliveryId as the per-endpoint idempotency key for retries.

Stream event ID

Map streamEventId when one monitor event should process once across endpoint changes.

Occurred at

Map occurredAt as the event timestamp.

Username

Map username for account monitor events.

Tweet ID

Map data.id as the tweet identifier.

Text

Map data.text as the tweet body.

Author username

Map data.author.userName when present. Use username as the monitored-account fallback.
Keep the webhook secret returned by Xquik. If the scenario includes a verification step before routing, verify x-xquik-signature with that secret before sending alerts.

​
Polling Trigger: Extraction Completed

Use a polling trigger when users want bulk results without webhook setup: 
{
  "url": "/extractions",
  "method": "GET",
  "qs": {
    "status": "completed",
    "limit": 25
  },
  "response": {
    "iterate": "{{body.extractions}}",
    "uid": "{{item.id}}",
    "output": {
      "id": "{{item.id}}",
      "status": "{{item.status}}",
      "toolType": "{{item.toolType}}",
      "createdAt": "{{item.createdAt}}",
      "completedAt": "{{item.completedAt}}"
    }
  }
}
Fetch the job detail with GET /extractions/{id} and loop through nextCursor when hasMore is true.

​
Recipes

​
Social Listening To Slack

Monitor Event Trigger

Start from the Xquik Monitor Event instant trigger for tweet.new, tweet.reply, tweet.quote, and tweet.retweet.

Topic Filter

Filter on eventType, username, and data.text before routing alerts.

Slack Message

Create a Slack message from data.text, data.id, data.author.userName, and occurredAt.

Dedupe Store

Upsert by deliveryId per endpoint. Use streamEventId when one monitor event should fan out once across endpoint changes.

​
Daily Topic Research To Sheets

Schedule Trigger

Run the scenario on a daily schedule for repeatable topic research.

Search Tweets

Call Xquik Search Tweets with q; use cursor for page loops and keep limit on bounded resumes.

Iterator

Iterate over tweets and pass one tweet bundle to each downstream module.

Sheet Row

Append id, author.username, text, createdAt, likeCount, and retweetCount.

​
Bulk Extraction To CRM

Start Run

Use a scheduler or manual trigger to start the bulk extraction.

Create Extraction

Call Xquik Create Extraction with toolType and the required target fields.

Wait or Poll

Wait before polling, or reuse the Extraction Completed polling trigger.

Get Extraction

Call GET /extractions/{id} until job.status is completed or failed.

CRM Upsert

Upsert by user id, then follow hasMore and nextCursor for additional result pages.

​
Test Checklist

  • Connection test rejects invalid API keys with a clear 401 message.
  • Every module sanitizes x-api-key in logs.
  • Search modules return arrays and stable IDs for Make deduplication.
  • Instant trigger maps tweet.new, tweet.reply, tweet.quote, and tweet.retweet.
  • Extraction polling stops when no new completed jobs are returned.
  • 429 errors tell users to wait for Retry-After.
  • The Universal module accepts any /api/v1 path but still injects the API key.

​
Next Steps

Last modified on May 22, 2026