Data and research

An X integration connects X public reads and one account's actions to Mobius. Loops can search and read posts, publish from the connected account, inspect metrics and mentions, or react to X callback events.

Use X when a run needs current public conversation context, profile metadata, or a bounded action from a project-owned X account. Webhook events and some metrics depend on the X product, permissions, and access tier you configure in X.

Capability map

api_key is the Mobius credential storage kind for this integration. X requests still use either app-only bearer authentication or OAuth 1.0a user context, as described below.

Connect X

The OAuth 1.0a bundle is api_key, api_secret, access_token, and access_secret. It represents the project-owned account and is required for publishing, replies, authenticated account reads, mentions, and non-public metrics. An optional user_id can save an account lookup for mentions; screen_name keeps the connected identity readable in the app.

An app-only bearer_token is enough for public post and user reads. If a project has no X integration, Mobius may use a platform bearer credential for those public reads, subject to the project's funding access. Account actions never fall back to a platform account.

The api_secret also validates webhook challenge-response checks and signed event POSTs. A bearer-only project can store api_secret for webhook verification without pretending it has the complete OAuth bundle.

When in doubt, connect the full OAuth 1.0a bundle. Add a bearer token when you want public reads separated from the account context.

Actions

Use x.post.search_recent for discovery, then move to stable post IDs or user IDs. x.post.get_metrics chooses its auth requirement from the requested fields: public_metrics can use bearer auth; non_public_metrics, organic_metrics, and promoted_metrics require the connected account.

Events

X webhook callbacks become provider events with the x. prefix:

x.post.created
x.post.matched
x.post.reply
x.post.mention
x.post.deleted
x.account.activity

Use x.post.reply for replies to a subscribed account's posts, and match is_reply_to_subscribed_user when you only want replies aimed at the account that X included as for_user_id. x.post.matched is emitted by Enterprise Filtered Stream Webhooks.

The callback panel is purpose-based. You choose the activity you want, and Mobius selects the matching X product:

• Connected account activity uses Account Activity for the account represented by the saved OAuth 1.0a access token. It includes posts, replies, mentions, likes, follows, and related account events.
• Posts from specific public accounts use X Activity. Each row pairs a public event type with a numeric X user ID. Supported post events are post.create and post.delete; supported public profile-change events are also available in the event selector.
• Topics and keywords use the x.post.search_recent action in a scheduled loop. Query operators such as keywords, hashtags, and from:user work here without an Enterprise plan. Real-time Filtered Stream webhook delivery requires X Enterprise and is not a self-serve callback option.
• Internal setup notes are stored in Mobius and are never sent to X.

Adding or removing a public-account row only edits the draft. Select Apply callback setup to create or remove the corresponding subscriptions in X. Mobius stores the confirmed, non-secret setup state:

• webhook_id: the X webhook ID returned after Mobius registers the callback.
• callback_products: which X callback products you expect this project to receive.
• account_activity_user_ids: subscribed account user IDs for Account Activity.
• x_activity_subscriptions: event type, user ID, tag, and subscription ID rows for X Activity.
• filtered_stream_rules: Enterprise Filtered Stream rule text, tags, and rule IDs when an Enterprise setup is managed through the API.
• filtered_stream_link_params: Enterprise Filtered Stream delivery fields.

The app preserves an existing Enterprise Filtered Stream configuration when you apply self-serve callback changes, but it does not expose that Enterprise editor. Manage or remove the Enterprise setup through the callback-setup API.

The webhook endpoint appears in the integration catalog and on the X integration page after X is connected:

/v1/provider/x/webhook?org_id=<org-id>&project_id=<project-id>

Mobius registers that HTTPS URL through POST /2/webhooks. The endpoint handles X challenge-response check (CRC) GET requests and signed event POST requests. A bearer token is required for webhook registration and public X Activity subscriptions. The API secret is required for CRC and event signature verification. Account Activity also requires the complete OAuth 1.0a user-context bundle because X subscribes the authenticating account. Enterprise Filtered Stream rules and stream linking also use bearer auth.

Mobius returns 200 OK quickly and persists the canonical integration event. The persisted event becomes a source event for triggers and waiting runs.

X has multiple callback products:

Applying callback setup creates or reuses the webhook registration, subscribes the connected account when enabled, and reconciles public X Activity subscriptions. Removing a public-account row and applying again removes the corresponding upstream resource. The operation is safe to retry: Mobius first lists the current X resources and reuses matching IDs. Enterprise API requests can additionally reconcile Filtered Stream rules and webhook delivery.

Select Check current setup for a read-only confirmation against X. Mobius verifies that the saved webhook ID is still registered, valid, and points to this project's callback URL. It also compares every saved Account Activity subscriber, X Activity subscription, and Filtered Stream rule, plus the Filtered Stream webhook link. A failed check names the missing or changed resource and recommends applying the setup again; it does not modify X.

X still enforces product access and account limits. Account Activity and public X Activity are available on self-serve access subject to X's current limits. Filtered Stream webhook delivery requires Enterprise access. If X rejects a product, Mobius reports the upstream error and does not claim that setup is active.

Next

• Combine research with agent steps.
• Store selected posts in tables.
• Start runs from triggers.
• Inspect provider readiness from integrations.