X API v2 changes affiliation and DM event fields, and explains refused DMs

Announced18 Feb 2025

Effective18 Feb 2025

StatusIn effect

What changed

Three response changes in X API v2. On February 18, 2025 affiliation.user_id became an array of user IDs instead of a single string. On June 3, 2025 DM events began including participant_ids only on ParticipantsJoin and ParticipantsLeave events, listing only who joined or left, and MessageCreate events dropped it. On October 26, 2026 refused Direct Message sends kept HTTP 403 but gained specific problem types and, where safe, a detail naming the cause.

What it means

Code that reads affiliation.user_id as a single string, or expects participant_ids on every DM message event, can break; refused DMs now carry a specific problem type.

Who is affected

Developers of DM inbox, customer care and profile tools that read X user affiliation data or DM events.

What to do by 18 Feb 2025

Parse affiliation.user_id as an array, read participants from ParticipantsJoin and ParticipantsLeave events instead of MessageCreate, and branch on the dm problem types when a DM send returns 403.

What this means for you

Apps that read X messages or account badges get their data from X in a set shape. X changed that shape three times. Apps that weren't updated can show wrong group members in a chat or mix up account badges. Apps can now also say why X refused to deliver a message. If your inbox tool acts oddly with X messages, ask the vendor about these changes.

The details

Affiliation (February 18, 2025): affiliation.user_id returns an array of user IDs. Before, it returned a single user ID as a string, "even if a user had multiple affiliations".
DM events (June 3, 2025): participant_ids is included only for ParticipantsJoin and ParticipantsLeave events, listing only the participants who joined or left at that time. MessageCreate no longer includes it.
Refused DMs (October 26, 2026): POST /2/dm_conversations, POST /2/dm_conversations/:id/messages and POST /2/dm_conversations/with/:participant_id/messages still return 403 when a message is refused. The problem type now identifies the refusal (https://api.x.com/2/problems/dm-...), and detail names the cause when it doesn't reveal a private fact about the recipient. Refusals X can't explain safely stay about:blank with "This operation is not permitted." Clients that only check the status code are unaffected. The new types are in the public OpenAPI Problem union and the generated SDKs.

What to do next

Business owners: Nothing.
Marketers and agencies: Nothing, unless your X inbox tool shows wrong chat members or unclear send failures: ask the vendor.
Developers: Treat affiliation.user_id as an array, track DM membership from join and leave events, and show the refusal reason from the new problem types.

Follow new entries with the RSS feed. Each platform also has its own feed, for example X or Meta.