Docs
Disappearing messages

Disappearing messages

Turn disappearing messages of a conversation on, change the time, or turn them off.

POST/client/dm/conversation/disappearing

Your account, your proxy, your risk.

Account actions run with the session cookie of your own X account and go out through your own proxy. Use only accounts you control and follow X's rules. Automated posting, following or liking can get the account limited or suspended; that is between you and X. Treat the cookie like a password: it gives full access to the account. Trial keys cannot call these endpoints.

New messages in the conversation are deleted ttl_seconds after they were sent. Like x.com, the change is signed with your chat key, so the passcode is required. The API reads the setting back and answers with the conversation as it is afterwards; when the conversation already has the requested setting, nothing is changed.

Parameters

  • cookiebody · string · required

    Cookie header of your own logged-in X session. Must contain auth_token, ct0 and twid (your account ID, set by x.com at login); guest_id is used when present.

  • proxybody · string · required

    Your proxy, format http://user:pass@host:port. The requests to X go out through it. Used only for this request.

  • passcodebody · string · required

    Your X Chat passcode, the one you set up for encrypted messages on X. Send it as a string (a number works too, but loses leading zeros), up to 64 characters. It unlocks your chat keys for this request and is not saved. The unlocked keys stay in the server's memory for up to 30 minutes, so follow-up calls need no new unlock.

  • conversation_idbody · string · optional

    ID of the conversation, as returned by /client/dm/inbox. A one-to-one chat has the ID <smaller user ID>:<larger user ID>. Letters, digits, colon, hyphen and underscore, up to 128 characters. Either conversation_id or user_id is required.

  • user_idbody · string · optional

    Numeric ID of the other person (up to 20 digits) for a one-to-one chat. Used when conversation_id is not set.

  • ttl_secondsbody · integer · required

    0 turns disappearing messages off; otherwise 60 (1 minute) to 31536000 (365 days).

Body parameters are sent as a JSON object with Content-Type: application/json.

Example request

curl -X POST 'https://api.twittrapi.com/client/dm/conversation/disappearing' \
  --header 'X-API-KEY: YOUR_API_KEY' \
  --header 'Content-Type: application/json' \
  --data '{"cookie":"auth_token=...; ct0=...; twid=u%3D...","proxy":"http://user:pass@host:port","passcode":"1234","user_id":"12","ttl_seconds":86400}'

Base URL https://api.twittrapi.com, key in the X-API-KEY header. The SDKs do not wrap account actions, so the examples are plain HTTP calls.

Response

The conversation after the change, like /client/dm/conversation/info: {conversation_id, type (direct or group), name (groups), muted, disappearing_messages {enabled, ttl_seconds}, screen_capture_blocking, participants [{id, screen_name, name, avatar, is_blue_verified}], detail (X's conversation_detail)}.

Simple format (?format=simple or X-Response-Format: simple): {data: {id, type (direct or group), name, muted, disappearingMessages {enabled, ttlSeconds}, screenCaptureBlocking, participants [{id, username, name, avatarUrl, verified}]}}. Schema.

Example response coming soon.

In the raw format, field names and nesting come from X and can change without notice. See Response format; the simple format keeps a fixed schema.

Errors

  • 400The body is not valid JSON.
  • 422cookie or proxy is missing, the cookie has no twid or ct0, or the passcode is neither a string nor a whole number or longer than 64 characters. The passcode or ttl_seconds is missing, ttl_seconds is not 0 or between 60 and 31536000, or the conversation is not set. Also: the account is suspended, or X rejected the session ("Twitter temporarily rejected this session; refresh the login and try again").
  • 407The proxy is unreachable or timed out.
  • 404Conversation not found.
  • 422Wrong passcode: "Wrong passcode (N attempts left before X deletes the chat keys)". X deletes the chat keys after too many wrong passcodes, so the API never sends the same wrong passcode to X twice (for 24 hours it answers 422 at once), and once only 3 attempts are left it does not try at all: "Only a few passcode attempts are left for this account; unlock Chat in the X app with the correct passcode first".
  • 422The account has no chat passcode yet: open Chat on x.com once and set one up.
  • 501Encrypted messages are not available on this server (the passcode cannot be used). Refunded.
  • 502The chat keys could not be unlocked ("Could not unlock the chat keys, try again") or the messages could not be decrypted. Refunded.
  • 502X accepted the change but the setting did not change ("X accepted the change but did not apply it"), or the change could not be signed. Refunded.
  • 429X's rate limit for this account: "X rate limit reached for this account, try again later".
  • X'sX refused the request: answered with X's status and {"error": "X refused the request: <X's reason>"}. When X answers 200 with an error, the status is 422.

Errors every endpoint can return (401, 402, 403, 404, 408, 409, 429, 5xx), and which of them are charged, are on the Errors page. Calls that fail with 400, 408, 409 or a 5xx error are refunded.