Developer-Apps

​

Übersicht

Wenn Sie bereits Apps haben, können Sie diese über die App-Seite des Entwicklerportals anzeigen, bearbeiten oder löschen.

Der Zugriff auf die X API und die X Ads API erfordert einen Satz von Authentifizierungs-Anmeldedaten, auch bekannt als Keys und Tokens, die Sie mit jeder Anfrage übermitteln müssen. Diese Anmeldedaten können je nach Art der Authentifizierung, die vom jeweiligen endpoint, den Sie verwenden, verlangt wird, unterschiedliche Formen annehmen.

Hier sind die verschiedenen Anmeldedaten, die Sie in Ihrer App generieren können, und wie Sie sie verwenden:

• API Key und Secret: Im Wesentlichen der Benutzername und das Passwort für Ihre App. Sie verwenden diese, um Anfragen zu authentifizieren, die OAuth 1.0a User Context erfordern, oder um andere Tokens wie Benutzer-Access Tokens oder App Access Token zu generieren.

• Access Token und Secret: Allgemein repräsentieren Access Tokens den Benutzer, in dessen Auftrag Sie die Anfrage stellen. Diejenigen, die Sie über das Entwicklerportal generieren können, repräsentieren den Benutzer, dem die App gehört. Sie verwenden diese, um Anfragen zu authentifizieren, die OAuth 1.0a User Context erfordern. Wenn Sie Anfragen im Namen eines anderen Benutzers stellen möchten, müssen Sie den 3-legged OAuth-Flow verwenden, damit dieser Sie autorisiert.

• Client ID und Client Secret: Diese Anmeldedaten werden verwendet, um mittels OAuth 2.0-Authentifizierung ein Benutzer-Access Token zu erhalten. Ähnlich wie bei OAuth 1.0a werden die Benutzer-Access Tokens verwendet, um Anfragen zu authentifizieren, die private Benutzerkontoinformationen bereitstellen oder Aktionen im Namen eines anderen Kontos ausführen, jedoch mit fein abgestuftem Scope für eine bessere Kontrolle darüber, welchen Zugriff die Client-Anwendung auf den Benutzer hat.

• App only Access Token: Sie verwenden dieses Token, wenn Sie Anfragen an endpoints stellen, die mit öffentlich auf X verfügbaren Informationen antworten.

Zusätzlich zur Generierung der Keys und Tokens, die für X API-Anfragen erforderlich sind, können Sie auch Zugriffs-Berechtigungen festlegen, den Use Case bzw. Zweck der App dokumentieren, eine Callback-URL definieren und weitere Einstellungen zu Ihrer App-Entwicklungsumgebung im Management-Dashboard vornehmen.

​

Apps und Projects

Sie können Apps und Projects verwenden, um Ihre Arbeit mit der X Developer Platform nach Anwendungsfällen zu organisieren. Jedes Project kann mit dem Free X API‑Plan eine App enthalten, mit dem Basic‑Plan bis zu zwei Apps und mit dem Pro‑Plan bis zu drei Apps.

Wenn Sie auf die neuen X API v2-endpoints zugreifen möchten, müssen Sie Keys und Tokens aus einer App verwenden, die einem Project zugeordnet ist.

Wenn Sie Apps haben, die erstellt wurden, bevor wir Projects eingeführt haben, werden diese im Abschnitt „Standalone Apps“ angezeigt. Standalone Apps sind Apps außerhalb der Project-Struktur. Wenn Sie eine Standalone App einem Project zuordnen, kann sie anschließend Anfragen an die v2-endpoints stellen.

​

Dashboard des Entwicklerportals

Sie können das Dashboard besuchen, um die mit Ihrem Konto verknüpften Apps zu verwalten. Weitere Informationen finden Sie auf unserer Dokumentationsseite zum Entwicklerportal. Das Dashboard ermöglicht es Entwicklern, die folgenden Aufgaben schnell und einfach durchzuführen:

• Anzeigen Ihrer vorhandenen Standalone-Apps und der zugehörigen App-id.
• Erstellen eines neuen Projects, einer App oder einer Standalone-App.
• DELETE eines ungenutzten Projects oder einer App.
• Überprüfen oder Aktualisieren der Einstellungen einer bestimmten App, einschließlich Aktualisierung von Name, Beschreibung, Website, Callback-URL und permissions.
• Neuerstellen appspezifischer Anmeldedaten wie API Key & Secret, App Access Token und der user Access Tokens des App-Inhabers.

