> ## Documentation Index
> Fetch the complete documentation index at: https://docs.open.cx/llms.txt
> Use this file to discover all available pages before exploring further.

# Connect X (Twitter)

> Bring your own X developer app, paste its credentials into OpenCX, and answer direct messages and public mentions with AI.

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.

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

## Before you start

You need an X account with a verified email and phone number — that account will own the developer
app permanently.

<Warning>
  Use a **company-owned X account**, not a personal one. Apps cannot be transferred between accounts
  later.
</Warning>

## 1. Create the app on X

1. Sign in at [console.x.com](https://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

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

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

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

## 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:

| OpenCX field            | Where to find it on X                                         |
| ----------------------- | ------------------------------------------------------------- |
| API Key                 | **OAuth 1.0 Keys → Consumer Key** (reveal with the eye icon)  |
| API Key Secret          | Revealed together with the Consumer Key                       |
| OAuth 2.0 Client ID     | **OAuth 2.0 Keys → Client ID**                                |
| OAuth 2.0 Client Secret | **OAuth 2.0 Keys → Client Secret** (reveal with the eye icon) |

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

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](/dashboard/introduction) 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](https://help.x.com/forms/platform).

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

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.

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

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