Search API: Enterprise

Bitte beachten: Wir haben eine neue Version von Posts durchsuchen und Post-Zählungen in der X API v2 veröffentlicht. Wir empfehlen Ihnen, sich die Neuerungen in X API v2 anzusehen. Diese Endpoints wurden aktualisiert und enthalten nun Bearbeitungs-Metadaten für Posts. Weitere Informationen zu diesen Metadaten finden Sie auf der Grundlagen-Seite zu „Posts bearbeiten“.

Überblick

Enterprise Die Enterprise-APIs sind ausschließlich innerhalb unserer verwalteten Zugangsstufen verfügbar. Um diese APIs zu nutzen, müssen Sie zunächst ein Konto über unser Enterprise-Vertriebsteam einrichten. Weitere Informationen finden Sie HIER. Sie können alle X API-Suchangebote für Posts HIER einsehen. Es gibt zwei Enterprise-Such-APIs:

Die 30-Day Search API stellt Daten aus den letzten 30 Tagen bereit.
Die Full-Archive Search API bietet vollständigen und sofortigen Zugriff auf den gesamten Korpus der X-Daten bis zurück zum ersten Post im März 2006.

Diese RESTful APIs unterstützen pro Anfrage eine einzelne query mit bis zu 2.048 Zeichen. Abfragen werden mit der PowerTrack-Regelsyntax verfasst – siehe Regeln und Filterung für weitere Details. Nutzer können einen beliebigen Zeitraum bis hinunter zur Auflösung einer Minute angeben. Antworten sind jedoch auf den kleineren Wert aus Ihrem angegebenen maxResults ODER 31 Tagen begrenzt und enthalten ein next_token zur Paginierung des nächsten Ergebnissatzes. Wenn keine Zeitparameter angegeben sind, gibt die API passende data aus den 30 jüngsten Tagen zurück. Die Enterprise-Such-APIs bieten latenzarmen, verlustfreien, abfragebasierten Zugriff auf das Post-Archiv mit Minutengenauigkeit. Post-Daten werden in umgekehrt chronologischer Reihenfolge bereitgestellt, beginnend mit dem neuesten Post, der Ihrer Abfrage entspricht. Posts sind etwa 30 Sekunden nach der Veröffentlichung über die Search API verfügbar. Diese Such-endpoints liefern bearbeitete Post metadata. Alle Objekte für Posts, die seit dem 29. September 2022 erstellt wurden, enthalten Metadaten zur Post-Bearbeitung, auch wenn der Post nie bearbeitet wurde. Jedes Mal, wenn ein Post bearbeitet wird, wird eine neue Post-ID erstellt. Der Bearbeitungsverlauf eines Posts wird durch ein Array von Post-IDs dokumentiert, beginnend mit der ursprünglichen ID. Diese endpoints geben immer die jüngste Bearbeitung zusammen mit dem gesamten Bearbeitungsverlauf zurück. Jeder Post, der nach seinem 30-minütigen Bearbeitungsfenster erfasst wird, entspricht seiner endgültigen Version. Um mehr über Edit-Post-Metadaten zu erfahren, siehe die Seite Grundlagen zu Edit Posts. Anfragen enthalten einen maxResults-Parameter, der die maximale Anzahl von Posts angibt, die pro API-Antwort zurückgegeben werden. Wenn mehr Posts mit der query verknüpft sind als diese maximale Anzahl an Ergebnissen pro Antwort, ist in der Antwort ein next_token enthalten. Diese next_tokens werden in nachfolgenden Anfragen verwendet, um durch den gesamten Satz von Posts zu blättern, die mit der query verknüpft sind. Diese Enterprise-Such-APIs bieten ein counts-endpoint, das es Nutzern ermöglicht, das mit ihrer query verbundene Datenvolumen anzufordern.

Anfragetypen

Die Enterprise-Such-APIs unterstützen zwei Arten von Anfragen:

Suchanfragen (data)

Suchanfragen an die Enterprise-Such-APIs ermöglichen es Ihnen, für einen bestimmten Zeitraum bis zu 500 Ergebnisse pro Antwort abzurufen, mit der Möglichkeit, für zusätzliche data zu paginieren. Mit dem Parameter maxResults können Sie kleinere Seitengrößen für Anzeige-Use-Cases festlegen (sodass Ihre Nutzer bei Bedarf mehr Ergebnisse anfordern können) oder größere Seitengrößen (bis zu 500) für umfangreichere Datenabrufe. Die data wird in umgekehrt chronologischer Reihenfolge geliefert und ist zum Zeitpunkt der Zustellung konform.

Counts-Anfragen (Post-Zählung)

Counts-Anfragen ermöglichen das Abrufen historischer Aktivitätszahlen, die die Anzahl der Aktivitäten widerspiegeln, die innerhalb des angeforderten Zeitraums aufgetreten sind und einer bestimmten Abfrage entsprechen. Die Antwort liefert im Wesentlichen ein Histogramm der Zählwerte, gruppiert nach Tag, Stunde oder Minute (der Standard-Bucket ist Stunde). Es ist wichtig zu beachten, dass Counts-Ergebnisse nicht immer Compliance-Ereignisse widerspiegeln (z. B. Post-Löschungen), die lange nach der Veröffentlichung eines Posts (7+ Tage) stattfinden; daher ist zu erwarten, dass die Counts-Metrik nicht immer mit der einer data-Anfrage für dieselbe Abfrage übereinstimmt. Hinweis zur Abrechnung: Jede Anfrage – einschließlich Paginierungsanfragen – an die data- und Counts-endpoints wird als abrechnungsrelevante Anfrage gezählt. Wenn es mehrere Ergebnisseiten für eine einzelne Abfrage gibt, entspricht das Durchblättern der X Ergebnisseiten X Anfragen für die Abrechnung.

Verfügbare Operatoren

Enterprise-Such-APIs unterstützen Regeln mit bis zu 2.048 Zeichen. Die Enterprise-Such-APIs unterstützen die unten aufgeführten Operatoren. Ausführliche Beschreibungen finden Sie HIER.


Abgleich von Post-Inhalten:	Abgleich von Accounts von Interesse:	Post-Attribute:	Geodaten-Operatoren:
* keyword * “quoted phrase” * “keyword1 keyword2”~N * # * @ * $ * url: * lang:	* from: * to: * retweets_of:	* is:retweet * has:mentions * has:hashtags * has:media * has:videos * has:images * has:links * has:symbols * is:verified * -is:nullcast (nur Negation)	* bounding_box:[west_long south_lat east_long north_lat] * point_radius:[lon lat radius] * has:geo * place: * place_country: * has:profile_geo * profile_country: * profile_region: * profile_locality:

Hinweise: Operatoren nicht einbetten/verschachteln („#cats“) wird bei den Such-APIs zu cats aufgelöst. Der Operator „lang:“ sowie alle Operatoren „is:“ und „has:“ können nicht alleinstehend verwendet werden und müssen mit einer weiteren Klausel kombiniert werden (z. B. @XDevelopers has:links). Such-APIs verwenden aufgrund der Tokenisierungs- und Matching-Funktionalität nur einen begrenzten Satz von Operatoren. Enterprise-Echtzeit- und batchweise historische APIs bieten zusätzliche Operatoren. Weitere Details finden Sie HIER. Weitere Details finden Sie im Leitfaden Erste Schritte mit Operatoren.

Datenverfügbarkeit / wichtige Daten

Bei der Verwendung der Full-Archive Search API ist zu beachten, dass sich die X Plattform seit 2006 weiterentwickelt hat. Mit der Einführung neuer Funktionen wurden den zugrunde liegenden JSON-Objekten neue metadata hinzugefügt. Aus diesem Grund ist es wichtig zu verstehen, wann Post-Attribute hinzugefügt wurden, auf die Suchoperatoren matchen. Nachfolgend sind einige der grundlegenden „Geburtsdaten“ wichtiger metadata-Gruppen aufgeführt. Weitere Informationen darüber, wann Post-Attribute erstmals eingeführt wurden, finden Sie in diesem Leitfaden.

Erster Post: 21.03.2006
Erste nativen Retweets: 06.11.2009
Erster geogetaggter Post: 19.11.2009
URLs erstmals zum Filtern indexiert: 27.08.2011
Erweiterte URL-Expansions-metadata (Website-Titel und -Beschreibungen): 01.12.2014
Profil-Geo-Enrichment-metadata und Filterung: 17.02.2015

Datenaktualisierungen und Änderbarkeit

Bei den Enterprise-Such-APIs sind einige Daten innerhalb eines Posts änderbar, d. h. sie können nach der ersten Archivierung aktualisiert oder verändert werden. Diese änderbaren Daten fallen in zwei Kategorien:

Metadaten des User-Objekts:
- @Handle des Users (die numerische id ändert sich nie)
- Bio-Beschreibung
- Zählwerte: statuses, followers, friends, favorites, lists
- Profilort
- Weitere Details wie Zeitzone und Sprache
Post-Statistiken – d. h. alles, was durch Nutzeraktionen auf der Plattform geändert werden kann (Beispiele unten):
- Anzahl der Favorites
- Anzahl der Retweets

In den meisten dieser Fälle geben die Such-APIs die Daten so zurück, wie sie zum Zeitpunkt der Abfrage (query-time) auf der Plattform vorliegen, nicht zum Zeitpunkt der Post-Erstellung. Bei Abfragen mit bestimmten Operatoren (z. B. from, to, @, is:verified) kann dies jedoch abweichen. Die Daten in unserem Index werden regelmäßig aktualisiert, mit erhöhter Frequenz für jüngste Zeiträume. Daher kann es in manchen Fällen vorkommen, dass die zurückgegebenen Daten nicht exakt den aktuell auf X.com angezeigten Daten entsprechen, sondern den Daten zum Zeitpunkt der letzten Indexierung. Beachten Sie, dass diese Inkonsistenz nur bei Abfragen auftritt, bei denen der Operator auf änderbare Daten angewendet wird. Ein Beispiel ist das Filtern nach Usernames; die beste Lösung besteht darin, für solche Abfragen numerische User-IDs statt @Handles zu verwenden.

Single- vs. Multithreaded-Anfragen

Jeder Kunde hat ein definiertes Rate Limit für seinen Such-endpoint. Das standardmäßige Rate Limit pro Minute für die Vollarchivsuche beträgt 120 Anfragen pro Minute, was durchschnittlich 2 Abfragen pro Sekunde (QPS) entspricht. Dieser durchschnittliche QPS bedeutet, dass theoretisch jede Sekunde 2 Anfragen an die API gestellt werden können. Angesichts der Paginierungsfunktion des Produkts würden, wenn eine einjährige Abfrage eine Million Posts zugeordnet hat, gleichmäßig über das Jahr verteilt, über 2.000 Anfragen benötigt (bei einem angenommenen „maxResults“ von 500), um alle data zu erhalten. Angenommen, es dauert zwei Sekunden pro Antwort, sind das 4.000 Sekunden (oder etwas mehr als eine Stunde), um all diese data seriell/sequenziell über einen einzelnen Thread abzurufen (1 Anfrage pro Sekunde mithilfe des „next“-Tokens der vorherigen Antwort). Nicht schlecht! Betrachten Sie nun die Situation, in der zwölf parallele Threads verwendet werden, um data zu empfangen. Bei einer gleichmäßigen Verteilung der einen Million Posts über den einjährigen Zeitraum könnten Sie die Anfragen in zwölf parallele Threads (multithreaded) aufteilen und mehr von dem pro Sekunde verfügbaren Rate Limit für den einzelnen „Job“ nutzen. Mit anderen Worten: Sie könnten einen Thread pro Monat ausführen, für den Sie sich interessieren, und dadurch könnten data 12x so schnell abgerufen werden (also ~6 Minuten). Dieses multithreaded Beispiel gilt gleichermaßen für den counts endpoint. Wenn Sie beispielsweise Post-Zählungen für einen Zeitraum von zwei Jahren erhalten möchten, könnten Sie eine Single-Thread-Anfrage stellen und die Zählungen seitenweise in Schritten von 31 Tagen zurückblättern. Angenommen, es dauert 2 Sekunden pro Antwort, würde es ungefähr 48 Sekunden dauern, die 24 API-Anfragen zu stellen und den gesamten Satz an Zählungen abzurufen. Sie haben jedoch auch die Möglichkeit, mehrere Ein-Monats-Anfragen gleichzeitig zu stellen. Wenn Sie 12 Anfragen pro Sekunde stellen, könnte der gesamte Satz an Zählungen in etwa 2 Sekunden abgerufen werden.

Wiederholungslogik

Wenn bei den Enterprise-Such-APIs ein 503-Fehler auftritt, handelt es sich wahrscheinlich um einen vorübergehenden Fehler, der sich durch einen erneuten Versuch der Anfrage nach kurzer Zeit beheben lässt. Wenn die Anfrage viermal in Folge fehlschlägt und Sie zwischen den Fehlschlägen jeweils mindestens 10 Minuten gewartet haben, führen Sie die folgenden Schritte zur Fehlerbehebung aus:

Versuchen Sie die Anfrage erneut, nachdem Sie den betrachteten Zeitraum verkleinert haben. Wiederholen Sie dies bei Bedarf bis hinunter zu einem Zeitfenster von 6 Stunden.
Wenn Sie eine große Anzahl von Begriffen mit OR verknüpfen, teilen Sie sie in separate Regeln auf und führen Sie jede einzeln erneut aus.
Wenn Sie in Ihrer Regel viele Ausschlüsse verwenden, reduzieren Sie die Anzahl der negierten Begriffe in der Regel und versuchen Sie es erneut.

Schnellstart

Erste Schritte mit Enterprise Search Posts: 30-Day API

Die Enterprise Search Posts: 30-Day API stellt Ihnen Posts bereit, die in den letzten 30 Tagen veröffentlicht wurden. Posts werden basierend auf der query, die Sie in Ihrer Anfrage angeben, abgeglichen und an Sie zurückgesendet. Eine Abfrage ist eine Regel, in der Sie definieren, was der Post, den Sie zurückerhalten, enthalten soll. In diesem Tutorial suchen wir nach Posts in englischer Sprache, die vom X-Konto @XDevelopers stammen. Die Posts, die Sie in Ihrem Payload zurückerhalten, können im data-Format vorliegen, das Ihnen den vollständigen Post-Payload liefert, oder im counts-Format, das Ihnen numerische Zähldaten zu abgeglichenen Posts liefert. Wir verwenden cURL, um Anfragen an die data- und counts-endpoints zu stellen. Sie benötigen Folgendes:

Ein Enterprise-Konto: https://developer.x.com/en/products/x-api/enterprise
Ihren Benutzernamen, Ihr Passwort und den Kontonamen
Das dem Such-endpoint zugeordnete Label, wie auf console.gnip.com angezeigt

Zugriff auf das data-endpoint

Das data-endpoint stellt uns den vollständigen Post-Payload der passenden Posts bereit. Wir verwenden die Operatoren from: und lang:, um Posts zu finden, die von @XDevelopers auf Englisch stammen. Für weitere Operatoren klicken Sie hier.

cURL
cURL example

cURL ist ein Kommandozeilenwerkzeug zum Abrufen oder Senden von Dateien mithilfe der URL-Syntax.Kopieren Sie die folgende cURL-Anfrage in Ihre Kommandozeile, nachdem Sie Folgendes angepasst haben:

Benutzername <USERNAME> z. B. email@domain.com
Kontoname <ACCOUNT-NAME> z. B. john-doe
Label <LABEL> z. B. prod
fromDate und toDate z. B. "fromDate":"201811010000", "toDate":"201811122359"

Nach dem Senden Ihrer Anfrage werden Sie zur Eingabe Ihres Passworts aufgefordert.

curl -X POST -u<USERNAME> "https://gnip-api.x.com/search/30day/accounts/<ACCOUNT-NAME>/<LABEL>.json" -d '{"query":"from:TwitterDev lang:en","maxResults":"500","fromDate":"<yyyymmddhhmm>","toDate":"<yyyymmddhhmm>"}'

Antwort-Payload des data-endpoints

Die Payload, die Sie auf Ihre API-Anfrage zurückerhalten, wird im JSON-Format ausgegeben, wie unten gezeigt.

{
	"results": [
		{
			"created_at": "Fri Nov 02 17:18:31 +0000 2018",
			"id": 1058408022936977409,
			"id_str": "1058408022936977409",
			"text": "RT @harmophone: „Das innovative Crowdsourcing, das die Zusammenarbeit von Tagboard, Twitter und TEGNA ermöglicht, bringt lokal relevante Konv…",
			"source": "<a href=\"http:\/\/twitter.com\" rel=\"nofollow\">Twitter Web Client<\/a>",
			"truncated": false,
			"in_reply_to_status_id": null,
			"in_reply_to_status_id_str": null,
			"in_reply_to_user_id": null,
			"in_reply_to_user_id_str": null,
			"in_reply_to_screen_name": null,
			"user": {
				"id": 2244994945,
				"id_str": "2244994945",
				"name": "Twitter Dev",
				"screen_name": "TwitterDev",
				"location": "Internet",
				"url": "https:\/\/developer.x.com\/",
				"description": "Ihre offizielle Quelle für Twitter Platform-Neuigkeiten, Updates und Events. Benötigen Sie technische Hilfe? Besuchen Sie https:\/\/devcommunity.com\/ ⌨️ #TapIntoTwitter",
				"translator_type": "null",
				"protected": false,
				"verified": true,
				"followers_count": 503828,
				"friends_count": 1477,
				"listed_count": 1437,
				"favourites_count": 2199,
				"statuses_count": 3380,
				"created_at": "Sat Dec 14 04:35:55 +0000 2013",
				"utc_offset": null,
				"time_zone": null,
				"geo_enabled": true,
				"lang": "en",
				"contributors_enabled": false,
				"is_translator": false,
				"profile_background_color": "null",
				"profile_background_image_url": "null",
				"profile_background_image_url_https": "null",
				"profile_background_tile": null,
				"profile_link_color": "null",
				"profile_sidebar_border_color": "null",
				"profile_sidebar_fill_color": "null",
				"profile_text_color": "null",
				"profile_use_background_image": null,
				"profile_image_url": "null",
				"profile_image_url_https": "https:\/\/pbs.twimg.com\/profile_images\/880136122604507136\/xHrnqf1T_normal.jpg",
				"profile_banner_url": "https:\/\/pbs.twimg.com\/profile_banners\/2244994945\/1498675817",
				"default_profile": false,
				"default_profile_image": false,
				"following": null,
				"follow_request_sent": null,
				"notifications": null
			},
			"geo": null,
			"coordinates": null,
			"place": null,
			"contributors": null,
			"retweeted_status": {
				"created_at": "Tue Oct 30 21:30:25 +0000 2018",
				"id": 1057384253116289025,
				"id_str": "1057384253116289025",
				"text": "„Das innovative Crowdsourcing, das die Zusammenarbeit von Tagboard, Twitter und TEGNA ermöglicht, bringt lokal relevante… https:\/\/t.co\/w46U5TRTzQ",
				"source": "<a href=\"http:\/\/twitter.com\" rel=\"nofollow\">Twitter Web Client<\/a>",
				"truncated": true,
				"in_reply_to_status_id": null,
				"in_reply_to_status_id_str": null,
				"in_reply_to_user_id": null,
				"in_reply_to_user_id_str": null,
				"in_reply_to_screen_name": null,
				"user": {
					"id": 175187944,
					"id_str": "175187944",
					"name": "Tyler Singletary",
					"screen_name": "harmophone",
					"location": "San Francisco, CA",
					"url": "http:\/\/medium.com\/@harmophone",
					"description": "SVP Product bei @Tagboard. War in den Bereichen Data, Business und Product bei @Klout & für @LithiumTech tätig; @BBI Vorstandsmitglied; @Insightpool Berater. Schlechtester Whiteboard-Nutzer der Welt.",
					"translator_type": "null",
					"protected": false,
					"verified": false,
					"followers_count": 1982,
					"friends_count": 1877,
					"listed_count": 245,
					"favourites_count": 23743,
					"statuses_count": 12708,
					"created_at": "Thu Aug 05 22:59:29 +0000 2010",
					"utc_offset": null,
					"time_zone": null,
					"geo_enabled": false,
					"lang": "en",
					"contributors_enabled": false,
					"is_translator": false,
					"profile_background_color": "null",
					"profile_background_image_url": "null",
					"profile_background_image_url_https": "null",
					"profile_background_tile": null,
					"profile_link_color": "null",
					"profile_sidebar_border_color": "null",
					"profile_sidebar_fill_color": "null",
					"profile_text_color": "null",
					"profile_use_background_image": null,
					"profile_image_url": "null",
					"profile_image_url_https": "https:\/\/pbs.twimg.com\/profile_images\/719985428632240128\/WYFHcK-m_normal.jpg",
					"profile_banner_url": "https:\/\/pbs.twimg.com\/profile_banners\/175187944\/1398653841",
					"default_profile": false,
					"default_profile_image": false,
					"following": null,
					"follow_request_sent": null,
					"notifications": null
				},
				"geo": null,
				"coordinates": null,
				"place": null,
				"contributors": null,
				"is_quote_status": false,
				"extended_tweet": {
					"full_text": "„Das innovative Crowdsourcing, das die Zusammenarbeit von Tagboard, Twitter und TEGNA ermöglicht, bringt lokal relevante Gespräche in Echtzeit an die Oberfläche und ermöglicht es Wählern, während Debatten Fragen zu stellen,"  -- @adamostrow, @TEGNA\nMehr erfahren: https:\/\/t.co\/ivAFtanfje",
					"display_text_range": [
						0,
						259
					],
					"entities": {
						"hashtags": [],
						"urls": [
							{
								"url": "https:\/\/t.co\/ivAFtanfje",
								"expanded_url": "https:\/\/blog.tagboard.com\/twitter-and-tagboard-collaborate-to-bring-best-election-content-to-news-outlets-with-tagboard-e85fc864bcf4",
								"display_url": "blog.tagboard.com\/twitter-and-ta…",
								"unwound": {
									"url": "https:\/\/blog.tagboard.com\/twitter-and-tagboard-collaborate-to-bring-best-election-content-to-news-outlets-with-tagboard-e85fc864bcf4",
									"status": 200,
									"title": "Twitter und Tagboard arbeiten zusammen, um beste Wahlinhalte über Tagboard an Nachrichtenredaktionen zu bringen…",
									"description": "Von Tyler Singletary, Head of Product, Tagboard"
								},
								"indices": [
									236,
									259
								]
							}
						],
						"user_mentions": [
							{
								"screen_name": "adamostrow",
								"name": "Adam Ostrow",
								"id": 5695942,
								"id_str": "5695942",
								"indices": [
									204,
									215
								]
							},
							{
								"screen_name": "TEGNA",
								"name": "TEGNA",
								"id": 34123003,
								"id_str": "34123003",
								"indices": [
									217,
									223
								]
							}
						],
						"symbols": []
					}
				},
				"quote_count": 0,
				"reply_count": 1,
				"retweet_count": 6,
				"favorite_count": 19,
				"entities": {
					"hashtags": [],
					"urls": [
						{
							"url": "https:\/\/t.co\/w46U5TRTzQ",
							"expanded_url": "https:\/\/twitter.com\/i\/web\/status\/1057384253116289025",
							"display_url": "twitter.com\/i\/web\/status\/1…",
							"indices": [
								117,
								140
							]
						}
					],
					"user_mentions": [],
					"symbols": []
				},
				"favorited": false,
				"retweeted": false,
				"possibly_sensitive": false,
				"filter_level": "low",
				"lang": "en"
			},
			"is_quote_status": false,
			"quote_count": 0,
			"reply_count": 0,
			"retweet_count": 0,
			"favorite_count": 0,
			"entities": {
				"hashtags": [],
				"urls": [],
				"user_mentions": [
					{
						"screen_name": "harmophone",
						"name": "Tyler Singletary",
						"id": 175187944,
						"id_str": "175187944",
						"indices": [
							3,
							14
						]
					}
				],
				"symbols": []
			},
			"favorited": false,
			"retweeted": false,
			"filter_level": "low",
			"lang": "en",
			"matching_rules": [
				{
					"tag": null
				}
			]
		}
	],
	"requestParameters": {
		"maxResults": 100,
		"fromDate": "201811010000",
		"toDate": "201811060000"
	}
}

Zugriff auf das Counts-endpoint

Mit dem Counts-endpoint rufen wir die Anzahl der Posts vom Konto @XDevelopers in englischer Sprache ab, gruppiert nach day.

cURL
cURL example

cURL ist ein Befehlszeilen-Tool zum Abrufen oder Senden von Dateien mithilfe der URL-Syntax.Kopieren Sie die folgende cURL-Anfrage in Ihre Befehlszeile, nachdem Sie die folgenden Anpassungen vorgenommen haben:

Benutzername <USERNAME>, z. B. email@domain.com
Kontoname <ACCOUNT-NAME>, z. B. john-doe
Label <LABEL>, z. B. prod
fromDate und toDate, z. B. "fromDate":"201811010000", "toDate":"201811122359"

Nach dem Senden Ihrer Anfrage werden Sie zur Eingabe Ihres Passworts aufgefordert.

curl -X POST -u<USERNAME> "https://gnip-api.x.com/search/30day/accounts/<ACCOUNT-NAME>/<LABEL>/counts.json" -d '{"query":"from:TwitterDev lang:en","fromDate":"<yyyymmddhhmm>","toDate":"<yyyymmddhhmm>","bucket":"day"}'

Antwortnutzlast des Counts-endpoints

Die Nutzlast, die Sie auf Ihre API-Anfrage zurückerhalten, liegt im JSON-Format vor, wie unten gezeigt.

{
	"results": [
		{
			"timePeriod": "201811010000",
			"count": 0
		},
		{
			"timePeriod": "201811020000",
			"count": 1
		},
		{
			"timePeriod": "201811030000",
			"count": 0
		},
		{
			"timePeriod": "201811040000",
			"count": 0
		},
		{
			"timePeriod": "201811050000",
			"count": 0
		}
	],
	"totalCount": 1,
	"requestParameters": {
		"bucket": "day",
		"fromDate": "201811010000",
		"toDate": "201811060000"
	}
}

Gute Arbeit! Sie haben jetzt erfolgreich auf die Enterprise Search Posts: 30‑Day API zugegriffen.

Verweise

Einstieg in die Enterprise Search Posts: Full-Archive API

Die Enterprise Search Posts: Full-Archive API stellt Ihnen Posts seit dem ersten aus dem Jahr 2006 bereit. Posts werden anhand der query, die Sie in Ihrer Anfrage angeben, abgeglichen und an Sie zurückgesendet. Eine query ist eine Regel, in der Sie definieren, was der Post, den Sie zurückerhalten, enthalten soll. In diesem Tutorial suchen wir nach Posts in englischer Sprache, die vom X-Konto @XDevelopers stammen. Die Posts, die Sie in Ihrer Payload zurückerhalten, können im data-Format vorliegen, das Ihnen die vollständige Post-Payload bereitstellt, oder in einem counts-Format, das Ihnen numerische Zähldaten der abgeglichenen Posts liefert. Wir verwenden cURL, um Anfragen an die data- und counts-endpoints zu stellen. Sie benötigen Folgendes:

[Ein Enterprise-Konto]https://developer.x.com/en/products/x-api/enterprise
Ihren Benutzernamen, Ihr Passwort und Ihren Kontonamen
Das Label, das Ihrem Search-endpoint zugeordnet ist, wie in console.gnip.com angezeigt

Zugriff auf das data endpoint

Das data endpoint liefert den vollständigen Post-Payload der übereinstimmenden Posts. Wir verwenden die Operatoren from: und lang:, um Posts zu finden, die von @XDevelopers auf Englisch stammen. Für weitere Operatoren klicken Sie hier.

cURL
cURL-Beispiel

cURL
cURL example

cURL ist ein Kommandozeilen-Tool zum Abrufen oder Senden von Dateien mithilfe der URL-Syntax.Kopieren Sie die folgende cURL-Anfrage in Ihre Kommandozeile, nachdem Sie die folgenden Anpassungen vorgenommen haben:

Username <USERNAME> z. B. email@domain.com
Account-Name <ACCOUNT-NAME> z. B. john-doe
Label <LABEL> z. B. prod
fromDate und toDate z. B. "fromDate":"201802010000", "toDate":"201802282359"

Nach dem Senden Ihrer Anfrage werden Sie zur Eingabe Ihres Passworts aufgefordert.

curl -X POST -u<USERNAME> "https://gnip-api.x.com/search/fullarchive/accounts/<ACCOUNT-NAME>/<LABEL>.json" -d '{"query":"from:TwitterDev lang:en","maxResults":"500","fromDate":"<yyyymmddhhmm>","toDate":"<yyyymmddhhmm>"}'

Antwort-Payload des data-endpoints

Die Payload, die Sie als Antwort auf Ihre API-Anfrage erhalten, wird im JSON-Format zurückgegeben, wie unten gezeigt.

{
	"results": [
		{
			"created_at": "Fri Nov 02 17:18:31 +0000 2018",
			"id": 1058408022936977409,
			"id_str": "1058408022936977409",
			"text": "RT @harmophone: „Das innovative Crowdsourcing, das die Zusammenarbeit von Tagboard, Twitter und TEGNA ermöglicht, bringt lokal relevante Konv…",
			"source": "<a href=\"http:\/\/twitter.com\" rel=\"nofollow\">Twitter Web Client<\/a>",
			"truncated": false,
			"in_reply_to_status_id": null,
			"in_reply_to_status_id_str": null,
			"in_reply_to_user_id": null,
			"in_reply_to_user_id_str": null,
			"in_reply_to_screen_name": null,
			"user": {
				"id": 2244994945,
				"id_str": "2244994945",
				"name": "Twitter Dev",
				"screen_name": "TwitterDev",
				"location": "Internet",
				"url": "https:\/\/developer.x.com\/",
				"description": "Ihre offizielle Quelle für Twitter Platform-Neuigkeiten, Updates und Events. Benötigen Sie technische Hilfe? Besuchen Sie https:\/\/devcommunity.com\/ ⌨️ #TapIntoTwitter",
				"translator_type": "null",
				"protected": false,
				"verified": true,
				"followers_count": 503828,
				"friends_count": 1477,
				"listed_count": 1437,
				"favourites_count": 2199,
				"statuses_count": 3380,
				"created_at": "Sat Dec 14 04:35:55 +0000 2013",
				"utc_offset": null,
				"time_zone": null,
				"geo_enabled": true,
				"lang": "en",
				"contributors_enabled": false,
				"is_translator": false,
				"profile_background_color": "null",
				"profile_background_image_url": "null",
				"profile_background_image_url_https": "null",
				"profile_background_tile": null,
				"profile_link_color": "null",
				"profile_sidebar_border_color": "null",
				"profile_sidebar_fill_color": "null",
				"profile_text_color": "null",
				"profile_use_background_image": null,
				"profile_image_url": "null",
				"profile_image_url_https": "https:\/\/pbs.twimg.com\/profile_images\/880136122604507136\/xHrnqf1T_normal.jpg",
				"profile_banner_url": "https:\/\/pbs.twimg.com\/profile_banners\/2244994945\/1498675817",
				"default_profile": false,
				"default_profile_image": false,
				"following": null,
				"follow_request_sent": null,
				"notifications": null
			},
			"geo": null,
			"coordinates": null,
			"place": null,
			"contributors": null,
			"retweeted_status": {
				"created_at": "Tue Oct 30 21:30:25 +0000 2018",
				"id": 1057384253116289025,
				"id_str": "1057384253116289025",
				"text": „Das innovative Crowdsourcing, das die Zusammenarbeit von Tagboard, Twitter und TEGNA ermöglicht, bringt lokal relevante… https:\/\/t.co\/w46U5TRTzQ",
				"source": "<a href=\"http:\/\/twitter.com\" rel=\"nofollow\">Twitter Web Client<\/a>",
				"truncated": true,
				"in_reply_to_status_id": null,
				"in_reply_to_status_id_str": null,
				"in_reply_to_user_id": null,
				"in_reply_to_user_id_str": null,
				"in_reply_to_screen_name": null,
				"user": {
					"id": 175187944,
					"id_str": "175187944",
					"name": "Tyler Singletary",
					"screen_name": "harmophone",
					"location": "San Francisco, CA",
					"url": "http:\/\/medium.com\/@harmophone",
					"description": "SVP Product bei @Tagboard. War in Data, Biz und Product bei @Klout & für @LithiumTech tätig; @BBI Vorstandsmitglied; @Insightpool Berater. Schlechtester Whiteboard-Nutzer der Welt.",
					"translator_type": "null",
					"protected": false,
					"verified": false,
					"followers_count": 1982,
					"friends_count": 1877,
					"listed_count": 245,
					"favourites_count": 23743,
					"statuses_count": 12708,
					"created_at": "Thu Aug 05 22:59:29 +0000 2010",
					"utc_offset": null,
					"time_zone": null,
					"geo_enabled": false,
					"lang": "en",
					"contributors_enabled": false,
					"is_translator": false,
					"profile_background_color": "null",
					"profile_background_image_url": "null",
					"profile_background_image_url_https": "null",
					"profile_background_tile": null,
					"profile_link_color": "null",
					"profile_sidebar_border_color": "null",
					"profile_sidebar_fill_color": "null",
					"profile_text_color": "null",
					"profile_use_background_image": null,
					"profile_image_url": "null",
					"profile_image_url_https": "https:\/\/pbs.twimg.com\/profile_images\/719985428632240128\/WYFHcK-m_normal.jpg",
					"profile_banner_url": "https:\/\/pbs.twimg.com\/profile_banners\/175187944\/1398653841",
					"default_profile": false,
					"default_profile_image": false,
					"following": null,
					"follow_request_sent": null,
					"notifications": null
				},
				"geo": null,
				"coordinates": null,
				"place": null,
				"contributors": null,
				"is_quote_status": false,
				"extended_tweet": {
					"full_text": „Das innovative Crowdsourcing, das die Zusammenarbeit von Tagboard, Twitter und TEGNA ermöglicht, bringt lokal relevante Gespräche in Echtzeit an die Oberfläche und ermöglicht es Wählern, während Debatten Fragen zu stellen," -- @adamostrow, @TEGNA\nMehr erfahren: https:\/\/t.co\/ivAFtanfje",
					"display_text_range": [
						0,
						259
					],
					"entities": {
						"hashtags": [],
						"urls": [
							{
								"url": "https:\/\/t.co\/ivAFtanfje",
								"expanded_url": "https:\/\/blog.tagboard.com\/twitter-and-tagboard-collaborate-to-bring-best-election-content-to-news-outlets-with-tagboard-e85fc864bcf4",
								"display_url": "blog.tagboard.com\/twitter-and-ta…",
								"unwound": {
									"url": "https:\/\/blog.tagboard.com\/twitter-and-tagboard-collaborate-to-bring-best-election-content-to-news-outlets-with-tagboard-e85fc864bcf4",
									"status": 200,
									"title": "Twitter und Tagboard arbeiten zusammen, um beste Wahlinhalte über Tagboard an Nachrichtenredaktionen zu bringen…",
									"description": "Von Tyler Singletary, Head of Product, Tagboard"
								},
								"indices": [
									236,
									259
								]
							}
						],
						"user_mentions": [
							{
								"screen_name": "adamostrow",
								"name": "Adam Ostrow",
								"id": 5695942,
								"id_str": "5695942",
								"indices": [
									204,
									215
								]
							},
							{
								"screen_name": "TEGNA",
								"name": "TEGNA",
								"id": 34123003,
								"id_str": "34123003",
								"indices": [
									217,
									223
								]
							}
						],
						"symbols": []
					}
				},
				"quote_count": 0,
				"reply_count": 1,
				"retweet_count": 6,
				"favorite_count": 19,
				"entities": {
					"hashtags": [],
					"urls": [
						{
							"url": "https:\/\/t.co\/w46U5TRTzQ",
							"expanded_url": "https:\/\/twitter.com\/i\/web\/status\/1057384253116289025",
							"display_url": "twitter.com\/i\/web\/status\/1…",
							"indices": [
								117,
								140
							]
						}
					],
					"user_mentions": [],
					"symbols": []
				},
				"favorited": false,
				"retweeted": false,
				"possibly_sensitive": false,
				"filter_level": "low",
				"lang": "en"
			},
			"is_quote_status": false,
			"quote_count": 0,
			"reply_count": 0,
			"retweet_count": 0,
			"favorite_count": 0,
			"entities": {
				"hashtags": [],
				"urls": [],
				"user_mentions": [
					{
						"screen_name": "harmophone",
						"name": "Tyler Singletary",
						"id": 175187944,
						"id_str": "175187944",
						"indices": [
							3,
							14
						]
					}
				],
				"symbols": []
			},
			"favorited": false,
			"retweeted": false,
			"filter_level": "low",
			"lang": "en",
			"matching_rules": [
				{
					"tag": null
				}
			]
		}
	],
	"requestParameters": {
		"maxResults": 100,
		"fromDate": "201811010000",
		"toDate": "201811060000"
	}
}

Zugriff auf das counts-endpoint

Mit dem counts-endpoint rufen wir die Anzahl der Posts vom Konto @XDevelopers in englischer Sprache ab, gruppiert nach day.

cURL
cURL example

cURL ist ein Befehlszeilentool zum Abrufen oder Senden von Dateien mithilfe der URL-Syntax.Kopieren Sie die folgende cURL-Anfrage in Ihre Befehlszeile, nachdem Sie die folgenden Anpassungen vorgenommen haben:

Benutzername <USERNAME> z. B. email@domain.com
Kontoname <ACCOUNT-NAME> z. B. john-doe
Label <LABEL> z. B. prod
fromDate und toDate z. B. "fromDate":"201802010000", "toDate":"201802282359"

Nach dem Senden Ihrer Anfrage werden Sie zur Eingabe Ihres Passworts aufgefordert.

curl -X POST -u<USERNAME> "https://gnip-api.x.com/search/fullarchive/accounts/<ACCOUNT-NAME>/<LABEL>/counts.json" -d '{"query":"from:TwitterDev lang:en","fromDate":"<yyyymmddhhmm>","toDate":"<yyyymmddhhmm>","bucket":"day"}'

Antwort-Payload des Counts-endpoints

Die Payload, die Sie auf Ihre API-Anfrage zurückerhalten, liegt im JSON-Format vor, wie unten gezeigt.

{
	"results": [
		{
			"timePeriod": "201811010000",
			"count": 0
		},
		{
			"timePeriod": "201811020000",
			"count": 1
		},
		{
			"timePeriod": "201811030000",
			"count": 0
		},
		{
			"timePeriod": "201811040000",
			"count": 0
		},
		{
			"timePeriod": "201811050000",
			"count": 0
		}
	],
	"totalCount": 1,
	"requestParameters": {
		"bucket": "day",
		"fromDate": "201811010000",
		"toDate": "201811060000"
	}
}

Großartige Arbeit! Sie haben nun erfolgreich auf die Enterprise Search Posts: Full-Archive API zugegriffen.

Leitfäden

Erstellen von Suchanfragen

Enterprise-Operatoren

Nachfolgend finden Sie eine Liste aller Operatoren, die in den Enterprise-Such-APIs von X unterstützt werden:

Enterprise-30‑Tage-Such-API
Enterprise-Vollarchiv-Such-API

Einen direkten Vergleich der verfügbaren Operatoren nach Produkt finden Sie HIER.

Operator	Beschreibung
keyword	Findet ein tokenisiertes Schlüsselwort im Inhalt oder in den URLs eines Posts. Dies ist eine tokenisierte Übereinstimmung, was bedeutet, dass Ihre Schlüsselwort-Zeichenkette mit dem tokenisierten Text des Post-Inhalts abgeglichen wird – die Tokenisierung basiert auf Interpunktion, Symbolen und Trennzeichen der Unicode-Grundebene. Zum Beispiel würde ein Post mit dem Text „I like coca-cola” in folgende Token aufgeteilt: I, like, coca, cola. Diese Token würden dann mit der in Ihrer Regel verwendeten Schlüsselwort-Zeichenkette verglichen. Um Zeichenketten mit Interpunktion (zum Beispiel coca-cola), Symbolen oder Trennzeichen zu finden, müssen Sie eine in Anführungszeichen gesetzte exakte Übereinstimmung verwenden, wie unten beschrieben. Hinweis: Bei der Search API werden akzentuierte und Sonderzeichen zu lateinischen Standardzeichen normalisiert, was die Bedeutung in Fremdsprachen ändern oder unerwartete Ergebnisse liefern kann: Zum Beispiel wird „músic” mit „music” übereinstimmen und umgekehrt. Zum Beispiel würden häufige Phrasen wie „Feliz Año Nuevo!” auf Spanisch als „Feliz Ano Nuevo” indexiert, was die Bedeutung der Phrase ändert. Hinweis: Dieser Operator findet sowohl URLs als auch entpackte URLs innerhalb eines Posts.
emoji	Findet ein Emoji im Inhalt eines Posts. Emojis sind eine tokenisierte Übereinstimmung, was bedeutet, dass Ihr Emoji mit dem tokenisierten Text des Post-Inhalts abgeglichen wird – die Tokenisierung basiert auf Interpunktion, Symbol-/Emoji- und Trennzeichen der Unicode-Grundebene. Zum Beispiel würde ein Post mit dem Text „I like ” in folgende Token aufgeteilt: I, like, . Diese Token würden dann mit dem in Ihrer Regel verwendeten Emoji verglichen. Beachten Sie, dass Sie „Anführungszeichen” verwenden müssen, um eine Regel hinzuzufügen, wenn ein Emoji eine Variante hat.
„exact phrase match”	Findet die tokenisierte und geordnete Phrase im Inhalt oder in den URLs eines Posts. Dies ist eine tokenisierte Übereinstimmung, was bedeutet, dass Ihre Schlüsselwort-Zeichenkette mit dem tokenisierten Text des Post-Inhalts abgeglichen wird – die Tokenisierung basiert auf Interpunktion, Symbolen und Trennzeichen der Unicode-Grundebene. Hinweis: Interpunktion wird nicht tokenisiert und stattdessen als Leerzeichen behandelt. Zum Beispiel wird das in Anführungszeichen gesetzte „#hashtag” mit „hashtag” übereinstimmen, aber nicht mit #hashtag (verwenden Sie den Hashtag-#-Operator ohne Anführungszeichen, um tatsächliche Hashtags zu finden). Zum Beispiel wird das in Anführungszeichen gesetzte „ $cashtag" mit „cashtag" übereinstimmen, aber nicht mit$ cashtag (verwenden Sie den Cashtag-$-Operator ohne Anführungszeichen, um tatsächliche Cashtags zu finden). Zum Beispiel wird „Love Snow” mit „#love #snow” übereinstimmen Zum Beispiel wird „#Love #Snow” mit „love snow” übereinstimmen Hinweis: Dieser Operator findet sowohl URLs als auch entpackte URLs innerhalb eines Posts.
„keyword1 keyword2”~N	Allgemein als Näherungsoperator bezeichnet, findet dieser einen Post, bei dem die Schlüsselwörter nicht mehr als N Token voneinander entfernt sind. Wenn die Schlüsselwörter in umgekehrter Reihenfolge stehen, können sie nicht mehr als N-2 Token voneinander entfernt sein. Kann eine beliebige Anzahl von Schlüsselwörtern in Anführungszeichen haben. N kann nicht größer als 6 sein. Beachten Sie, dass dieser Operator nur in den Enterprise Search APIs verfügbar ist.
from:	Findet jeden Post von einem bestimmten Nutzer. Der Wert muss die numerische X-Konto-ID oder der Nutzername des Nutzers sein (ohne das @-Zeichen). Siehe HIER oder HIER für Methoden zum Nachschlagen numerischer X-Konto-IDs.
to:	Findet jeden Post, der eine Antwort auf einen bestimmten Nutzer ist. Der Wert muss die numerische Konto-ID oder der Nutzername des Nutzers sein (ohne das @-Zeichen). Siehe HIER für Methoden zum Nachschlagen numerischer X-Konto-IDs.
url:	Führt eine tokenisierte (Schlüsselwort/Phrase) Übereinstimmung mit den erweiterten URLs eines Posts durch (ähnlich wie url_contains). Token und Phrasen mit Interpunktion oder Sonderzeichen sollten in doppelte Anführungszeichen gesetzt werden. Zum Beispiel url:„/developer”. Obwohl generell nicht empfohlen, wenn Sie ein bestimmtes Protokoll finden möchten, setzen Sie es in doppelte Anführungszeichen: url:„https://developer.x.com”. Hinweis: Bei Verwendung von PowerTrack oder Historical PowerTrack findet dieser Operator URLs, die im ursprünglichen Post eines Quote Posts enthalten sind. Zum Beispiel, wenn Ihre Regel url:„developer.x.com” enthält und ein Post diese URL enthält, werden alle Quote Tweets dieses Posts in die Ergebnisse einbezogen. Dies ist bei Verwendung der Search API nicht der Fall.
#	Findet jeden Post mit dem angegebenen Hashtag. Dieser Operator führt eine exakte Übereinstimmung durch, KEINE tokenisierte Übereinstimmung, was bedeutet, dass die Regel „2016” Posts mit dem exakten Hashtag „2016” findet, aber nicht solche mit dem Hashtag „2016election” Hinweis: Der Hashtag-Operator basiert auf Xs Entitätsextraktion, um Hashtags zu finden, anstatt den Hashtag aus dem Inhalt selbst zu extrahieren. Siehe HIER für weitere Informationen zu X Entities JSON-Attributen.
@	Findet jeden Post, der den angegebenen Nutzernamen erwähnt. Der to:-Operator gibt eine Teilmenge des @mention-Operators zurück.
$	Findet jeden Post, der das angegebene „Cashtag” enthält (wobei das führende Zeichen des Tokens das „$“-Zeichen ist). Beachten Sie, dass der Cashtag-Operator auf Xs „symbols”-Entitätsextraktion basiert, um Cashtags zu finden, anstatt zu versuchen, das Cashtag aus dem Inhalt selbst zu extrahieren. Siehe HIER für weitere Informationen zu X Entities JSON-Attributen. Beachten Sie, dass dieser Operator nur in den Enterprise Search APIs verfügbar ist.
retweets_of:	Verfügbarer Alias: retweets_of_user: Findet Posts, die Retweets eines bestimmten Nutzers sind. Akzeptiert sowohl Nutzernamen als auch numerische X-Konto-IDs (NICHT Post-Status-IDs). Siehe HIER für Methoden zum Nachschlagen numerischer X-Konto-IDs.
lang:	Findet Posts, die von X als einer bestimmten Sprache zugehörig klassifiziert wurden (wenn und nur wenn der Post klassifiziert wurde). Es ist wichtig zu beachten, dass jeder Post derzeit nur als einer Sprache zugehörig klassifiziert wird, sodass die UND-Verknüpfung mehrerer Sprachen keine Ergebnisse liefert. Hinweis: Wenn keine Sprachklassifizierung vorgenommen werden kann, ist das bereitgestellte Ergebnis „und” (für undefiniert). Die folgende Liste stellt die derzeit unterstützten Sprachen und ihre entsprechenden BCP 47-Sprachkennungen dar:


Amharisch: am	Deutsch: de	Malayalam: ml	Slowakisch: sk
Arabisch: ar	Griechisch: el	Dhivehi (Maledivisch): dv	Slowenisch: sl
Armenisch: hy	Gujarati: gu	Marathi: mr	Sorani: ckb
Baskisch: eu	Haitianisches Kreol: ht	Nepali: ne	Spanisch: es
Bengalisch: bn	Hebräisch: iw	Norwegisch: no	Schwedisch: sv
Bosnisch: bs	Hindi: hi	Odia: or	Tagalog: tl
Bulgarisch: bg	Lateinisiertes Hindi: hi-Latn	Panjabi: pa	Tamil: ta
Birmanisch: my	Ungarisch: hu	Paschtu: ps	Telugu: te
Kroatisch: hr	Isländisch: is	Persisch: fa	Thailändisch: th
Katalanisch: ca	Indonesisch: in	Polnisch: pl	Tibetisch: bo
Tschechisch: cs	Italienisch: it	Portugiesisch: pt	Traditionelles Chinesisch: zh-TW
Dänisch: da	Japanisch: ja	Rumänisch: ro	Türkisch: tr
Niederländisch: nl	Kannada: kn	Russisch: ru	Ukrainisch: uk
Englisch: en	Khmer: km	Serbisch: sr	Urdu: ur
Estnisch: et	Koreanisch: ko	Vereinfachtes Chinesisch: zh-CN	Uigurisch: ug
Finnisch: fi	Lao: lo	Sindhi: sd	Vietnamesisch: vi
Französisch: fr	Lettisch: lv	Singhalesisch: si	Walisisch: cy
Georgisch: ka	Litauisch: lt


place:	Findet Posts, die mit dem angegebenen Ort oder der X-Place-ID getaggt sind (siehe Beispiele). Mehrteilige Ortsnamen („New York City“, „Palo Alto“) sollten in Anführungszeichen stehen. Hinweis: Informationen zum Abrufen von X-Place-IDs finden Sie im öffentlichen API-endpoint GET geo/search. Hinweis: Dieser Operator greift nicht bei Retweets, da die Orte des Retweet am ursprünglichen Post hängen. Er greift auch nicht bei Orten, die am ursprünglichen Post eines Quote Tweet hängen.
place_country:	Findet Posts, bei denen der mit einem getaggten Place verknüpfte Ländercode dem angegebenen ISO-Alpha-2-Code entspricht. Gültige ISO-Codes finden Sie hier: http://en.wikipedia.org/wiki/ISO_3166-1_alpha-2 Hinweis: Dieser Operator greift nicht bei Retweets, da die Orte des Retweet am ursprünglichen Post hängen. Er greift auch nicht bei Orten, die am ursprünglichen Post eines Quote Tweet hängen.
point_radius:[lon lat radius]	Vergleicht mit dem exakten Standort (x, y) des Post, wenn vorhanden, und in X mit einem „Place“-Geo-Polygon, wobei der Place vollständig innerhalb der definierten Region liegt. * Unterstützte Radieneinheiten sind Meilen (mi) und Kilometer (km). * Der Radius muss kleiner als 25 mi sein. * Längengrad liegt im Bereich von ±180. * Breitengrad liegt im Bereich von ±90. * Alle Koordinaten sind in Dezimalgrad. * Regelargumente stehen in eckigen Klammern und sind durch Leerzeichen getrennt. Hinweis: Dieser Operator greift nicht bei Retweets, da die Orte des Retweet am ursprünglichen Post hängen. Er greift auch nicht bei Orten, die am ursprünglichen Post eines Quote Tweet hängen.
bounding_box:[west_long south_lat east_long north_lat]	Verfüglicher Alias: geo_bounding_box: Vergleicht mit dem exakten Standort (long, lat) des Post, wenn vorhanden, und in X mit einem „Place“-Geo-Polygon, wobei der Place vollständig innerhalb der definierten Region liegt. * west_long und south_lat bilden die südwestliche Ecke der Begrenzungsbox, wobei west_long der Längengrad dieses Punktes ist und south_lat der Breitengrad. * east_long und north_lat bilden die nordöstliche Ecke der Begrenzungsbox, wobei east_long der Längengrad dieses Punktes ist und north_lat der Breitengrad. * Breite und Höhe der Begrenzungsbox müssen kleiner als 25 mi sein. * Längengrad liegt im Bereich von ±180. * Breitengrad liegt im Bereich von ±90. * Alle Koordinaten sind in Dezimalgrad. * Regelargumente stehen in eckigen Klammern und sind durch Leerzeichen getrennt. Hinweis: Dieser Operator greift nicht bei Retweets, da die Orte des Retweet am ursprünglichen Post hängen. Er greift auch nicht bei Orten, die am ursprünglichen Post eines Quote Tweet hängen.
profile_country:	Exakte Übereinstimmung mit dem Feld „countryCode“ aus dem Objekt „address“ in der Profile-Geo-Anreicherung. Verwendet einen normalisierten Satz zweibuchstabiger Ländercodes, basierend auf der Spezifikation ISO-3166-1-alpha-2. Dieser Operator wird der Kürze halber anstelle eines Operators für das Feld „country“ aus dem Objekt „address“ bereitgestellt.
profile_region:	Vergleicht mit dem Feld „region“ aus dem Objekt „address“ in der Profile-Geo-Anreicherung. Dies ist eine exakte vollständige Zeichenfolgenübereinstimmung. Es ist nicht erforderlich, Zeichen mit einem Backslash zu maskieren. Wenn Sie beispielsweise etwas mit einem Slash abgleichen, verwenden Sie „one/two“, nicht „one/two“. Verwenden Sie doppelte Anführungszeichen, um Teilzeichenfolgen abzugleichen, die Leerzeichen oder Satzzeichen enthalten.
profile_locality:	Vergleicht mit dem Feld „locality“ aus dem Objekt „address“ in der Profile-Geo-Anreicherung. Dies ist eine exakte vollständige Zeichenfolgenübereinstimmung. Es ist nicht erforderlich, Zeichen mit einem Backslash zu maskieren. Wenn Sie beispielsweise etwas mit einem Slash abgleichen, verwenden Sie „one/two“, nicht „one/two“. Verwenden Sie doppelte Anführungszeichen, um Teilzeichenfolgen abzugleichen, die Leerzeichen oder Satzzeichen enthalten.

HINWEIS: Alle is:- und has:-Operatoren können bei Verwendung der Search API nicht als eigenständige Operatoren genutzt werden und müssen mit einer weiteren Klausel kombiniert werden.Zum Beispiel: @XDevelopers has:links


has:geo	Findet Posts, die Post-spezifische Geo-Standortdaten von X enthalten. Dies können entweder „geo” Breiten-/Längengrad-Koordinaten oder ein „location” in Form eines X „Place” mit entsprechendem Anzeigenamen, Geo-Polygon und anderen Feldern sein. Hinweis: Bei Verwendung der Search API muss dieser Operator in Verbindung mit anderen Operatoren verwendet werden, die nicht `is:` oder `has:` enthalten.
has:profile_geo	Verfügbarer Alias: has:derived_user_geo Findet Posts, die beliebige Profile Geo metadata enthalten, unabhängig vom tatsächlichen Wert. Hinweis: Bei Verwendung der Search API muss dieser Operator in Verbindung mit anderen Operatoren verwendet werden, die nicht `is:` oder `has:` enthalten.
has:links	Dieser Operator findet Posts, die Links im Nachrichtentext enthalten. Hinweis: Bei Verwendung der Search API muss dieser Operator in Verbindung mit anderen Operatoren verwendet werden, die nicht `is:` oder `has:` enthalten.
is:retweet	Liefert nur explizite Retweets, die einer Regel entsprechen. Kann auch negiert werden, um Retweets auszuschließen, die einer Regel entsprechen, und nur ursprüngliche Inhalte zu liefern. Dieser Operator sucht nur nach echten Retweets, die die Retweet-Funktionalität von X verwenden. Quote Tweets und modifizierte Posts, die nicht die Retweet-Funktionalität von X verwenden, werden von diesem Operator nicht erfasst. Hinweis: Bei Verwendung der Search API muss dieser Operator in Verbindung mit anderen Operatoren verwendet werden, die nicht `is:` oder `has:` enthalten.
is:reply	Ein Operator zum Filtern von Posts basierend darauf, ob sie Antworten auf Posts sind oder nicht. Liefert nur explizite Antworten, die einer Regel entsprechen. Kann auch negiert werden, um Antworten auszuschließen, die einer Regel entsprechen. Beachten Sie, dass dieser Operator für kostenpflichtige Premium- und Enterprise-Suche verfügbar ist und nicht in Sandbox-Entwicklungsumgebungen verfügbar ist. Hinweis: Bei Verwendung der Search API muss dieser Operator in Verbindung mit anderen Operatoren verwendet werden, die nicht `is:` oder `has:` enthalten.
is:quote	Liefert nur Quote Tweets oder Posts, die auf einen anderen Post verweisen, wie durch das „is_quote_status”:true in Post-Payloads identifiziert. Kann auch negiert werden, um Quote Tweets auszuschließen. Hinweis: Bei Verwendung der Search API muss dieser Operator in Verbindung mit anderen Operatoren verwendet werden, die nicht `is:` oder `has:` enthalten.
is:verified	Liefert nur Posts, bei denen der Autor von X „verifiziert” ist. Kann auch negiert werden, um Posts auszuschließen, bei denen der Autor verifiziert ist. Hinweis: Bei Verwendung der Search API muss dieser Operator in Verbindung mit anderen Operatoren verwendet werden, die nicht `is:` oder `has:` enthalten.
has:mentions	Findet Posts, die einen anderen X-Benutzer erwähnen. Hinweis: Bei Verwendung der Search API muss dieser Operator in Verbindung mit anderen Operatoren verwendet werden, die nicht `is:` oder `has:` enthalten.
has:hashtags	Findet Posts, die einen Hashtag enthalten. Hinweis: Bei Verwendung der Search API muss dieser Operator in Verbindung mit anderen Operatoren verwendet werden, die nicht `is:` oder `has:` enthalten.
has:media	Verfügbarer Alias: has:media_link Findet Posts, die eine von X klassifizierte Medien-URL enthalten. Zum Beispiel pic.x.com. Hinweis: Bei Verwendung der Search API muss dieser Operator in Verbindung mit anderen Operatoren verwendet werden, die nicht `is:` oder `has:` enthalten.
has:images	Findet Posts, die eine von X klassifizierte Medien-URL enthalten. Zum Beispiel pic.x.com. Hinweis: Bei Verwendung der Search API muss dieser Operator in Verbindung mit anderen Operatoren verwendet werden, die nicht `is:` oder `has:` enthalten.
has:videos	Verfügbarer Alias: has:video_link Findet Posts, die native X-Videos enthalten, die direkt auf X hochgeladen wurden. Dies findet keine Videos, die mit Vine, Periscope erstellt wurden, oder Posts mit Links zu anderen Video-Hosting-Sites. Hinweis: Bei Verwendung der Search API muss dieser Operator in Verbindung mit anderen Operatoren verwendet werden, die nicht `is:` oder `has:` enthalten.
has:symbols	Findet Posts, die ein Cashtag-Symbol enthalten (mit einem führenden „ $"-Zeichen. Zum Beispiel$ tag). Beachten Sie, dass dieser Operator nur in den `enterprise` Search APIs verfügbar ist. Hinweis: Bei Verwendung der Search API muss dieser Operator in Verbindung mit anderen Operatoren verwendet werden, die nicht `is:` oder `has:` enthalten.

Produktübersicht

Die Full-archive Search der Enterprise-Stufe wurde im August 2015 eingeführt, die Version der Premium-Stufe im Februar 2018. Diese Suchprodukte ermöglichen Kundinnen und Kunden den sofortigen Zugriff auf jeden öffentlich verfügbaren Post. Mit Full-archive Search senden Sie eine einzelne Abfrage und erhalten eine Antwort im klassischen RESTful-Stil. Full-archive Search implementiert eine Paginierung von bis zu 500 Posts pro Antwort und unterstützt ein Rate-Limit von bis zu 60 Anfragen pro Minute (rpm) für Premium und 120 rpm für Enterprise. Unter diesen Bedingungen kann Full-archive Search verwendet werden, um Posts schnell und in großem Umfang über parallele Anfragen abzurufen. Im Gegensatz zu Historical PowerTrack, dessen Archiv auf einer Reihe von Post-Flatfiles auf Datenträgern basiert, ähnelt das Full-archive Search Post-Archiv eher einer Online-Datenbank. Wie bei allen Datenbanken unterstützt es das Absetzen von Abfragen auf seine Inhalte. Es verwendet außerdem einen Index, um eine performante Datenabfrage zu ermöglichen. Bei Full-archive Search endpoints besteht die Abfragesprache aus PowerTrack Operators, und diese Operators entsprechen jeweils einem indizierten Post-JSON-Attribut. Ebenso gibt es, wie bei Historical PowerTrack, Post-Attribute, die zum Zeitpunkt der Abfrage den aktuellen Stand widerspiegeln. Wenn Sie beispielsweise die Search API verwenden, um heute auf einen Post zuzugreifen, der 2010 veröffentlicht wurde, werden die Profilbeschreibung des Users, der Home-Standort des Kontos, der Anzeigename sowie die Post metrics für like- und Retweet-Zählungen auf die heutigen Werte aktualisiert und nicht auf die Werte von 2010.

Metadaten-Zeitlinien

Nachfolgend finden Sie eine Zeitlinie, ab wann die Operatoren des Full-Archive-Search-endpoints mit dem Abgleich beginnen. In einigen Fällen setzte das Operator-Matching erst lange nach dem Zeitpunkt ein, zu dem eine „Kommunikationskonvention“ auf X verbreitet wurde. Beispielsweise etablierten sich @Replies 2006 als Nutzerkonvention, wurden jedoch erst Anfang 2007 mit „unterstützendem“ JSON zu einem First-Class-Objekt bzw. Ereignis. Entsprechend erfordert das Matching von @Replies im Jahr 2006 die Prüfung des Post-Texts, statt sich auf die PowerTrack-Operatoren to: und in_reply_to_status_id: zu verlassen. Die hier bereitgestellten Details wurden mit der Full-Archive Search (als Ergebnis Hunderter Suchvorgänge) erstellt. Diese Zeitlinie ist nicht zu 100 % vollständig oder exakt. Wenn Sie ein weiteres grundlegendes Filter-/Metadaten-„Geburtsdatum“ identifizieren, das für Ihren Anwendungsfall wesentlich ist, lassen Sie es uns bitte wissen. Beachten Sie, dass der zugrunde liegende Suchindex neu aufgebaut werden kann. Entsprechend können sich diese Angaben zur Zeitlinie ändern.

2006

1. März – lang:. Ein Beispiel dafür, wie Post-Metadaten beim Erstellen des Suchindex nachträglich aufgefüllt werden.
1. Juli – has:mentions beginnt zu greifen.
1. Oktober – has:symbols. $Cashtags (oder Symbole) zur Diskussion von Börsentickern werden erst Anfang 2009 verbreitet. Bis dahin waren die meisten Verwendungen vermutlich Slang (z. B.$ slang).
1. Oktober – has:links beginnt zu greifen.
1. November – has:hashtags beginnt zu greifen.

2007

1. Januar - Erste @reply auf Ebene „First-Class“ (in_reply_to_user_id), reply_to_status_id: beginnt zu matchen.
1. August - Hashtags setzen sich als gängige Konvention zur Organisation von Themen und Unterhaltungen durch. Erste tatsächliche Nutzung eine Woche später.

2009

1. Mai – is:retweet. Beachten Sie, dass dieser Operator ab der Beta-Veröffentlichung der offiziellen Retweets und ihrem „Via @“-Muster greift. Während dieses Beta-Zeitraums ist das Post-Verb „post“ und der ursprüngliche Post ist nicht im Payload enthalten.
1. August – Die endgültige Version der offiziellen Retweets wird mit dem Muster „RT @“, einem auf „share“ gesetzten Verb und dem Attribut „retweet_status“, das den ursprünglichen Post enthält, veröffentlicht (was die Größe des JSON-Payloads in etwa verdoppelt).

2010

1. März – has:geo, bounding_box: und point_radius: Geo-Operatoren beginnen übereinzustimmen.
1. August – has:videos (Bis Februar 2015 stimmte dieser Operator mit Posts überein, die Links zu ausgewählten Video-Hosting-Websites wie youtube.com, vimeo.com und vivo.com enthalten).

2011

1. Juli – has:media und has:images werden unterstützt. Native Fotos wurden am 9. August 2010 offiziell angekündigt.

2014

1. Dezember – (ungefähr) einige erweiterte URL-Metadaten mit HTML-Title und -Description erscheinen in den Payloads. Die erweiterten Metadaten waren ab Mai 2016 umfassender verfügbar.

2015

1. Februar – has:videos stimmt für „native“ X‑Videos.
1. Februar – has:profile_geo, profile_country:, profile_region:, profile_locality: Profile-Geo-Operatoren beginnen zu greifen.
1. Februar – place_country: und place: Post‑Geo‑Operatoren beginnen zu greifen.

2016

1. Mai – Erweiterte URL-Metadaten waren breiter verfügbar und wurden offiziell als Teil des Gnip‑2.0‑Launches im August 2016 angekündigt. Keine zugehörigen Operatoren für diese Metadata mit Search-APIs.

2017

1. Februar – Umfrage-metadata sind im erweiterten nativen Format verfügbar. Keine zugehörigen Operatoren für diese metadata.

2022

1. September – Alle seit diesem Datum erstellten Post-Objekte verfügen über Metadaten zu bearbeiteten Posts. Alle Enterprise-endpoints, die Post-Objekte bereitstellen, wurden ab diesem Datum aktualisiert, um diese Metadaten auszugeben. Die bereitgestellten Bearbeitungsmetadaten umfassen die Objekte edit_history und edit_controls. Diese Metadaten werden für Posts, die vor dem 27. September 2022 erstellt wurden, nicht zurückgegeben. Derzeit sind keine Enterprise Operators verfügbar, die zu diesen Metadaten passen. Weitere Informationen zu Metadaten für bearbeitete Posts finden Sie auf der Seite Edit Posts fundamentals.

2022

1. September – Alle seit diesem Datum erstellten Post-Objekte verfügen über Edit-Post-Metadaten. Alle Enterprise-endpoints, die Post-Objekte bereitstellen, wurden ab diesem Datum aktualisiert, um diese metadata bereitzustellen. Die bereitgestellten Bearbeitungs-metadata umfassen die Objekte edit_history und edit_controls. Diese metadata werden nicht für Posts zurückgegeben, die vor dem 27. September 2022 erstellt wurden. Derzeit sind keine Enterprise-Operators verfügbar, die diesen metadata entsprechen. Weitere Informationen zu Edit-Post-metadata findest du auf der Seite Edit Posts fundamentals.

Tipps zum Filtern

Angesichts all der oben genannten Informationen zur Timeline ist klar, dass es beim Schreiben von Search-API-Filtern viele Details zu berücksichtigen gibt. Es gibt zwei zentrale Aspekte:

Einige Metadaten haben „Geburtsdaten“, sodass Filter zu falsch negativen Ergebnissen führen können. Solche Suchen umfassen Operatoren, die von Metadaten abhängen, die während des gesamten oder eines Teils des Suchzeitraums nicht vorhanden waren. Wenn Sie beispielsweise nach Posts mit dem Operator has:images suchen, erhalten Sie für Zeiträume vor Juli 2011 keine Treffer. Das liegt daran, dass dieser Operator auf nativen Fotos basiert (über die X-Benutzeroberfläche an einen Post angehängt). Für einen vollständigeren Datensatz von Posts mit Fotos müssten Filter für Zeiträume vor Juli 2011 Regelklauseln enthalten, die auf gängige Foto-Hosting-URLs matchen.
Einige Metadaten wurden mit Angaben aus einer Zeit nach dem Zeitpunkt, zu dem der Post auf X veröffentlicht wurde, nachträglich angereichert.

Es gibt mehrere Attributtypen, auf die bei der Erstellung von PowerTrack-Abfragen häufig der Fokus gelegt wird:

X Profile
Ursprüngliche oder geteilte Posts
Sprachklassifizierung von Posts
Georeferenzierte Posts
Geteilte Link-Medien

Einige davon haben produktspezifisches Verhalten, während andere identisches Verhalten aufweisen. Siehe unten für weitere Details.

X-Profile

Die Search APIs liefern historische Posts zusammen mit den Profildaten des Nutzers so, wie sie zum Zeitpunkt der Abfrage vorliegen. Wenn Sie einen Post aus dem Jahr 2014 anfordern, spiegeln die Profilmetadata des Nutzers wider, wie sie zum Abfragezeitpunkt existieren.

Originale Posts und Retweets

Der PowerTrack-Operator is:retweet ermöglicht es Nutzern, Retweets entweder einzuschließen oder auszuschließen. Nutzer dieses Operators benötigen zwei Strategien für das Matching (bzw. Nicht-Matching) von Retweets für data vor August 2009. Vor August 2009 muss die Post-Nachricht selbst mittels exakter Phrasenübereinstimmung auf das Muster „@RT “ geprüft werden (tatsächlich sollte, wenn Sie Retweets aus dem Zeitraum Mai–August 2009 filtern, auch das Muster „Via @“ berücksichtigt werden). Für Zeiträume nach August 2009 ist der Operator is:retweet verfügbar.

Sprachklassifizierungen von Posts

Beim Filtern nach der Sprachklassifizierung eines Posts unterscheiden sich die historischen Produkte von X deutlich. Als das Sucharchiv erstellt wurde, wurden alle Posts rückwirkend mit der X-Sprachklassifizierung versehen. Daher ist der Operator lang: für das gesamte Post-Archiv verfügbar.

Geo-Referenzierung von Posts

Es gibt drei primäre Methoden, Posts geo zu referenzieren:

Geografische Verweise im Post-Text. Das Matching anhand geografischer Verweise im Post-Text ist zwar oft die anspruchsvollste Methode, da sie von lokalen Kenntnissen abhängt, steht jedoch für das gesamte Post-Archiv zur Verfügung. Hier ist ein Beispiel für ein geo-referenziertes Matching aus dem Jahr 2006 für den Raum San Francisco, basierend auf einem „golden gate“-Filter.
Vom Nutzer geo-getaggte Posts. Mit den Search-APIs war das Matching auf Posts mit einigen Geo Operators ab März 2010 möglich, mit weiteren ab Februar 2015:
- 1. März 2010: has:geo, bounding_box: und point_radius:
- 1. Februar 2015: place_country: und place:
Vom Nutzer festgelegter „Home“-Standort im Kontoprofil. Profile Geo Operators sind sowohl in Historical PowerTrack als auch in den Search-APIs verfügbar. In den Search-APIs sind diese Profil-Geo-Metadaten seit Februar 2015 verfügbar. Für Posts, die vor der Verfügbarkeit der Profil-Geo-Metadaten veröffentlicht wurden, steht der Operator bio_location: zur Verfügung, mit dem sich auf nicht normalisierte Nutzereingaben matchen lässt.

Geteilte Links und Medien

Im März 2012 wurde die Anreicherung mit erweiterten URLs eingeführt. Zuvor enthielten die Post-Payloads nur die vom Nutzer angegebene URL. Wenn der Nutzer also eine verkürzte URL einfügte, ist es schwierig, Übereinstimmungen mit (expandierten) interessierenden URLs herzustellen. Mit den Search APIs sind diese metadata ab März 2012 verfügbar. Im Juli 2016 wurde die verbesserte URL-Anreicherung eingeführt. Diese Version liefert den HTML-Titel und die Beschreibung einer Website in der Post-Payload, zusammen mit Operatoren zum Abgleich darauf. Diese metadata tauchen ab Dezember 2014 auf. Im September 2016 führte X „native attachments“ ein, bei denen ein nachgestellter geteilter Link nicht auf das Zeichenlimit von 140 für Posts angerechnet wird. Beide URL-Anreicherungen gelten weiterhin für diese geteilten Links. Ab wann entsprechende Search-Operatoren Übereinstimmungen liefern:

1. Oktober 2006 - has:links
1. Juli 2011 - has:images und has:media
August 2011 - url: mit der Expanded URLs enrichment Bereits im September 2006 führt (url:"spotify.com" OR url:gnip OR url:microsoft OR url:google OR url:youtube) zu einer Übereinstimmung mit http://x.com/Adam/statuses/16602, obwohl es keine urls[] metadata in twitter_entities und gnip-Objekten gibt. „youtube.com“ ist ein Beispiel für Nachrichteninhalt, der ohne jegliche urls[] metadata mit url:youtube übereinstimmt.
1. Februar 2015 - has:videos für native Videos. Zwischen 2010/08/28 und 2015/02/10 stimmt dieser Operator mit Posts überein, die Links zu ausgewählten Video-Hosting-Seiten wie youtube.com, vimeo.com und vivo.com enthalten.
1. Mai 2016 - url_title: und url_description:, basierend auf der Enhanced URLs enrichment, allgemein verfügbar. Erste Enhanced-URL metadata begannen im Dezember 2014 zu erscheinen.

Häufig gestellte Fragen (FAQ)

Allgemeine Fragen zur Search-Post-API

Die Anzahl der Posts, die ich über das data-endpoint erhalte, stimmt nicht mit der Anzahl der Posts überein, die vom counts-endpoint ermittelt wird. Warum ist das so?

Es gibt einen bekannten Unterschied zwischen den Ergebnissen, die vom counts endpoint und vom data endpoint bereitgestellt werden. In Ihren Ergebnissen kann es zu Abweichungen kommen, weil der counts endpoint pre-compliance ist (d. h. er berücksichtigt Dinge wie gelöschte Posts, Scrub-Geo usw. nicht), während der data endpoint zum Zeitpunkt der Bereitstellung compliant ist und alle Compliance-Ereignisse berücksichtigt.

Ich habe keinen Post erhalten, der meiner query entsprechen sollte. Warum?

Es gibt mehrere mögliche Gründe, warum dies passiert sein könnte, unter anderem:

Der Post, den Sie zu sehen erwartet haben, stammt von einem geschützten Konto.
Das data endpoint berücksichtigt alle Compliance-Ereignisse (das heißt, gelöschte Posts, bereinigte Geodaten usw. werden nicht in der Antwort enthalten sein).

Meine Abfrage hat einen Post gefunden, enthält aber ein von mir negiertes Schlüsselwort. Warum passiert das?

Dies liegt wahrscheinlich an einer fehlerhaften Nutzung unserer Premium-Regeln und Filter. Bitte lesen Sie unsere Dokumentation hier und stellen Sie sicher, dass Sie die Einschränkungen beim Erstellen von Regeln verstehen.

Gibt es Bibliotheken, mit denen ich den Einstieg in die Verwendung der Search Post APIs finden kann?

Ja, die gibt es, darunter:

Tweepy – gut geeignet für die Nutzung des Standardprodukts Suche/Posts (Python)
X API – gut geeignet für die Nutzung der Standard-Search-Post-APIs (Python)
Search Posts Python und Search Posts Ruby – zwei geeignete Tools für die Verwendung mit den Enterprise- (und v2!) Search-Post-APIs

Alle Bibliotheken, die wir direkt unterstützen, finden Sie auf unserer xdevplatform-GitHub-Seite: https://github.com/xdevplatform.Es gibt weitere Bibliotheken von Drittanbietern, die ebenfalls hilfreich sein können; beachten Sie jedoch, dass einige davon möglicherweise nicht mit unseren Premium- und Enterprise-Produkten funktionieren.

Werde ich jemals ein geringeres Volumen an Posts erhalten als den Wert, den ich in meiner Anfrage an das data-endpoint als `maxResults` festgelegt habe?

Ja. Unser data endpoint paginiert entweder bei dem angegebenen maxResults-Wert oder nach 30 Tagen.Wenn Sie beispielsweise in einem Zeitraum von 30 Tagen 800 Posts haben, müssen Sie zwei Anfragen stellen, um die vollständigen Ergebnisse abzurufen; denn die maximale Anzahl von Posts, die pro Anfrage zurückgegeben werden kann, beträgt 500 (maxResults). Und wenn Sie im ersten Monat nur 400 Posts und im zweiten Monat 100 Posts haben, müssen Sie ebenfalls zwei Anfragen stellen, um die vollständigen Ergebnisse abzurufen; denn die Paginierung erfolgt nach 30 Tagen, auch wenn die erste Anfrage weniger als die angegebenen maxResults Posts zurückgibt.

In welcher Reihenfolge werden die passenden Posts zurückgegeben?

Posts werden in umgekehrter chronologischer Reihenfolge zurückgegeben. Beispielsweise zeigt die erste Ergebnisseite die neuesten Posts, die mit der Abfrage übereinstimmen; die Paginierung wird fortgesetzt, bis die in den Ergebnissen enthaltenen Veröffentlichungsdaten das ursprünglich angeforderte fromDate erreichen.

Wie wirken sich Bearbeitungen von Posts auf meine Nutzung und Abrechnung aus?

Für Abrechnungszwecke wird nur der ursprüngliche Post berücksichtigt. Alle nachfolgenden Bearbeitungen werden ignoriert und fließen nicht in Ihre Gesamtaktivität ein. Enterprise

Ich möchte mehr über die Preisgestaltung der Enterprise Search Post API erfahren und mich für dieses Angebot bewerben. Wie gehe ich dabei vor?

Unsere Enterprise‑Lösungen bieten transparente, planbare Preise und werden individuell auf die Anforderungen Ihres Unternehmens zugeschnitten. Weitere Informationen erhalten Sie, wenn Sie sich hier bewerben.

Wie erstelle ich einen Regelsatz, der meinem Anwendungsfall entspricht?

Bitte beachten Sie unsere Dokumentation zu den Enterprise Search Post APIs hier
Nützliche Informationen zu Regeln und Filterung finden Sie hier
Nützliche Informationen zur Verwendung des data endpoint finden Sie hier
Nützliche Informationen zur Verwendung des counts endpoint finden Sie hier
Eine Liste der verfügbaren Operatoren finden Sie hier

Ich habe meine Anfragenobergrenzen/-limits für diesen Monat überschritten, benötige aber Zugriff auf weitere data – was kann ich tun?

Bitte wenden Sie sich an Ihren Account Manager bei X, der Ihnen dabei weiterhelfen kann.

Leitfaden zur Fehlerbehebung

Code 404 – Nicht gefunden

Bitte stellen Sie sicher, dass Sie die richtigen Parameter für jeden endpoint verwenden (z. B. kann das buckets-Feld nur mit dem counts endpoint verwendet werden, nicht mit dem data endpoint).
Bitte prüfen Sie, ob die Felder :product, :account_name und :label korrekt sind. Ihr :label-Feld finden Sie in der GNIP Console (nur für Enterprise-Kundinnen und -Kunden).

API-Referenz

Enterprise-Such-APIs

Es gibt zwei Enterprise-Such-APIs:

30-Day Search API - stellt Tweets bereit, die in den letzten 30 Tagen veröffentlicht wurden.
Full-Archive Search API - stellt Tweets ab 2006 bereit, beginnend mit dem ersten im März 2006 veröffentlichten Tweet.

Diese Such-APIs folgen einem gemeinsamen Design und die untenstehende Dokumentation gilt für beide. Beachten Sie, dass für Tweets, die ab dem 29. September 2022 erstellt wurden, Tweet-Objekte Bearbeitungs-Metadaten enthalten, die deren Änderungshistorie beschreiben. Siehe die “Edit Tweets” Grundlagen-Seite für weitere Details. Nachfolgend finden Sie wichtige Details, die Sie für die Integration mit den Enterprise-Such-APIs benötigen:

Methoden für das Anfordern von Tweet-Daten und Zählungen
Authentifizierung
Paginierung
API-Anfrageparameter und Beispielanfragen
API-Antwort-JSON-Nutzlasten und Beispielantworten
HTTP-Antwortcodes

Die Enterprise-APIs bieten latenzarmen, vollständig originalgetreuen, abfragebasierten Zugriff auf das Tweet-Archiv. Der einzige Unterschied zwischen den beiden APIs ist der durchsuchbare Zeitraum: entweder die vergangenen 30 Tage oder ab 2006. Zeiträume können minutengenau angegeben werden. Tweet-Daten werden in umgekehrt chronologischer Reihenfolge bereitgestellt, beginnend mit dem neuesten Tweet, der Ihrer Abfrage entspricht. Tweets sind etwa 30 Sekunden nach der Veröffentlichung über die Such-API verfügbar.

Methoden

Die Basis-URI für die Enterprise-Suche lautet https://gnip-api.x.com/search/.

Methode	Beschreibung
POST /search/:product/accounts/:account_name/:label	Ruft Tweets der letzten 30 Tage ab, die der angegebenen PowerTrack-Regel entsprechen.
POST /search/:product/accounts/:account_name/:label/counts	Ruft die Anzahl der Tweets der letzten 30 Tage ab, die der angegebenen PowerTrack-Regel entsprechen.

Dabei gilt:

:product gibt das Such-endpoint an, an das Sie Anfragen stellen, entweder 30day oder fullarchive.
:account_name ist der (Groß-/Kleinschreibung beachtende) Name, der mit Ihrem Konto verknüpft ist, wie auf console.gnip.com angezeigt.
:label ist das (Groß-/Kleinschreibung beachtende) Label, das mit Ihrem Such-endpoint verknüpft ist, wie auf console.gnip.com angezeigt.

Wenn beispielsweise das Konto TwitterDev das 30-Day-Suchprodukt mit dem Label „prod“ (Kurzform für „production“) hat, lauten die Such-endpoints:

Data-endpoint: https://gnip-api.x.com/search/30day/accounts/TwitterDev/prod.json
Counts-endpoint: https://gnip-api.x.com/search/30day/accounts/TwitterDev/prod/counts.json

Ihr vollständiger Enterprise-Such-API-endpoint wird unter https://console.gnip.com angezeigt. Unten finden Sie mehrere Beispielanfragen mit einem einfachen HTTP-Dienstprogramm namens curl. Diese Beispiele verwenden URLs mit :product, :account_name und :label. Um diese Beispiele zu verwenden, aktualisieren Sie die URLs mit Ihren Details.

Authentifizierung

Alle Anfragen an die Enterprise-Such-APIs müssen HTTP Basic Authentication verwenden, die aus der E-Mail-Adresse und dem Passwort Ihres Logins für https://console.gnip.com aufgebaut wird. Die Anmeldedaten sind bei jeder Anfrage im Authorization-Header zu übermitteln.

Anforderungs-/Antwortverhalten

Mit den Parametern fromDate und toDate können Sie jeden von der API unterstützten Zeitraum anfordern. Die 30‑Day Search API stellt Tweets aus den jüngsten 31 Tagen bereit (auch wenn sie als „30‑Day“ API bezeichnet wird, sind 31 Tage verfügbar, damit Nutzer vollständige Monatsabfragen stellen können). Die Full‑Archive Search API liefert Tweets bis zurück zum allerersten Tweet (21. März 2006). Eine einzelne Antwort ist jedoch auf den jeweils kleineren Wert aus Ihrem angegebenen maxResults oder 31 Tagen begrenzt. Wenn die übereinstimmenden data oder Ihr Zeitraum Ihre angegebenen maxResults oder 31 Tage überschreiten, erhalten Sie ein next‑Token, das Sie zur Paginierung über den restlichen von Ihnen angegebenen Zeitraum verwenden sollten. Beispielsweise: Angenommen, Sie verwenden die Full‑Archive Search und möchten alle Tweets, die Ihrer Abfrage vom 1. Januar 2017 bis zum 30. Juni 2017 entsprechen. Sie geben diesen vollständigen Sechsmonatszeitraum in Ihrer Anfrage mit den Parametern fromDate und toDate an. Die Search API antwortet mit der ersten „Seite“ von Tweets, mit der Anzahl an Tweets entsprechend Ihrem Parameter maxResults (standardmäßig 100). Unter der Annahme, dass es mehr Tweets gibt (was höchstwahrscheinlich der Fall ist), stellt die API außerdem ein next‑Token bereit, das es Ihnen ermöglicht, eine Anfrage für die nächste „Seite“ von data zu stellen. Dieser Vorgang wird wiederholt, bis die API kein next‑Token zurückgibt. Weitere Details finden Sie im nächsten Abschnitt.

Paginierung

Wenn Sie sowohl data- als auch Count-Anfragen stellen, ist es wahrscheinlich, dass mehr Daten vorliegen, als in einer einzelnen Antwort zurückgegeben werden können. In diesem Fall enthält die Antwort ein „next“-Token. Das „next“-Token wird als JSON-Attribut auf Root-Ebene bereitgestellt. Immer wenn ein „next“-Token vorhanden ist, gibt es weitere Daten abzurufen, sodass Sie weiterhin API-Anfragen stellen müssen. Hinweis: Das Verhalten des „next“-Tokens unterscheidet sich leicht bei data- und Count-Anfragen; beide werden unten beschrieben, mit Beispielantworten im Abschnitt API Reference.

Datenpaginierung

Datenanforderungen liefern meist mehr Ergebnisse, als in einer einzelnen Antwort zurückgegeben werden können. Jede Anfrage enthält einen Parameter, der die maximale Anzahl an Tweets festlegt, die pro Anfrage zurückgegeben werden. Der Parameter maxResults ist standardmäßig auf 100 gesetzt und kann auf einen Wert zwischen 10 und 500 eingestellt werden. Wenn Ihre Abfrage mehr Tweets ergibt, als der in der Anfrage verwendete Parameter „maxResults“ zulässt, enthält die Antwort ein „next“-Token (als JSON-Attribut auf Root-Ebene). Dieses „next“-Token wird in der nachfolgenden Anfrage verwendet, um den nächsten Abschnitt der passenden Tweets für diese Abfrage abzurufen (d. h. die nächste „Seite“). „Next“-Tokens werden so lange bereitgestellt, bis Sie die letzte „Seite“ der Ergebnisse für diese Abfrage erreicht haben, bei der kein „next“-Token mehr bereitgestellt wird. Um die nächste „Seite“ der Daten anzufordern, müssen Sie exakt dieselbe Abfrage wie die ursprüngliche stellen, einschließlich der Parameter query, toDate und fromDate (falls verwendet), und zusätzlich einen „next“-Anfrageparameter einschließen, der auf den Wert aus der vorherigen Antwort gesetzt ist. Dies kann entweder mit einer GET- oder POST-Anfrage erfolgen. Der „next“-Parameter muss jedoch im Fall einer GET-Anfrage URL-codiert sein. Sie können das „next“-Element aus Ihrer vorherigen Abfrage weiterhin übergeben, bis Sie alle Tweets aus dem von Ihrer Abfrage abgedeckten Zeitraum erhalten haben. Wenn Sie eine Antwort erhalten, die kein „next“-Element enthält, bedeutet dies, dass Sie die letzte Seite erreicht haben und keine weiteren Daten für die angegebene Abfrage und den angegebenen Zeitraum verfügbar sind.

Paginierung von Counts

Der „counts“-endpoint liefert Tweet-Volumina, die mit einer Abfrage entweder täglich, stündlich oder pro Minute verknüpft sind. Der „counts“-API-endpoint gibt ein mit Zeitstempeln versehenes Array von Counts für maximal eine 31-tägige Nutzlast von Counts zurück. Wenn Sie mehr als 31 Tage an Counts anfordern, erhalten Sie ein „next“-Token. Wie bei den data-„next“-Tokens müssen Sie exakt dieselbe query wie die ursprüngliche ausführen und außerdem einen „next“-Request-Parameter einschließen, der auf den Wert aus der vorherigen Antwort gesetzt ist. Über die Anforderung von mehr als 31 Tagen an Counts hinaus gibt es ein weiteres Szenario, in dem ein „next“-Token bereitgestellt wird. Bei Abfragen mit höherem Volumen kann die Erstellung der Counts so lange dauern, dass ein Antwort-Timeout ausgelöst wird. In diesem Fall erhalten Sie weniger als 31 Tage an Counts, bekommen jedoch ein „next“-Token, um weiterhin Anfragen für die gesamte Nutzlast an Counts zu stellen. Wichtig: Timeouts geben nur vollständige „Buckets“ aus – 2,5 Tage würden also in 2 vollständigen Tages-„Buckets“ resultieren.

Zusätzliche Hinweise

Wenn Sie in einer Suchanfrage fromDate oder toDate verwenden, erhalten Sie nur Ergebnisse innerhalb Ihres Zeitbereichs. Wenn Sie die letzte Gruppe von Ergebnissen innerhalb Ihres Zeitbereichs erreichen, erhalten Sie kein „next“-Token.
Das Element „next“ kann mit jedem maxResults-Wert zwischen 10 und 500 verwendet werden (Standardwert: 100). Der Wert von maxResults bestimmt, wie viele Tweets in jeder Antwort zurückgegeben werden, verhindert jedoch nicht, dass Sie letztlich alle Ergebnisse erhalten.
Das Element „next“ läuft nicht ab. Mehrere Anfragen mit derselben „next“-query erhalten dieselben Ergebnisse, unabhängig davon, wann die Anfrage gestellt wird.
Beim Paging durch Ergebnisse mit dem Parameter „next“ können an den Rändern der Abfrage Duplikate auftreten. Ihre App sollte dies tolerieren.

Data-endpoint

POST /search/:product/:label

Endpoint-Muster:

Dieses endpoint gibt data für die angegebene Abfrage und den angegebenen Zeitraum zurück. Wenn kein Zeitraum angegeben ist, werden die Zeitparameter standardmäßig auf die letzten 30 Tage gesetzt. Hinweis: Diese Funktionalität kann auch mit einer GET-Anfrage statt einer POST-Anfrage erreicht werden, indem die unten beschriebenen Parameter in die URL kodiert werden.

Parameter für Datenanfragen

Parameter	Beschreibung	Erforderlich	Beispielwert
query	Entspricht einer PowerTrack-Regel mit bis zu 2.048 Zeichen (ohne Begrenzung der Anzahl positiver und negativer Klauseln). Dieser Parameter muss ALLE Bestandteile der PowerTrack-Regel enthalten, einschließlich aller Operatoren; Teile der Regel sollten nicht auf andere Parameter der query verteilt werden. Hinweis: Nicht alle PowerTrack-Operatoren werden unterstützt. Unterstützte Operatoren sind HIER aufgeführt.	Ja	(snow OR cold OR blizzard) weather
tag	Tags können verwendet werden, um Regeln und ihre zugehörigen data in unterschiedliche logische Gruppen zu gliedern. Wenn ein Regel-Tag angegeben wird, ist es im Attribut ‘matching_rules’ enthalten. Es wird empfohlen, regelspezifische UUIDs als Regel-Tags zu vergeben und die gewünschten Zuordnungen clientseitig zu verwalten.	Nein	8HYG54ZGTU
fromDate	Der älteste UTC-Zeitstempel (bis zurück zum 21.03.2006 bei Full-Archive-Suche), ab dem die Tweets bereitgestellt werden. Der Zeitstempel hat Minutenauflösung und ist inklusive (d. h. 12:00 schließt die Minute 00 ein). Angegeben: Nur fromDate ohne toDate-Parameter liefert Ergebnisse für die query rückwärts in der Zeit von now() bis zur fromDate. Nicht angegeben: Wenn kein fromDate angegeben ist, liefert die API alle Ergebnisse für 30 Tage vor now() bzw. vor toDate (falls angegeben). Wenn weder der Parameter fromDate noch toDate verwendet wird, liefert die API alle Ergebnisse der letzten 30 Tage, beginnend zum Zeitpunkt der Anfrage, rückwärts.	Nein	201207220000
toDate	Der neueste UTC-Zeitstempel, bis zu dem die Tweets bereitgestellt werden. Der Zeitstempel hat Minutenauflösung und ist exklusiv (d. h. 11:59 schließt die 59. Minute der Stunde nicht ein). Angegeben: Nur toDate ohne fromDate-Parameter liefert die jüngsten 30 Tage an Daten vor der toDate. Nicht angegeben: Wenn kein toDate angegeben ist, liefert die API ab now() alle Ergebnisse für die query rückwärts in der Zeit bis zur fromDate. Wenn weder der Parameter fromDate noch toDate verwendet wird, liefert die API alle Ergebnisse für den gesamten 30‑Tage‑Index, beginnend zum Zeitpunkt der Anfrage, rückwärts.	Nein	201208220000
maxResults	Die maximale Anzahl der Suchergebnisse, die von einer Anfrage zurückgegeben werden. Eine Zahl zwischen 10 und dem Systemlimit (derzeit 500). Standardmäßig liefert eine Antwort 100 Ergebnisse.	Nein	500
next	Dieser Parameter wird verwendet, um die nächste „Seite“ der Ergebnisse abzurufen, wie HIER beschrieben. Der mit dem Parameter verwendete Wert wird direkt der von der API bereitgestellten Antwort entnommen und sollte nicht geändert werden.	Nein	NTcxODIyMDMyODMwMjU1MTA0

Zusätzliche Details


Verfügbarer Zeitraum	30‑Tage: letzte 31 Tage Vollarchiv: 21. März 2006 – heute
Abfrageformat	Entspricht einer PowerTrack-Regel mit bis zu 2.048 Zeichen (ohne Begrenzung der Anzahl positiver und negativer Klauseln). Hinweis: Nicht alle PowerTrack-Operatoren werden unterstützt. Eine Liste der unterstützten Operatoren finden Sie unter Available operators.
Rate Limit	Partner unterliegen Rate Limits mit Granularität in Minuten und Sekunden. Das Rate Limit pro Minute variiert je nach Partner, wie in Ihrem Vertrag festgelegt. Diese Rate Limits pro Minute sind jedoch nicht dafür gedacht, in einem einzelnen Burst ausgeschöpft zu werden. Unabhängig von Ihrem Rate Limit pro Minute sind alle Partner auf maximal 20 Anfragen pro Sekunde beschränkt, aggregiert über alle Anfragen für data und/oder counts.
Compliance	Alle über die Full-Archive Search API gelieferten data sind zum Zeitpunkt der Lieferung konform.
Verfügbarkeit in Echtzeit	Daten sind innerhalb von 30 Sekunden nach der Generierung auf der X Plattform im Index verfügbar

Beispiel-Requests und -Responses für data

Beispiel einer POST-Anfrage

Anfrageparameter in einer POST-Anfrage werden über einen JSON-formatierten Body gesendet, wie unten gezeigt.
Alle Bestandteile der PowerTrack-Regel, nach der gesucht wird (z. B. Schlüsselwörter, andere Operatoren wie bounding_box:), sollten im Parameter ‘query’ angegeben werden.
Teile der Regel nicht als separate Parameter in der Query-URL auslagern.

Hier ist ein Beispiel für einen POST-Befehl (mit cURL) zum Stellen einer initialen Datenabfrage:

    curl -X POST -u<username> "https://gnip-api.x.com/search/:product/accounts/:account_name/:label.json" -d '{"query":"from:twitterDev","maxResults":500,"fromDate":"yyyymmddhhmm","toDate":"yyyymmddhhmm"}'

Wenn die API-data-Antwort ein „next“-Token enthält, finden Sie unten eine nachfolgende Anfrage, die der ursprünglichen Anfrage entspricht, wobei der Parameter „next“ auf das bereitgestellte Token gesetzt ist:

    curl -X POST -u<username> "https://gnip-api.x.com/search/:product/accounts/:account_name/:label.json" -d '{"query":"from:twitterDev","maxResults":500,"fromDate":"yyyymmddhhmm","toDate":"yyyymmddhhmm",
    "next":"NTcxODIyMDMyODMwMjU1MTA0"}'

Beispiel einer GET-Anfrage

Anfrageparameter in einer GET-Anfrage werden mithilfe der standardmäßigen URL-Codierung in die URL codiert.
Alle Bestandteile der PowerTrack-Regel, nach der abgefragt wird (z. B. Schlüsselwörter, andere Operatoren wie bounding_box:), sollten im Parameter ‘query’ angegeben werden.
Teile der Regel nicht als separate Parameter in der Abfrage-URL auslagern.

Hier ist ein Beispiel für einen GET-Befehl (mit cURL), um eine erste data-Anfrage zu stellen:

    curl -u<username> "http://gnip-api.x.com/search/:product/accounts/:account_name/:label.json?query=from%3Atwitterdev&maxResults=500&fromDate=yyyymmddhhmm&toDate=yyyymmddhhmm"

Beispielantworten mit data

Beachten Sie, dass für Tweets, die ab dem 29. September 2022 erstellt wurden, Tweet-Objekte Bearbeitungsmetadata enthalten, die ihre Bearbeitungshistorie beschreiben. Weitere Details finden Sie auf der Grundlagen-Seite “Edit Tweets”. Nachfolgend finden Sie eine Beispielantwort auf eine data-Abfrage. In diesem Beispiel wird angenommen, dass mehr als ‚maxResults‘ Tweets verfügbar waren, sodass ein ‘next’-Token für nachfolgende Anfragen bereitgestellt wird. Wenn ‘maxResults’ oder weniger Tweets mit Ihrer Abfrage verknüpft sind, wird kein ‘next’-Token in die Antwort aufgenommen. Der Wert des ‘next’-Elements ändert sich mit jeder Abfrage und sollte als undurchsichtige Zeichenfolge behandelt werden. Das ‘next’-Element sieht im Antworttext wie folgt aus:

{
    "results":
      [
            {--Tweet 1--},
            {--Tweet 2--},
            ...
            {--Tweet 500--}
      ],
    "next":"NTcxODIyMDMyODMwMjU1MTA0",
    "requestParameters":
      {
        "maxResults":500,
        "fromDate":"201101010000",
        "toDate":"201201010000"
      }
  }

Die Antwort auf eine nachfolgende Anfrage könnte wie folgt aussehen (beachten Sie die neuen Tweets und den abweichenden „next“-Wert):

{
      "results":
      [
            {--Tweet 501--},
            {--Tweet 502--},
            ...
            {--Tweet 1000--}
      ],
      "next":"R2hCDbpBFR6eLXGwiRF1cQ",
      "requestParameters":
      {
        "maxResults":500,
        "fromDate":"201101010000",
        "toDate":"201201010000"
      }
  }

Sie können das Element ‘next’ aus Ihrer vorherigen Abfrage weiterhin übergeben, bis Sie alle Tweets aus dem von Ihrer Abfrage abgedeckten Zeitraum erhalten haben. Wenn Sie eine Antwort erhalten, die kein Element ‘next’ enthält, bedeutet dies, dass Sie die letzte Seite erreicht haben und in Ihrem Zeitraum keine zusätzlichen data verfügbar sind.

Counts-Endpoint

/search/:stream/counts

Endpoint-Muster:

/search/fullarchive/accounts/:account_name/:label/counts.json Dieses endpoint liefert Zählwerte (Datenvolumina) für die angegebene Abfrage. Wenn kein Zeitraum angegeben ist, werden die Zeitparameter standardmäßig auf die letzten 30 Tage gesetzt. Die Datenvolumina werden als zeitgestempeltes Array entweder täglich, stündlich (Standard) oder minütlich zurückgegeben. Hinweis: Diese Funktionalität kann auch mit einer GET-Anfrage statt mit einer POST-Anfrage genutzt werden, indem die unten beschriebenen Parameter in die URL kodiert werden.

Parameter für Counts-Anfragen

Parameters	Description	Required	Sample Value
query	Entspricht einer PowerTrack-Regel mit bis zu 2.048 Zeichen (ohne Begrenzung der Anzahl positiver und negativer Klauseln). Dieser Parameter sollte ALLE Teile der PowerTrack-Regel enthalten, einschließlich aller Operatoren. Teile der Regel sollten nicht in andere Parameter der query aufgeteilt werden. Hinweis: Nicht alle PowerTrack-Operatoren werden unterstützt. Eine Liste der unterstützten Operatoren finden Sie unter Available operators.	Yes	(snow OR cold OR blizzard) weather
fromDate	Der älteste UTC-Zeitstempel (bis zurück zum 21.03.2006), ab dem Tweets bereitgestellt werden. Der Zeitstempel hat Minutenauflösung und ist inklusiv (d. h. 12:00 schließt die 00. Minute ein). Angegeben: Wird nur fromDate ohne toDate-Parameter verwendet, liefert die API Counts (Datenvolumen) für die Abfrage rückwärts von jetzt bis zum fromDate. Ist der fromDate älter als 31 Tage ab jetzt, erhalten Sie ein next-Token, um Ihre Anfrage zu paginieren. Nicht angegeben: Wenn kein fromDate angegeben ist, liefert die API Counts (Datenvolumen) für die 30 Tage vor jetzt oder bis zum toDate (falls angegeben). Wenn weder der Parameter fromDate noch toDate verwendet wird, liefert die API Counts (Datenvolumen) für die letzten 30 Tage, beginnend zum Zeitpunkt der Anfrage, rückwärts.	No	201207220000
toDate	Der jüngste, aktuellste UTC-Zeitstempel, bis zu dem Tweets bereitgestellt werden. Der Zeitstempel hat Minutenauflösung und ist nicht inklusiv (d. h. 11:59 schließt die 59. Minute der Stunde nicht ein). Angegeben: Nur toDate ohne fromDate-Parameter liefert die aktuellsten Counts (Datenvolumen) für die 30 Tage vor dem toDate. Nicht angegeben: Wenn kein toDate angegeben ist, liefert die API Counts (Datenvolumen) für die Abfrage rückwärts bis zum fromDate. Ist der fromDate mehr als 31 Tage ab jetzt, erhalten Sie ein next-Token, um Ihre Anfrage zu paginieren. Wenn weder der Parameter fromDate noch toDate verwendet wird, liefert die API Counts (Datenvolumen) für die letzten 30 Tage, beginnend zum Zeitpunkt der Anfrage, rückwärts.	No	201208220000
bucket	Die Zeiteinheit, für die Count-Daten bereitgestellt werden. Count-Daten können für jeden Tag, jede Stunde oder jede Minute im angeforderten Zeitraum zurückgegeben werden. Standardmäßig werden stündliche Counts bereitgestellt. Optionen: ‘day’, ‘hour’, ‘minute’	No	minute
next	Dieser Parameter wird verwendet, um die nächste „Seite“ von Ergebnissen abzurufen, wie HIER beschrieben. Der mit dem Parameter verwendete Wert wird direkt aus der von der API bereitgestellten Antwort übernommen und sollte nicht geändert werden.	No	NTcxODIyMDMyODMwMjU1MTA0

Zusätzliche Details


Verfügbarer Zeitraum	30‑Tage: letzte 31 Tage Full‑Archive: 21. März 2006 – heute
Abfrageformat	Entspricht einer PowerTrack‑Regel mit bis zu 2.048 Zeichen. Hinweis: Nicht alle PowerTrack‑Operatoren werden unterstützt. Eine Liste der unterstützten Operatoren finden Sie unter Available operators.
Rate Limit	Partner unterliegen Rate Limits mit Granularität auf Minuten‑ und Sekundenebene. Das Rate Limit pro Minute variiert je nach Partner, wie in Ihrem Vertrag festgelegt. Diese Rate Limits pro Minute sind jedoch nicht dafür gedacht, in einem einzelnen Burst ausgeschöpft zu werden. Unabhängig von Ihrem Rate Limit pro Minute sind alle Partner auf maximal 20 Requests pro Sekunde beschränkt, aggregiert über alle Requests für data und/oder Counts.
Zählgenauigkeit	Die über dieses endpoint gelieferten Counts spiegeln die Anzahl der aufgetretenen Tweets wider und berücksichtigen keine späteren Compliance‑Ereignisse (Löschungen, Scrub Geos). Einige gezählte Tweets sind möglicherweise nicht über das data endpoint verfügbar, da Nutzer Compliance‑Maßnahmen ergriffen haben.

Beispiele für Zählanfragen und -antworten

Beispiel einer POST-Anfrage

Anfrageparameter in einer POST-Anfrage werden über einen JSON-formatierten Body gesendet, wie unten gezeigt.
Alle Bestandteile der PowerTrack-Regel, nach der gesucht wird (z. B. Schlüsselwörter, andere Operatoren wie bounding_box:), gehören in den Parameter ‘query’.
Teilen Sie Bestandteile der Regel nicht als separate Parameter in der query-URL auf.

Hier ist ein Beispiel für einen POST-Befehl (mit cURL), um eine erste Zählabfrage zu stellen:

    curl -X POST -u<username> "https://gnip-api.x.com/search/:product/accounts/:account_name/:label/counts.json" -d '{"query":"TwitterDev","fromDate":"yyyymmddhhmm","toDate":"yyyymmddhhmm","bucket":"day"}'

Wenn die Antwort der API auf Counts ein „next“-Token enthält, folgt unten eine weitere Anfrage: dieselbe wie die ursprüngliche, jedoch mit dem Parameter „next“, der auf das bereitgestellte Token gesetzt ist:

    curl -X POST -u<username> "https://gnip-api.x.com/search/:product/accounts/:account_name/:label/counts.json" -d '{"query":"TwitterDev","fromDate":"yyyymmddhhmm","toDate":"yyyymmddhhmm","bucket":"day",
    "next":"YUcxO87yMDMyODMwMjU1MTA0"}'