​

Anmeldung für den Zugriff

Wenn Sie bereits X Apps besitzen, können Sie Ihre Apps über das X App-Dashboard anzeigen und bearbeiten, sofern Sie auf developer.x.com in Ihrem X Konto angemeldet sind. Bitte beachten Sie, dass Sie sich nicht für ein Konto registrieren müssen, um alle Apps zu verwalten, die zuvor auf developer.x.com erstellt wurden.

Wenn Sie eine neue X App erstellen müssen, benötigen Sie ein Developer-Konto. Wenn Sie Mitglied eines Teamkontos sind, müssen Sie die Admin-Rolle zugewiesen bekommen, um eine neue App zu erstellen.

​

Kennzeichnung „Automated Account“ für Bots

Sie können Ihren Bot-Konten das Label „Automated Account“ hinzufügen, damit Nutzer auf X wissen, dass es sich bei Ihrem Bot um ein automatisiertes Konto handelt. Diese Bots führen programmierte Aktionen über die X API aus. Wenn Sie Ihrem Bot das Label „Automated Account“ hinzufügen, stärken Sie das Vertrauen Ihres Publikums, legitimieren Ihr Konto und grenzen sich von Spam-Bots ab. So verstehen Menschen auf X den Zweck Ihres Kontos bei der Interaktion mit Ihrem Bot besser.

Gehen Sie wie folgt vor, um Ihrem Bot-Konto ein Label hinzuzufügen:

1. Gehen Sie zu Ihren Kontoeinstellungen
2. Wählen Sie „Your account“
3. Wählen Sie „Automation“
4. Wählen Sie „Managing account“
5. Wählen Sie anschließend das X Konto aus, das Ihr Bot-Konto betreibt
6. Geben Sie Ihr Passwort ein, um sich anzumelden
7. Abschließend sollten Sie eine Bestätigung sehen, dass das Label auf Ihr Konto angewendet wurde.

---

​

Verwaltung von Apps

​

Einführung

Das X App-Dashboard ermöglicht es Entwicklerinnen und Entwicklern, die folgenden Aufgaben schnell und einfach durchzuführen:

• Anzeigen Ihrer vorhandenen Apps und Projects sowie der zugehörigen App-id.
• Erstellen eines neuen Projects oder einer eigenständigen App.
• Löschen eines Projects, einer App oder einer eigenständigen App.
• Öffnen der Einstellungen einer bestimmten App durch Klicken auf die App. In den Einstellungen können Sie die App-Details, Keys und Tokens sowie Berechtigungen einsehen.
• Aktualisieren der Benutzerauthentifizierungseinstellungen Ihrer App zur Verwendung von OAuth 1.0a oder OAuth 2.0.

Hinweis:

Alle App-Keys und Tokens sind im Entwicklerportal nicht mehr einsehbar und müssen nach der Generierung sicher gespeichert werden. Wir empfehlen die Verwendung eines Passwortmanagers zur Aufbewahrung Ihrer Keys und Tokens.

Sie können einen API Key‑Hinweis einblenden, um Ihre Zugangsdaten der entsprechenden App zuzuordnen.

​

App-Einstellungen

​

App-Details

Hier können Sie das App-Icon, den App-Namen, die App-Beschreibung, Ihre Website-URL, Callback-URLs/Redirect-URIs, die URL der Nutzungsbedingungen, die URL der Datenschutzrichtlinie, den Namen der Organisation, die URL der Organisation sowie den Zweck bzw. Anwendungsfall der App bearbeiten.

OAuth 2.0 und OAuth 1.0a sind Authentifizierungsmethoden, mit denen sich Nutzer bei Ihrer App mit X anmelden können. Sie ermöglichen Ihrer App außerdem, bestimmte Anfragen im Namen authentifizierter Nutzer zu stellen. Sie können eine oder beide Methoden für Ihre App aktivieren.

