The X Chat API in v2.169: Group Endpoints and What a DM Really Costs

On September 30, 2026 the X Developers account posted that a large set of X Chat endpoints is now available in X API v2.169, and the developer-forum changelog spelled out the surface: you can now manage group conversations, admin workflows, invites, join requests, membership, mute state, disappearing-message TTL, pinned messages and chat settings from the API. X Chat is X's encrypted direct-message system, so this is programmatic control over real conversations, not metadata around them.

For a developer, two questions follow. What can you actually build on it, and what does a message cost once it is running? This guide answers both from dated, first-party sources, and sets the official route beside a per-call route for the plainer DM jobs where the cost gap is large.

TL;DR: X API v2.169, announced September 30, 2026, shipped the group half of the X Chat API: create and update group conversations, manage admins, invites, join requests and members, set mute and disappearing-message TTL, pin messages and change chat settings, plus bots, encrypted media and public keys. X Chat is end-to-end encrypted, so you manage keys on-device through the Chat XDK. On the official X API a direct-message read bills $0.010 per message returned and a send $0.015, while an X Chat message you receive bills $0.010 and a send is not billed. For the ordinary job of reading or sending plain DMs, a per-call API bills $0.0016 and returns a whole thread in one call, so a 20-message thread is $0.20 on the official read and $0.0016 per call.

New X Chat endpoints are now available in X API v2.169. You can now manage groups, admins, invites, join requests, members, mute, TTL, pinned messages, and chat settings from the X API.

@XDevelopers view on X

What shipped in X API v2.169

The v2.169 release is the group and administration half of the X Chat API. The one-to-one send and receive flow arrived earlier in the year; this set is what turns X Chat from a two-person channel into something you can run a community or a multi-party agent inside.

Reading the API reference on docs.x.com, the endpoints group cleanly. There is a block for group conversations themselves, create, update, add members and remove members. There is an admin block, add and remove admins, plus request, approve and reject flows so a member can ask for admin and an existing admin can grant it. There is an invites-and-join-requests block, enable and disable an invite link, request to join, and reject join requests. Conversation settings cover mute and unmute, turning disappearing messages on and off, and a screen-capture control. And a privacy block reads and updates chat settings. Alongside those sit bots, encrypted media upload and download, and the public-key endpoints the encryption needs.

The X Chat endpoint groups shipped in API v2.169

Endpoint group	What it manages	Provenance	Source
Group conversations	Create, update, add and remove members	published	published
Admins	Add, remove, request, approve and reject admin roles	published	published
Invites and join requests	Enable or disable invite links, accept or reject joins	published	published
Conversation settings	Mute, disappearing-message TTL, screen-capture controls	published	published
Messages	Send, delete, pin, typing indicator, mark as read	published	published
Bots, media and keys	Create bots, encrypted media upload and download, public keys	published	published

as of 2026-10-19

What X Chat actually is

Before the cost math, the shape of the thing matters, because X Chat is not the old plaintext DM surface with new routes bolted on. It is an end-to-end encrypted system. Message bodies are encrypted on the client, so X routes ciphertext and cannot read the plaintext, and every message is signed so the recipient can verify who sent it.

The piece that makes this workable is the Chat XDK, X's open-source encryption SDK built on a Rust core. It generates your identity and signing keys, encrypts and decrypts, signs and verifies, and offers an optional passcode-protected key backup, and it ships in Python, JavaScript, Rust, Go, C# and Java. You authorize with OAuth 2.0 user context and the dm.read and dm.write scopes, and each user authorizes their own chat, because the keys live on their device, not on yours. Independent coverage noted the same launch when X opened the system to outside developers: the write-up on r/RuntimeWire framed it as X opening its encrypted direct-messaging system to bots and AI agents.

X launches encrypted Chat API for bots and AI agents from r/RuntimeWire

For a feel of the product these endpoints sit behind, this walkthrough shows the X Chat app itself, the encrypted inbox your code is writing into:

https://www.youtube.com/watch?v=oLNBMFN1Uao

What can you build on the X Chat API?

The group endpoints are the unlock. A two-person encrypted channel is useful, but the ability to create a group, manage its members and admins, gate it behind an invite link and run a bot inside it is what opens real products.