Beispiel-GET-Anfrage

Anfrageparameter in einer GET-Anfrage werden mithilfe der standardmäßigen URL-Codierung in die URL eingebettet
Alle Teile der PowerTrack-Regel, nach denen gesucht wird (z. B. Schlüsselwörter, andere Operatoren wie bounding_box:), sollten im Parameter ‘query’ angegeben werden
Teile der Regel nicht als separate Parameter in der Query-URL aufsplitten

Hier ist ein Beispiel für einen GET-Befehl (mithilfe von cURL), um eine initiale Zählabfrage zu stellen:

    curl -u<username> "http://gnip-api.x.com/search/fullarchive/accounts/:account_name/:label/counts.json?query=TwitterDev&bucket=day&fromDate=yyyymmddhhmm&toDate=yyyymmddhhmm"

Beispielantworten für Counts

Unten finden Sie eine Beispielantwort auf eine Counts-Abfrage (Datenvolumen). Diese Beispielantwort enthält ein „next“-Token. Das bedeutet, dass die Counts-Anfrage einen Zeitraum von mehr als 31 Tagen umfasste oder dass die übermittelte Abfrage ein so großes Volumen hatte, dass eine Teilantwort zurückgegeben wurde. Der Wert des „next“-Elements ändert sich mit jeder Abfrage und sollte als opake Zeichenfolge behandelt werden. Das „next“-Element sieht im Antworttext wie folgt aus:

    {
      "results": [
        { "timePeriod": "201101010000", "count": 32 },
        { "timePeriod": "201101020000", "count": 45 },
        { "timePeriod": "201101030000", "count": 57 },
        { "timePeriod": "201101040000", "count": 123 },
        { "timePeriod": "201101050000", "count": 134 },
        { "timePeriod": "201101060000", "count": 120 },
        { "timePeriod": "201101070000", "count": 43 },
        { "timePeriod": "201101080000", "count": 65 },
        { "timePeriod": "201101090000", "count": 85 },
        { "timePeriod": "201101100000", "count": 32 },
        { "timePeriod": "201101110000", "count": 23 },
        { "timePeriod": "201101120000", "count": 85 },
        { "timePeriod": "201101130000", "count": 32 },
        { "timePeriod": "201101140000", "count": 95 },
        { "timePeriod": "201101150000", "count": 109 },
        { "timePeriod": "201101160000", "count": 34 },
        { "timePeriod": "201101170000", "count": 74 },
        { "timePeriod": "201101180000", "count": 24 },
        { "timePeriod": "201101190000", "count": 90 },
        { "timePeriod": "201101200000", "count": 85 },
        { "timePeriod": "201101210000", "count": 93 },
        { "timePeriod": "201101220000", "count": 48 },
        { "timePeriod": "201101230000", "count": 37 },
        { "timePeriod": "201101240000", "count": 54 },
        { "timePeriod": "201101250000", "count": 52 },
        { "timePeriod": "201101260000", "count": 84 },
        { "timePeriod": "201101270000", "count": 120 },
        { "timePeriod": "201101280000", "count": 34 },
        { "timePeriod": "201101290000", "count": 83 },
        { "timePeriod": "201101300000", "count": 23 },
        { "timePeriod": "201101310000", "count": 12 }
       ],
      "totalCount":2027,
      "next":"NTcxODIyMDMyODMwMjU1MTA0",
      "requestParameters":
        {
          "bucket":"day",
          "fromDate":"201101010000",
          "toDate":"201201010000"
        }
    }