Es ist wichtig, diese Informationen aktuell zu halten. Ihr App-Name und Ihre Website-URL werden als Quelle innerhalb der metadata für alle Tweets angezeigt, die von Ihrer Anwendung programmgesteuert erstellt werden. Wenn Sie den Anwendungsfall einer X App ändern, aktualisieren Sie ihn in diesen Einstellungen, um sicherzustellen, dass Sie die Developer Terms einhalten.

Wenn Ihre Anwendung mit einem Tag „suspended“ gekennzeichnet ist, liegt dies daran, dass Ihre App gegen eine oder mehrere der developer terms von X verstößt, beispielsweise gegen unsere automation rules. Das Richtlinienteam der Developer Platform kommuniziert mit Entwicklern über die E-Mail-Adresse, die im X-Konto des App-Inhabers hinterlegt ist. Um diese E-Mail-Adresse zu überprüfen, sehen Sie bitte in Ihren X-Kontoeinstellungen nach. Benachrichtigungs-E-Mails zu Sperrungen werden an diese E-Mail-Adresse mit einem title ähnlich „Application suspension notice“ gesendet und enthalten konkrete Informationen zu den nächsten Schritten. Um mit dem X-Team an der Behebung von Sperren zu arbeiten, prüfen Sie bitte Ihre E-Mails auf konkrete Anweisungen oder verwenden Sie unser Platform Help Form.

​

Keys und Tokens

Innerhalb einer App in einem Project oder über eine eigenständige App können Sie die folgenden Tokens anzeigen, neu generieren oder widerrufen:

• API Key (Consumer Key) und API Secret (Consumer Secret)
• App Access Token
• User Access Token und Access Token Secret - Das im Entwicklerportal verfügbare Access Token und Secret beziehen sich auf den Nutzer, dem die App gehört.

Bitte beachten – Wenn Sie Anfragen im Namen eines anderen Nutzers stellen möchten (also nicht des Nutzers, dem die App gehört), müssen Sie entweder den OAuth 1.0a 3-legged OAuth-Flow oder den OAuth 2.0 Authorization Code with PKCE Flow verwenden, um einen Satz nutzerspezifischer Access Tokens zu generieren. Diese nutzerspezifischen Tokens verwenden Sie dann in Ihrer Anfrage an die API.

​

Einstellungen zur Benutzer-Authentifizierung

Sie können die Authentifizierungseinstellungen Ihrer App auf OAuth 1.0a oder OAuth 2.0 festlegen. OAuth 2.0 kann nur mit der X API v2 verwendet werden. Mit OAuth 2.0 können Sie fein granulare Scopes auswählen, die Ihnen im Namen eines Nutzers bestimmte Berechtigungen erteilen. OAuth 1.0a kann mit der X API v1.1 und v2 verwendet werden und nutzt eine breitere Autorisierung mit groben Scopes.

​

OAuth 1.0a-Berechtigungen für App und Nutzer

Wenn Sie der App-Inhaber sind, können Sie die Berechtigungen der App anpassen (nur Lesen; Lesen und Schreiben; oder Lesen, Schreiben und Direct Messages). Dies steuert, auf welche Ressourcen und Ereignisse Sie über die X API Zugriff haben (Hinweis: Einige Ressourcen erfordern zusätzliche Berechtigungen direkt von X).

Sie können auf dieser Seite außerdem die Möglichkeit Ihrer Apps, E-Mail-Adressen von Nutzern anzufordern, ein- und ausschalten (hierfür müssen auf der Seite „App details“ eine URL zu den Nutzungsbedingungen und eine URL zur Datenschutzerklärung hinterlegt sein).

​

OAuth 2.0-Typ der App

Wenn Sie OAuth 2.0 als Benutzerauthentifizierungsmethode wählen, müssen Sie den Typ der App festlegen, die Sie erstellen. Zur Auswahl stehen Native App, Single Page App, Web App, Automated App oder Bot. Native App und Single Page Apps sind Public Clients, während Web App sowie Automated App oder Bots Confidential Clients sind.

Confidential Clients authentifizieren sich sicher beim Autorisierungsserver. Sie schützen Ihr Client Secret. Public Clients sind Anwendungen, die üblicherweise in einem Browser oder auf einem mobilen Gerät ausgeführt werden und keine Client Secrets verwenden können. Wenn Sie einen App-Typ wählen, der ein Confidential Client ist, erhalten Sie ein Client Secret.

---

​

App-Berechtigungen

