X

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

Use X when an assistant needs current public conversation context, profile metadata, or a specific action from a connected X account. Webhook events and some metrics depend on the X product, permissions, and access tier configured for that account's developer app.

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 X account that will publish, reply, perform authenticated account reads, inspect mentions, and request non-public metrics. An optional user_id saves 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 your organization has no X integration, Mobius may use a platform bearer credential for those public reads, subject to the organization'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 connection 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.

Choose the account manager and audience

Use Account manager to choose You for an account you manage personally or Your team for a company account that organization administrators should maintain. Changing that Mobius manager does not change the X identity represented by the saved access token.

Open the connected account and grant it under Assistant access. A personal grant limits use of the X account and retention of its tool results to the manager's Mobius audience. A team-managed account can be available to the whole team or to named people. This audience does not control who can see a post published on X. Connecting a second account adds it beside the first. Give both clear labels, then set Your chats, Channel replies, or a routine's saved account so Mobius uses the intended identity.

Platform-funded public reads are different. They do not represent a customer X account and have no account grant. They can read public data only; publishing, mentions, account metrics, and callback subscriptions still require a connected account.

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.

x.post.publish, x.post.publish_thread, and x.post.reply publish without an automatic Mobius confirmation after the exact X connection and live grant are checked. Use a draft-and-review interaction when the instructions call for it; that review does not itself enforce the later publish call.

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 assistant. 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 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>

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 in the organization's event stream.

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 organization'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

• Review account access in Connect accounts.
• Grant X actions to an assistant from actions.
• Store selected posts in tables.