Skip to main content
The Account Activity API (AAA) reaches end of life on January 1, 2027. Migrate to the X Activity API (XAA) before then to avoid an interruption in event delivery.

Summary

The X Activity API (XAA) replaces the Account Activity API (AAA) for real-time user activity. Every activity type AAA delivers has an equivalent XAA event, and XAA adds many event types that AAA never supported. You have two ways to migrate:
  • Managed migration. Submit a request and the X team migrates your existing AAA subscriptions to XAA for you. See Managed migration.
  • Self-serve migration. Create the XAA subscriptions yourself using the API. See Self-serve migration.
Either way, your webhook consumer must be updated to read the XAA payload format before you cut over. See What changes for your integration. Contact your account manager with any questions.

Benefits of XAA

  • Covers everything AAA delivers. Posts, mentions, replies, quotes, reposts, deletes, likes, follows, blocks, mutes, DMs, typing indicators, read receipts, and app revocations all have XAA equivalents. See the event mapping.
  • Granular subscriptions. Instead of an all-or-nothing subscription per user, choose exactly which event types you want for each user, and narrow them further with filter qualifiers such as direction, post_id, and conversation_type. You only receive, and process, the events you need.
  • New event types. XAA supports event families AAA never served, including encrypted XChat messages, profile updates, live broadcast start, end, and chat events, Spaces, paid subscriptions, and Grok-curated news headlines filtered by keyword. See Supported event types.
  • Webhook or streaming delivery. Receive events on your existing webhook, over a persistent HTTP stream, or both. The stream supports up to 5 minutes of backfill on connect and recovery of missed events with start_time and end_time.
  • Keep your webhook and your users’ authorizations. XAA uses the same V2 Webhooks API, CRC checks, and signature headers as AAA, so you can point XAA subscriptions at the webhook you already use. XAA accepts the OAuth 1.0a user access tokens you already hold, so users don’t need to re-authorize your app to migrate.
  • OAuth 2.0 with fine-grained scopes. XAA supports OAuth 2.0, so you can request only the scopes you need (for example dm.read, like.read, block.read, mute.read, tweet.read). OAuth 1.0a support in XAA will be deprecated soon, so plan to move your users to OAuth 2.0.
  • Same replay window. Recover events from the past 24 hours with POST /2/webhooks/replay, the same window as AAA replay.
  • X API v2 data format. Post and user objects match the rest of X API v2, with related objects in includes, so the same parsing code works across endpoints.
  • Better subscription management. Tag subscriptions, set an automatic expires_at, list subscriptions for a single user, and delete up to 100 subscriptions in one request.

Managed migration

Enterprise customers can ask the X team to perform the migration for you. We’ll move your existing AAA subscriptions to the equivalent XAA subscriptions internally, so you don’t need to re-create subscriptions or ask your users to re-authorize your app.
1

Submit a migration request

2

Confirm the details with our team

We’ll contact you to confirm which apps, webhooks, and event types to migrate, and agree on a cutover time.
3

Update your webhook consumer

Before cutover, update your webhook handler to accept XAA payloads. See What changes for your integration.
4

Verify delivery

After cutover, confirm XAA events are arriving at your webhook. You can list the migrated subscriptions with GET /2/activity/subscriptions.
Submit your request well ahead of January 1, 2027 so there’s time to schedule and verify the cutover.

AAA to XAA event mapping

AAA delivers every activity type below for each subscribed user. In XAA, each event type is a separate subscription. Replicating an AAA subscription for one user takes up to 17 XAA subscriptions (one per event type in the table, excluding oauth.revoke). Each one counts toward your subscription limit, so only subscribe to the event types you use. Contact your account manager if you need a higher limit.

What changes for your integration

Payload format

AAA sends v1.1 objects keyed by activity type, with for_user_id identifying the subscribed user. XAA wraps every event in a common envelope and uses X API v2 objects.
See Event payloads for a full example of every XAA event type.
During the transition you may receive both formats on the same webhook. AAA payloads have a top-level for_user_id, and XAA payloads have a top-level data.event_type, so your handler can route on whichever is present.

Behavior differences

We’re looking at closing the reply and protected account gaps in XAA. This page will be updated as that work lands.

Self-serve migration

1

Inventory your AAA subscriptions

List your webhooks with GET /2/webhooks, then list the subscribed users on each with GET /2/account_activity/webhooks/:webhook_id/subscriptions/all/list.
2

Choose event types

Use the event mapping to decide which XAA event types each user needs.
3

Update your webhook consumer

Add support for the XAA envelope and v2 objects, and keep AAA parsing in place until cutover is complete.
4

Create XAA subscriptions

Call POST /2/activity/subscriptions once per user and event type, passing your existing webhook_id. Authenticate with the subscribed user’s access token: either an OAuth 2.0 token with the matching scope, or the OAuth 1.0a token you already use for AAA. Public events can also be created with your app’s bearer token. See Event privacy and authentication.
5

Verify delivery

Confirm XAA events are arriving for each migrated user. While both AAA and XAA subscriptions are active for a user, you receive each activity twice, once in each format.
6

Remove AAA subscriptions

The following example creates XAA subscriptions for one user with the OAuth 1.0a credentials from your AAA integration:
OAuth 1.0a support in XAA will be deprecated soon. You can use your existing OAuth 1.0a tokens to migrate, but plan to move your users to OAuth 2.0.

Frequently asked questions

Yes. XAA uses the same V2 Webhooks API as AAA. Pass your existing webhook_id when you create XAA subscriptions. CRC checks and signature verification work the same way.
Not to migrate. XAA accepts the OAuth 1.0a user access tokens you already use with AAA, and if you use managed migration, we migrate your existing subscriptions for you. OAuth 1.0a support in XAA will be deprecated soon, though, so plan to move your users to OAuth 2.0.
You can optionally upgrade your users to OAuth 2.0 without asking them to log in again. Use the OAuth 1.0a token exchange to swap each stored OAuth 1.0a access token and secret for an OAuth 2.0 access token and refresh token for the same user.
Yes, for any user who has both an AAA and an XAA subscription on the same webhook. Remove the AAA subscription once XAA delivery is verified, or have your handler ignore one format during the overlap.
Yes. Connect to GET /2/activity/stream to receive events for all your subscriptions over a persistent HTTP connection. A subscription with a webhook_id is delivered to both the webhook and the stream when the stream is open.
AAA reaches end of life and is no longer supported. Migrate your subscriptions before that date to avoid missing events.
Contact your account manager for details on XAA subscription limits and pricing for your account.

Next steps

Request a managed migration

Have the X team migrate your AAA subscriptions

XAA introduction

Event types, authentication, and limits

XAA quickstart

Create a subscription and receive events

Event payloads

Sample JSON for every XAA event type