​

OAuth 1.0a App-Berechtigungen

App-Berechtigungen beschreiben die Zugriffsebene für die OAuth 1.0a-Authentifizierung im Kontext Anwendung–Nutzer. App-Berechtigungen werden pro Anwendung in den Einstellungen Ihrer X App konfiguriert.

Es gibt drei Berechtigungsebenen:

1. Nur Lesen
2. Lesen und Schreiben
3. Lesen, Schreiben und Zugriff auf Direct Messages

Zusätzlich gibt es eine Berechtigung, mit der die Sichtbarkeit der E-Mail-Adresse eines Nutzers angefordert werden kann – diese lässt sich mit jeder der drei oben genannten Ebenen kombinieren.

Wenn eine Berechtigungsebene geändert wird, müssen alle bereits für diese X App ausgegebenen Nutzertokens verworfen werden, und die Nutzer müssen die App erneut autorisieren, damit das Token die aktualisierten Berechtigungen übernimmt.

Als Best Practice gilt, nur das minimale Maß an Zugriff auf die Kontodaten eines Nutzers anzufordern, das eine Anwendung oder ein Dienst benötigt.

​

Nur Lesezugriff

Diese Berechtigungsstufe erlaubt das Lesen von X‑Ressourcen, darunter (zum Beispiel) die Tweets eines Nutzers, die Startseiten-Timeline und Profilinformationen. Sie erlaubt keinen Zugriff auf die Direct Messages eines Nutzers und ermöglicht keine Aktualisierung von Elementen oder Objekten.

​

Lesen und Schreiben

Diese Berechtigungsstufe gewährt Lese- und Schreibzugriff auf X-Ressourcen. Zusätzlich zum Lesezugriff erlaubt sie das Posten von Tweets, das Folgen von Nutzern und das Aktualisieren von Elementen der Profilinformationen eines Nutzers. Außerdem können damit im Namen des authentifizierten Nutzers Antworten verborgen werden. Diese Berechtigungsstufe erlaubt keinen Zugriff auf Direct Messages (einschließlich Lesen, Schreiben oder DELETE).

​

Lesen, Schreiben und Zugriff auf Direct Messages

Diese Berechtigungsstufe umfasst den Zugriff auf alle oben genannten Punkte und erweitert diesen um die Möglichkeit, Direct Messages im Namen eines Nutzers zu lesen, zu schreiben und zu löschen.

• POST /2/dm_conversations/:dm_conversation_id/messages
• POST /2/dm_conversations/
• POST /2/dm_conversations/with/:participant_id/messages
• GET /2/dm_conversations/with/:user_id/dm_events
• GET /2/dm_conversations/:dm_conversation_id/dm_events
• GET /2/dm_events

​

Berechtigungen ermitteln

Alle authentifizierten API-Anfragen enthalten in der HTTP-Antwort einen x-access-level-Header. Der Wert dieses Headers gibt die aktuell verwendete Berechtigungsstufe an. Mögliche Werte sind read, read-write und read-write-directmessages.

---

​

Callback-URLs

Die Authentifizierungsmethoden OAuth 1.0a User Context und OAuth 2.0 Authorization Code mit PKCE ermöglichen es Entwicklern, im Namen verschiedener X-Nutzer, die einen bestimmten Anmelde-Flow durchlaufen haben, Anfragen zu stellen. Derzeit gibt es zwei Flows, mit denen Sie Nutzern die Autorisierung Ihrer Anwendung ermöglichen können:

• OAuth 2.0 Authorization Code mit PKCE
• OAuth 1.0a 3-legged OAuth-Flow (und separat der Sign in with X-Flow)

Während Nutzer diese Flows durchlaufen, benötigen sie eine Webseite bzw. einen Zielort, zu dem sie nach erfolgreicher Anmeldung und Autorisierung für die App des Entwicklers weitergeleitet werden. Diese Seite bzw. dieser Ort wird als Callback-URL bezeichnet.

Beim Einrichten dieser Flows müssen Entwickler eine Callback-URL in ihren Anfragen an die Authentifizierungs-endpoints übergeben, aus denen die oben genannten Flows bestehen. Beispielsweise müssen Entwickler, die OAuth 1.0a User Context verwenden, den Parameter callback_url übergeben, wenn sie eine Anfrage an den endpoint GET oauth/request_token stellen. Ebenso müssen Entwickler, die OAuth 2.0 Authorization Code mit PKCE verwenden, den Parameter redirect_uri mit ihrer Anfrage an den endpoint GET oauth2/authorize übergeben.

