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. Enabling mentions in OpenCX records who confirmed the checklist and when.
Once enabled, the AI replies only to posts that mention your handle — X only permits programmatic replies when the author has “summoned” your account — and it honors opt-out phrases such as “stop”.

Encrypted messages

X moved direct messages to XChat, which is end-to-end encrypted. OpenCX sets up the encryption keys for a connected handle automatically and you will normally never see this step. If the handle already uses XChat (someone set it up in the X app), OpenCX asks you to choose:
  • Enter the XChat PIN — keeps the handle’s existing encrypted-chat identity.
  • Generate new keys — resets encrypted chat for that handle. Earlier encrypted conversations stay unreadable to OpenCX and the X app may ask to set chat up again.
Too many wrong PIN attempts permanently destroys X’s key backup for that account. Verify the PIN in the X app before entering it.

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.