The clearest fit is a support bot that lives inside an encrypted thread, answering customers without the conversation ever leaving end-to-end encryption. From there the same primitives give you group AI agents that read and post in a shared conversation, community moderation that adds, removes and invites members by code, onboarding flows that spin up a group and seed its first members, and alerting that pushes a message to a thread when something happens in your system. X ships a starter for the bot case: the xchat-agent-skeleton repo is a Grok pass-through out of the box, encrypted messages in and an encrypted reply out, with a handler you fill in. Third-party tooling has caught up too: Vercel's Chat SDK now supports XChat for one-to-one and group conversations.

Introducing 𝕏 Chat Agents powered by our new 𝕏 Chat API & Chat XDK.

@XDevelopers view on X

Here is the shape of a support bot on the official route, end to end. Because billing runs on delivered events, the receiver is where your cost accrues, so verify the event and decrypt before you do any work. Our guide to building a Twitter chatbot walks the plain-DM version of the same loop, and the Grok Bot versus X data API breakdown covers when an agent is the right shape at all.

# An X Chat webhook receiver: verify the signed delivery, then decrypt with the Chat XDK.
import hmac, hashlib, time
from flask import Flask, request, abort

app = Flask(__name__)
WEBHOOK_SECRET = "whsec_..."  # returned once when the webhook is registered

def verify(header, raw, tolerance=300):
    parts = dict(p.split("=", 1) for p in header.split(",") if "=" in p)
    t, v1 = parts.get("t", ""), parts.get("v1", "")
    if not t.isdigit() or abs(time.time() - int(t)) > tolerance:
        return False
    expected = hmac.new(WEBHOOK_SECRET.encode(), f"{t}.{raw}".encode(), hashlib.sha256).hexdigest()
    return hmac.compare_digest(expected, v1)

@app.post("/webhooks/xchat")
def receive():
    raw = request.get_data(as_text=True)
    if not verify(request.headers.get("X-Signature", ""), raw):
        abort(401)
    event = request.get_json()
    if event.get("event") == "chat.received":   # this is the $0.010 billable event
        ciphertext = event["message"]["ciphertext"]
        # plaintext = chat_xdk.decrypt(ciphertext)  # keys stay on your device
        print("New encrypted chat message in", event["conversation_id"])
    return {"ok": True}

What does a direct message really cost?

The X API prices reads per resource returned and writes per request, which is the detail that decides a messaging budget. Reading the pay-per-usage pricing on docs.x.com on October 19, 2026, a DM Event Read is $0.010 per message and a DM Interaction Create is $0.015 per request. For X Chat specifically, billing runs on webhook events: chat.received is $0.010 per delivered message, while chat.sent and chat.conversation_join are not billed. So on the official route you pay to receive, not to send or to join.

The per-resource unit is the thing to internalise. Reading a conversation is not one charge, it is one charge per message the response returns, and that scales with how chatty the thread is.

The per-call route for the ordinary DM job

For the plainer job of reading or sending ordinary direct messages, a per-call API prices the whole operation at a flat rate instead of per message. On this route all three DM endpoints bill $0.0016 a call, and a call to the conversation endpoint returns the thread's messages together rather than charging for each one. A standard read is $0.0008, and new accounts get $0.50 in credits, about 625 standard calls, with no card. Our X direct-message API guide walks the three endpoints and the session model, and the live rates are on the pricing page.

Put the two routes side by side on the same direct message and the billing unit, not the sticker price, is what moves the number.

What each route bills to read or send a direct message

Operation	Official X API	Per-call API	Source
Read one message	$0.010 per message returned	$0.0016 per thread call	published
Send a direct message	$0.015 per request	$0.0016 per call	published
X Chat message you receive	$0.010 per delivered event	Not offered	published
Send an X Chat message	Not billed	Not offered	published
Read a 20-message thread	$0.20	$0.0016	derived
Monthly ceiling	3M post reads, then Enterprise	None	published

as of 2026-10-19

The sharpest example is a single busy thread. Twenty messages read on the official per-message rate is twenty charges at $0.010, so $0.20. The same thread on the per-call route is one call, $0.0016.

