Skip to main content
OpenCX connects to X through your own X developer app. You create the app on X, paste four credentials into OpenCX, and authorize each brand handle you want to support.
Because the app is yours, X bills you directly for API usage and the app’s rate limits are yours alone. OpenCX never sits between you and X’s billing.

​
Before you start

You need an X account with a verified email and phone number — that account will own the developer app permanently.
Use a company-owned X account, not a personal one. Apps cannot be transferred between accounts later.

​
1. Create the app on X

  1. Sign in at console.x.com and complete the developer signup.
  2. Create an app, giving it a name and a description of your support use case.
  3. Open the app’s User authentication settings and set:
    • App type: Web App / Automated App (a confidential client)
    • App permissions: Read and write and Direct Messages
    • Callback URL: the value OpenCX shows you in the connection dialog
    • Website URL: your company site
Set App permissions before generating any credentials. X bakes permissions into tokens at the moment they are issued, so credentials created before you enable Direct Messages will not be able to read or send DMs — you would have to regenerate them.

​
2. Add credit and a spending limit

X’s API is pay-per-use. In the console, add a payment method and buy credits, then set a spending limit per billing cycle and, optionally, auto-recharge.
If your credits run out or your spending limit is reached, X stops accepting messages. OpenCX surfaces this as a banner on the channel page and marks the affected replies as failed, but the fix always happens in your X console.

​
3. Paste the credentials into OpenCX

In OpenCX go to Channels → X (Twitter) → Add app. All four values live on the app’s Keys & Tokens tab on X, split across two blocks:
X’s naming is inconsistent: the credential we call API Key / API Key Secret appears in the console as Consumer Key, filed under a heading that says OAuth 1.0 Keys. Use it anyway — OpenCX authenticates accounts with OAuth 2.0, but X signs webhooks with the consumer pair, so both blocks are needed.
You do not need the Bearer Token or either Access Token on that page. OpenCX derives its own app-only bearer from the Consumer Key pair, and account tokens come from the OAuth redirect in the next step. If a secret was never saved and the eye icon only reveals the key, press Regenerate on that block — it shows both values once. Regenerating invalidates the previous pair, so do it before connecting accounts, not after. OpenCX validates the credentials and registers a webhook on your app before saving. Two failures are worth knowing about in advance:
  • “X rejected these API credentials” — the API Key or Secret is wrong, or was regenerated after you copied it.
  • “Your X developer account already has a webhook registered” — X allows one webhook per developer account on pay-per-use. Remove the existing one in the console, or use a separate developer account for OpenCX. OpenCX will never delete a webhook it did not create.

​
4. Connect your handles

With the app saved, choose Add account and authorize the brand handle on X. You can connect several handles to one app. If the authorization comes back missing a permission, OpenCX refuses the connection and names the missing scope — fix App permissions on X, regenerate, and try again. Direct messages start flowing immediately, and the AI answers according to your autopilot settings for the X channel.

​
5. Public mentions (optional)

Replying publicly when someone mentions your handle is off by default. Turning it on opens a checklist you must confirm, because X places these requirements on the account, not on OpenCX:
  • The handle has the Automated label enabled (X → Settings → Your account → Account information → Automation).
  • The account bio discloses automation, for example “AI support by @yourcompany”.
  • You have X’s prior approval to deploy AI-generated replies, requested through the Policy Support form.
X’s developer guidelines state that deploying AI-generated replies without prior approval is a violation even when the replies are helpful. Confirm the checklist before enabling mentions.
Once enabled, the AI replies only to posts that explicitly mention the receiving handle and honors opt-out phrases such as “stop”.

​
Reply to mentions as

To use a support handle for public replies to another brand handle, open Channels → X with permission to manage channel settings. On the receiving account’s card, enable public mentions, then choose Reply to mentions as:
  • This account (default): reply from the handle that received the mention.
  • Another connected account: reply from that handle when the customer’s post also mentions it. Only accounts connected to the same app are available.
Confirm the automation notice when choosing another handle, then click Save. The setting applies to both AI and agent replies, including existing sessions. Each account’s choice is independent: replies use the chosen handle directly, even if that handle has its own different reply setting. X only accepts a reply from an account the post mentions. When a post mentions the receiving handle but not the chosen handle, the reply comes from the receiving handle instead. For example, if your brand account replies as your support handle, a post mentioning both handles gets a reply from the support handle, and a post mentioning only the brand handle gets a reply from the brand handle. Direct messages always use the account that received them. The AI replies to DMs switch is independent of the public reply identity. In a public mention session, the inbox shows Replying as @handle above the composer for the session’s latest customer post.
X’s automation rules require the author to have summoned the automated account. Acknowledging the notice does not grant permission from X. Confirm that your intended use is permitted before enabling it.
If the selected reply account disconnects or moves to another app, affected public replies pause. The account card shows Public replies are paused. Reconnect the same handle to the same app, or select another reply account and save. While replies are paused, OpenCX doesn’t fall back to the receiving brand account, even for posts that don’t mention the selected account. Changing the selection to This account explicitly restores that behavior.

​
Encrypted messages

X moved direct messages to XChat, which is end-to-end encrypted. Encrypted chat in OpenCX is opt-in and always starts from your side:
  1. The account holder sets up Chat in the X app on the handle first, choosing a 4-digit PIN.
  2. In OpenCX, on the channel page, enter that PIN for the handle and confirm.
Entering the PIN joins OpenCX to the handle’s existing encrypted-chat identity as an additional device — X allows any number of devices, so Chat in the X app keeps working exactly as before. OpenCX never creates, replaces, or resets encryption keys, and it never touches the handle’s key backup. There is nothing to set up on our side and nothing we do behind your back. You can enable encrypted chat at connect time or at any later point — the PIN entry stays available on the channel page for every handle that has not enabled it yet. A handle without XChat keeps working on unencrypted direct messages. One caveat: it may not receive DMs from users who have migrated to XChat — if that starts happening, OpenCX shows a banner on the channel page (“encrypted messages are arriving that OpenCX can’t read”), and entering the PIN is the fix.
Each PIN entry is checked once against X’s key backup, and repeated wrong PIN entries can permanently destroy that backup for the account. Verify the PIN in the X app before entering it — OpenCX never retries a PIN on its own and blocks further attempts for an hour after three failures.

​
Delivery status

Agent and AI replies show a delivery state in the inbox, the same as WhatsApp: a single check when sent, blue checks when the customer has read it, and a red icon when X rejected the message — hover it for X’s reason, such as a message flagged as spam or a recipient whose encryption keys changed.