Die Antwort auf eine nachfolgende Anfrage könnte wie folgt aussehen (beachten Sie die neue Zählungs-Zeitleiste und den anderen „next“-Wert):

    {
      "results": [
        { "timePeriod": "201102010000", "count": 45 },
        { "timePeriod": "201102020000", "count": 76 },
         ....
        { "timePeriod": "201103030000", "count": 13 }
     ],
     "totalCount":3288,
     "next":"WE79fnakFanyMDMyODMwMjU1MTA0",
     "requestParameters":
        {
          "bucket":"day",
          "fromDate":"201101010000",
          "toDate":"201201010000"
        }
    }

Sie können das Element ‘next’ aus Ihrer vorherigen query weiterhin übergeben, bis Sie alle Zählwerte für den query-Zeitraum erhalten haben. Wenn Sie eine Antwort erhalten, die kein ‘next’-Element enthält, haben Sie die letzte Seite erreicht und in Ihrem Zeitraum sind keine weiteren Zählwerte verfügbar.

HTTP-Antwortcodes

Status	Text	Beschreibung
200	OK	Die Anfrage war erfolgreich. Die JSON-Antwort sieht etwa wie folgt aus:
400	Bad Request	Diese Antwort tritt in der Regel auf, wenn die Anfrage ungültiges JSON enthält oder gar keinen JSON-Payload sendet.
401	Unauthorized	Die HTTP-Authentifizierung ist aufgrund ungültiger Anmeldedaten fehlgeschlagen. Melden Sie sich mit Ihren Anmeldedaten bei console.gnip.com an, um sicherzustellen, dass Sie sie in Ihrer Anfrage korrekt verwenden.
404	Not Found	Die Ressource wurde unter der URL, an die die Anfrage gesendet wurde, nicht gefunden, vermutlich weil eine falsche URL verwendet wurde.
422	Unprocessable Entity	Wird aufgrund ungültiger Parameter in der Abfrage zurückgegeben — z. B. ungültige PowerTrack-Regeln.
429	Unknown Code	Ihre App hat das Limit für Verbindungsanfragen überschritten. Die entsprechende JSON-Nachricht sieht in etwa wie folgt aus:
500	Internal Server Error	Es ist ein Fehler auf der Serverseite aufgetreten. Wiederholen Sie Ihre Anfrage mit exponentiellem Backoff.
502	Proxy Error	Es ist ein Fehler auf der Serverseite aufgetreten. Wiederholen Sie Ihre Anfrage mit exponentiellem Backoff.
503	Service Unavailable	Es ist ein Fehler auf der Serverseite aufgetreten. Wiederholen Sie Ihre Anfrage mit exponentiellem Backoff.