# One 20-message thread, both ways.
messages = 20
official = messages * 0.010   # DM Event Read bills per message returned
per_call = 0.0016             # one dm/conversation call, whole thread
print(round(official, 3), per_call, round(official / per_call))  # 0.2 0.0016 125

By job

The X Chat API and the per-call DM endpoints, compared

	Official X Chat API	Per-call DM endpoints
Encryption	End-to-end, via the Chat XDK	None, plain DMs
Group management	Admins, invites, members, TTL	Not offered
Billing unit	Per message delivered	Per call
Read a 20-message thread	$0.20	$0.0016
SDK required	Chat XDK, six languages	None, a bearer token
Best for	Encrypted group chat and bots	Reading and sending plain DMs

The honest line through that grid: the per-call endpoints do not do encrypted X Chat, group management or TTL, and they are not trying to. They do the plain-DM read and send job at a flat, predictable cost. The new encrypted group features live on the official X Chat API, and that is where they should live.

A month of a DM job, priced in advance

The point of a per-resource or per-call price is that you can model the job before you write it. Take a job that reads 50 direct-message threads a day, twenty messages each, for thirty days.

Worked example

One month of a DM-reading job, priced before any code

Threads read per day: 50 · Official X API, 30 days: $300.00 · Per-call API, 30 days: $2.40

☐ 50 threads x 20 messages x 30 days x $0.010 is $300 on the per-message read (billed per message returned) · ☑ 50 thread calls x 30 days x $0.0016 is $2.40 on the per-call route · ☑ The $0.50 signup credit covers a full day of the per-call job · ☑ Encrypted X Chat group features are the official API's, not the per-call route's (a different surface)

An illustration at a stated volume, not a customer account. Assumes 50 threads a day of 20 messages each. Official rate $0.010 per message returned and per-call rate $0.0016 per thread call, both read 2026-10-19.

On the official per-message read that is 50 times 20 times 30 at $0.010, which is $300 for the month. On the per-call route it is 50 thread calls a day for thirty days at $0.0016, which is $2.40, because each call returns the whole thread. The gap is the billing unit doing its work, and it is why read-heavy DM jobs tend to move off per-resource pricing.

# Model the month before you write the job: per-message vs per-call.
THREADS_PER_DAY = 50
MSGS_PER_THREAD = 20
DAYS = 30

official_per_msg = 0.010   # DM Event Read, per message returned
per_call = 0.0016          # one dm/conversation call returns the whole thread

official = THREADS_PER_DAY * MSGS_PER_THREAD * DAYS * official_per_msg
percall  = THREADS_PER_DAY * DAYS * per_call
print(round(official, 2), round(percall, 2))   # 300.0 2.4

Our per-user cost-of-goods breakdown, the cost by workload rundown and the one-million-tweet dataset price run the same arithmetic on other workloads, and the X API pricing change breakdown and the cost benchmark cover how the official rate card got here. The live calculator is on the cost calculator page.

How much attention is this change drawing? We read the X Chat launch posts back through our own API to see.

696,576 combined views across the five X Chat API announcement posts, measured through our own API.

Our data · Dataset: x-chat-launch-posts-2026 · Source: public X posts, read through our API · Query: GET /twitter/tweet/advanced_search?query=%22X+Chat%22+(API+OR+endpoints+OR+group)+(from%3AXDevelopers)&product=Latest plus the X Chat API build-guide post · Pulled: 2026-10-19 · n = 5 · Method: sum of the view_count X reports for the five announcement posts; a dated snapshot, the counters keep moving.

The X Chat launch posts, measured through our API

Post	Posted	Views	Likes	Source
@XDevelopers: X Chat Agents	2026-08-26	430,835	1,619	measured
@XDevelopers: X Chat API live	2026-07-30	186,966	375	measured
@XDevelopers: v2.169 release	2026-09-30	46,724	159	measured
@santiagomed: build guide	2026-10-16	19,368	127	measured
@XDevelopers: API guide	2026-10-16	12,683	117	measured

as of 2026-10-19

Measured

Views on the X Chat launch posts, read through our API