Zusätzlich zur Verwendung dieser Parameter muss der Entwickler sicherstellen, dass die Callback-URL auch der Allowlist der App für Callback-URLs hinzugefügt wurde, die auf der Einstellungsseite der App im Entwicklerportal zu finden ist.

Wenn alles korrekt eingerichtet ist, werden Nutzer nach erfolgreicher Anmeldung bei X im Rahmen dieser Flows zur Callback-URL weitergeleitet.

​

Wichtige Hinweise

Beim Einrichten Ihrer Callback-URLs sollten Sie Folgendes beachten:

Query-Parameter HTTP-codieren

Da Sie die Callback-URL als Query-Parameter über die Parameter callback_url oder redirect_uri übergeben, stellen Sie bitte sicher, dass die URL HTTP-codiert ist.

Grenzen für Callback-URLs

Im X Apps-Dashboard gibt es eine feste Obergrenze von 10 Callback-URLs. Ihre Callback-URL muss exakt mit der auf die Allowlist gesetzten Callback-URL übereinstimmen, die Sie dem Apps-Dashboard hinzufügen, sowie mit dem Parameter, den Sie im Autorisierungsfluss übergeben.

Wenn Sie anfragebezogene Daten in der Callback-URL übermitteln möchten, können Sie den Parameter state verwenden, um Daten zu speichern, die nach der Weiterleitung des Nutzers verfügbar sind. Sie können die Daten entweder direkt im Parameter state kodieren oder den Parameter als Sitzungs-ID nutzen, um den Zustand auf dem Server zu speichern.

Verwenden Sie localhost nicht als Callback-URL Verwenden Sie lokal statt localhost einen benutzerdefinierten Host oder http(s)://127.0.0.1

Benutzerdefinierte Protokoll-URLs Wenn Sie Mobile Deep Linking nutzen möchten, können Sie benutzerdefinierte Protokoll-URLs mit Pfad- und Domain-Teil verwenden, z. B. twitter://callback/path. Es gibt jedoch eine Liste nicht zulässiger Protokolle, die Sie vermeiden müssen. Die Liste der nicht zulässigen Protokolle finden Sie unten.

Nicht zulässige Protokolle

vbscript	ldap
javascript	mailto
vbs	mmst
data	mmsu
mocha	msbd
keyword	rtsp
livescript	mso-offdap
ftp	snews
file	news
gopher	nntp
acrobat	outlook
callto	stssync
daap	rlogin
itpc	telnet
itms	tn3270
firefoxurl	shell
hcp	sip

​

Fehlerbeispiel

Wenn Sie eine Callback-URL verwenden, die nicht ordnungsgemäß in den Einstellungen Ihrer App im Entwicklerportal hinterlegt wurde, erhalten Sie die folgende Fehlermeldung:

OAuth 1.0a

HTTP 403 - Forbidden

{
  "errors": [
    {
      "code":415,"message":"Callback-URL für diese Client-App nicht genehmigt. Genehmigte Callback-URLs können in Ihren App-Einstellungen angepasst werden."
    }
  ]
}

ODER

<?xml version="1.0" encoding="UTF-8"?>
<hash>
<error>Callback-URL für diese Client-Anwendung nicht genehmigt. Genehmigte Callback-URLs können in Ihren Anwendungseinstellungen angepasst werden</error>
<request>/oauth/request_token</request>
</hash>

OAuth 2.0

HTTP 400

{
  "error": "invalid_request",
  "error_description": "Der für die Weiterleitungs-URI übergebene Wert stimmte nicht mit der URI des Autorisierungscodes überein."
}

Fehlerbehebung

Wenn ein Fehler auftritt, stellen Sie bitte sicher, dass die in Ihren Authentifizierungsanforderungen verwendete Callback-URL URL-codiert (percent-encoded) ist und mit einer Callback-URL übereinstimmt, die der Allowlist der App hinzugefügt wurde, deren Keys und Tokens Sie in Ihrer Anfrage verwenden.

---