Make.com Twitter integration for X API automation

Xquik supports a Make.com Twitter integration without an X Developer app. Build tweet searches, profile lookups, follower exports, scheduled posts, and monitor alerts. The same integration supports replies, trends, extraction jobs, and signed webhooks. The 2025 decommissioning removed Make’s native X app. A private Make custom app keeps each scenario focused and authentication testable. Teams can later decide whether public app review fits their distribution needs.

Choose a Make Twitter automation pattern

A Make Twitter automation should start with one clear trigger. Use schedules for recurring tweet searches, trends, or follower exports. Instant webhook delivery applies to replies, quotes, reposts, and new tweets. Use polling when an extraction job can finish after the scenario ends. Build a Make scenario automation around one bounded Xquik operation. Then route normalized tweet or profile fields to each destination. This structure keeps the automation workflow observable and easier to retry. The HTTP module supports a limited private prototype. A private custom app suits reusable actions and consistent error handling. Both approaches can call the same documented API endpoints.

Build a Make.com API integration

A Make.com API integration uses an Xquik API key for authentication. It does not require X OAuth or a native Twitter account connection. The Make custom app stores the key inside an encrypted connection field. Use /account to validate API keys without changing tweets or profiles. Place the base URL, authentication header, and sanitization rules centrally. Focused modules should cover tweets, users, followers, monitors, and webhooks. A Make Twitter integration should return small, stable output bundles. Avoid passing complete API responses into Slack, Sheets, or a CRM. The Make API integration should retain IDs, cursors, timestamps, and status fields. Treat the Make Twitter API layer as a private integration boundary. The integration platform can then support drag-and-drop scenario assembly. This step-by-step structure keeps every module focused on one result.

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.

Control rate limiting and error handling

Read each endpoint contract before configuring retries. Xquik documents status codes per route, not as universal responses.

A 400 response identifies invalid request fields. The module mapping requires correction.
A 401 response identifies invalid authentication. Replace the API key.
A 402 response identifies billing requirements. The subscription requires an update first.
A 404 response identifies a missing tweet, profile, monitor, or webhook.
A 424 response identifies a dependency failure. Bounded backoff governs safe-read retries.
A 429 response identifies rate limiting. Retry timing follows the Retry-After header.
A 502 response identifies a temporary upstream failure. Cautious backoff governs safe-read retries.

Never retry a write only because its HTTP status appears temporary. Inspect the returned safeToRetry field for every write action. Use a new idempotency key only when the contract permits another attempt. Make webhooks can queue bursts before a scenario processes them. Set a scenario rate limit that matches the destination’s capacity. Enable sequential processing when bundle order matters. Use incomplete executions for recoverable failures that need operator review.

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

Send a unique Idempotency-Key. Store the returned action. Poll status_url while terminal is false. Retry only when safe_to_retry is true, using a new key.

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 cursor 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": "username",
    "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

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.

Automate focused Twitter workflows

Tweet search automation can collect posts matching a brand or topic query. Filter by author, timestamp, language, or engagement before sending alerts. Store tweet IDs so repeated searches do not create duplicate messages. A Twitter monitor webhook can route new tweets and replies immediately. Verify its signature before parsing the request body. Deduplicate deliveries before posting to Slack or updating a CRM. Use follower pages for bounded exports to Google Sheets. Use extraction jobs for larger follower or following exports. Preserve profile IDs because usernames can change. Social media automation should keep publishing under human control. The approval queue governs every scheduled tweet and reply. Review text, links, media, and the target account before posting tweets. Do not automate unsolicited replies, follows, or direct messages.

Make.com Twitter integration questions

How do I connect the Twitter API to Make?

A private Make custom app or HTTP module provides the integration path. Authenticate each Xquik request with the x-api-key header. Start with one read endpoint before adding writes or webhooks.

Does Make.com still have a native Twitter integration?

The native X app became unavailable in Make during 2025. Xquik remains available through a private app or the Make HTTP module. This approach avoids a native Twitter integration dependency.

How can I schedule tweets automatically?