Point	Value
X Chat Agents	430,835
X Chat API live	186,966
v2.169 release	46,724
Build guide	19,368
API guide	12,683

The X Chat Agents post alone cleared 430,835 views, and the September 30 release post sat at 46,724 a few weeks on. Interest in building on X Chat is not a niche, which is exactly why the cost of running it is worth getting right before you scale.

When should you use which route?

The choice is not official versus per-call in the abstract. It is which route fits the job in front of you, and the two barely overlap.

Reach for the official X Chat API when you need what v2.169 shipped: encrypted group conversations, admins, invites, join requests, members, disappearing-message TTL and bots, all inside end-to-end encryption. Reach for the per-call DM endpoints when the job is reading or sending ordinary direct messages at a flat, known cost and encryption is not the point. Plenty of products will want both, running encrypted chat on X Chat while reading plain DMs per call.

The plain-DM job, per call

If your job is the simple one, reading and sending ordinary DMs, the per-call route is a few endpoints and a bearer token. You register your own X session once, list conversations, read a whole thread in a single call, and send by recipient id and text.

# Register your own X session once, then list conversations. Listing is one call.
curl -X POST "https://api.twitterapis.com/twitter/customer/session" \
  -H "Authorization: Bearer $TWITTERAPIS_KEY" \
  -H "Content-Type: application/json" \
  -d '{"session": "<your x session blob>"}'

curl "https://api.twitterapis.com/twitter/dm/list" \
  -H "Authorization: Bearer $TWITTERAPIS_KEY"

# Read a whole DM thread in one call, billed once at $0.0016.
curl "https://api.twitterapis.com/twitter/dm/conversation?conversation_id=100215065-1938492597917650949" \
  -H "Authorization: Bearer $TWITTERAPIS_KEY"

import os, requests

BASE = "https://api.twitterapis.com/twitter"
KEY = os.environ["TWITTERAPIS_KEY"]

def send_dm(recipient_id, text):
    """One plain-DM send: one call, $0.0016."""
    r = requests.post(f"{BASE}/dm/send",
                      json={"recipient_id": recipient_id, "text": text},
                      headers={"Authorization": f"Bearer {KEY}"}, timeout=30)
    r.raise_for_status()
    return r.json()

The DM API guide covers the session model, the no-cursor limit on DM history and the send-rate cap in depth, and the authentication guide covers the bearer token. For monitoring a thread or an account rather than polling it, our real-time mentions monitor, the coverage-honesty post and the webhook API push each new message to an endpoint you own. If you are deciding whether to pay at all, is the Twitter API free lays out the floor.

Five things to settle before you build on X Chat

X Chat is more involved than a plain DM endpoint, because encryption, key management and per-event billing all sit in the path, so running this short checklist before you write the first handler saves a costly rebuild later and keeps your budget predictable from day one.

First, encryption: you manage keys on-device and the Chat XDK does the math, so plan where keys live and how you back them up. Second, scopes: OAuth 2.0 user context with dm.read and dm.write, and each user authorizes their own chat. Third, delivery: webhooks or the activity stream for live events, the events API for history. Fourth, what bills: a received message bills $0.010, a sent one does not, so your cost tracks inbound volume. Fifth, your ceiling: pay-per-use caps at 3 million post reads a month, and once you hit a rate-limit window or what rate-limited means on X you page through it the same way you would any paginated read. If any of those is a blocker, our guide to choosing a Twitter API, the official versus third-party comparison and the how to build a Twitter bot walkthrough help you place the job.

The short version

X added the group half of the X Chat API in v2.169 on September 30, 2026: create and run encrypted group conversations, manage admins, invites, join requests and members, set mute and TTL, pin messages, and drive bots and media. It is a genuine platform opening for encrypted group products.

The cost is the part to model first. A received message bills $0.010 on the official route and a sent one is free, but an ordinary DM read bills per message returned, so a chatty thread adds up. For the plain job of reading and sending DMs at a flat cost, the per-call route is $0.0016 a call and returns a whole thread at once. Sign up for the $0.50 credit, read a real thread against the pricing page, and if you are wiring an agent, the MCP server and our guide to what to build with the X API are the next stops.