Übersicht

Posts

Nutzer

Direktnachrichten

Likes

Lists

Spaces

Communities

Community Notes

Trends

Medien

Verwendung

Stream-Verbindungen

Compliance

Enterprise v2

Like-Streams

GNIP 2.0

​Überblick

​Anfragetypen

​Suchanfragen (data)

​Counts-Anfragen (Post-Zählung)

​Verfügbare Operatoren

​Datenverfügbarkeit / wichtige Daten

​Datenaktualisierungen und Änderbarkeit

​Single- vs. Multithreaded-Anfragen

​Wiederholungslogik

​Schnellstart

​Erste Schritte mit Enterprise Search Posts: 30-Day API

​Zugriff auf das data-endpoint

​Antwort-Payload des data-endpoints

​Zugriff auf das Counts-endpoint

​Antwortnutzlast des Counts-endpoints

Verweise

​Einstieg in die Enterprise Search Posts: Full-Archive API

​Zugriff auf das data endpoint

Antwort-Payload des data-endpoints

​Zugriff auf das counts-endpoint

​Antwort-Payload des Counts-endpoints

Verwandte Artikel

​Leitfäden

​Erstellen von Suchanfragen

​Enterprise-Operatoren

​Produktübersicht

​Metadaten-Zeitlinien

​2006