Create a scheduled scenario that prepares one draft payload. Send the draft through an approval step before publishing. Use an idempotency key and inspect the returned write status.

How do I build a Twitter webhook in Make?

The workflow requires a Make webhook URL registered with Xquik. Choose the required monitor event types during webhook registration. Verify signatures, reject stale requests, and deduplicate event IDs.

Can Make automate Twitter search without coding?

Yes. Install the private Xquik app, then configure its search module. Map the query, filters, limit, and cursor through the scenario builder. The scenario can append matching tweets to Sheets without custom code.

How do I automate replies based on keywords?

Search recent replies or receive monitored account events. Filter each tweet with explicit terms and safety rules. Send the proposed reply to an approval queue before publishing.

How do I connect Twitter activity to a CRM?

Receive a verified monitor event, then fetch its author profile. The CRM upsert uses the immutable X user ID. The CRM record retains the triggering tweet URL with the profile fields.

Which Twitter automation tool fits Make scenarios?

Use Xquik when scenarios need tweets, profiles, followers, or monitor webhooks. Use Make for scheduling, routing, approvals, and destination integrations. Together, they form a focused Twitter API integration.

Make and Xquik sources

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.
The instant trigger must map tweet.new, tweet.reply, tweet.quote, and tweet.retweet.
Extraction polling stops when no new completed jobs are returned.
A 429 test confirms that retry timing follows Retry-After.
The Universal module accepts any /api/v1 path but still injects the API key.

Next steps

Read Webhooks for payload shape and retries.
Read Extraction Workflow for job creation and pagination.
Use Zapier or Pipedream when the team prefers code-backed workflow components.

​Choose a Make Twitter automation pattern

​Build a Make.com API integration

​Prerequisites

​App shape

Connection

Base URL

Modules

Triggers

Error handling

​Connection

​Base request pattern

401 authentication

402 billing state

429 rate limit

5xx transient

​Control rate limiting and error handling

​Starter modules

Search tweets

Get tweet

Get user

Get trends

Create tweet

Create extraction

Create monitor

Create webhook

Make an API call

​Output handoff

Tweet search page

User profile rows

Trend rows

Tweet or reply write

Media attachments

Monitor and webhook setup

Extraction jobs

Webhook event dedupe

Stored event replay

Receiver acceptance

​Instant trigger: monitor events

Event type

Delivery ID

Stream event ID

Occurred at

Username

Tweet ID

Text

Author username

​Polling trigger: extraction completed

​Recipes

​Social listening to Slack

Monitor event trigger

Topic filter

Slack message

Dedupe store

​Daily topic research to sheets

Schedule trigger

Search tweets

Iterator

Sheet row

​Bulk extraction to CRM

Start run

Create extraction

Wait or poll

Get extraction

CRM upsert

​Automate focused Twitter workflows

​Make.com Twitter integration questions

​How do I connect the Twitter API to Make?

​Does Make.com still have a native Twitter integration?

​How can I schedule tweets automatically?

​How do I build a Twitter webhook in Make?

​Can Make automate Twitter search without coding?

​How do I automate replies based on keywords?

​How do I connect Twitter activity to a CRM?

​Which Twitter automation tool fits Make scenarios?

​Make and Xquik sources

​Test checklist

​Next steps

Choose a Make Twitter automation pattern

Build a Make.com API integration

Prerequisites

App shape

Connection

Base request pattern

Control rate limiting and error handling

Starter modules

Output handoff

Instant trigger: monitor events

Polling trigger: extraction completed

Recipes

Social listening to Slack

Daily topic research to sheets

Bulk extraction to CRM

Automate focused Twitter workflows

Make.com Twitter integration questions

How do I connect the Twitter API to Make?

Does Make.com still have a native Twitter integration?

How can I schedule tweets automatically?

How do I build a Twitter webhook in Make?

Can Make automate Twitter search without coding?

How do I automate replies based on keywords?

How do I connect Twitter activity to a CRM?

Which Twitter automation tool fits Make scenarios?

Make and Xquik sources

Test checklist

Next steps