Dieses Endpoint wurde aktualisiert, um Metadaten zu Post-Bearbeitungen einzuschließen. Erfahren Sie mehr über diese Metadaten auf der Seite „Grundlagen zu Edit Posts“ (/x-api/enterprise-gnip-2.0/fundamentals/edit-tweets). Dieses Endpoint wird häufig zusammen mit den Direct-Messages-Endpoints verwendet. Wir haben neue v2 Direct-Messages-Endpoints eingeführt. Beachten Sie, dass die Enterprise- und Premium-Account-Activity-APIs v2-Eins-zu-eins-Nachrichten unterstützen, derzeit jedoch keine Gruppenkonversationen. Weitere Informationen finden Sie in den Direct Messages Grundlagen und auf der Seite Edit Posts. Enterprise
Die Account Activity API ermöglicht es Ihnen, per Webhook Echtzeitaktivitäten zu einem Nutzerkonto zu abonnieren. Das bedeutet, dass Sie über eine einzelne Verbindung Echtzeit-Posts, Direct Messages und andere Kontoereignisse von einem oder mehreren Ihrer eigenen oder abonnierten Konten empfangen können.
Sie erhalten alle unten aufgeführten Aktivitäten für jedes Nutzerabonnement bei Ihrer Webhook-Registrierung:
| Aktivitätstypen | |
|---|
* Posts (vom Nutzer)
* Post-Löschungen (vom Nutzer)
* @Erwähnungen (des Nutzers)
* Antworten (an den Nutzer oder vom Nutzer)
* Retweets (vom Nutzer oder des Nutzers)
* Quote Tweets (vom Nutzer oder des Nutzers)
* Retweets von Quote Tweets (vom Nutzer oder des Nutzers)
* Likes (vom Nutzer oder des Nutzers)
* Follows (vom Nutzer oder des Nutzers)
* Unfollows (vom Nutzer) | * Blocks (vom Nutzer)
* Unblocks (vom Nutzer)
* Mutes (vom Nutzer)
* Unmutes (vom Nutzer)
* Direct Messages gesendet (vom Nutzer)
* Direct Messages empfangen (vom Nutzer)
* Tippindikatoren (an den Nutzer)
* Lesebestätigungen (an den Nutzer)
* Widerrufe von Abonnements (vom Nutzer) |
Bitte beachten - Wir liefern keine Home-Timeline-Daten über die Account Activity API. Bitte verwenden Sie GET statuses/home_timeline, um diese Daten abzurufen.
Sehen Sie sich unsere vierteilige Video-Serie zur Account Activity API an, um schnell auf den neuesten Stand zu kommen!
| Stufe | Preis | Anzahl eindeutiger Subscriptions | Anzahl von Webhooks | Zuverlässigkeit und Wiederherstellung der Aktivität |
|---|
| Enterprise | Vertrieb kontaktieren | Bis zu 500+ | 3+ | Retries und Replay |
-
Haben Sie Fragen? Treten Fehler auf?
-
Entdecken Sie unseren Beispielcode:
Webhooks und abonnierte Nutzer verwalten
Verwalten eines Webhooks:
Beginnen wir mit der Registrierung einer neuen Webhook-URL für den angegebenen Anwendungskontext.Die URL wird vor dem Speichern per CRC-Anfrage validiert. Sobald Sie einen Webhook registriert haben, notieren Sie sich die Webhook-ID, da Sie sie später benötigen.Kopieren Sie die folgende cURL-Anfrage in Ihre Befehlszeile, nachdem Sie die folgenden Werte ersetzt haben:
-
URL
<URL> z. B. https://yourdomain.com/webhooks/twitter/
-
Consumer Key
<CONSUMER_KEY> z. B. xvz1evFS4wEEPTGEFPHBog
-
Access Token
<ACCESS_TOKEN> z. B. 370773112-GmHxMAgYyLbNEtIKZeRNFsMKPR9EyMZeS9weJAEb
curl --request POST --url 'https://api.x.com/1.1/account_activity/webhooks.json?url=<URL>' --header 'authorization: OAuth oauth_consumer_key="<CONSUMER_KEY>", oauth_nonce="GENERATED", oauth_signature="GENERATED", oauth_signature_method="HMAC-SHA1", oauth_timestamp="GENERATED", oauth_token="<ACCESS_TOKEN>", oauth_version="1.0"'
Abonnierte Nutzer verwalten:
Wir beginnen damit, einen Nutzer zu abonnieren, damit Sie alle Ereignistypen erhalten.Kopieren Sie die folgende cURL-Anfrage in Ihre Befehlszeile, nachdem Sie die folgenden Elemente angepasst haben:
-
Webhook-ID
<:WEBHOOK_ID> z. B. 1234567890
-
Consumer-Key-Name
<CONSUMER_KEY> z. B. xvz1evFS4wEEPTGEFPHBog
-
Access Token des abonnierenden Nutzers
<SUBSCRIBING_USER'S_ACCESS_TOKEN> z. B. 370773112-GmHxMAgYyLbNEtIKZeRNFsMKPR9EyMZeS9weJAEb
curl --request POST --url https://api.x.com/1.1/account_activity/webhooks/<:WEBHOOK_ID>/subscriptions/all.json --header 'authorization: OAuth oauth_consumer_key="<CONSUMER_KEY>", oauth_nonce="GENERATED", oauth_signature="GENERATED", oauth_signature_method="HMAC-SHA1", oauth_timestamp="GENERATED", oauth_token="<SUBSCRIBING_USER'S_ACCESS_TOKEN>", oauth_version="1.0"'
Ein Video‑Walkthrough zur Account Activity API
- Registrieren eines Webhooks
- Hinzufügen eines Benutzerabonnements
- Entfernen eines Benutzerabonnements
- Empfangen von Kontoaktivitäten
- Wiedergeben von Kontoaktivitäten
-
Haben Sie Fragen? Stoßen Sie auf Fehler?
-
Entdecken Sie unseren Beispielcode:
Enterprise
Erste Schritte mit Webhooks
1. Erstellen Sie eine X App.
- Erstellen Sie eine X App mit einem genehmigten Developer-Konto im Entwicklerportal. Wenn Sie die App im Auftrag Ihres Unternehmens erstellen, wird empfohlen, die App mit einem Unternehmens-X-Konto zu erstellen. Um ein Developer-Konto zu beantragen, klicken Sie hier.
- Aktivieren Sie „Lesen, Schreiben und Zugriff auf Direct Messages“ auf der Registerkarte permissions auf der App-Seite.
- Notieren Sie sich auf der Registerkarte „Keys and Access Tokens“ den Consumer Key (API Key) und den Consumer Token (API Secret) Ihrer App.
- Generieren Sie auf derselben Registerkarte den Access Token und das Access Token Secret Ihrer App. Sie benötigen diese Access Tokens, um Ihre Webhook-URL zu registrieren, an die X Kontenereignisse sendet.
- Wenn Sie mit X Sign-in und der Funktionsweise von Benutzerkontexten mit der X API nicht vertraut sind, lesen Sie Obtaining Access Tokens. Wenn Sie Konten hinzufügen, für die Ereignisse empfangen werden sollen, abonnieren Sie sie mit den Access Tokens dieses Kontos.
- Notieren Sie sich die numerische id Ihrer App, wie sie auf der Seite „Apps“ des Entwicklerportals angezeigt wird. Wenn Sie den Zugriff auf die Account Activity API beantragen, benötigen Sie diese App-id.
2. Zugriff auf die Account Activity API erhalten
3. Entwickeln Sie eine Webhook-Consumer-App
-
Erstellen Sie eine Web-App mit einer URL, die Sie als Webhook zum Empfangen von Ereignissen verwenden. Dies ist das endpoint, das auf Ihrem Server bereitgestellt wird und auf eingehende X-Webhook-Ereignisse lauscht.
-
Wie in unserem Leitfaden Securing Webhooks beschrieben, besteht ein erster Schritt darin, Code zu schreiben, der eine X Challenge Response Check (CRC)-GET-Anfrage empfängt und mit einer korrekt formatierten JSON-Antwort antwortet.
-
Registrieren Sie Ihre Webhook-URL. Sie senden eine POST-Anfrage an ein /webhooks.json?url=-endpoint. Wenn Sie diese Anfrage stellen, sendet X eine CRC-Anfrage an Ihre Web-App. Wenn ein Webhook erfolgreich registriert wurde, enthält die Antwort eine Webhook-id. Diese Webhook-id wird später benötigt, wenn einige Anfragen an die Account Activity API gestellt werden.
-
X sendet Konto-Webhook-Ereignisse an die von Ihnen registrierte URL. Stellen Sie sicher, dass Ihre Web-App POST-Anfragen für eingehende Ereignisse unterstützt. Diese Ereignisse werden in JSON kodiert. Siehe HIER für Beispiel-Webhook-JSON-Payloads.
-
Sobald Ihre Web-App bereit ist, besteht der nächste Schritt darin, Konten hinzuzufügen, für die Aktivitäten empfangen werden sollen. Beim Hinzufügen (oder Löschen) von Konten senden Sie POST-Anfragen, in denen die Konto-id referenziert wird. Weitere Informationen finden Sie in unserem Leitfaden zum Verwalten von Subscriptions.
- Um zu überprüfen, ob Ihre App und Ihr Webhook korrekt konfiguriert sind, markieren Sie einen Post eines der X-Konten, auf die Ihre App abonniert ist, als Favorit. Für jeden Favoriten, den Ihre Abonnenten erhalten, sollten Sie ein
favorite_events per POST-Anfrage an Ihre Webhook-URL erhalten.
- Beachten Sie, dass es bis zu 10 Sekunden dauern kann, bis nach dem Hinzufügen eines Abonnements mit der Zustellung von Ereignissen begonnen wird.
Wichtige Hinweise
-
Beim Registrieren Ihrer Webhook-URL muss sich Ihre Web-App mit ihrem Consumer-Token und -Secret sowie dem access token und Secret des App-Eigentümers authentifizieren.
-
Alle eingehenden Direct Messages werden über Webhooks zugestellt. Alle Direct Messages, die über POST direct_messages/events/new (message_create) gesendet werden, werden ebenfalls über Webhooks zugestellt. So kann Ihre Web-App über Direct Messages informiert sein, die über einen anderen Client gesendet wurden.
-
Beachten Sie, dass jedes Webhook-Ereignis ein for_user_id User-ID-Feld enthält, das angibt, für welches Abonnement das Ereignis zugestellt wurde.
-
Wenn zwei Nutzer Ihre Web-App für Direct Messages in derselben Unterhaltung verwenden, erhält Ihr Webhook zwei doppelte Ereignisse (je eines pro Nutzer). Ihre Web-App sollte dies berücksichtigen.
-
Wenn Sie mehr als eine Web-App mit derselben Webhook-URL betreiben und derselbe Nutzer jeweils den Apps zugeordnet ist, wird dasselbe Ereignis mehrfach an Ihren Webhook gesendet (einmal pro Web-App).
-
In einigen Fällen kann Ihr Webhook doppelte Ereignisse empfangen. Ihre Webhook-App sollte dies tolerieren und anhand der Ereignis-ID deduplizieren.
-
Erwarten Sie nicht, dass eine Quick-Reply-Antwort unmittelbar auf eine Anfrage folgt. Ein Nutzer kann eine Quick-Reply-Anfrage ignorieren und stattdessen über eine herkömmliche Direct Message antworten. Der Nutzer kann auch eine Quick-Reply-Antwort auf eine Anfrage geben, auf die er zuvor im Nachrichten-Thread nicht geantwortet hat.
-
Beispielcode ansehen:
-
Enterprise Account Activity API dashboard, eine Node-Web-App, die Webhook-Ereignisse mithilfe der Enterprise-Stufe der Account Activity API anzeigt und Replay-Funktionalität enthält.
-
Der SnowBot-Chatbot, eine Ruby-Web-App, die auf der Account Activity API und den Direct Messages APIs aufbaut. Dieser Codebestand enthält ein Skript, das beim Einrichten von Account Activity API-Webhooks hilft.
Die Webhook-basierten APIs von X bieten zwei Methoden, um die Sicherheit Ihres Webhook-Servers zu verifizieren:
- Die Challenge-Response-Prüfungen ermöglichen es X, den Besitz der Web-App zu bestätigen, die Webhook-Ereignisse empfängt.
- Der Signatur-Header in jeder POST-Anfrage ermöglicht es Ihnen, zu verifizieren, dass X die Quelle der eingehenden Webhooks ist.
Challenge-Response-Prüfungen
Um zu verifizieren, dass Sie sowohl der Eigentümer der App als auch der Webhook-URL sind, führt X eine Challenge-Response-Prüfung (CRC) durch, die nicht mit einer zyklischen Redundanzprüfung zu verwechseln ist. Wenn ein CRC gesendet wird, stellt X eine GET-Anfrage an Ihre Web-App mit dem Parameter crc_token. Wenn diese Anfrage eingeht, muss Ihre Web-App ein verschlüsseltes response_token auf Basis des Parameters crc_token und des Consumer Secret Ihrer App (Details unten) erzeugen. Das response_token muss in JSON codiert sein (siehe Beispiel unten) und innerhalb von drei Sekunden zurückgegeben werden. Bei Erfolg wird eine Webhook-id zurückgegeben.
Ein CRC wird gesendet, wenn Sie Ihre Webhook-URL registrieren; daher ist die Implementierung Ihres CRC-Antwortcodes ein grundlegender erster Schritt. Sobald Ihr Webhook eingerichtet ist, löst X ungefähr alle 24 Stunden seit der letzten erfolgreichen Antwort einen CRC aus. Ihre App kann bei Bedarf ebenfalls einen CRC auslösen, indem sie eine PUT-Anfrage mit Ihrer Webhook-id stellt. Das Auslösen eines CRC ist hilfreich während der Entwicklung Ihrer Webhook-Anwendung, nach dem Deployen neuen Codes und dem Neustart Ihres Dienstes.
Es ist zu erwarten, dass sich das crc_token bei jeder eingehenden CRC-Anfrage ändert und in der Berechnung als Nachricht verwendet werden sollte, wobei Ihr Consumer Secret der Schlüssel ist.
Falls die Antwort nicht innerhalb von 3 Sekunden zurückgesendet wird oder ungültig ist, werden Ereignisse nicht mehr an den registrierten Webhook gesendet.
- Wenn eine Webhook-URL registriert wird.
- Etwa stündlich, um Ihre Webhook-URL zu validieren.
- Sie können eine CRC manuell auslösen, indem Sie eine PUT-Anfrage senden. Während Sie Ihren Webhook-Client entwickeln, sollten Sie einplanen, die CRC manuell auszulösen, während Sie Ihre CRC-Antwort implementieren.
Anforderungen an die Antwort:
- Ein base64-kodierter HMAC-SHA-256-hash, erstellt aus dem
crc_token und dem Consumer Secret Ihrer App
- Gültiger response_token und JSON-Format.
- Latenz unter 3 Sekunden.
- HTTP-Statuscode 200.
Sprachspezifische HMAC-Bibliotheken:
Beispiel zur Generierung eines Antwort-Tokens in Python:
import base64
import hashlib
import hmac
import json
\# Definiert eine Route für die GET-Anfrage
@app.route('/webhooks/twitter', methods=\['GET'\])
def webhook_challenge():
# erstellt HMAC SHA-256-Hash aus eingehendem Token und Ihrem Consumer Secret
sha256\_hash\_digest = hmac.new(TWITTER\_CONSUMER\_SECRET, msg=request.args.get('crc_token'), digestmod=hashlib.sha256).digest()
# konstruiert Antwortdaten mit base64-kodiertem Hash
response = {
'response\_token': 'sha256=' + base64.b64encode(sha256\_hash_digest)
}
# gibt ordnungsgemäß formatierte JSON-Antwort zurück
return json.dumps(response)
{
"response_token": "sha256=x0mYd8hz2goCTfcNAaMqENy2BFgJJfJOb4PdvTffpwg="
}
- HIER ist eine Beispielmethode für eine CRC-Antwort, geschrieben in Node/JS.
- HIER ist eine Beispielmethode für eine CRC-Antwort, geschrieben in Ruby (siehe generate_crc_response und die /GET-Route, die CRC-Events empfängt).
Wenn Sie eine POST-Anfrage von X erhalten, eine GET-Anfrage senden, um einen Webhook zu erstellen, oder eine GET-Anfrage senden, um einen manuellen CRC auszuführen, wird in den Headern eine Hash-Signatur als x-twitter-webhooks-signature übermittelt. Diese Signatur kann verwendet werden, um zu prüfen, dass X die Quelle der data ist. Die POST-Hash-Signatur beginnt mit sha256= und weist auf die Verwendung von HMAC SHA-256 zur Verschlüsselung Ihres X App Consumer Secret und des Payloads hin. Der GET-Hash wird aus der query-Parameterzeichenfolge crc_token=token&nonce=nonce berechnet.
Schritte zur Validierung einer Anfrage
- Erstellen Sie einen Hash unter Verwendung Ihres Consumer Secrets und des eingehenden Payload-Bodys.
- Vergleichen Sie den erstellten Hash mit dem base64-codierten Wert von x-twitter-webhooks-signature. Verwenden Sie eine Methode wie compare_digest, um die Anfälligkeit für Timing-Angriffe zu verringern.
Zusätzliche Sicherheitsrichtlinien
Aggregierte Netzwerkblöcke von X
-
199.59.148.0/22
-
199.16.156.0/22
-
192.133.77.0/26
-
64.63.15.0/24
-
64.63.31.0/24
-
64.63.47.0/24
-
202.160.128.0/24
-
202.160.129.0/24
-
202.160.130.0/24
Empfohlene Serverkonfigurationen
- Bewertung „A“ im Test auf ssllabs.com
- TLS 1.2 aktivieren
- Forward Secrecy aktivieren
- SSLv2 deaktivieren
- SSLv3 deaktivieren (aufgrund von POODLE)
- TLS 1.0 deaktivieren
- TLS 1.1 deaktivieren
- TLS-Komprimierung deaktivieren
- Session Tickets deaktivieren, es sei denn, Sie rotieren die Session-Ticket-Schlüssel.
- Die Option „ssl_prefer_server_ciphers“ oder „SSLHonorCipherOrder“ in der SSL-Konfiguration auf „on“ setzen.
- Sicherstellen, dass die Cipher-Liste modern ist, z. B.:
ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES128-SHA256:AES128-SHA:AES256-GCM-SHA384:AES256-SHA256:AES256-SHA:ECDHE-RSA-DES-CBC3-SHA:DES-CBC3-SHA
Webhooks und Abonnements verwalten
Webhooks erstellen und ändern
Endpoints zur Verwaltung der Webhook-Konfiguration:
Warum kann ich die Webhook-URL nicht einfach aktualisieren?
Hinzufügen und Entfernen von Nutzerabonnements
Endpunkte für die Abonnementverwaltung
Bitte beachten: X muss den Zugriff auf die Account Activity API für Ihre Developer-App aktivieren, bevor Sie die API verwenden können. Teilen Sie hierfür die App-id, die Sie für die Authentifizierung verwenden möchten, mit Ihrer Account-Managerin/Ihrem Account-Manager oder dem technischen Supportteam.
- Consumer Keys (API Key und Secret)
- Access Tokens (Access Token und Secret)
Bei den folgenden drei Endpoints führen Sie Schreibaktionen im Kontext Ihrer Anwendung aus (es sind keine X-Nutzer beteiligt). Daher sind die Access Tokens, die Sie bereitstellen müssen, diejenigen, die zu Ihrer Developer-App gehören. Diese können direkt im Entwicklerportal im Tab „Keys und Tokens“ für Ihre App generiert werden.
Bei den folgenden drei Endpoints senden Sie hingegen eine Anfrage, die Ihrer Anwendung erlaubt, im Namen eines X-Nutzers auf geschützte Daten zuzugreifen (zum Beispiel Direct Messages). Daher müssen Sie die Access Tokens des betreffenden abonnierenden Nutzers bereitstellen. Die erforderlichen Access Tokens können mithilfe des 3-legged OAuth-Flow bezogen werden (siehe OAuth 1.0a: how to obtain a user’s Access Tokens). Diese Endpoints sind in der obigen Tabelle mit einem Sternchen (*) gekennzeichnet.
Bitte beachten: Stellen Sie sicher, dass Ihre Developer-App für „Lesen, Schreiben und Direct Messages“ aktiviert ist. Sie können diese Einstellung im Bereich Projects & Apps Ihres Developer-Kontos unter „App permissions“ für die ausgewählte Developer-App ändern. Nach dem Ändern der Berechtigungseinstellungen müssen Sie Ihre App-Zugangsdaten neu generieren. Bitte beachten: X muss den Zugriff auf die Account Activity API für Ihre Developer-App freischalten, bevor Sie die API verwenden können. Teilen Sie zu diesem Zweck die App-ID, die Sie für Authentifizierungszwecke verwenden möchten, Ihrem Account Manager oder dem technischen Supportteam mit.
- Consumer Keys (API Key und Secret)
- Access Tokens (Access Token und Secret)
Bei den folgenden drei Endpoints führen Sie Schreibaktionen im Kontext Ihrer Anwendung aus (es sind keine X-Nutzer beteiligt). Daher sind die Access Tokens, die Sie angeben müssen, diejenigen, die zu Ihrer Developer-App gehören. Diese können direkt im Entwicklerportal im Tab „Keys und Tokens“ für Ihre App generiert werden.
Bei den folgenden drei endpoints stellen Sie hingegen eine Anfrage, die Ihrer Anwendung ermöglicht, im Namen eines X Nutzers auf geschützte Daten zuzugreifen (z. B. Direct Messages). Sie müssen daher die Access Tokens des betreffenden abonnierenden Nutzers bereitstellen. Die erforderlichen Access Tokens können über den 3-legged OAuth-Flow bezogen werden (siehe OAuth 1.0a: how to obtain a user’s Access Tokens). Diese endpoints sind in der obigen Tabelle mit einem Sternchen (*) gekennzeichnet.
Bitte beachten: Stellen Sie sicher, dass Ihre Developer-App für „Read, Write, and Direct Messages“ aktiviert ist. Sie können diese Einstellung im Projects & Apps-Bereich Ihres Developer-Kontos unter „App permissions“ für die ausgewählte Developer-App ändern. Nach dem Ändern der Berechtigungseinstellungen müssen Sie Ihre App-Anmeldedaten neu generieren. Enterprise
Einer der Vorteile der Enterprise-Stufe der Account Activity API ist ein Wiederholungsmechanismus für Webhook-Ereignisse. Wenn kein 200-HTTP-Antwortcode „Success“ empfangen wird, initiiert der X-Server einen Wiederholungsmechanismus und sendet das Webhook-Ereignis innerhalb von fünf Minuten bis zu dreimal erneut. Dieser Wiederholungsdienst für Webhook-Ereignisse trägt zur Zuverlässigkeit und zur Wiederherstellung von Ereignissen bei, wenn Netzwerkprobleme auftreten sowie während clientseitiger Dienstunterbrechungen und Deployments.
Was sind Wiederholungsversuche?
Zeitplan für erneute Zustellung
Zeitplan für erneute Zustellversuche
|
|---|
| Aktivität erstellt; POST an die Webhook-URL der Account Activity API und Timeout nach drei Sekunden. |
| Drei Sekunden nach Abschluss des vorherigen Timeouts: POST an die Webhook-URL der Account Activity API, Timeout nach drei Sekunden. |
| 27 Sekunden nach Abschluss des vorherigen Timeouts: POST an die Webhook-URL der Account Activity API, Timeout nach drei Sekunden. |
| 242 Sekunden nach Abschluss des vorherigen Timeouts: POST an die Webhook-URL der Account Activity API, Timeout nach drei Sekunden. |
| Die Account Activity API unternimmt danach keine weiteren POSTs. Der Client muss andere X endpoints verwenden, um data wiederherzustellen. |
Struktur des Account-Activity-Datenobjekts
| Objekt | Details |
|---|
| for_user_id | Identifiziert das Benutzerabonnement, auf das sich das Ereignis bezieht. |
| is_blocked_by | (bedingt) Wird nur angezeigt, wenn ein anderer Benutzer Ihren abonnierten Benutzer erwähnt. Nur enthalten, wenn true, und nur bei Erwähnungsereignissen von Posts. |
| source | Der Benutzer, der die Aktivität ausführt. Zum Beispiel ist der Benutzer, der folgt, blockiert oder stumm schaltet, der Quellbenutzer. |
| target | Der Benutzer, auf den die Aktivität angewendet wird. Zum Beispiel ist der Benutzer, dem gefolgt wird bzw. der blockiert oder stumm geschaltet wird, der Zielbenutzer. |
Verfügbare Aktivitäten
| Nachrichtentyp | Details |
|---|
| tweet_create_events | Status-Payload eines Posts, wenn eine der folgenden Aktionen vom oder gegenüber dem Abonnementbenutzer ausgeführt wird: Posts, Retweets, Antworten, @mentions, QuoteTweets, Retweet von QuoteTweets. |
| favorite_events | like-Ereignisstatus mit dem Benutzer und dem Ziel. |
| follow_events | Follow-Ereignis mit dem Benutzer und dem Ziel. |
| unfollow_events | Unfollow-Ereignis mit dem Benutzer und dem Ziel. |
| block_events | Block-Ereignis mit dem Benutzer und dem Ziel. |
| unblock_events | Unblock-Ereignis mit dem Benutzer und dem Ziel. |
| mute_events | Mute-Ereignis mit dem Benutzer und dem Ziel. |
| unmute_events | Unmute-Ereignis mit dem Benutzer und dem Ziel. |
| user_event | Revoke-Ereignisse, die gesendet werden, wenn ein Benutzer die App-Autorisierung entfernt und das Abonnement automatisch gelöscht wird. |
| direct_message_events | Status für Direktnachrichten mit dem Benutzer und dem Ziel, wenn eine Direktnachricht gesendet oder empfangen wird. |
| direct_message_indicate_typing_events | Tippanzeige-Ereignis für Direktnachrichten mit dem Benutzer und dem Ziel. |
| direct_message_mark_read_events | Lesebestätigungs-Ereignis für Direktnachrichten mit dem Benutzer und dem Ziel. |
| tweet_delete_events | Hinweis auf gelöschte Posts, um die Compliance leichter zu gewährleisten. |
Payload-Beispiele
Nachfolgend finden Sie die Payload-Beispiele für jedes in der obigen Tabelle beschriebene Account-Activity-Ereignis.
{
"for_user_id": "2244994945",
"tweet_create_events": [
{
<Tweet-Objekt>
}
]
}
{
"for_user_id": "2244994945",
"user_has_blocked": "false",
"tweet_create_events": [
{
<Tweet-Objekt>
}
]
}
favorite_events
{
"for_user_id": "2244994945",
"favorite_events": [{
"id": "a7ba59eab0bfcba386f7acedac279542",
"created_at": "Mon Mar 26 16:33:26 +0000 2018",
"timestamp_ms": 1522082006140,
"favorited_status": {
<Tweet-Objekt>
},
"user": {
<User-Objekt>
}
}]
}
follow_events
{
"for_user_id": "2244994945",
"follow_events": [{
"type": "follow",
"created_timestamp": "1517588749178",
"target": {
<User-Objekt>
},
"source": {
<User-Objekt>
}
]
}
}
unfollow_events
{
"for_user_id": "2244994945",
"follow_events": [{
"type": "unfollow",
"created_timestamp": "1517588749178",
"target": {
<User-Objekt>
},
"source": {
<User-Objekt>
}
]
}
}
block_events
{
"for_user_id": "2244994945",
"block_events": [{
"type": "block",
"created_timestamp": "1518127020304",
"source": {
<User-Objekt>
},
"target": {
<User-Objekt>
}
}]
}
unblock_events
{
"for_user_id": "2244994945",
"block_events": [{
"type": "unblock",
"created_timestamp": "1518127020304",
"source": {
<User-Objekt>
},
"target": {
<User-Objekt>
}
}]
}
mute_events
{
"for_user_id": "2244994945",
"mute_events": [
{
"type": "mute",
"created_timestamp": "1518127020304",
"source": {
<User-Objekt>
},
"target": {
<User-Objekt>
}
}
]
}
unmute_events
{
"for_user_id": "2244994945",
"mute_events": [
{
"type": "unmute",
"created_timestamp": "1518127020304",
"source": {
<User-Objekt>
},
"target": {
<User-Objekt>
}
}
]
}
user_event
{
"user_event": {
"revoke": {
"date_time": "2018-05-24T09:48:12+00:00",
"target": {
"app_id": "13090192"
},
"source": {
"user_id": "63046977"
}
}
}
}
direct_message_events
{
"for_user_id": "4337869213",
"direct_message_events": [{
"type": "message_create",
"id": "954491830116155396",
"created_timestamp": "1516403560557",
"message_create": {
"target": {
"recipient_id": "4337869213"
},
"sender_id": "3001969357",
"source_app_id": "13090192",
"message_data": {
"text": "Hallo Welt!",
"entities": {
"hashtags": [],
"symbols": [],
"user_mentions": [],
"urls": []
}
}
}
}],
"apps": {
"13090192": {
"id": "13090192",
"name": "FuriousCamperTestApp1",
"url": "https://x.com/furiouscamper"
},
"users": {},
"3001969357": {
"id": "3001969357",
"created_timestamp": "1422556069340",
"name": "Jordan Brinks",
"screen_name": "furiouscamper",
"location": "Boulder, CO",
"description": "Alter Ego - X PE Meinungen sind meine eigenen",
"url": "https://t.co/SnxaA15ZuY",
"protected": false,
"verified": false,
"followers_count": 22,
"friends_count": 45,
"statuses_count": 494,
"profile_image_url": "null",
"profile_image_url_https": "https://pbs.twimg.com/profile_images/851526626785480705/cW4WTi7C_normal.jpg"
},
"4337869213": {
"id": "4337869213",
"created_timestamp": "1448312972328",
"name": "Harrison Test",
"screen_name": "Harris_0ff",
"location": "Burlington, MA",
"protected": false,
"verified": false,
"followers_count": 8,
"friends_count": 8,
"profile_image_url": "null",
"statuses_count": 240,
"profile_image_url_https": "https://abs.twimg.com/sticky/default_profile_images/default_profile_normal.png"
}
}
}
direct_message_indicate_typing_events
{
"for_user_id": "4337869213",
"direct_message_indicate_typing_events": [{
"created_timestamp": "1518127183443",
"sender_id": "3284025577",
"target": {
"recipient_id": "3001969357"
}
}],
"users": {
"3001969357": {
"id": "3001969357",
"created_timestamp": "1422556069340",
"name": "Jordan Brinks",
"screen_name": "furiouscamper",
"location": "Boulder, CO",
"description": "Alter Ego - X PE Meinungen sind meine eigenen",
"url": "https://t.co/SnxaA15ZuY",
"protected": false,
"verified": false,
"followers_count": 23,
"friends_count": 47,
"statuses_count": 509,
"profile_image_url": "null",
"profile_image_url_https": "https://pbs.twimg.com/profile_images/851526626785480705/cW4WTi7C_normal.jpg"
},
"3284025577": {
"id": "3284025577",
"created_timestamp": "1437281176085",
"name": "Bogus Bogart",
"screen_name": "bogusbogart",
"protected": true,
"verified": false,
"followers_count": 1,
"friends_count": 4,
"statuses_count": 35,
"profile_image_url": "null",
"profile_image_url_https": "https://pbs.twimg.com/profile_images/763383202857779200/ndvZ96mE_normal.jpg"
}
}
}
direct_message_mark_read_events
{
"for_user_id": "4337869213",
"direct_message_mark_read_events": [{
"created_timestamp": "1518452444662",
"sender_id": "199566737",
"target": {
"recipient_id": "3001969357"
},
"last_read_event_id": "963085315333238788"
}],
"users": {
"199566737": {
"id": "199566737",
"created_timestamp": "1286429788000",
"name": "Le Braat",
"screen_name": "LeBraat",
"location": "Denver, CO",
"description": "tagsüber Daten @X, abends Design",
"protected": false,
"verified": false,
"followers_count": 299,
"friends_count": 336,
"statuses_count": 752,
"profile_image_url": "null",
"profile_image_url_https": "https://pbs.twimg.com/profile_images/936652894371119105/YHEozVAg_normal.jpg"
},
"3001969357": {
"id": "3001969357",
"created_timestamp": "1422556069340",
"name": "Jordan Brinks",
"screen_name": "furiouscamper",
"location": "Boulder, CO",
"description": "Alter Ego - X PE, Meinungen sind meine eigenen",
"url": "https://t.co/SnxaA15ZuY",
"protected": false,
"verified": false,
"followers_count": 23,
"friends_count": 48,
"statuses_count": 510,
"profile_image_url": "null",
"profile_image_url_https": "https://pbs.twimg.com/profile_images/851526626785480705/cW4WTi7C_normal.jpg"
}
}
}
{
"for_user_id": "930524282358325248",
"tweet_delete_events": [
{
"status": {
"id": "1045405559317569537",
"user_id": "930524282358325248"
},
"timestamp_ms": "1432228155593"
}
]
}
Account Activity Replay API
Enterprise
Die Account Activity Replay API ist ein Tool zur Datenwiederherstellung, mit dem Sie Ereignisse bis zu fünf Tage rückwirkend abrufen können. Sie sollte verwendet werden, um Daten wiederherzustellen, wenn Ihr Webhook-Server Ereignisse verpasst — sei es aufgrund von Verbindungsunterbrechungen, die länger als das Retry-Fenster andauern, oder in Notfallwiederherstellungs-Szenarien, in denen Sie einige Tage benötigen, um Ihr System wieder in den Normalbetrieb zu versetzen.
Die Account Activity Replay API wurde für Szenarien entwickelt, in denen Sie über einen bestimmten Zeitraum Aktivitäten nicht verarbeiten konnten. Sie liefert Aktivitäten an denselben Webhook, der auch für die ursprüngliche Echtzeitbereitstellung der Aktivitäten verwendet wurde. Dieses Produkt ist ein Wiederherstellungstool und kein Backfill-Tool, was bedeutet, dass Ereignisse nur erneut zugestellt werden, wenn zuvor eine Zustellung versucht wurde. Die Account Activity Replay API kann keine Ereignisse für einen Zeitraum vor dem Erstellungszeitpunkt eines Abonnements zustellen.
Verwendung der Account Activity Replay API
webhook id enthalten, der angibt, für welchen Webhook die Aktivitäten wiedergegeben werden sollen. Anders ausgedrückt fordert eine Replay-Anfrage die Account Activity Replay API auf, Ereignisse von einem Startdatum und -zeitpunkt bis zu einem Enddatum und -zeitpunkt auf Basis der webhook id und der application id abzurufen.
Bitte beachten Sie, dass UTC-Zeit erwartet wird. Diese Aktivitäten werden über den registrierten Webhook, der der id zugeordnet ist, mit bis zu 2.500 Ereignissen pro Sekunde zugestellt. Beachten Sie außerdem, dass jeweils nur ein Replay-Job pro Webhook ausgeführt werden kann, auch wenn alle Abonnements, die während des auf diesem Webhook angegebenen Datums/Zeitraums aktiv waren, wiedergegeben werden.
Ereignisse werden beginnend mit der ersten (ältesten) Minute des angegebenen Zeitraums zugestellt und chronologisch (so gut wie möglich) fortgesetzt, bis die letzte Minute zugestellt wurde. Anschließend sendet Replay ein Job-Abschlussereignis an den Webhook. Da wir Aktivitäten chronologisch zustellen, kann es, wenn es zum Startzeitpunkt nur wenige oder keine passenden Ergebnisse gibt, bis zur Zustellung der ersten Ergebnisse zu einer Verzögerung kommen.
Replay ist als Tool gedacht, um Aktivitäten bis zu fünf Tage rückwirkend einfach wiederherzustellen, liefert jedoch keine Ereignisse, die vor dem Erstellungszeitpunkt eines Abonnements liegen. Wenn Sie beispielsweise vor drei Tagen ein neues Abonnement hinzugefügt und anschließend einen Replay-Job mit einem Zeitfenster von fünf Tagen bis heute ausgeführt haben, würden Sie nur data für die drei Tage erhalten, in denen dieses neue Abonnement aktiv war.
Datenverfügbarkeit und -typen
Einführung in die Migration
- User Streams
- Site Streams
- GET direct_messages
- GET direct_messages/sent
- GET direct_messages/show
- POST direct_messages/new
- POST direct_messages/destroy
Wir haben neue endpoints und Dienste, die einen ähnlichen Zugriff und – für Direct Messages – zusätzliche Funktionen bieten:
Um Ihnen eine reibungslose Migration zu diesen neuen endpoints und Diensten zu ermöglichen, haben wir zwei Migrationsleitfäden:
Zusätzlich haben wir eine Videoreihe zur Account Activity API und zum Einstieg.
Und schließlich haben wir Codebeispiele, um Ihr Verständnis zu vertiefen und Ihnen einen schnellen Einstieg zu ermöglichen:
- Das Account Activity Dashboard ist eine Beispiel-Node.js-Web-App mit Hilfsskripten, um den Einstieg in die Account Activity API zu erleichtern.
- SnowBot ist ein Beispiel-Chatbot, der die Account Activity API und REST-Direct-Message-endpoints verwendet. Er ist in Ruby geschrieben, nutzt das Sinatra-Web-App-Framework und wird auf Heroku bereitgestellt.
Migrationsleitfaden: Wechsel von User Streams/Site Streams zur Account Activity API
Zusammenfassung der Änderungen
Unterschiede und Überlegungen zur Migration
Verwalten von Benutzerabonnements
Migration: Vorgehensweise
Befolgen Sie die folgenden Schritte, um problemlos von der Site Streams API zur Account Activity API zu migrieren
- Anzahl der benötigten Webhooks
- Aktuelle/prognostizierte Abonnements/autorisierte Nutzer, die in Ihrer Anwendung verwaltet werden
- Aktuelle Anzahl der X-Client-Anwendungen
- Das gewünschte Supportniveau von X (Forumssupport oder verwalteter Enterprise-1:1-Support)
- Preis jedes Pakets
Schritt 2: Überprüfen Sie die Einrichtung Ihrer X App im Entwicklerportal
Die X App, die derzeit für User Streams oder Site Streams verwendet wird, wird für den Besitzer im Entwicklerportal aufgeführt. Diese X App kann auch für die Account Activity API verwendet werden, um autorisierte Nutzer für diese Anwendung beizubehalten. Sie können auch eine neue App erstellen und Nutzer bei Bedarf für diese neue App erneut autorisieren. Wenn Sie eine neue App im Namen eines Unternehmens erstellen, wird empfohlen, die App mit einem Unternehmens-X-@handle-Konto zu erstellen.
- Aktivieren Sie „Lesen, Schreiben und Zugriff auf Direct Messages“ auf der Registerkarte permissions Ihrer X App-Seite.
Beachten Sie, dass die Änderung dieser Einstellungen nicht rückwirkend ist; alle autorisierten Nutzer behalten die Autorisierungseinstellungen zum Zeitpunkt ihrer Autorisierung. Wenn ein Nutzer Ihnen noch keinen Lese-, Schreib- und Direct-Message-Zugriff gewährt hat, muss dieser Nutzer Ihre Anwendung erneut autorisieren.
- Wenn Sie mit X Sign-in und der Funktionsweise von Nutzerkontexten mit der X API nicht vertraut sind, lesen Sie Obtaining Access Tokens.
- Generieren Sie Access Tokens für den Besitzer der X App am unteren Rand der Registerkarte „Keys and Tokens“. Notieren Sie sich auf derselben Registerkarte Ihren Consumer Key, Consumer Secret, Access Token und Access Token Secret. Diese benötigen Sie für die Nutzung der API.
- Generieren Sie ein Bearer Token mit Ihrem Consumer Key und Consumer Secret für application-only-API-Methoden.
Schritt 3: Richten Sie Ihre Webhooks ein und konfigurieren Sie sie
-
Erstellen Sie eine Web-App mit einem endpoint, das als Webhook zum Empfangen von Ereignissen dient (z. B. https://your_domain.com/webhook/twitter oder https://webhooks.your_domain.com).
-
Verwenden Sie Ihren Consumer Key, Consumer Secret, Access Token und Access Token Secret beim Erstellen Ihres Webhooks. Beachten Sie, dass Ihr endpoint eine JSON-Antwort mit einem response_token zurückgeben muss, das ein base64-codierter HMAC-SHA-256-hash ist, der aus dem crc_token und dem Consumer Secret Ihrer App erstellt wird.
-
Lesen Sie die Dokumentation zu Securing Webhooks und beachten Sie insbesondere die Anforderungen des Challenge Response Check (CRC).
-
Stellen Sie sicher, dass Ihr Webhook POST-Anfragen für eingehende Ereignisse und GET-Anfragen für den CRC unterstützt.
-
Stellen Sie sicher, dass Ihr Webhook eine geringe Latenz aufweist (weniger als 3 Sekunden für die Antwort auf POST-Anfragen).
Schritt 4: Validieren Sie Ihre Webhook-Einrichtung
-
Webhook-APIs sichern Ihre Webhooks auf zwei Arten:
-
Challenge-Response-Prüfungen sind erforderlich, um zu validieren, dass der Webhook-Besitzer auch der Besitzer der Web-App ist.
-
Ein Signatur-Header in jeder POST-Anfrage, damit Ihre Web-App die Quelle validieren kann.
-
Um zu verifizieren, dass Sie sowohl der Besitzer der Web-App als auch der Webhook-URL sind, führt X einen Challenge Response Check (CRC) durch, der nicht mit einer zyklischen Redundanzprüfung zu verwechseln ist.
-
Eine GET-Anfrage mit einem Parameter namens crc_token wird an Ihre Webhook-URL gesendet. Ihr endpoint muss eine JSON-Antwort mit einem response_token zurückgeben, der ein base64-codierter HMAC-SHA-256-hash ist, der aus dem crc_token und dem Consumer Secret Ihrer App erstellt wird.
-
Es ist zu erwarten, dass sich der crc_token bei jeder eingehenden CRC-Anfrage ändert. Der crc_token sollte als Nachricht in der Berechnung verwendet werden, wobei Ihr Consumer Secret der Schlüssel ist.
-
Falls die Antwort ungültig ist, werden keine Ereignisse mehr an den registrierten Webhook gesendet.
Schritt 5: Erstellen Sie Abonnements für jeden User Stream- oder Site Streams-autorisierten Nutzer
Umstellung von User Streams auf die Account Activity API:
- Erstellen Sie eine Liste Ihrer aktuellen Benutzerabonnements in User Streams
- Richten Sie Ihre neuen Abonnements für die Account Activity API mit folgender Anfrage ein: POST account_activity/all/:env_name/subscriptions
- Bestätigen Sie Ihre Abonnements für die Account Activity API mit folgender Anfrage: _GET account_activity/all/:env_name/subscriptions/list
_
Umstieg auf die Account Activity API von Site Streams (unter Verwendung von Control Streams):
- Erstellen Sie eine Liste Ihrer aktuellen Abonnements in Site Streams mit folgender Anfrage: GET /1.1/site/c/:stream_id/info.json
- Richten Sie Ihre neuen Abonnements für die Account Activity API mit folgender Anfrage ein: POST account_activity/all/:env_name/subscriptions
- Bestätigen Sie Ihre Abonnements für die Account Activity API mit folgender Anfrage: _GET account_activity/all/:env_name/subscriptions/list
_
Registrieren eines Webhooks und Erstellen von Abonnements (keine Migration von Site Streams oder User Streams)
Das Account Activity-Dashboard (Beispiel-App für die Account Activity API)
- Laden Sie die Beispiel-App „Account Activity Dashboard“ hier herunter (sie verwendet Node.js)
- Befolgen Sie die Anweisungen in der README, um die App zu installieren und zu starten
- Sobald die Anwendung läuft, können Sie die UI verwenden, um Ihren Webhook einfach einzurichten und ein neues Abonnement zu erstellen
Veraltete Streaming-Nachrichtentypen
| |
|---|
| Leere Zeilen | Leere Zeilen werden in der Account Activity API nicht mehr ausgeliefert, da sie in User Streams und Site Streams als Keep-Alive-Nachrichten verwendet wurden. |
| Limit-Hinweise | Limit-Hinweise werden nicht mehr an einen bestimmten Webhook gesendet. Stattdessen können Nutzer die API aufrufen, um die aktuelle Nutzung verfügbarer Handles abzurufen. Diese Information wird zu einem späteren Zeitpunkt auch im Entwicklerportal verfügbar sein. |
| Disconnect-Nachrichten | Disconnect-Hinweise sind nicht mehr erforderlich, da Webhooks nicht von einer aktiven Verbindung abhängen. |
| Stall-Warnungen | Stall-Warnungen sind nicht mehr erforderlich, da Webhooks nicht auf eine aktive Verbindung angewiesen sind, die große Mengen eingehender Nachrichten verarbeiten kann. |
| Freundesliste | Freundeslisten werden nicht mehr proaktiv gesendet. Es wird nun ein REST-endpoint geben, um diese Informationen abzurufen. |
| | | | |
|---|
| Beschreibung | Ereignisname | Quelle | Ziel | Zielobjekt |
| Nutzer löscht einen Post | delete | Aktueller Nutzer | Aktueller Nutzer | Post |
| Gefolgter Nutzer löscht einen Post | delete | Gefolgter Nutzer | Gefolgter Nutzer | Post |
| Nutzer entfernt „Gefällt mir“ von einem Post | unfavorite | Aktueller Nutzer | Post-Autor | Post |
| Post des Nutzers wird „entfavorisiert“ | unfavorite | Entfavorisierender Nutzer | Aktueller Nutzer | Post |
| Nutzer entfolgt jemandem | unfollow | Aktueller Nutzer | Gefolgter Nutzer | Null |
| Nutzer erstellt eine List | list_created | Aktueller Nutzer | Aktueller Nutzer | List |
| Nutzer löscht eine List | list_destroyed | Aktueller Nutzer | Aktueller Nutzer | List |
| Nutzer bearbeitet eine List | list_updated | Aktueller Nutzer | Aktueller Nutzer | List |
| Nutzer fügt jemanden zu einer List hinzu | list_member_added | Aktueller Nutzer | Hinzugefügter Nutzer | List |
| Nutzer wird zu einer List hinzugefügt | list_member_added | Hinzufügender Nutzer | Aktueller Nutzer | List |
| Nutzer entfernt jemanden aus einer List | list_member_removed | Aktueller Nutzer | Entfernte(r) Nutzer(in) | List |
| Nutzer wird aus einer List entfernt | list_member_removed | Entfernender Nutzer | Aktueller Nutzer | List |
| Nutzer abonniert eine List | list_user_subscribed | Aktueller Nutzer | List-Inhaber | List |
| List des Nutzers wird abonniert | list_user_subscribed | Abonnierender Nutzer | Aktueller Nutzer | List |
| Nutzer beendet das Abonnement einer List | list_user_unsubscribed | Aktueller Nutzer | List-Inhaber | List |
| Abonnement der List des Nutzers wird beendet | list_user_unsubscribed | Kündigender Nutzer | Aktueller Nutzer | List |
| Nutzer aktualisiert sein Profil | user_update | Aktueller Nutzer | Aktueller Nutzer | Null |
| Nutzer aktualisiert seinen geschützten Status | user_update | Aktueller Nutzer | Aktueller Nutzer | Null |
Leitfaden zur Migration von Direct Messages
Zusammenfassung der Änderungen
- Unterstützung für Medienanhänge (Bild, GIF und Video).
- Möglichkeit, Nutzer mit einer vordefinierten Auswahlliste zu strukturierten Antworten aufzufordern.
- Zugriff auf bis zu 30 Tage an vergangenen Direct Messages.
Eine vollständige Liste der neuen Direct-Message-Funktionen und zusätzlicher neuer API endpoints finden Sie in der technischen Dokumentation.
Unterschiede und Migrationsaspekte
Neues Direct-Messages-Objekt
{
"type": "message_create",
"id": "1234858592",
"created_timestamp": "1392078023603",
"initiated_via": {
"tweet_id": "123456",
"welcome_message_id": "456789"
},
"message_create": {
"target": {
"recipient_id": "1234858592"
},
"sender_id": "3805104374",
"source_app_id": "268278",
"message_data": {
"text": "Blauer Vogel",
"entities": {
"hashtags": [],
"symbols": [],
"urls": [],
"user_mentions": [],
},
"quick_reply_response": {
"type": "options",
"metadata": "external_id_2"
},
"attachment": {
"type": "media",
"media": {
...
}
}
}
}
- Vollständig neue Struktur des Direct-Message-Objekts.
- Gestrafftes User-Objekt.
- Neue bereitgestellte Informationen (Schnellantwort-Antworten, Anhänge usw.).
Senden von Direct Messages
twurl -A 'Content-type: application/json' -X POST /1.1/direct\_messages/events/new.json -d '{"event": {"type": "message\_create", "message\_create": {"target": {"recipient\_id": "4534871"}, "message_data": {"text": "Hallo Welt!"}}}}'
- Die Nachricht wird im JSON-POST-Body definiert
- Der Content-Type-Header muss auf application/json gesetzt sein
- Der JSON-Body wird nicht in die Erstellung der OAuth-Signatur einbezogen.
Abrufen von Direct Messages
- Gesendete und empfangene Nachrichten werden jetzt über dasselbe endpoint zurückgegeben.
- Es werden bis zu 30 Tage an Nachrichten zurückgegeben.
- Cursorbasierte Paginierung.
- Echtzeitzugriff auf Direktnachrichten via Webhook.
Direct Messages können jetzt mit DELETE direct_messages/events/destroy gelöscht werden. Die Schnittstelle ist weitgehend unverändert und erfordert die id der zu löschenden Nachricht. Der wesentliche Unterschied besteht darin, dass das endpoint nun eine DELETE-Anfrage statt einer POST-Anfrage erwartet.
Wie gelöschte Direct Messages in offiziellen X‑Clients dargestellt werden, bleibt unverändert. Direct Messages werden nur aus der Oberfläche des angegebenen Nutzerkontexts entfernt. Andere Teilnehmer der Unterhaltung können weiterhin auf die Direct Message zugreifen.
- Zum Löschen einer Direct Message wird die id benötigt.
- Das neue endpoint erfordert eine DELETE-Anfrage.
- Die Darstellung gelöschter Direct Messages in offiziellen X‑Clients bleibt unverändert.
**Fragen zur Migration zu den neuen Direct Message-endpoints?
**Stellen Sie Ihre Frage im Entwickler-Community-Forum auf devcommunity.com.
Welche Vorteile bietet die Account Activity API?
Die Account Activity API verwendet Webhooks. Anders als bei den Streaming-APIs ist daher keine offene Verbindung erforderlich, damit wir Ihnen Informationen senden können. Webhooks unterscheiden sich auch von REST-APIs, weil Sie uns nicht alle 15 Minuten Hunderte Male abfragen müssen, um die für Sie relevanten Daten zu erhalten. Das erhöht die Effizienz zwischen einem Nutzer und Ihrer App, da Daten in Echtzeit bereitgestellt werden.
Die Account Activity API bietet eine Reihe von Vorteilen:
- Geschwindigkeit: Wir liefern Daten mit der Geschwindigkeit von X.
- Einfachheit: Wir liefern alle Ereignisse eines Accounts über eine einzige Webhook-Verbindung. Die in der API gelieferten Aktivitäten umfassen Posts, @Mentions, Antworten, Retweets, Quote Tweets, Retweets von Quote Tweets, Likes, gesendete Direct Messages, empfangene Direct Messages, Follows, Blocks, Mutes.
- Skalierung: Sie erhalten alle Aktivitäten für einen von Ihnen verwalteten Account, ohne durch Rate Limits oder Ereignisobergrenzen eingeschränkt zu sein.
Die Account Activity API ist als Premium-Sandbox, kostenpflichtiges Premium sowie als Enterprise-Angebot verfügbar, sodass Sie je nach Bedarf bei mehr Accounts für Haftungsfunktionen oder zusätzliche Funktionalität skalieren können.
Für den Einstieg laden Sie Beispielcode-Snippets von GitHub herunter.
Wie finde ich heraus, welche Produktstufe am besten zu mir passt?
Bitte lesen Sie unsere Seite Account Activity API Overview, um mehr über die Unterschiede zwischen den Premium-Optionen und der Enterprise-Option zu erfahren.
Was ist der Unterschied zwischen einer Premium-Umgebung und einem Enterprise-Webhook?
Es gibt keinen Unterschied. Jede Premium-Umgebung hat ihre eigene webhook_id.
Ich benötige Entwicklungs-, Staging- und Produktionsumgebungen für die Account Activity API. Ist das möglich?
Ja! Mit den kostenpflichtigen Stufen der Account Activity API (Paid Premium und Enterprise) ist es möglich, mehrere Webhook-URLs zu registrieren und Abonnements für jede Umgebung separat über die API-Methoden zu verwalten. Zusätzlich können mehrere Client-Apps zu einer Allowlist hinzugefügt werden, um die Autorisierung für Ihre derzeit autorisierten Nutzer aufrechtzuerhalten.
Gibt es Schritt-für-Schritt-Anleitungen, wie ich die Account Activity API einrichte?
Tatsächlich gibt es die!
-
Wenn Sie gerade erst anfangen, empfehlen wir unseren Leitfaden Getting started with webhooks
-
Folgen Sie unseren von X Dev unterstützten Skripten:
- Account Activity API Dashboard, eine Node-Web-App, die Webhook-Ereignisse anzeigt.
- Der SnowBot-Chatbot, eine Ruby-Web-App, basierend auf der Account Activity API und den Direct Message APIs. Dieser Codebestand enthält ein Skript zur Einrichtung von Account Activity API-Webhooks.
Gibt es eine Möglichkeit, Daten wiederherzustellen, wenn unser System für einen Zeitraum ausfällt?
Mit den kostenpflichtigen Stufen der Account Activity API (Paid Premium und Enterprise) wird unser system retry versuchen, Ihnen die Aktivitäten mehrfach über einen Zeitraum von vier Stunden zu senden. Wenn Ihr System innerhalb dieses Vier-Stunden-Zeitraums nicht antwortet, geht die Aktivität verloren und Sie müssen andere REST-endpoints verwenden, um Daten innerhalb von 7 Tagen wiederherzustellen.
Wir empfehlen, Ihre unterschiedlichen Webhooks bzw. Umgebungen als Redundanzwerkzeug wie die Account Activity Replay API zu nutzen, um sicherzustellen, dass Ihnen keine Aktivitäten entgehen, falls eines Ihrer Systeme ausfällt.
Welche Authentifizierung muss ich mit der Account Activity API verwenden?
Die erforderlichen Autorisierungsmethoden für die Account Activity API sind pro Methode auf den API Reference Pages beschrieben. Wenn Sie gerade erst mit der X-Authentifizierung beginnen, empfehlen wir Ihnen, diesen Abschnitt zu lesen.
Was ist ein Challenge-Response-Check (CRC)?
Die Challenge-Response-Prüfung der Account Activity API ist eine Sicherheitsfunktion, die sicherstellt, dass die Aktivitäten der Account Activity API an den richtigen Entwickler gesendet werden. Sie kann auch von Entwicklern verwendet werden, um zu verifizieren, dass die empfangenen Daten tatsächlich von X stammen. X sendet automatisch einmal alle 24 Stunden eine CRC an Ihre Webhook-URL, ausgehend vom Zeitpunkt der letzten Validierung der Webhook-URL. Ihr System muss innerhalb von 3 Sekunden mit einer gültigen Antwort reagieren, um validiert zu bleiben.
Bitte besuchen Sie unsere Seite Securing webhooks für weitere Details.
Gibt es etwas, das meine Webhook-URL sofort ungültig machen würde?
Wenn einer der folgenden Fälle eintritt, markieren wir Ihren Webhook sofort als ungültig:
- Der Server antwortet auf eine CRC mit einem falschen Token. In diesem Fall wird unser System keinen Retry durchführen, um Ihnen die Aktivität zu senden.
- Für die Webhook-URL ist ein falsches Zertifikat konfiguriert. In diesem Fall wird unser System keinen Retry durchführen, um Ihnen die Aktivität zu senden.
- Ihr Server gibt einen Antwortcode zurück, der weder 2XX noch 4XX noch 5XX ist.
- Sie geben die Verwendung von gzip an, senden es aber tatsächlich nicht.
- Sie geben die Verwendung von gzip nicht an, senden es aber tatsächlich in der Antwort.
Erhalte ich doppelte Aktivitäten, wenn ich auf Nutzer abonniert bin, die miteinander interagieren?
Ja. Wenn Ihre Web-App aktive Abonnements für Nutzer A und Nutzer B hat und Nutzer A Nutzer B in einem Post erwähnt, werden zwei POST-Aktivitäten an den registrierten Webhook gesendet. Jede Aktivität enthält einen Indikator “for_user_id”, der angibt, zu welchem Abonnement die Aktivität gehört.
Wenn ich ein Abonnement für meinen Webhook erstelle, kann ich den /all/-Teil des folgenden endpoint durch andere Account-Activity-Datenobjekte ersetzen, um die vom API gelieferten Aktivitäten einzuschränken? POST https://api.x.com/1.1/account_activity/all/:env_name/subscriptions.json
Nein, das ist nicht möglich. Derzeit ist nur das Produkt /all/ verfügbar.
Gibt es eine Möglichkeit, die Account Activity API zu verwenden, ohne von Nutzern Berechtigungen für Direct Messages anzufordern?
Derzeit sind Berechtigungen für Direct Messages erforderlich, da es keine Möglichkeit gibt, die Aktivitäten zu Direct Messages für diese API „herauszufiltern“.
Gibt es eine kostenlose Version der Account Activity API?
Ja, wir bieten die Sandbox-Version als kostenlose Stufe an. Unsere Sandbox-Option ist auf einen einzelnen Webhook mit maximal 15 Abonnements begrenzt. Weitere Informationen zur Sandbox-Option finden Sie in unserer Dokumentation.
Ist es möglich, die Account Activity API zu verwenden, um Retweets von Posts zu erhalten, die abonnierte Nutzer erwähnen?
Leider ist dies nicht Teil der Aktivitäten, die mit dieser API geliefert werden. Dafür empfehlen wir stattdessen die Verwendung der Streaming API.
Welche möglichen Aktivitätstypen werden durch ein tweet_create_event repräsentiert?
Ein tweet_create_event-Payload wird gesendet:
Wenn der abonnierte Nutzer eine der folgenden Aktionen ausführt:
- Erstellt einen Post
- Retweetet
- Antwortet auf einen Post
Wenn ein anderer Nutzer:
- @erwähnt* den abonnierten Nutzer
- Zitiert einen vom abonnierten Nutzer erstellten Tweet
Hinweis: Die Account Activity API liefert nur Ereignisse, wenn der abonnierte Nutzer von X eine Benachrichtigung erhalten würde und das Ereignis öffentlich sehen könnte. Das bedeutet: Wenn der erwähnte Account (@userA) dem geschützten Account (@userB) folgt, erhält UserA eine Benachrichtigung, dass UserB ihn erwähnt hat. Wenn UserA UserB nicht folgt (und nicht von UserB genehmigt wurde), erhält UserA keine Benachrichtigung, und daher würde ein tweet_create_event nicht über die AAA gesendet, wenn @userA ein Abonnement hätte.
Wenn ein blockierter Nutzer meinen abonnierten Nutzer erwähnt, wie kann ich das erkennen?
Sie sehen ein boolesches Feld user_has_blocked auf der obersten Ebene der JSON-Antwort, gesetzt auf entweder “true” oder “false”. Dieses Feld wird nur bei Post-Erwähnungen angezeigt.
Enterprise
Wie kann ich meine App zu einer Allowlist hinzufügen oder prüfen, ob sich meine App bereits auf der Allowlist befindet?
Um die X Apps zu verwalten, die Sie für den Zugriff über die Enterprise-APIs auf eine Allowlist gesetzt haben, wenden Sie sich bitte mit Ihrer App-id an Ihre Account-Managerin/Ihren Account-Manager. Ihre App-id finden Sie, indem Sie zur Seite “Apps” im Entwicklerportal navigieren.
Wenn ich Zugriff auf drei Webhooks habe, kann ich dann für jede der für die Enterprise-Nutzung registrierten Apps drei Webhooks verwenden?
Das Webhook-Limit ist auf Kontoebene festgelegt, nicht auf App-Ebene. Wenn Sie Zugriff auf drei Webhooks und zwei für die Enterprise-Nutzung registrierte Apps haben, können Sie zwei Webhooks bei einer App und den dritten bei der anderen App verwenden, aber nicht drei bei jeder App.
Kann ich festlegen, welche Arten von Ereignissen mit der Account Activity Replay API erneut zugestellt werden?
Die Arten von Ereignissen, die wiedergegeben werden, können nicht festgelegt werden. Alle Ereignisse, die innerhalb des angegebenen Datums- und Zeitfensters zugestellt wurden, werden erneut zugestellt.
Gibt es erneute Zustellversuche, wenn meine Anwendung ein Ereignis der Account Activity Replay API nicht verarbeiten kann?
Nein, es gibt keine erneuten Zustellversuche. Wenn eine Anwendung ein von der Account Activity Replay API gesendetes Ereignis nicht verarbeitet, kann ein weiterer Replay-Job für denselben Zeitraum eingereicht werden, um die erneute Zustellung verpasster Replay-Ereignisse zu versuchen.
Was soll ich tun, wenn ich ein Abschlussereignis mit teilweisem Erfolg erhalte?
Wir empfehlen, die Zeitstempel der empfangenen Ereignisse zu notieren und einen weiteren Replay-Job für die verpassten Ereignisse anzufordern.
Wie viele Account Activity Replay API-Jobs kann ich gleichzeitig ausführen?
Pro Webhook darf jeweils nur ein Account Activity Replay API-Job ausgeführt werden.
Wie kann ich Account Activity Replay API-Ereignisse von Echtzeit-Produktionsereignissen unterscheiden, wenn sie an meinen Webhook zugestellt werden?
Da die Account Activity Replay API stets Ereignisse aus der Vergangenheit liefert, können Ereignisse anhand ihres Zeitstempels von Echtzeit-Produktionsereignissen unterschieden werden.
Wie schnell kann ich die Account Activity Replay API nutzen, um eine Aktivität erneut zuzustellen, die meine Anwendung verworfen oder verpasst hat?
Eine Aktivität wird etwa 10 Minuten nach ihrer Erstellung für die erneute Zustellung verfügbar.
Leitfaden zur Fehlerdiagnose
-
Enterprise - Stellen Sie sicher, dass die von Ihnen verwendeten Consumer Keys und Access Tokens zu einer X App gehören, die für die Nutzung von Enterprise‑Produkten registriert wurde. Wenn Sie Ihre Consumer Keys und Access Tokens nicht zur Hand haben oder Ihre X App zur Allowlist hinzufügen müssen, wenden Sie sich bitte an Ihre Account‑Managerin bzw. Ihren Account‑Manager.
-
Wenn Sie mit Benutzerkontext authentifizieren, stellen Sie sicher, dass Sie Ihre Anfrage autorisiert haben – mit dem korrekten
oauth nonce, oauth_signature und oauth_timestamp.
-
Stellen Sie sicher, dass Ihre Access Tokens die richtige Berechtigungsstufe haben.
- Auf dem Tab „Keys und Tokens“ im App-Dashboard vergewissern Sie sich bitte, dass Ihre Access Tokens die Berechtigungsstufe „Read, write, and Direct Messages“ haben (permission level).
- Wenn die Berechtigungsstufe der Tokens darunter liegt, wechseln Sie bitte zum Tab „Permissions“, stellen Sie die Zugriffsberechtigung auf „Read, write, and Direct Messages“ ein und generieren Sie anschließend Ihre Access Tokens und das Secret im Tab „Keys und Tokens“ neu.
-
Stellen Sie sicher, dass Ihre URL korrekt formatiert ist.
- Bitte beachten Sie, dass
:env_name zwischen Groß- und Kleinschreibung unterscheidet.
-
Premium - Stellen Sie sicher, dass Sie ein genehmigtes Developer-Konto haben, bevor Sie eine Anfrage an die API stellen. Außerdem müssen Sie den richtigen :env_name in der Anfrage verwenden; diesen können Sie auf der Seite dev environments konfigurieren.
-
Enterprise - Stellen Sie sicher, dass Ihre Account-Managerin/Ihr Account-Manager Ihnen Zugriff auf die Account Activity API eingerichtet hat.
-
Stellen Sie sicher, dass die URI korrekt konfiguriert ist. Dieser Fehler kann auftreten, wenn Sie eine falsche URI in Ihrer Anfrage angegeben haben.
Code 214 – Webhook-URL erfüllt die Anforderungen nicht.
Code 214 - Hohe Latenz bei CRC-GET-Anfrage. Ihr Webhook sollte innerhalb von 3 Sekunden antworten.
- Das bedeutet, dass Ihr Server langsam ist. Stellen Sie sicher, dass Sie innerhalb von 3 Sekunden auf den CRC antworten.
Code 214 – Nicht-200-Antwortcode während einer CRC-GET-Anfrage (z. B. 404, 500, usw.).
- Ihr Server ist nicht erreichbar. Stellen Sie sicher, dass er ordnungsgemäß läuft.
Code 214 - Es wurden bereits zu viele Ressourcen erstellt.
- Enterprise - Sie haben bereits alle Ihre Webhooks verwendet. Verwenden Sie das endpoint GET webhooks mit jeder Ihrer registrierten Apps, um nachzuvollziehen, wo Ihre Webhooks eingerichtet sind.
- Die App, die Sie mit der API verwenden, hat nicht die richtige Berechtigungsstufe für ihr Access Token und Access Token Secret. Navigieren Sie zur Registerkarte „Keys und Tokens“ im X Apps-Dashboard und prüfen Sie die Berechtigungsstufen, die Ihrem Access Token und Access Token Secret zugewiesen sind. Wenn diese auf etwas anderes als „Read, write and Direct Messages“ eingestellt sind, passen Sie die Einstellungen auf der Registerkarte „Permissions“ an und generieren Sie Ihr Access Token und Access Token Secret neu, damit die neuen Einstellungen wirksam werden.
- Alternativ versuchen Sie möglicherweise, einen Webhook mit App-only-Authentifizierung zu registrieren, was nicht unterstützt wird. Authentifizieren Sie sich stattdessen mit Benutzerkontext, wie in den API-Referenzabschnitten zur Registrierung eines Webhooks für die Enterprise Account Activity API beschrieben.
Account Activity API Referenzindex
Enterprise Account Activity API
POST account_activity/webhooks
Registriert eine neue Webhook-URL für den angegebenen Anwendungskontext. Die URL wird vor dem Speichern mittels einer CRC-Anfrage validiert. Schlägt die Validierung fehl, erhält die anfragende Partei eine aussagekräftige Fehlermeldung.
Die Anzahl zulässiger Webhooks wird durch das Abrechnungspaket bestimmt.
https://api.x.com/1.1/account_activity/webhooks.json
| |
|---|
| Antwortformat | JSON |
| Authentifizierung erforderlich | Ja (Benutzerkontext – alle Consumer- und Access Tokens) |
| Rate Limit | Ja |
| Anfragen pro 15‑Minuten‑Fenster (Benutzerauth) | 15 |
| Unterstützung für Tweet-Bearbeitungen | Alle Tweet-Objekte enthalten Tweet-Edit-metadata, die die Bearbeitungshistorie des Tweets beschreibt. Weitere Details finden Sie auf der Seite “Tweet edits” – Grundlagen. |
| |
|---|
| url (erforderlich) | Kodierte URL für das Callback-endpoint. |
$ curl —request POST
—url ‘https://api.x.com/1.1/account_activity/webhooks.json?url=https%3A%2F%2Fyour_domain.com%2Fwebhooks%2Ftwitter%2F0'
—header ‘authorization: OAuth oauth_consumer_key=“CONSUMER_KEY”, oauth_nonce=“GENERATED”, oauth_signature=“GENERATED”, oauth_signature_method=“HMAC-SHA1”, oauth_timestamp=“GENERATED”, oauth_token=“ACCESS_TOKEN”, oauth_version=“1.0“‘
| HTTP-Code | Meldung |
|---|
| 200 | Die Webhook-URL ist bei der angegebenen App registriert |
| 403 | Ihre Anfrage enthält einen Fehler. Weitere Informationen finden Sie im Abschnitt „Fehlermeldungen“ unten. |
_HTTP 200_
{
"id": "1234567890",
"url": "https://your_domain.com/webhook/twitter/0",
"valid": true,
"created_at": "2016-06-02T23:54:02Z"
}
| Code | Nachricht |
|---|
| 214 | Webhook-URL erfüllt die Anforderungen nicht. |
| 214 | Es wurden bereits zu viele Ressourcen erstellt. |
| 214 | Webhook-URL erfüllt die Anforderungen nicht. Ungültiges CRC-Token oder JSON-Antwortformat. |
| 214 | Hohe Latenz bei der CRC-GET-Anfrage. Ihr Webhook sollte in weniger als 3 Sekunden antworten. |
| 214 | Nicht-200-Antwortcode während der CRC-GET-Anfrage (z. B. 404, 500 usw.). |
HTTP 403
{
"errors": [
{
"code": 214,
"message": "Zu viele Ressourcen wurden bereits erstellt."
}
]
}
GET account_activity/webhooks
Gibt alle URLs und deren Status für die angegebene App zurück.
Eine URL wird als ungültig markiert, wenn sie die tägliche Validierungsprüfung nicht besteht. Um die URL wieder zu aktivieren, rufen Sie das Update-endpoint auf.
Ressourcen-URL
https://api.x.com/1.1/account_activity/webhooks.json
| |
|---|
| Antwortformat | JSON |
| Authentifizierung erforderlich | Ja (nur App – Bearer Token) |
| Rate Limit | Ja |
| Anfragen pro 15-Minuten-Fenster (App-Authentifizierung) | 15 |
$ curl --request GET
--url https://api.x.com/1.1/account_activity/webhooks.json
--header 'authorization: Bearer TOKEN'
[
{
"id": "1234567890",
"url": "https://your_domain.com/webhook/twitter/0",
"valid": true,
"created_at": "2016-06-02T23:54:02Z"
}
{
"id": "2468013579",
"url": "https://your_domain2.com/webhook/twitter/0",
"valid": true,
"created_at": "2016-06-04T22:31:29Z"
}
]
| Code | Meldung |
|---|
| 99 | Sie haben keinen Zugriff auf diese Ressource. |
PUT account_activity/webhooks/:webhook_id
Löst die Challenge-Response-Prüfung (CRC) für die URL des angegebenen Webhooks aus. Wenn die Prüfung erfolgreich ist, wird der Statuscode 204 zurückgegeben und der Webhook wird durch Setzen seines Status auf valid wieder aktiviert.
Ressourcen-URL
https://api.x.com/1.1/account_activity/webhooks/:webhook_id.json
| |
|---|
| Antwortformat | JSON |
| Authentifizierung erforderlich | Ja (Benutzerkontext – alle Consumer- und Access Tokens) |
| Rate Limit | Ja |
| Anfragen pro 15-Minuten-Fenster (Benutzerauthentifizierung) | 15 |
| |
|---|
| webhook_id (erforderlich) | Webhook-ID. Im Ressourcenpfad definiert. |
$ curl --request PUT
--url https://api.x.com/1.1/account_activity/webhooks/:WEBHOOK_ID.json
--header 'authorization: OAuth oauth_consumer_key="CONSUMER_KEY", oauth_nonce="GENERATED", oauth_signature="GENERATED", oauth_signature_method="HMAC-SHA1", oauth_timestamp="GENERATED", oauth_token="ACCESS_TOKEN", oauth_version="1.0"'
| Code | Nachricht |
|---|
| 34 | Webhook ist nicht vorhanden oder einer anderen X App zugeordnet. |
| 214 | Webhook-URL erfüllt die Anforderungen nicht. |
| 214 | Webhook-URL erfüllt die Anforderungen nicht. Ungültiges CRC-Token oder JSON-Antwortformat. |
| 214 | Hohe Latenz bei CRC-GET-Anfrage. Ihr Webhook sollte innerhalb von weniger als 3 Sekunden antworten. |
| 214 | Nicht-200-Antwortcode während der CRC-GET-Anfrage (z. B. 404, 500 usw.). |
POST account_activity/webhooks/:webhook_id/subscriptions/all
Abonniert die angegebene App auf alle Ereignisse im bereitgestellten Benutzerkontext und für alle Nachrichtentypen. Nach der Aktivierung werden alle Ereignisse für den anfragenden Benutzer per POST an den Webhook der App gesendet.
Abonnements sind derzeit durch Ihre Kontokonfiguration begrenzt. Wenn Sie zusätzliche Abonnements benötigen, wenden Sie sich bitte an Ihren Account-Manager.
https://api.x.com/1.1/account_activity/webhooks/:webhook_id/subscriptions/all.json
| |
|---|
| Antwortformat | JSON |
| Authentifizierung erforderlich | Ja (3-legged OAuth – Whitelisted Consumer Key und Access Token des abonnierenden Nutzers) |
| Rate Limit | Ja |
| Anfragen/15-Minuten-Fenster (Benutzerauth) | 500 |
| |
|---|
| webhook_id (erforderlich) | Webhook‑ID. Im Ressourcenpfad definiert. |
$ curl --request POST
--url https://api.x.com/1.1/account_activity/webhooks/:WEBHOOK_ID/subscriptions/all.json
--header 'authorization: OAuth oauth_consumer_key="WHITELISTED_CONSUMER_KEY", oauth_nonce="GENERATED", oauth_signature="GENERATED", oauth_signature_method="HMAC-SHA1", oauth_timestamp="GENERATED", oauth_token="SUBSCRIBING_USER'S_ACCESS_TOKEN", oauth_version="1.0"'
Beispielantwort – Erfolg
HTTP 204 Kein Inhalt
Fehlermeldungen
| Code | Meldung |
|---|
| 34 | Webhook ist nicht vorhanden oder einer anderen X App zugeordnet. |
| 348 | Die Client‑App ist nicht berechtigt, auf die Webhook-Abonnements dieses Nutzers zuzugreifen. |
GET account_activity/subscriptions/count
Gibt die Anzahl der Abonnements zurück, die derzeit in Ihrem Account aktiv sind. Beachten Sie, dass das /count endpoint ausschließlich App-only OAuth erfordert. Senden Sie Anfragen daher mit einem Bearer Token statt im Benutzerkontext.
https://api.x.com/1.1/account_activity/subscriptions/count.json
| |
|---|
| Antwortformat | HTTP-Statuscode |
| Authentifizierung erforderlich | Ja (nur App – Bearer Token) |
| Rate Limited | Ja |
| Anfragen pro 15-Minuten-Fenster (App-Authentifizierung) | 15 |
| |
|---|
| Code | Meldung |
| 200 | Erfolg. Die Anzahl der Abonnements für den angeforderten Webhook wird zurückgegeben. |
| 401 | Ihre App hat keine Berechtigung, die Abonnements für den angegebenen Webhook anzuzeigen. |
$ curl --request GET
--url https://api.x.com/1.1/account_activity/subscriptions/count.json
--header 'authorization: Bearer TOKEN'
{
"account_name":"mein-konto",
"subscriptions_count_all":"1",
"subscriptions_count_direct_messages":"0",
"provisioned_count":"50"
}
| Code | Meldung |
|---|
| 32 | Authentifizierung fehlgeschlagen. |
HTTP 401
{
"errors": [
{
"code": 32,
"message": "Authentifizierung fehlgeschlagen."
}
]
}
GET account_activity/webhooks/:webhook_id/subscriptions/all
Ermöglicht zu prüfen, ob eine Webhook-Konfiguration für die Ereignisse des angegebenen Nutzers abonniert ist. Wenn der angegebene Nutzerkontext ein aktives Abonnement mit der angegebenen App hat, wird 204 OK zurückgegeben. Ist der Antwortcode nicht 204, hat der Nutzer kein aktives Abonnement. Siehe unten „HTTP-Statuscode“ und Fehlermeldungen für Details.
Ressourcen-URL
https://api.x.com/1.1/account_activity/webhooks/:webhook_id/subscriptions/all.json
| |
|---|
| Antwortformat | JSON |
| Authentifizierung erforderlich | Ja (3-legged OAuth – whitelisted Consumer Key und access token des abonnierenden Nutzers) |
| Rate Limit | Ja |
| Anfragen/15‑Minuten‑Fenster (Benutzerauth) | 500 |
| |
|---|
| webhook_id (erforderlich) | Webhook-ID. Im Ressourcenpfad definiert. |
$ curl —request GET
—url https://api.x.com/1.1/account_activity/webhooks/:WEBHOOK_ID/subscriptions/all.json
—header ‘authorization: OAuth oauth_consumer_key=“WHITELISTED_CONSUMER_KEY”, oauth_nonce=“GENERATED”, oauth_signature=“GENERATED”, oauth_signature_method=“HMAC-SHA1”, oauth_timestamp=“GENERATED”, oauth_token=“SUBSCRIBING_USER’S_ACCESS_TOKEN”, oauth_version=“1.0“‘
Beispielantwort – Erfolg
HTTP 204 No Content
GET account_activity/webhooks/:webhook_id/subscriptions/all/list
Gibt eine Liste der aktuellen Abonnements des Typs „All Activity“ für den angegebenen Webhook zurück. Beachten Sie, dass das /list-endpoint ausschließlich Application-only OAuth erfordert; daher sollten Anfragen mit einem Bearer Token statt im Nutzerkontext gestellt werden.
Ressourcen-URL
https://api.x.com/1.1/account_activity/webhooks/:webhook_id/subscriptions/all/list.json
| |
|---|
| Antwortformat | HTTP-Statuscode |
| Authentifizierung erforderlich | Ja (nur App – Bearer Token) |
| Rate Limited | Ja |
| Anfragen pro 15‑Minuten‑Fenster (App-Authentifizierung) | 50 |
| |
|---|
| webhook_id (required) | Webhook-ID. Im Ressourcenpfad definiert. |
| Code | Nachricht |
|---|
| 200 | Erfolg. Eine Liste der Abonnements für den angeforderten Webhook wird zurückgegeben. |
| 401 | Ihre App hat keine Berechtigung, die Abonnements für den angegebenen Webhook anzuzeigen. |
$ curl —request GET
—url https://api.x.com/1.1/account_activity/webhooks/:WEBHOOK_ID/subscriptions/all/list.json
—header ‘authorization: Bearer TOKEN’
HTTP 200
{
"webhook_id": "1234567890",
"webhook_url": "https://your_domain.com/webhook/twitter/0",
"application_id": "11231812",
"subscriptions": [{
"user_id": "20212306"
}]
}
Fehlermeldungen
| Code | Meldung |
|---|
| 32 | Authentifizierung fehlgeschlagen. |
HTTP 401
{
"errors": [
{
"code": 32,
"message": "Authentifizierung fehlgeschlagen."
}
]
}
DELETE account_activity/webhooks/:webhook_id
Entfernt den Webhook aus der Konfiguration der angegebenen App. Die Webhook-id kann abgerufen werden, indem ein Aufruf an GET /1.1/account_activity/webhooks vorgenommen wird.
https://api.x.com/1.1/account_activity/webhooks/:webhook_id.json
| |
|---|
| Antwortformat | JSON |
| Authentifizierung erforderlich | Ja (Nutzerkontext – alle Consumer- und Access Tokens) |
| Rate Limit | Ja |
| Anfragen pro 15-Minuten-Fenster (Nutzerauthentifizierung) | 15 |
| |
|---|
| webhook_id (required) | Webhook-ID. Im Ressourcenpfad definiert. |
$ curl --request DELETE
--url https://api.x.com/1.1/account_activity/webhooks/:WEBHOOK_ID.json
--header 'authorization: OAuth oauth_consumer_key="CONSUMER_KEY", oauth_nonce="GENERATED", oauth_signature="GENERATED", oauth_signature_method="HMAC-SHA1", oauth_timestamp="GENERATED", oauth_token="ACCESS_TOKEN", oauth_version="1.0"'
DELETE account_activity/webhooks/:webhook_id/subscriptions/all (VERALTET)
Deaktiviert die Abonnements für den angegebenen Benutzerkontext und die App. Nach der Deaktivierung werden alle Ereignisse für den anfordernden Benutzer nicht mehr an die Webhook-URL gesendet.
Ressourcen-URL
https://api.x.com/1.1/account_activity/webhooks/:webhook_id/subscriptions/all.json
| |
|---|
| Antwortformat | JSON |
| Authentifizierung erforderlich | Ja (3-legged OAuth – freigeschalteter Consumer Key und abonniertes Benutzer-access token) |
| Rate Limit | Ja |
| Anfragen/15-Minuten-Zeitraum (Benutzerauth) | 500 |
| |
|---|
| webhook_id (required) | Webhook-ID. Im Ressourcenpfad definiert. |
Beispielanfrage
$ curl --request DELETE
--url https://api.x.com/1.1/account_activity/webhooks/:WEBHOOK_ID/subscriptions/all.json
--header 'authorization: OAuth oauth_consumer_key="WHITELISTED_CONSUMER_KEY", oauth_nonce="GENERATED", oauth_signature="GENERATED", oauth_signature_method="HMAC-SHA1", oauth_timestamp="GENERATED", oauth_token="SUBSCRIBED_USER'S_ACCESS_TOKEN", oauth_version="1.0"'
DELETE /account_activity/webhooks/:webhook_id/subscriptions/:user_id/all.json
Deaktiviert das Abonnement für den angegebenen Webhook und die Benutzer-id. Nach der Deaktivierung werden alle Ereignisse für den anfragenden Benutzer nicht mehr an die Webhook-URL gesendet. Beachten Sie, dass dieses endpoint ausschließlich App-only OAuth erfordert; Anfragen sollten daher mit einem Bearer Token statt im Benutzerkontext gestellt werden.
Ressourcen-URL
https://api.x.com/1.1/account_activity/webhooks/:webhook_id/subscriptions/:user_id/all.json
| |
|---|
| Antwortformat | JSON |
| Authentifizierung erforderlich | Ja (nur App – Bearer Token) |
| Rate Limit | Ja |
| Anfragen/15-Minuten-Zeitraum | 500 |
$ curl --request DELETE
--url https://api.x.com/1.1/account_activity/webhooks/:webhook_id/subscriptions/:user_id/all.json
--header 'authorization: Bearer TOKEN'
| Code | Nachricht |
|---|
| 404 | Entschuldigung, diese Seite existiert nicht. – Dies tritt häufig auf, wenn die angegebene Benutzer-id tatsächlich nicht abonniert ist. |
POST /1.1/account_activity/replay/webhooks/:webhook_id/subscriptions/all.json ¶
Sendet eine Anforderung, um Aktivitäten aus bis zu den letzten fünf Tagen von allen Abonnements abzurufen, die während der im Request angegebenen Datums- und Zeitfenster aktiv waren. Wenn Ihr Webhook aktive Benutzerabonnements hat, erhalten Sie diese Ereignisse gleichzeitig ebenfalls. Hinweis: Vor der Zustellung von Replay-Ereignissen führen wir eine CRC-Prüfung durch.
| |
|---|
| Request Method | HTTP POST |
| URL | /1.1/account_activity/replay/webhooks/:webhook_id/subscriptions/all.json?from_date=yyyymmddhhmm&to_date=yyyymmddhhmm |
| Response Format | JSON |
| Requires Authentication | Ja (nur Anwendung – Bearer Token) |
| Rate Limit | 5 Requests pro 15 Minuten. Derzeit gibt es kein Maximum für die Anzahl der Replay-Jobs, die angefordert werden können. |
| from_date | Der älteste (beginnend) UTC-Zeitstempel, ab dem die Ereignisse bereitgestellt werden; muss im Format ‘yyyymmddhhmm’ vorliegen. Der Zeitstempel hat Minutenauflösung und ist inklusiv (d. h. 12:00 schließt die 00. Minute ein). Gültige Zeiten müssen innerhalb der letzten 5 Tage (UTC) liegen und dürfen nicht aktueller als 31 Minuten vor dem jetzigen Zeitpunkt sein. Es wird empfohlen, dass from_date und to_date innerhalb von etwa 2 Stunden liegen. |
| to_date | Der jüngste (endende) UTC-Zeitstempel, bis zu dem die Ereignisse bereitgestellt werden; muss im Format ‘yyyymmddhhmm’ vorliegen. Der Zeitstempel hat Minutenauflösung und ist exklusiv (d. h. 12:30 schließt die 30. Minute der Stunde nicht ein). Gültige Zeiten müssen innerhalb der letzten 5 Tage (UTC) liegen und dürfen nicht aktueller als 10 Minuten vor dem jetzigen Zeitpunkt sein. |
Die folgenden Antworten können von der API zurückgegeben werden. Die meisten Fehlercodes werden mit einer Zeichenfolge im Body zurückgegeben, die zusätzliche Details enthält. Bei Nicht-200-Antworten sollten Sie den Fehler beheben und es erneut versuchen.
| Status | Text | Fehlercode | Beschreibung | Nachricht |
|---|
| 202 | Accepted | N/V | Die Anfrage war erfolgreich und die Aktivitäten werden gesendet. | N/V |
| 400 | Bad Request | 214 | Webhook wurde als ungültig markiert. | Webhook ist als ungültig markiert und erfordert eine CRC-Prüfung. |
| 400 | Bad Request | 357 | Query-Parameter fehlt. | : queryParam ist erforderlich. |
| 400 | Bad Request | 358 | Route- oder Query-Parameter ist fehlerhaft. | Parameter kann nicht geparst werden. |
| 400 | Bad Request | 360 | Routenparameter ist negativ. | webhook_id: [] ist nicht größer oder gleich 0. |
| 400 | Bad Request | 368 | from_date oder to_date liegt nicht in der Vergangenheit. | : [<field_value>] liegt nicht in der Vergangenheit. |
| 400 | Bad Request | 356 | from_date muss vor to_date liegen. | from_date muss vor to_date liegen. |
| 400 | Bad Request | 356 | from_date muss innerhalb der letzten 5 Tage liegen. | from_date muss innerhalb der letzten 5 Tage liegen. |
| 401 | Unauthorized | 32 | HTTP-Authentifizierung aufgrund bereitgestellter 3-legged auth fehlgeschlagen. | Ungültige Authentifizierungsmethode. Bitte verwenden Sie ausschließlich App-Only-Authentifizierung. |
| 401 | Unauthorized | 61 | Client ist nicht berechtigt, diese Methode anzufordern. | Client ist nicht berechtigt, diese Methode anzufordern. |
| 403 | Forbidden | 200 | Client verfügt nicht über ein Enterprise-Konto mit aktiviertem Replay. | Account Activity API Enterprise-Konto mit Replay ist erforderlich. Bitte bestätigen Sie, dass Sie ein Enterprise-Konto haben und Replay aktiviert ist. |
| 404 | Not Found | 34 | Nicht vorhandene webhook_id; webhook_id-application_id stimmt nicht überein. | Webhook ist nicht vorhanden oder ist einer anderen X App zugeordnet. |
| 409 | Conflict | 355 | Es gibt eine laufende Anfrage, die erst abgeschlossen werden muss, bevor eine weitere gestellt werden kann. | Ein Replay-Job ist für diesen Webhook bereits in Bearbeitung. |
| 429 | Too Many Requests | 88 | Rate Limit erreicht (Anzahl der Anfragen pro Zeitraum überschritten) | Zu viele Anfragen. Bitte reduzieren Sie Ihre API-Anfragerate. |
| 500 | Internal Server Error | 0 | Interner Serverfehler. | Interner Serverfehler. |
| 503 | Service Unavailable | 67 | Einer oder mehrere abhängige Dienste bei X sind nicht verfügbar. | X-Serverfehler. Wiederholen Sie die Anfrage mit exponentiellem Backoff. |
„Auftrag erfolgreich abgeschlossen“-Meldung
{
"replay\_job\_status": {
"webhook_id": "1234577122340233217",
"job_state": "Complete",
"job\_state\_description": "Job erfolgreich abgeschlossen"
"job_id": "1095098195724558337"
}
}
„Job failed to complete“-Meldung
{
"replay\_job\_status": {
"webhook_id": "123451374207332352",
"job_state": "Incomplete",
"job\_state\_description": "Job konnte nicht alle Events übermitteln, bitte wiederholen Sie Ihren Replay-Job",
"job_id": "1093226942650736640"
}
}
curl --request POST --url 'https://api.x.com/1.1/account_activity/replay/webhooks/:webhook_id/subscriptions/all.json?from_date=yyyymmddhhmm&to_date=yyyymmddhhmm'
--header 'authorization: Bearer TOKEN'
{
"job_id": "1234567890",
"created_at": "2016-06-02T23:54:02Z"
}
