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