​2007

​2009

​2010

​2011

​2014

​2015

​2016

​2017

​2022

​2022

​Tipps zum Filtern

​X-Profile

​Originale Posts und Retweets

​Sprachklassifizierungen von Posts

​Geo-Referenzierung von Posts

​Geteilte Links und Medien

​Häufig gestellte Fragen (FAQ)

​Allgemeine Fragen zur Search-Post-API

​Leitfaden zur Fehlerbehebung

​API-Referenz

​Enterprise-Such-APIs

​Methoden

​Authentifizierung

​Anforderungs-/Antwortverhalten

​Paginierung

Datenpaginierung

Paginierung von Counts

Zusätzliche Hinweise

​Data-endpoint

POST /search/:product/:label

Endpoint-Muster:

Parameter für Datenanfragen

Zusätzliche Details

Beispiel-Requests und -Responses für data

Beispiel einer POST-Anfrage

Überblick

Anfragetypen

Suchanfragen (data)

Counts-Anfragen (Post-Zählung)

Verfügbare Operatoren

Datenverfügbarkeit / wichtige Daten

Datenaktualisierungen und Änderbarkeit

Single- vs. Multithreaded-Anfragen

Wiederholungslogik

Schnellstart

Erste Schritte mit Enterprise Search Posts: 30-Day API

Zugriff auf das data-endpoint

Antwort-Payload des data-endpoints

Zugriff auf das Counts-endpoint

Antwortnutzlast des Counts-endpoints

Einstieg in die Enterprise Search Posts: Full-Archive API

Zugriff auf das data endpoint

Zugriff auf das counts-endpoint

Antwort-Payload des Counts-endpoints

Leitfäden

Erstellen von Suchanfragen

Enterprise-Operatoren

Produktübersicht

Metadaten-Zeitlinien

2006

2007

2009

2010

2011

2014

2015

2016

2017

2022

2022

Tipps zum Filtern

X-Profile

Originale Posts und Retweets

Sprachklassifizierungen von Posts

Geo-Referenzierung von Posts

Geteilte Links und Medien

Häufig gestellte Fragen (FAQ)

Allgemeine Fragen zur Search-Post-API

Leitfaden zur Fehlerbehebung

API-Referenz

Enterprise-Such-APIs

Methoden

Authentifizierung

Anforderungs-/Antwortverhalten

Paginierung

Data-endpoint

Counts-Endpoint

Beispielantworten für Counts

HTTP-Antwortcodes