API de recherche : Enterprise

Veuillez noter :

Nous avons publié une nouvelle version de la recherche de Posts et du comptage de Posts dans la X API v2. Nous vous encourageons à consulter les nouveautés de la X API v2.

Ces endpoints ont été mis à jour pour inclure les metadata d’édition de Post. Pour en savoir plus, consultez la page des notions fondamentales “Modifier des Posts”. 

​

Aperçu

Enterprise

Les API Enterprise sont disponibles uniquement dans le cadre de nos niveaux d’accès gérés. Pour utiliser ces API, vous devez d’abord configurer un compte avec notre équipe commerciale Enterprise. Pour en savoir plus, voir ICI.

Vous pouvez consulter toutes les offres de recherche de Posts de la X API ICI.

Il existe deux API de recherche Enterprise :

1. L’API de recherche sur 30 jours fournit des données des 30 derniers jours.
2. L’API de recherche sur l’archive complète offre un accès complet et instantané à l’intégralité du corpus de données X, jusqu’au premier Post en mars 2006.

Ces API RESTful prennent en charge une seule query allant jusqu’à 2 048 caractères par requête. Les queries sont rédigées avec la syntaxe de règles PowerTrack — voir Règles et filtrage pour plus de détails. Les utilisateurs peuvent spécifier n’importe quelle période, avec une granularité à la minute. Cependant, les réponses seront limitées au plus petit de votre maxResults spécifié OU 31 jours et incluront un jeton next pour paginer vers l’ensemble de résultats suivant. Si les paramètres temporels ne sont pas spécifiés, l’API renverra les data correspondantes des 30 jours les plus récents.

Les API de recherche Enterprise offrent un accès à faible latence, haute fidélité et basé sur des queries à l’archive des Posts avec une granularité à la minute. Les data des Posts sont renvoyées par ordre antéchronologique, en commençant par le Post le plus récent correspondant à votre query. Les Posts sont disponibles via l’API de recherche environ 30 secondes après leur publication.

Ces endpoints de recherche fournissent des metadata d’édition de Post. Tous les objets pour les Posts créés depuis le 29 septembre 2022 incluent des metadata d’édition de Post, même si le Post n’a jamais été modifié. Chaque fois qu’un Post est modifié, un nouvel ID de Post est créé. L’historique des modifications d’un Post est documenté par un tableau d’ID de Post, en commençant par l’ID d’origine.

Ces endpoints renverront toujours la modification la plus récente, ainsi que tout historique des modifications. Tout Post collecté après sa fenêtre de modification de 30 minutes représentera sa version finale. Pour en savoir plus sur les metadata d’édition de Post, consultez la page Principes de base des Posts modifiés.

Les requêtes incluent un paramètre maxResults qui spécifie le nombre maximal de Posts à renvoyer par réponse de l’API. Si davantage de Posts sont associés à la query que ce nombre maximal de résultats par réponse, un jeton next est inclus dans la réponse. Ces jetons next sont utilisés dans les requêtes ultérieures pour parcourir l’ensemble des Posts associés à la query.

Ces API de recherche Enterprise fournissent un endpoint counts qui permet aux utilisateurs de demander le volume de data associé à leur query. 

​

Types de requêtes

Les API de recherche Enterprise prennent en charge deux types de requêtes :

​

Requêtes de recherche (data)

Les requêtes de recherche vers les API de recherche Enterprise vous permettent de récupérer jusqu’à 500 résultats par réponse pour une période donnée, avec la possibilité de paginer pour obtenir des data supplémentaires. En utilisant le paramètre maxResults, vous pouvez spécifier des tailles de page plus petites pour les cas d’utilisation d’affichage (permettant à vos utilisateurs de demander plus de résultats si nécessaire) ou des tailles de page plus grandes (jusqu’à 500) pour des extractions de data plus volumineuses. Les data sont renvoyées dans l’ordre antéchronologique et sont conformes au moment de leur livraison.

​

Requêtes de comptage (nombre de Posts)

Les requêtes de comptage permettent de récupérer des décomptes d’activité historiques, qui reflètent le nombre d’activités correspondant à une query donnée sur la période demandée. La réponse vous fournit essentiellement un histogramme des décomptes, regroupés par jour, heure ou minute (le regroupement par défaut est heure). Il est important de noter que les résultats de comptage ne reflètent pas toujours les événements de conformité (p. ex., suppressions de Posts) qui se produisent bien après (7+ jours) la publication d’un Post ; il est donc attendu que la métrique de comptage ne corresponde pas toujours à celle d’une requête data pour la même query.

Note de facturation : chaque requête – y compris les requêtes de pagination – effectuée sur les endpoints data et de comptage est comptabilisée comme une requête facturée. Par conséquent, s’il existe plusieurs pages de résultats pour une seule query, parcourir les X pages de résultats équivaut à X requêtes pour la facturation.

​

Opérateurs disponibles

Les API de recherche Enterprise prennent en charge des règles allant jusqu’à 2 048 caractères. Les API de recherche Enterprise prennent en charge les opérateurs listés ci-dessous. Pour des descriptions détaillées, voir ICI.

Correspondance sur le contenu des Posts :	Correspondance sur les comptes d’intérêt :	Attributs de Post :	Opérateurs géospatiaux :
* mot-clé * « expression entre guillemets » * « 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 (opérateur de négation uniquement)	* 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:

Notes : N’imbriquez pas d’opérateurs (« #cats ») ; avec les API de recherche, cela sera interprété comme cats. L’opérateur « lang: », ainsi que tous les opérateurs « is: » et « has: », ne peuvent pas être utilisés seuls et doivent être combinés avec une autre clause (par ex. @XDevelopers has:links).

Les API de recherche utilisent un ensemble limité d’opérateurs en raison de la tokenisation et de la correspondance. Les API Enterprise en temps réel et les API historiques par lots fournissent des opérateurs supplémentaires. Voir ICI pour plus de détails.

Pour plus d’informations, veuillez consulter le guide Prise en main des opérateurs.

​

Disponibilité des données / date importante

Lors de l’utilisation de l’API de recherche Full-Archive, gardez à l’esprit que la plateforme X n’a cessé d’évoluer depuis 2006. Au fur et à mesure que de nouvelles fonctionnalités ont été ajoutées, de nouvelles metadata ont été ajoutées aux objets JSON sous-jacents. Pour cette raison, il est important de comprendre à quel moment des attributs de Post ont été ajoutés et sur lesquels les opérateurs de recherche s’appuient. Vous trouverez ci-dessous quelques-unes des dates « de naissance » fondamentales de groupes importants de metadata. Pour en savoir plus sur le moment où des attributs de Post ont été introduits pour la première fois, consultez ce guide.

• Premier Post : 21/03/2006
• Premiers Retweets natifs : 06/11/2009
• Premier Post géolocalisé : 19/11/2009
• URL indexées pour la première fois pour le filtrage : 27/08/2011
• Metadata d’expansion d’URL enrichies (titres et descriptions de sites web) : 01/12/2014
• Metadata d’enrichissement et de filtrage de Profil Geo : 17/02/2015

​

Mises à jour des données et mutabilité

Avec les API de recherche Enterprise, certaines données d’un Post sont mutables, c’est‑à‑dire qu’elles peuvent être mises à jour ou modifiées après l’archivage initial.

Ces données mutables se répartissent en deux catégories :

• Métadonnées de l’objet utilisateur :
  • @handle de l’utilisateur (l’id numérique ne change jamais)
  • Description de la bio
  • Compteurs : statuses, followers, friends, favorites, lists
  • Localisation du profil
  • Autres détails tels que le fuseau horaire et la langue
• Statistiques du Post — c’est‑à‑dire tout ce qui peut être modifié sur la plateforme par des actions des utilisateurs (exemples ci‑dessous) :
  • Nombre de favorites
  • Nombre de Retweets

Dans la plupart de ces cas, les API de recherche renvoient les données telles qu’elles existent sur la plateforme au moment de la query, plutôt qu’au moment de la création du Post. Toutefois, pour des requêtes utilisant certains opérateurs (p. ex. from, to, @, is:verified), ce n’est pas forcément le cas. Les données sont mises à jour régulièrement dans notre index, avec une fréquence accrue pour les périodes les plus récentes. Par conséquent, dans certains cas, les données renvoyées peuvent ne pas correspondre exactement aux données actuelles affichées sur X.com, mais correspondent aux données au moment de leur dernier indexage.

Notez que ce problème d’incohérence ne s’applique qu’aux requêtes dont l’opérateur porte sur des données mutables. Par exemple, pour filtrer par nom d’utilisateur, la meilleure solution consiste à utiliser des id numériques d’utilisateur plutôt que des @handles pour ces requêtes.

​

Requêtes mono‑thread vs multi‑thread

Chaque client dispose d’une limite de taux définie pour son endpoint de recherche. Par défaut, la limite de taux par minute pour la recherche Full‑Archive est de 120 requêtes par minute, soit une moyenne de 2 requêtes par seconde (QPS). Cette moyenne de QPS signifie que, en théorie, 2 requêtes peuvent être envoyées à l’API chaque seconde. Étant donné la pagination du produit, si une query d’un an a un million de Posts associés, répartis uniformément sur l’année, plus de 2 000 requêtes seraient nécessaires (en supposant un ‘maxResults’ de 500) pour recevoir toutes les data. En supposant qu’il faille deux secondes par réponse, cela représente 4 000 secondes (ou un peu plus d’une heure) pour extraire toutes ces data de manière sérielle/séquentielle via un seul thread (1 requête par seconde en utilisant le jeton “next” de la réponse précédente). Pas mal !

Considérez maintenant la situation où douze threads parallèles sont utilisés pour recevoir des data. En supposant une répartition uniforme du million de Posts sur la période d’un an, vous pourriez diviser les requêtes en douze threads parallèles (multi‑thread) et exploiter davantage la limite de taux par seconde pour le “job” unique. En d’autres termes, vous pourriez exécuter un thread par mois qui vous intéresse et, ce faisant, les data pourraient être récupérées 12x plus rapidement (ou ~6 minutes).

Cet exemple multi‑thread s’applique tout aussi bien à l’endpoint de comptage. Par exemple, si vous souhaitez recevoir les décomptes de Posts pour une période de deux ans, vous pourriez effectuer une requête mono‑thread et remonter page par page dans les comptages par tranches de 31 jours. En supposant qu’il faille 2 secondes par réponse, il faudrait environ 48 secondes pour effectuer les 24 requêtes API et récupérer l’ensemble des comptages. Cependant, vous avez également la possibilité d’effectuer plusieurs requêtes d’un mois à la fois. En effectuant 12 requêtes par seconde, l’ensemble des comptages pourrait être récupéré en environ 2 secondes.

​

Logique de nouvelle tentative

Si vous rencontrez une erreur 503 avec les API de recherche Enterprise, il s’agit probablement d’une erreur transitoire qui peut être résolue en réessayant la requête peu de temps après.

Si la requête échoue 4 fois de suite et que vous avez attendu au moins 10 minutes entre chaque échec, suivez les étapes de dépannage suivantes :

• Réessayez la requête après avoir réduit la période qu’elle couvre. Si nécessaire, répétez jusqu’à une fenêtre de 6 heures.
• Si vous combinez un grand nombre de termes avec OR, scindez-les en règles distinctes et réessayez chacune séparément.
• Si votre règle contient un grand nombre d’exclusions, réduisez le nombre de termes négatifs dans la règle et réessayez.

​

Bien démarrer

​

Prise en main de enterprise Search Posts : API 30-Day

L’API enterprise Search Posts : 30-Day fournit des Posts publiés au cours des 30 derniers jours. Les Posts sont identifiés et renvoyés en fonction du paramètre query que vous spécifiez dans votre requête. Une query est une règle qui définit ce que le Post retourné doit contenir. Dans ce tutoriel, nous rechercherons des Posts en anglais provenant du compte X @XDevelopers.

Les Posts renvoyés dans votre charge utile peuvent être au format data, qui vous fournit la charge utile complète du Post, ou au format counts, qui vous donne des données de comptage numériques des Posts correspondants. Nous utiliserons cURL pour effectuer des requêtes vers les endpoints data et counts.

Vous aurez besoin des éléments suivants :

• [Un compte Enterprise]https://developer.x.com/en/products/x-api/enterprise
• Votre nom d’utilisateur, votre mot de passe et le nom de votre compte
• Le label associé à votre endpoint de recherche, tel qu’affiché sur console.gnip.com

​

Accéder à l’endpoint de données

L’endpoint de données nous fournira la charge utile complète du Post pour les Posts correspondants. Nous utiliserons les opérateurs from: et lang: pour trouver des Posts publiés par @XDevelopers en anglais. Pour plus d’opérateurs, cliquez ici.

cURL

cURL est un outil en ligne de commande permettant de récupérer ou d’envoyer des fichiers à l’aide de la syntaxe d’URL.

Copiez la requête cURL suivante dans votre terminal après avoir modifié les éléments suivants :

• Nom d’utilisateur <USERNAME> p. ex. [e-mail]

• Nom du compte <ACCOUNT-NAME> p. ex. john-doe

• Label <LABEL> p. ex. prod

• fromDate et toDate p. ex. "fromDate":"201811010000", "toDate":"201811122359"

Après l’envoi de votre requête, il vous sera demandé de saisir votre mot de passe.

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>"}'

​

Charge utile de la réponse de l’endpoint de données

La charge utile renvoyée par votre requête API sera au format JSON, comme indiqué ci-dessous.

{
	"results": [
		{
			"created_at": "Fri Nov 02 17:18:31 +0000 2018",
			"id": 1058408022936977409,
			"id_str": "1058408022936977409",
			"text": "RT @harmophone: \"Le crowdsourcing innovant que permet la collaboration Tagboard, Twitter et TEGNA fait émerger des conv…",
			"source": "<a href=\"http:\/\/twitter.com\" rel=\"nofollow\">Client Web Twitter<\/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": "Votre source officielle pour les actualités, mises à jour et événements de la plateforme Twitter. Besoin d'aide technique ? Visitez 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": "\"Le crowdsourcing innovant que permet la collaboration Tagboard, Twitter et TEGNA fait émerger des conv… https:\/\/t.co\/w46U5TRTzQ",
				"source": "<a href=\"http:\/\/twitter.com\" rel=\"nofollow\">Client Web Twitter<\/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": "VP Senior Produit chez @Tagboard. Ai travaillé sur la Data, le business et le produit chez @Klout & pour @LithiumTech ; membre du conseil @BBI ; conseiller @Insightpool. Le pire dessinateur de tableaux blancs au monde.",
					"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": "\"Le crowdsourcing innovant que permet la collaboration Tagboard, Twitter et TEGNA fait émerger des conversations localement pertinentes en temps réel et permet aux électeurs de poser des questions pendant les débats,\" -- @adamostrow, @TEGNA\nEn savoir plus : 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 et Tagboard collaborent pour apporter le meilleur contenu électoral aux médias avec Tagboard…",
									"description": "Par Tyler Singletary, Responsable Produit, 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"
	}
}

​

Accéder à l’endpoint de comptage

Avec l’endpoint de comptage, nous allons récupérer le nombre de Posts publiés depuis le compte @XDevelopers en anglais, regroupés par day.

cURL

cURL est un outil en ligne de commande qui permet de récupérer ou d’envoyer des fichiers en utilisant la syntaxe des URL.

Copiez la requête cURL suivante dans votre terminal après avoir apporté les modifications suivantes :

• Nom d’utilisateur <USERNAME> (p. ex. : [e-mail])

• Nom du compte <ACCOUNT-NAME> (p. ex. : john-doe)

• Label <LABEL> (p. ex. : prod)

• fromDate et toDate (p. ex. : "fromDate":"201811010000", "toDate":"201811122359")

Après l’envoi de votre requête, votre mot de passe vous sera demandé.

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"}'

​

Charge utile de la réponse de l’endpoint Counts

La charge utile renvoyée par votre requête à l’API sera au format JSON, comme illustré ci-dessous.

{
	"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"
	}
}

Beau travail ! Vous avez maintenant réussi à accéder à l’API Enterprise Search Posts: 30-Day.

Articles de référence

• Introduction aux Objets Post
• Opérateurs de recherche
• Objets Post et payloads

​

Prise en main de l’API Enterprise Search Posts : Full-Archive

L’API Enterprise Search Posts : Full-Archive vous donne accès à des Posts depuis le tout premier publié en 2006. Les Posts sont identifiés et renvoyés en fonction de la query que vous spécifiez dans votre requête. Une query est une règle dans laquelle vous définissez ce que le Post renvoyé doit contenir. Dans ce tutoriel, nous rechercherons des Posts provenant du compte X @XDevelopers en anglais.

Les Posts que vous recevez dans votre charge utile peuvent être au format data, qui fournit le contenu complet du Post, ou au format counts, qui fournit les données de comptage numériques des Posts correspondants. Nous utiliserons cURL pour effectuer des requêtes vers les endpoints data et counts.

Vous aurez besoin de ce qui suit :

• [Un compte Enterprise]https://developer.x.com/en/products/x-api/enterprise
• Votre nom d’utilisateur, votre mot de passe et le nom du compte
• Le libellé associé à votre endpoint de recherche, tel qu’affiché sur console.gnip.com

​

Accéder à l’endpoint de données

L’endpoint de données nous fournira la charge utile complète d’un Post pour les Posts correspondants. Nous utiliserons les opérateurs from: et lang: pour trouver des Posts provenant de @XDevelopers en anglais. Pour plus d’opérateurs cliquez ici.

• cURL
• Exemple cURL

cURL

cURL est un outil en ligne de commande permettant de récupérer ou d’envoyer des fichiers à l’aide de la syntaxe d’URL.

Copiez la requête cURL suivante dans votre terminal après avoir modifié les éléments suivants :

• Nom d’utilisateur <USERNAME> p. ex. [e-mail]

• Nom du compte <ACCOUNT-NAME> p. ex. john-doe

• Label <LABEL> p. ex. prod

• fromDate et toDate p. ex. "fromDate":"201802010000", "toDate":"201802282359"

Après l’envoi de votre requête, il vous sera demandé de saisir votre mot de passe.

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>"}'

Charge utile de la réponse de l’endpoint de données

La charge utile renvoyée par votre requête à l’API sera au format JSON, comme illustré ci-dessous.

{
	"results": [
		{
			"created_at": "Fri Nov 02 17:18:31 +0000 2018",
			"id": 1058408022936977409,
			"id_str": "1058408022936977409",
			"text": "RT @harmophone: \"Le crowdsourcing innovant que permet la collaboration Tagboard, Twitter et TEGNA fait émerger des conv…",
			"source": "<a href=\"http:\/\/twitter.com\" rel=\"nofollow\">Client Web Twitter<\/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": "Votre source officielle pour les actualités, mises à jour et événements de la plateforme Twitter. Besoin d'aide technique ? Visitez 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": "\"Le crowdsourcing innovant que permet la collaboration Tagboard, Twitter et TEGNA fait émerger des conv… https:\/\/t.co\/w46U5TRTzQ",
				"source": "<a href=\"http:\/\/twitter.com\" rel=\"nofollow\">Client Web Twitter<\/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": "VP Senior Produit chez @Tagboard. Ai travaillé sur la Data, le business et le produit chez @Klout & pour @LithiumTech ; membre du conseil @BBI ; conseiller @Insightpool. Le pire dessinateur de tableaux blancs au monde.",
					"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": "\"Le crowdsourcing innovant que permet la collaboration Tagboard, Twitter et TEGNA fait émerger des conversations localement pertinentes en temps réel et permet aux électeurs de poser des questions pendant les débats,\" -- @adamostrow, @TEGNA\nEn savoir plus : 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 et Tagboard collaborent pour apporter le meilleur contenu électoral aux médias avec Tagboard…",
									"description": "Par Tyler Singletary, Responsable Produit, 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"
	}
}

​

Accéder à l’endpoint de comptage

Avec l’endpoint de comptage, nous allons récupérer le nombre de Posts en anglais provenant du compte @XDevelopers, regroupés par day.

cURL

cURL est un outil en ligne de commande permettant d’obtenir ou d’envoyer des fichiers en utilisant la syntaxe des URL.

Copiez la requête cURL suivante dans votre terminal après avoir modifié les éléments suivants :

• Nom d’utilisateur <USERNAME> p. ex. [e-mail]

• Nom du compte <ACCOUNT-NAME> p. ex. john-doe

• Label <LABEL> p. ex. prod

• fromDate et toDate p. ex. "fromDate":"201802010000", "toDate":"201802282359"

Après l’envoi de votre requête, votre mot de passe vous sera demandé.

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"}'

​

Charge utile de la réponse de l’endpoint Counts

La charge utile renvoyée par votre requête API sera au format JSON, comme illustré ci-dessous.

{
	"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"
	}
}

Excellent travail ! Vous avez maintenant réussi à accéder à l’API Enterprise Search Posts : Full-Archive.

Articles de référence

• Introduction aux Objets Post
• Opérateurs de recherche
• Objets Post et payloads

​

Guides

​

Concevoir des requêtes de recherche

​

Opérateurs Enterprise

Vous trouverez ci-dessous la liste de tous les opérateurs pris en charge dans les API de recherche Enterprise de X :

• API de recherche Enterprise sur 30 jours
• API de recherche Enterprise de l’intégralité des archives

Pour une comparaison côte à côte des opérateurs disponibles selon le produit, consultez ICI.

Opérateur	Description
keyword	Correspond à un mot-clé tokenisé dans le corps ou les URL d’un Post. Il s’agit d’une correspondance tokenisée, ce qui signifie que votre chaîne de mot-clé sera comparée au texte tokenisé du corps du Post – la tokenisation est basée sur la ponctuation, les symboles et les caractères de séparation du plan de base Unicode. Par exemple, un Post avec le texte « I like coca-cola » serait divisé en tokens suivants : I, like, coca, cola. Ces tokens seraient ensuite comparés à la chaîne de mot-clé utilisée dans votre règle. Pour faire correspondre des chaînes contenant de la ponctuation (par exemple, coca-cola), des symboles ou des caractères de séparation, vous devez utiliser une correspondance exacte entre guillemets comme décrit ci-dessous. Remarque : Avec l’API Search, les caractères accentués et spéciaux sont normalisés en caractères latins standard, ce qui peut changer les significations dans les langues étrangères ou retourner des résultats inattendus : Par exemple, « músic » correspondra à « music » et vice versa. Par exemple, des phrases courantes comme « Feliz Año Nuevo! » en espagnol, seraient indexées comme « Feliz Ano Nuevo », ce qui change la signification de la phrase. Remarque : Cet opérateur correspondra à la fois aux URL et aux URL déroulées dans un Post.
emoji	Correspond à un emoji dans le corps d’un Post. Les emojis sont une correspondance tokenisée, ce qui signifie que votre emoji sera comparé au texte tokenisé du corps du Post – la tokenisation est basée sur la ponctuation, les symboles/emojis et les caractères de séparation du plan de base Unicode. Par exemple, un Post avec le texte « I like » serait divisé en tokens suivants : I, like, . Ces tokens seraient ensuite comparés à l’emoji utilisé dans votre règle. Notez que si un emoji a une variante, vous devez utiliser des « guillemets » pour l’ajouter à une règle.
”correspondance de phrase exacte”	Correspond à la phrase tokenisée et ordonnée dans le corps ou les URL d’un Post. Il s’agit d’une correspondance tokenisée, ce qui signifie que votre chaîne de mot-clé sera comparée au texte tokenisé du corps du Post – la tokenisation est basée sur la ponctuation, les symboles et les caractères de séparation du plan de base Unicode. Remarque : La ponctuation n’est pas tokenisée et est plutôt traitée comme un espace. Par exemple, « #hashtag » entre guillemets correspondra à « hashtag » mais pas à #hashtag (utilisez l’opérateur hashtag # sans guillemets pour correspondre aux hashtags réels). Par exemple, « $cashtag » entre guillemets correspondra à « cashtag » mais pas à$cashtag (utilisez l’opérateur cashtag $ sans guillemets pour correspondre aux cashtags réels). Par exemple, « Love Snow » correspondra à « #love #snow » Par exemple, « #Love #Snow » correspondra à « love snow » Remarque : Cet opérateur correspondra à la fois aux URL et aux URL déroulées dans un Post.
”keyword1 keyword2”~N	Communément appelé opérateur de proximité, cela correspond à un Post où les mots-clés ne sont pas à plus de N tokens l’un de l’autre. Si les mots-clés sont dans l’ordre inverse, ils ne peuvent pas être à plus de N-2 tokens l’un de l’autre. Peut avoir n’importe quel nombre de mots-clés entre guillemets. N ne peut pas être supérieur à 6. Notez que cet opérateur n’est disponible que dans les API de recherche Enterprise.
from:	Correspond à tout Post d’un utilisateur spécifique. La valeur doit être l’ID de compte numérique X de l’utilisateur ou le nom d’utilisateur (excluant le caractère @). Voir ICI ou ICI pour les méthodes de recherche des ID de compte X numériques.
to:	Correspond à tout Post qui est en réponse à un utilisateur particulier. La valeur doit être l’ID de compte numérique de l’utilisateur ou le nom d’utilisateur (excluant le caractère @). Voir ICI pour les méthodes de recherche des ID de compte X numériques.
url:	Effectue une correspondance tokenisée (mot-clé/phrase) sur les URL étendues d’un Post (similaire à url_contains). Les tokens et phrases contenant de la ponctuation ou des caractères spéciaux doivent être entre guillemets doubles. Par exemple, url:“/developer”. Bien que généralement non recommandé, si vous voulez faire correspondre un protocole spécifique, mettez-le entre guillemets doubles : url:“https://developer.x.com”. Remarque : Lors de l’utilisation de PowerTrack ou Historical PowerTrack, cet opérateur correspondra aux URL contenues dans le Post original d’un Quote Post. Par exemple, si votre règle inclut url:“developer.x.com”, et qu’un Post contient cette URL, tous les Quote Tweets de ce Post seront inclus dans les résultats. Ce n’est pas le cas lors de l’utilisation de l’API Search.
#	Correspond à tout Post avec le hashtag donné. Cet opérateur effectue une correspondance exacte, PAS une correspondance tokenisée, ce qui signifie que la règle « 2016 » correspondra aux posts avec le hashtag exact « 2016 », mais pas à ceux avec le hashtag « 2016election » Remarque : l’opérateur hashtag s’appuie sur l’extraction d’entités de X pour faire correspondre les hashtags, plutôt que d’extraire le hashtag du corps lui-même. Voir ICI pour plus d’informations sur les attributs JSON des entités X.
@	Correspond à tout Post qui mentionne le nom d’utilisateur donné. L’opérateur to: retourne une correspondance de sous-ensemble de l’opérateur @mention.
$	Correspond à tout Post qui contient le « cashtag » spécifié (où le caractère de tête du token est le caractère « $ »). Notez que l’opérateur cashtag s’appuie sur l’extraction d’entités « symbols » de X pour faire correspondre les cashtags, plutôt que d’essayer d’extraire le cashtag du corps lui-même. Voir ICI pour plus d’informations sur les attributs JSON des entités X. Notez que cet opérateur n’est disponible que dans les API de recherche Enterprise.
retweets_of:	Alias disponible : retweets_of_user: Correspond aux Posts qui sont des retweets d’un utilisateur spécifié. Accepte à la fois les noms d’utilisateur et les ID de compte X numériques (PAS les ID de statut de Post). Voir ICI pour les méthodes de recherche des ID de compte X numériques.
lang:	Correspond aux Posts qui ont été classifiés par X comme étant d’une langue particulière (si, et seulement si, le post a été classifié). Il est important de noter que chaque Post n’est actuellement classifié que comme étant d’une seule langue, donc utiliser AND avec plusieurs langues ne donnera aucun résultat. Remarque : si aucune classification de langue ne peut être faite, le résultat fourni est « und » (pour indéfini). La liste ci-dessous représente les langues actuellement prises en charge et leur identifiant de langue BCP 47 correspondant :

Amharique : am	Allemand : de	Malayalam : ml	Slovaque : sk
Arabe : ar	Grec : el	Maldivien : dv	Slovène : sl
Arménien : hy	Gujarati : gu	Marathi : mr	Kurde sorani : ckb
Basque : eu	Créole haïtien : ht	Népalais : ne	Espagnol : es
Bengali : bn	Hébreu : iw	Norvégien : no	Suédois : sv
Bosniaque : bs	Hindi : hi	Odia : or	Tagalog : tl
Bulgare : bg	Hindi latinisé : hi-Latn	Pendjabi : pa	Tamoul : ta
Birman : my	Hongrois : hu	Pachto : ps	Télougou : te
Croate : hr	Islandais : is	Persan : fa	Thaï : th
Catalan : ca	Indonésien : in	Polonais : pl	Tibétain : bo
Tchèque : cs	Italien : it	Portugais : pt	Chinois traditionnel : zh-TW
Danois : da	Japonais : ja	Roumain : ro	Turc : tr
Néerlandais : nl	Kannada : kn	Russe : ru	Ukrainien : uk
Anglais : en	Khmer : km	Serbe : sr	Ourdou : ur
Estonien : et	Coréen : ko	Chinois simplifié : zh-CN	Ouïghour : ug
Finnois : fi	Lao : lo	Sindhi : sd	Vietnamien : vi
Français : fr	Letton : lv	Sinhala : si	Gallois : cy
Géorgien : ka	Lituanien : lt

place:	Fait correspondre les Posts tagués avec le lieu spécifié ou l’id de lieu X (voir exemples). Les noms de lieux comportant plusieurs mots (« New York City », « Palo Alto ») doivent être entre guillemets. Remarque : Consultez l’endpoint API public GET geo/search pour savoir comment obtenir des id de lieux X. Remarque : Cet opérateur ne correspond pas aux Retweets, car les lieux d’un Retweet sont rattachés au Post d’origine. Il ne correspond pas non plus aux lieux rattachés au Post d’origine d’un Quote Tweet.
place_country:	Fait correspondre les Posts dont le code pays associé à un lieu tagué correspond au code ISO alpha-2 fourni. Des codes ISO valides sont disponibles ici : http://en.wikipedia.org/wiki/ISO_3166-1_alpha-2 Remarque : Cet opérateur ne correspond pas aux Retweets, car les lieux d’un Retweet sont rattachés au Post d’origine. Il ne correspond pas non plus aux lieux rattachés au Post d’origine d’un Quote Tweet.
point_radius:[lon lat radius]	Fait correspondre la position exacte (x,y) du Post lorsque présente et, sur X, un polygone géographique « Place » lorsque le Place est entièrement contenu dans la zone définie. * Les unités de rayon prises en charge sont les miles (mi) et les kilomètres (km). * Le rayon doit être inférieur à 25 mi. * La longitude est comprise entre ±180 * La latitude est comprise entre ±90 * Toutes les coordonnées sont en degrés décimaux. * Les arguments de règle sont placés entre crochets, séparés par des espaces. Remarque : Cet opérateur ne correspond pas aux Retweets, car les lieux d’un Retweet sont rattachés au Post d’origine. Il ne correspond pas non plus aux lieux rattachés au Post d’origine d’un Quote Tweet.
bounding_box:[west_long south_lat east_long north_lat]	Alias disponible : geo_bounding_box: Fait correspondre la position exacte (long, lat) du Post lorsque présente et, sur X, un polygone géographique « Place » lorsque le Place est entièrement contenu dans la zone définie. * west_long et south_lat représentent le coin sud-ouest de la boîte englobante, où west_long est la longitude de ce point et south_lat en est la latitude. * east_long et north_lat représentent le coin nord-est de la boîte englobante, où east_long est la longitude de ce point et north_lat en est la latitude. * La largeur et la hauteur de la boîte englobante doivent être inférieures à 25 mi * La longitude est comprise entre ±180 * La latitude est comprise entre ±90 * Toutes les coordonnées sont en degrés décimaux. * Les arguments de règle sont placés entre crochets, séparés par des espaces. Remarque : Cet opérateur ne correspond pas aux Retweets, car les lieux d’un Retweet sont rattachés au Post d’origine. Il ne correspond pas non plus aux lieux rattachés au Post d’origine d’un Quote Tweet.
profile_country:	Correspondance exacte avec le champ « countryCode » de l’objet « address » dans l’enrichissement Profile Geo. Utilise un ensemble normalisé de codes pays à deux lettres, basé sur la spécification ISO-3166-1-alpha-2. Cet opérateur est fourni à la place d’un opérateur pour le champ « country » de l’objet « address » par souci de concision.
profile_region:	Fait correspondre le champ « region » de l’objet « address » dans l’enrichissement Profile Geo. Il s’agit d’une correspondance de chaîne complète et exacte. Il n’est pas nécessaire d’échapper les caractères avec une barre oblique inverse. Par exemple, pour faire correspondre un texte contenant une barre oblique, utilisez « one/two », et non « one/two ». Utilisez des guillemets doubles pour faire correspondre des sous-chaînes contenant des espaces ou de la ponctuation.
profile_locality:	Fait correspondre le champ « locality » de l’objet « address » dans l’enrichissement Profile Geo. Il s’agit d’une correspondance de chaîne complète et exacte. Il n’est pas nécessaire d’échapper les caractères avec une barre oblique inverse. Par exemple, pour faire correspondre un texte contenant une barre oblique, utilisez « one/two », et non « one/two ». Utilisez des guillemets doubles pour faire correspondre des sous-chaînes contenant des espaces ou de la ponctuation.

REMARQUE : Les opérateurs is: et has: ne peuvent pas être utilisés seuls avec la Search API et doivent être combinés à une autre clause.

Par exemple : @XDeevelopers has:links

has:geo	Correspond aux Posts qui contiennent des données de géolocalisation spécifiques au Post fournies par X. Il peut s’agir soit de coordonnées « geo » latitude-longitude, soit d’un « location » sous la forme d’un X « Place », avec le nom d’affichage correspondant, le polygone géographique et d’autres champs. Remarque : Lors de l’utilisation de l’API Search, cet opérateur doit être utilisé conjointement avec d’autres opérateurs qui n’incluent pas is: ou has:.
has:profile_geo	Alias disponible : has:derived_user_geo Correspond aux Posts qui contiennent des métadonnées Profile Geo, quelle que soit la valeur réelle. Remarque : Lors de l’utilisation de l’API Search, cet opérateur doit être utilisé conjointement avec d’autres opérateurs qui n’incluent pas is: ou has:.
has:links	Cet opérateur correspond aux Posts qui contiennent des liens dans le corps du message. Remarque : Lors de l’utilisation de l’API Search, cet opérateur doit être utilisé conjointement avec d’autres opérateurs qui n’incluent pas is: ou has:.
is:retweet	Renvoie uniquement les retweets explicites qui correspondent à une règle. Peut également être inversé pour exclure les retweets qui correspondent à une règle et ne renvoyer que le contenu original. Cet opérateur recherche uniquement les vrais Retweets, qui utilisent la fonctionnalité de retweet de X. Les Tweets cités et les Posts modifiés qui n’utilisent pas la fonctionnalité de retweet de X ne seront pas détectés par cet opérateur. Remarque : Lors de l’utilisation de l’API Search, cet opérateur doit être utilisé conjointement avec d’autres opérateurs qui n’incluent pas is: ou has:.
is:reply	Un opérateur pour filtrer les Posts selon qu’ils sont ou ne sont pas des réponses à des Posts. Renvoie uniquement les réponses explicites qui correspondent à une règle. Peut également être inversé pour exclure les réponses qui correspondent à une règle. Notez que cet opérateur est disponible pour la recherche premium payante et Enterprise et n’est pas disponible dans les environnements de développement Sandbox. Remarque : Lors de l’utilisation de l’API Search, cet opérateur doit être utilisé conjointement avec d’autres opérateurs qui n’incluent pas is: ou has:.
is:quote	Renvoie uniquement les Quote Tweets, ou Posts qui référencent un autre Post, comme identifié par le « is_quote_status »:true dans les charges utiles de Post. Peut également être inversé pour exclure les Quote Tweets. Remarque : Lors de l’utilisation de l’API Search, cet opérateur doit être utilisé conjointement avec d’autres opérateurs qui n’incluent pas is: ou has:.
is:verified	Renvoie uniquement les Posts dont l’auteur est « vérifié » par X. Peut également être inversé pour exclure les Posts dont l’auteur est vérifié. Remarque : Lors de l’utilisation de l’API Search, cet opérateur doit être utilisé conjointement avec d’autres opérateurs qui n’incluent pas is: ou has:.
has:mentions	Correspond aux Posts qui mentionnent un autre utilisateur X. Remarque : Lors de l’utilisation de l’API Search, cet opérateur doit être utilisé conjointement avec d’autres opérateurs qui n’incluent pas is: ou has:.
has:hashtags	Correspond aux Posts qui contiennent un hashtag. Remarque : Lors de l’utilisation de l’API Search, cet opérateur doit être utilisé conjointement avec d’autres opérateurs qui n’incluent pas is: ou has:.
has:media	Alias disponible : has:media_link Correspond aux Posts qui contiennent une URL de média classifiée par X. Par exemple, pic.x.com. Remarque : Lors de l’utilisation de l’API Search, cet opérateur doit être utilisé conjointement avec d’autres opérateurs qui n’incluent pas is: ou has:.
has:images	Correspond aux Posts qui contiennent une URL de média classifiée par X. Par exemple, pic.x.com. Remarque : Lors de l’utilisation de l’API Search, cet opérateur doit être utilisé conjointement avec d’autres opérateurs qui n’incluent pas is: ou has:.
has:videos	Alias disponible : has:video_link Correspond aux Posts qui contiennent des vidéos natives X, téléchargées directement sur X. Cela ne correspondra pas aux vidéos créées avec Vine, Periscope, ou aux Posts avec des liens vers d’autres sites d’hébergement vidéo. Remarque : Lors de l’utilisation de l’API Search, cet opérateur doit être utilisé conjointement avec d’autres opérateurs qui n’incluent pas is: ou has:.
has:symbols	Correspond aux Posts qui contiennent un symbole cashtag (avec un caractère « $» en préfixe. Par exemple,$tag). Notez que cet opérateur n’est disponible que dans les API de recherche enterprise. Remarque : Lors de l’utilisation de l’API Search, cet opérateur doit être utilisé conjointement avec d’autres opérateurs qui n’incluent pas is: ou has:.

​

Présentation du produit

La recherche Full-archive de niveau Enterprise a été lancée en août 2015, et la version de niveau Premium en février 2018. Ces produits de recherche permettent aux clients d’accéder immédiatement à tout Post disponible publiquement. Avec Full-archive Search, vous soumettez une seule query et recevez une réponse selon le modèle RESTful classique. Full-archive Search implémente une pagination allant jusqu’à 500 Posts par réponse, et prend en charge une limite de débit allant jusqu’à 60 requêtes par minute (rpm) pour le niveau Premium, et 120 rpm pour le niveau Enterprise. Compte tenu de ces éléments, Full-archive Search peut être utilisé pour récupérer rapidement des Posts, et à grande échelle grâce à des requêtes concurrentes.

Contrairement à Historical PowerTrack, dont l’archive est basée sur un ensemble de fichiers plats de Posts sur disque, l’archive de Posts de Full-archive Search s’apparente davantage à une base de données en ligne. Comme pour toutes les bases de données, elle permet d’exécuter des requêtes sur son contenu. Elle utilise également un index pour permettre une récupération de données haute performance. Avec les endpoints de Full-archive Search, le langage de requête est composé d’opérateurs PowerTrack, et chacun de ces opérateurs correspond à un attribut JSON de Post indexé.

Comme pour Historical PowerTrack, certains attributs de Post sont actualisés au moment où une query est effectuée. Par exemple, si vous utilisez la Search API aujourd’hui pour accéder à un Post publié en 2010, la description du profil de l’utilisateur, l’emplacement « home » du compte, le nom d’affichage et les métriques du Post pour les likes et les Retweets seront mis à jour avec les valeurs d’aujourd’hui, et non celles de 2010. 

​

Chronologie des métadonnées

Vous trouverez ci-dessous une chronologie indiquant à partir de quand les opérateurs de l’endpoint de recherche sur l’intégralité des archives commencent à faire correspondre. Dans certains cas, la prise en charge par les opérateurs a commencé bien après qu’une « convention de communication » est devenue courante sur X. Par exemple, les @Replies ont émergé comme convention d’usage en 2006, mais ne sont devenues un objet de première classe ou un événement avec un JSON « de support » qu’au début de 2007. En conséquence, faire correspondre les @Replies en 2006 nécessite d’examiner le corps du Post, plutôt que de s’appuyer sur les opérateurs PowerTrack to: et in_reply_to_status_id:.

Les détails fournis ici ont été générés à l’aide de la recherche sur l’intégralité des archives (issue de centaines de recherches). Cette chronologie n’est pas complète à 100 % ni parfaitement précise. Si vous identifiez une autre « date de naissance » de filtrage/de métadonnées fondamentale pour votre cas d’utilisation, veuillez nous en informer.

Notez que l’index de recherche sous-jacent peut être reconstruit. En conséquence, ces détails chronologiques sont susceptibles d’évoluer.

​

2006

• 26 mars - lang:. Exemple de metadata de Post renseignées a posteriori lors de la génération de l’index de recherche.
• 13 juillet - has:mentions commence à faire des correspondances.
• 6 octobre - has:symbols. Les $cashtags (ou symboles) pour discuter des symboles boursiers ne deviennent courants qu’au début de 2009. Jusqu’alors, la plupart des usages étaient probablement de l’argot (par ex.,$slang).
• 26 octobre - has:links commence à faire des correspondances.
• 23 novembre - has:hashtags commence à faire des correspondances.

​

2007

• 30 janvier - Première @reply de premier rang (in_reply_to_user_id), reply_to_status_id: commence à faire des correspondances.
• 23 août - Les hashtags s’imposent comme convention courante pour organiser les sujets et les conversations. Première utilisation concrète une semaine plus tard.

​

2009

• 15 mai - is:retweet. Notez que cet opérateur commence à faire correspondre avec la version « bêta » des Retweets officiels et son motif « Via @ ». Pendant cette période bêta, le verbe Post est « post » et le Post original n’est pas inclus dans le payload.
• 13 août - La version finale des Retweets officiels est publiée avec le motif « RT @ », un verbe défini sur « share », et l’attribut « retweet_status » contenant le Post original (ce qui double approximativement la taille du payload JSON).

​

2010

• 6 mars - Les opérateurs géo has:geo, bounding_box: et point_radius: commencent à effectuer des correspondances.
• 28 août - has:videos (Jusqu’en février 2015, cet opérateur correspond aux Posts contenant des liens vers certains sites d’hébergement vidéo, tels que youtube.com, vimeo.com et vivo.com).

​

2011

• 20 juillet - has:media et has:images commencent à faire correspondre. Les photos natives ont été officiellement annoncées le 9 août 2010.

​

2014

• 3 décembre - (Environ) Certaines métadonnées d’URL enrichies incluant le title HTML et la description commencent à apparaître dans les payloads. Les métadonnées enrichies se sont pleinement déployées en mai 2016.

​

2015

• 10 février - has:videos correspond aux vidéos « natives » de X.
• 17 février - has:profile_geo, profile_country:, profile_region:, profile_locality: Les opérateurs Profile Geo commencent à correspondre.
• 17 février - Les opérateurs de géolocalisation des Posts place_country: et place: commencent à correspondre.

​

2016

• 1er mai - Enhanced URL metadata désormais plus largement disponible et officiellement annoncé dans le cadre du lancement de Gnip 2.0 en août 2016. Aucun opérateur associé pour ces metadata avec les API de recherche.

​

2017

• 22 février - Les metadata des sondages sont disponibles dans un format natif enrichi. Aucun opérateur associé pour ces metadata.

​

2022

• 27 septembre - Tous les objets Post créés depuis cette date disposent des métadonnées d’édition de Post. Tous les endpoints Enterprise qui fournissent des objets Post ont été mis à jour à partir de cette date pour inclure ces métadonnées. Les métadonnées d’édition fournies incluent les objets edit_history et edit_controls. Ces métadonnées ne seront pas renvoyées pour les Posts créés avant le 27 septembre 2022. Actuellement, il n’existe aucun opérateur Enterprise correspondant à ces métadonnées. Pour en savoir plus sur les métadonnées d’édition de Post, consultez la page Principes fondamentaux de l’édition des Posts.

​

2022

• 29 septembre - Tous les objets Post créés depuis cette date disposent des métadonnées d’édition de Post. Tous les endpoints Enterprise qui fournissent des objets Post ont été mis à jour pour fournir ces métadonnées à compter de cette date. Les métadonnées d’édition fournies incluent les objets edit_history et edit_controls. Ces métadonnées ne seront pas renvoyées pour les Posts créés avant le 27 septembre 2022. Actuellement, aucun opérateur Enterprise ne correspond à ces métadonnées. Pour en savoir plus sur les métadonnées d’édition de Post, consultez la page Fondamentaux des Posts modifiés.

​

Conseils de filtrage

Compte tenu de toutes les informations de chronologie ci-dessus, il est clair qu’il y a de nombreux détails à prendre en compte lors de la rédaction de filtres pour les API de recherche. Deux éléments clés sont à considérer :

• Certaines metadata ont des dates de « naissance », de sorte que les filtres peuvent entraîner des faux négatifs. Ces recherches incluent des opérateurs reposant sur des metadata qui n’existaient pas pendant tout ou partie de la période de recherche. Par exemple, si vous recherchez des Posts avec l’opérateur has:images, vous n’obtiendrez aucune correspondance pour les périodes antérieures à juillet 2011. Cela s’explique par le fait que cet opérateur cible les photos natives (jointes à un Post via l’interface utilisateur de X). Pour obtenir un ensemble de données plus complet de Posts de partage de photos, les filtres portant sur une période antérieure à juillet 2011 devraient inclure des clauses de règles correspondant aux URL courantes d’hébergement de photos.
• Certaines metadata ont été rétro-remplies avec des metadata issues d’une période postérieure à la publication sur X.

Plusieurs types d’attributs sont couramment privilégiés lors de la création de requêtes PowerTrack :

• Profils X
• Posts originaux ou partagés
• Classification de la langue du Post
• Géoréférencement des Posts
• Médias des liens partagés

Certains de ces éléments présentent un comportement spécifique au produit, tandis que d’autres ont un comportement identique. Voir ci-dessous pour plus de détails.

​

Profils X

Les Search APIs renvoient des Posts historiques avec les données de profil utilisateur telles qu’elles sont au moment de la récupération. Si vous demandez un Post de 2014, les metadata du profil de l’utilisateur refléteront son état au moment de la query.

​

Posts d’origine et Retweets

L’opérateur PowerTrack _is:retweet_ permet d’inclure ou d’exclure les Retweets. Les utilisateurs de cet opérateur doivent adopter deux stratégies pour faire correspondre (ou non) les Retweets dans les data antérieures à août 2009. Avant août 2009, il faut vérifier le message du Post lui‑même, en utilisant une correspondance d’expression exacte, afin d’identifier le motif « @RT » (en fait, si vous filtrez des Retweets entre mai et août 2009, il convient d’inclure également le motif « Via @ »). Pour les périodes postérieures à août 2009, l’opérateur is:retweet est disponible.

​

Classifications de langue des Posts

Pour filtrer selon la classification linguistique d’un Post, les produits historiques de X diffèrent sensiblement. Lorsque l’archive Search a été créée, tous les Posts ont été rétroremplis avec la classification de langue de X. Par conséquent, l’opérateur lang: est disponible pour l’intégralité de l’archive des Posts.

​

Référencement géographique des Posts

Il existe trois principales manières de géoréférencer des Posts :

• Références géographiques dans le message du Post. La recherche de correspondances sur des références géographiques dans le message du Post, bien que souvent la méthode la plus difficile car elle dépend des connaissances locales, est une option pour l’ensemble de l’archive de Posts. Voici un exemple de correspondance géoréférencée datant de 2006 pour la région de San Francisco, basé sur un filtre « golden gate ».

• Posts géolocalisés par l’utilisateur. Avec les API de recherche, la possibilité de commencer à faire correspondre des Posts à l’aide de certains opérateurs Geo a débuté en mars 2010, puis avec d’autres en février 2015 :

  • 6 mars 2010 : has:geo, bounding_box: et point_radius:
  • 17 février 2015 : place_country: et place:

• Localisation « domicile » du profil du compte définie par l’utilisateur. Les opérateurs Geo de profil sont disponibles à la fois dans Historical PowerTrack et dans les API de recherche. Avec les API de recherche, ces métadonnées Geo de profil sont disponibles à partir de février 2015. Pour les Posts publiés avant la disponibilité des métadonnées Geo de profil, l’opérateur bio_location: est disponible et peut être utilisé pour faire correspondre des saisies utilisateur non normalisées.

​

Liens partagés et médias

En mars 2012, l’enrichissement d’URL développée a été introduit. Avant cette période, les payloads de Post incluaient uniquement l’URL fournie par l’utilisateur. Ainsi, si l’utilisateur incluait une URL raccourcie, il peut être difficile d’établir une correspondance avec les URL (développées) d’intérêt. Avec les API de recherche, ces metadata sont disponibles à partir de mars 2012.

En juillet 2016, l’enrichissement d’URL améliorée a été introduit. Cette version améliorée fournit le titre HTML et la description d’un site web dans le payload du Post, ainsi que des opérateurs pour faire correspondre ces éléments. Ces metadata commencent à apparaître en décembre 2014.

En septembre 2016, X a introduit les « pièces jointes natives », où un lien partagé final n’est pas comptabilisé dans la limite de 140 caractères du Post. Les deux enrichissements d’URL s’appliquent toujours à ces liens partagés.

Voici à partir de quand les opérateurs de recherche associés commencent à faire correspondre :

• 26 octobre 2006 - has:links
• 20 juillet 2011 - has:images et has:media
• Août 2011 - url: avec l’enrichissement Expanded URLs Dès septembre 2006, (url:"spotify.com" OR url:gnip OR url:microsoft OR url:google OR url:youtube) correspond à http://x.com/Adam/statuses/16602, même s’il n’y a pas de metadata urls[] dans twitter_entities et les objets gnip. « youtube.com » est un exemple de contenu de message qui, sans aucune metadata urls[], correspond à url:youtube.
• 10 février 2015 - has:videos pour les vidéos natives. Entre le 28/08/2010 et le 10/02/2015, cet opérateur correspond aux Posts comportant des liens vers certains sites d’hébergement vidéo tels que youtube.com, vimeo.com et vivo.com.
• 1er mai 2016 - url_title: et url_description:, basés sur l’enrichissement Enhanced URLs, généralement disponibles. Les premières metadata Enhanced URL ont commencé à apparaître en décembre 2014.

​

Foire aux questions (FAQ)

​

Questions générales sur l’API de recherche de Posts

Le nombre de Posts que je reçois avec l’endpoint data ne correspond pas au nombre de Posts identifié par l’endpoint counts. Pourquoi est-ce le cas ?

Il existe une différence connue entre les résultats fournis par l’endpoint counts et l’endpoint data. Vous pouvez constater un écart dans vos résultats, car l’endpoint counts est pré‑conformité (c’est‑à‑dire qu’il ne prend pas en compte des éléments comme les Posts supprimés, le scrub geo, etc.), tandis que l’endpoint data est conforme au moment de la livraison et tient compte de tous les événements de conformité.

Je n’ai pas reçu un Post qui devrait correspondre à ma query. Pourquoi ?

Il existe plusieurs raisons pour lesquelles cela a pu se produire, notamment :

1. le Post que vous vous attendiez à voir provient d’un compte protégé ;
2. l’endpoint data tient compte de tous les événements de conformité (ce qui signifie que les Posts supprimés, les géodonnées purgées, etc., ne seront pas incluses dans la réponse).

Ma query a correspondu à un Post mais includes un mot-clé que j’ai exclu. Pourquoi cela se produit-il ?

Cela est probablement dû à une mauvaise utilisation de nos règles et filtres Premium. Veuillez consulter notre documentation ici et vous assurer de bien comprendre les restrictions relatives à la création de règles.

Existe-t-il des bibliothèques que je peux utiliser pour commencer à utiliser les API Search Post ?

Oui, il y en a, notamment :

• Tweepy - idéal pour utiliser le produit standard Search/Posts (Python)
• X API - idéal pour utiliser les API standard Search Posts (Python)
• Search Posts Python et Search Posts Ruby - deux excellents outils pouvant être utilisés avec les API Search Posts pour Enterprise (et v2 !)

Toutes les bibliothèques que nous prenons directement en charge se trouvent sur notre page GitHub xdevplatform : https://github.com/xdevplatform.

Il existe d’autres bibliothèques tierces qui peuvent également être utiles ; toutefois, veuillez noter que certaines d’entre elles peuvent ne pas fonctionner avec nos produits Premium et Enterprise.

Recevrai‑je parfois un volume de Posts inférieur à la valeur que j’ai définie pour `maxResults` dans ma requête vers l’endpoint de data ?

Oui. Notre endpoint data effectue la pagination soit au niveau du maxResults spécifié, soit au bout de 30 jours.

Par exemple, si vous avez 800 Posts sur une période de 30 jours, vous devrez effectuer deux requêtes pour récupérer l’ensemble des résultats, car le nombre maximal de Posts pouvant être renvoyés par requête est de 500 (maxResults). Et si vous avez seulement 400 Posts le premier mois, puis 100 Posts le deuxième mois, vous devrez également effectuer deux requêtes pour récupérer l’intégralité des résultats, car la pagination intervient après une période de 30 jours, même si la première requête renvoie moins que le nombre de Posts spécifié par maxResults.

Dans quel ordre les Posts correspondants sont-ils renvoyés ?

Les Posts sont renvoyés dans l’ordre antichronologique. Par exemple, la première page de résultats affichera les Posts les plus récents correspondant à la query, et la pagination se poursuivra jusqu’à ce que les dates de publication des résultats atteignent la valeur fromDate demandée initialement.

Comment les Post modifiés affectent-ils mon utilisation et ma facturation ?

Seul le Post original sera pris en compte à des fins de facturation. Toute modification ultérieure sera ignorée et ne sera pas prise en compte dans votre volume d’activité global.

Enterprise

Je souhaite en savoir plus sur la tarification de l’API Search Post Enterprise et déposer une demande pour cette offre. Comment procéder ?

Nos solutions Enterprise sont personnalisées, avec une tarification prévisible, pour répondre aux besoins de votre entreprise. Veuillez faire une demande ici pour plus d’informations.

Comment créer un ensemble de règles correspondant à mon cas d’utilisation ?

• Veuillez consulter la documentation de nos API de recherche de Post Enterprise ici
• Des informations utiles sur les règles et le filtrage sont disponibles ici
• Des informations utiles sur l’utilisation de l’endpoint data sont disponibles ici
• Des informations utiles sur l’utilisation de l’endpoint counts sont disponibles ici
• Une liste des opérateurs disponibles est proposée ici

J’ai dépassé mes plafonds/limites de requêtes pour ce mois, mais j’ai besoin d’accéder à davantage de data – que puis‑je faire ?

Veuillez contacter votre chargé(e) de compte chez X, qui pourra vous aider à ce sujet.

​

Guide de dépannage des erreurs

Code 404 - Non trouvé

1. Assurez-vous d’utiliser les paramètres appropriés pour chaque endpoint (par exemple, le champ buckets ne peut être utilisé qu’avec l’endpoint de comptage, pas avec l’endpoint de data)
2. Vérifiez à nouveau que les champs :product, :account_name et :label sont corrects. Vous pouvez trouver votre champ :label dans la GNIP Console (clients Enterprise uniquement).

​

Référence de l’API

​

API de recherche Enterprise

Il existe deux API de recherche Enterprise :

• 30-Day Search API - fournit des Tweets publiés au cours des 30 derniers jours.
• Full-Archive Search API - fournit des Tweets remontant jusqu’en 2006, en commençant par le premier Tweet publié en mars 2006.

Ces API de recherche partagent une architecture commune et la documentation ci-dessous s’applique aux deux. Notez que pour les Tweets créés à partir du 29 septembre 2022, les objets Tweet incluent des métadonnées d’édition décrivant leur historique des modifications. Consultez la page de notions fondamentales “Edit Tweets” pour plus de détails.

Vous trouverez ci-dessous des informations importantes nécessaires lors de l’intégration avec les API de recherche Enterprise :

• Méthodes pour demander des données et des décomptes de Tweets
• Authentification
• Pagination
• Paramètres de requête de l’API et exemples de requêtes
• Charges utiles JSON de réponse de l’API et exemples de réponses
• Codes de réponse HTTP

Les API Enterprise offrent un accès à faible latence, de fidélité complète et basé sur des requêtes à l’archive des Tweets. La seule différence entre les deux API est la période sur laquelle vous pouvez effectuer des recherches, soit les 30 derniers jours, soit depuis 2006. Les périodes peuvent être spécifiées à la minute près. Les données de Tweet sont renvoyées dans l’ordre chronologique inverse, en commençant par le Tweet le plus récent correspondant à votre query. Les Tweets sont disponibles via l’API de recherche environ 30 secondes après leur publication.

​

Méthodes

L’URI de base pour la recherche Enterprise est https://gnip-api.x.com/search/.

Méthode	Description
POST /search/:product/accounts/:account_name/:label	Récupère les Tweets des 30 derniers jours correspondant à la règle PowerTrack spécifiée.
POST /search/:product/accounts/:account_name/:label/counts	Récupère le nombre de Tweets des 30 derniers jours correspondant à la règle PowerTrack spécifiée.

Où :

• :product indique l’endpoint de recherche auquel vous adressez des requêtes, soit 30day, soit fullarchive.
• :account_name est le nom (sensible à la casse) associé à votre compte, tel qu’affiché sur console.gnip.com.
• :label est le libellé (sensible à la casse) associé à votre endpoint de recherche, tel qu’affiché sur console.gnip.com.

Par exemple, si le compte TwitterDev dispose du produit de recherche 30‑Day avec le libellé « prod » (abréviation de production), les endpoints de recherche seraient :

• Endpoint de données : https://gnip-api.x.com/search/30day/accounts/TwitterDev/prod.json
• Endpoint de comptage : https://gnip-api.x.com/search/30day/accounts/TwitterDev/prod/counts.json

Votre endpoint complet de l’API de recherche Enterprise est affiché sur https://console.gnip.com.

Ci‑dessous figurent plusieurs exemples de requêtes utilisant un utilitaire HTTP simple appelé curl. Ces exemples utilisent des URL avec :product, :account_name et :label. Pour utiliser ces exemples, veillez à mettre à jour les URL avec vos informations.

​

Authentification

Toutes les requêtes adressées aux API de recherche Enterprise doivent utiliser l’authentification HTTP Basic, composée d’une adresse e‑mail et d’un mot de passe valides utilisés pour vous connecter à votre compte sur https://console.gnip.com. Les identifiants doivent être transmis dans l’en‑tête Authorization pour chaque requête.

​

Comportement des requêtes/réponses

En utilisant les paramètres fromDate et toDate, vous pouvez demander n’importe quelle période prise en charge par l’API. L’API de recherche 30-Day fournit des Tweets issus des 31 derniers jours (bien que dite « 30-Day », elle en expose 31 afin de permettre des requêtes couvrant un mois complet). L’API de recherche Full-Archive fournit des Tweets remontant jusqu’au tout premier Tweet (21 mars 2006). Toutefois, une seule réponse sera limitée à la plus petite valeur entre votre maxResults spécifié et 31 jours. Si les données correspondantes ou votre plage temporelle dépassent votre maxResults spécifié ou 31 jours, vous recevrez un jeton « next » que vous devrez utiliser pour paginer le reste de la plage temporelle spécifiée.

Par exemple, supposons que vous utilisiez la recherche Full-Archive et souhaitiez récupérer tous les Tweets correspondant à votre query du 1er janvier 2017 au 30 juin 2017. Vous indiquerez cette période de six mois dans votre requête à l’aide des paramètres fromDate et toDate. L’API de recherche renverra la première « page » de Tweets, avec un nombre de Tweets correspondant à votre paramètre maxResults (qui vaut 100 par défaut). En supposant qu’il y ait plus de Tweets (ce qui est très probable), l’API fournira également un jeton « next » qui vous permettra d’effectuer une requête pour la « page » de données suivante. Ce processus est répété jusqu’à ce que l’API ne renvoie plus de jeton « next ». Voir la section suivante pour plus de détails.

​

Pagination

Lors de l’envoi de requêtes de données et de comptage, il est probable qu’il y ait plus de données que ce qui peut être renvoyé dans une seule réponse. Dans ce cas, la réponse inclura un jeton « next ». Le jeton « next » est fourni en tant qu’attribut JSON au niveau racine. Chaque fois qu’un jeton « next » est fourni, cela indique que des données supplémentaires sont disponibles ; vous devrez donc continuer à effectuer des requêtes à l’API.

Remarque : Le comportement du jeton « next » diffère légèrement entre les requêtes de données et de comptage. Les deux sont décrits ci‑dessous, avec des exemples de réponses fournis dans la section Référence de l’API.

Pagination des données

Les requêtes de données renverront probablement plus d’éléments qu’il n’est possible d’inclure dans une seule réponse. Chaque requête comprend un paramètre qui définit le nombre maximal de Tweets à retourner par requête. Ce paramètre maxResults est par défaut à 100 et peut être fixé entre 10 et 500. Si votre query correspond à plus de Tweets que la valeur de ‘maxResults’ utilisée dans la requête, la réponse inclura un jeton ‘next’ (en tant qu’attribut JSON au niveau racine). Ce jeton ‘next’ est utilisé dans la requête suivante pour récupérer la portion suivante des Tweets correspondant à cette query (c’est‑à‑dire la « page » suivante). Des jetons ‘next’ continueront d’être fournis jusqu’à ce que vous atteigniez la dernière « page » de résultats pour cette query, moment auquel aucun jeton ‘next’ n’est renvoyé.

Pour demander la « page » suivante de données, vous devez effectuer exactement la même query que l’originale, y compris les paramètres query, toDate et fromDate, le cas échéant, et inclure également un paramètre de requête ‘next’ défini sur la valeur de la réponse précédente. Cela peut être utilisé avec une requête GET ou POST. Toutefois, dans le cas d’une requête GET, le paramètre ‘next’ doit être encodé dans l’URL.

Vous pouvez continuer à transmettre l’élément ‘next’ de votre query précédente jusqu’à ce que vous ayez reçu tous les Tweets de la période couverte par votre query. Lorsque vous recevez une réponse qui n’inclut pas d’élément ‘next’, cela signifie que vous avez atteint la dernière page et qu’aucune donnée supplémentaire n’est disponible pour la query et la plage temporelle spécifiées.

Pagination des décomptes

L’endpoint ‘counts’ fournit les volumes de Tweet associés à une query sur une base quotidienne, horaire ou à la minute. L’endpoint API ‘counts’ renverra un tableau horodaté de décomptes pour un maximum de 31 jours. Si vous demandez plus de 31 jours de décomptes, un jeton ‘next’ vous sera fourni. Comme pour les jetons ‘next’ de data, vous devez effectuer exactement la même query que l’originale et inclure également un paramètre de requête ‘next’ défini sur la valeur de la réponse précédente.

Au-delà d’une demande portant sur plus de 31 jours de décomptes, il existe un autre scénario où un jeton ‘next’ est fourni. Pour les queries à volume élevé, il est possible que la génération des décomptes prenne suffisamment de temps pour déclencher un délai d’expiration de la réponse. Dans ce cas, vous recevrez moins de 31 jours de décomptes, mais un jeton ‘next’ sera fourni afin de continuer à effectuer des requêtes pour l’ensemble de la charge utile de décomptes. Important : Les délais d’expiration ne renvoient que des « buckets » complets — ainsi, 2,5 jours se traduiront par 2 « buckets » d’une journée complets.

Notes supplémentaires

• Lorsque vous utilisez fromDate ou toDate dans une requête de recherche, vous n’obtiendrez que des résultats compris dans votre plage temporelle. Lorsque vous atteignez le dernier groupe de résultats de votre plage temporelle, vous ne recevrez pas de jeton “next”.
• L’élément “next” peut être utilisé avec n’importe quelle valeur maxResults comprise entre 10 et 500 (valeur par défaut : 100). Le paramètre maxResults détermine le nombre de Tweets renvoyés dans chaque réponse, mais ne vous empêche pas d’obtenir l’ensemble des résultats au final.
• L’élément “next” n’expire pas. Plusieurs requêtes utilisant la même query “next” recevront les mêmes résultats, quel que soit le moment où la requête est effectuée.
• Lors de la pagination des résultats à l’aide du paramètre “next”, vous pouvez rencontrer des doublons aux limites de la query. Votre application doit les tolérer.

​

Endpoint data

POST /search/:product/:label

Modèle d’endpoint :

Cet endpoint renvoie les data correspondant à la query et à la période spécifiées. Si aucune période n’est indiquée, les paramètres temporels prennent par défaut les 30 derniers jours. Remarque : cette fonctionnalité peut également être obtenue au moyen d’une requête GET, plutôt qu’un POST, en encodant les paramètres décrits ci-dessous dans l’URL.

Paramètres de requête de données

Paramètres	Description	Requis	Valeur d’exemple
query	L’équivalent d’une règle PowerTrack, jusqu’à 2 048 caractères (sans limite quant au nombre de clauses positives et négatives). Ce paramètre doit inclure TOUTES les composantes de la règle PowerTrack, y compris tous les opérateurs, et aucune partie de la règle ne doit être séparée dans d’autres paramètres de la query. Remarque : Tous les opérateurs PowerTrack ne sont pas pris en charge. Les opérateurs pris en charge sont répertoriés ICI.	Oui	(snow OR cold OR blizzard) weather
tag	Les tags peuvent être utilisés pour regrouper les règles et leurs données correspondantes en ensembles logiques distincts. Si un tag de règle est fourni, il est inclus dans l’attribut ‘matching_rules’. Il est recommandé d’attribuer des UUID spécifiques à chaque règle aux tags et de maintenir les correspondances souhaitées côté client.	Non	8HYG54ZGTU
fromDate	L’horodatage UTC le plus ancien (jusqu’au 21/03/2006 avec la recherche Full-Archive) à partir duquel les Tweets seront fournis. L’horodatage est à la granularité de la minute et est inclusif (p. ex., 12:00 inclut la minute 00). Spécifié : Utiliser uniquement fromDate sans paramètre toDate renverra des résultats pour la query en remontant dans le temps depuis maintenant( ) jusqu’à fromDate. Non spécifié : Si fromDate n’est pas indiqué, l’API renverra tous les résultats pour les 30 jours précédant maintenant( ) ou toDate (s’il est indiqué). Si ni fromDate ni toDate n’est utilisé, l’API renverra tous les résultats des 30 derniers jours, à partir du moment de la requête, en remontant dans le temps.	Non	201207220000
toDate	L’horodatage UTC le plus récent jusqu’auquel les Tweets seront fournis. L’horodatage est à la granularité de la minute et n’est pas inclusif (p. ex., 11:59 n’inclut pas la 59e minute de l’heure). Spécifié : Utiliser uniquement toDate sans paramètre fromDate renverra les 30 derniers jours de données avant toDate. Non spécifié : Si toDate n’est pas indiqué, l’API renverra tous les résultats depuis maintenant( ) pour la query en remontant dans le temps jusqu’à fromDate. Si ni fromDate ni toDate n’est utilisé, l’API renverra tous les résultats pour l’ensemble de l’index de 30 jours, à partir du moment de la requête, en remontant dans le temps.	Non	201208220000
maxResults	Le nombre maximal de résultats de recherche renvoyés par une requête. Un nombre entre 10 et la limite du système (actuellement 500). Par défaut, la réponse à une requête renvoie 100 résultats.	Non	500
next	Ce paramètre est utilisé pour obtenir la « page » suivante de résultats, comme décrit ICI. La valeur utilisée avec ce paramètre est extraite directement de la réponse fournie par l’API et ne doit pas être modifiée.	Non	NTcxODIyMDMyODMwMjU1MTA0

Détails supplémentaires

Période disponible	30-Day : 31 derniers jours Full-Archive : 21 mars 2006 - aujourd’hui
Format de query	Équivalent d’une règle PowerTrack, jusqu’à 2 048 caractères (sans limite quant au nombre de clauses positives et négatives). Remarque : Tous les opérateurs PowerTrack ne sont pas pris en charge. Consultez la page Available operators pour la liste des opérateurs pris en charge.
Limite de taux	Des limites de taux s’appliquent à la minute et à la seconde. La limite par minute varie selon le partenaire, comme indiqué dans votre contrat. Toutefois, ces limites par minute ne sont pas destinées à être consommées en une seule rafale. Quelle que soit votre limite par minute, tous les partenaires sont limités à un maximum de 20 requêtes par seconde, agrégées sur l’ensemble des requêtes de data et/ou de décomptes.
Conformité	Toutes les data fournies via la Full-Archive Search API sont conformes au moment de la livraison.
Disponibilité en temps réel	Les données sont disponibles dans l’index dans les 30 secondes suivant leur génération sur la plateforme X.

Exemples de requêtes et de réponses de données

Exemple de requête POST

• Les paramètres d’une requête POST sont envoyés dans un corps au format JSON, comme illustré ci-dessous.
• Toutes les parties de la règle PowerTrack faisant l’objet de la requête (p. ex. des mots-clés, d’autres opérateurs comme bounding_box:) doivent être placées dans le paramètre ‘query’.
• Ne scindez pas la règle en paramètres distincts dans l’URL de la requête.

Voici un exemple de commande POST (avec cURL) pour effectuer une requête initiale de data :

    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"}'

Si la réponse de l’API contient un jeton « next », voici une requête suivante qui reprend la requête initiale, avec le paramètre « next » défini sur le jeton fourni :

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

Exemple de requête GET

• Les paramètres d’une requête GET sont encodés dans l’URL à l’aide de l’encodage URL standard.
• Toutes les parties de la règle PowerTrack faisant l’objet de la requête (p. ex. des mots-clés, d’autres opérateurs comme bounding_box:) doivent être placées dans le paramètre ‘query’.
• Ne scindez pas des parties de la règle en paramètres distincts dans l’URL de requête.

Voici un exemple de commande GET (avec cURL) pour effectuer une requête de data initiale :

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

Exemples de réponses data

Notez que pour les Tweets créés à partir du 29 septembre 2022, les objets Tweet incluront des métadonnées d’édition de Tweet décrivant leur historique des modifications. Consultez la page de fondamentaux “Edit Tweets” pour plus de détails.

Ci-dessous figure un exemple de réponse à une requête data. Cet exemple suppose qu’il y avait plus de Tweets que ‘maxResults’ disponibles, de sorte qu’un jeton ‘next’ est fourni pour les requêtes suivantes. Si ‘maxResults’ ou moins de Tweets sont associés à votre query, aucun jeton ‘next’ ne sera inclus dans la réponse. La valeur de l’élément ‘next’ changera à chaque query et doit être traitée comme une chaîne opaque. L’élément ‘next’ aura l’apparence suivante dans le corps de la réponse :

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

La réponse à une requête ultérieure pourrait ressembler à ce qui suit (notez les nouveaux Tweets et la valeur « next » différente) :

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

Vous pouvez continuer à transmettre l’élément ‘next’ de votre précédente query jusqu’à avoir reçu tous les Tweets pour la période couverte par votre query. Lorsque vous recevez une réponse qui n’inclut pas l’élément ‘next’, cela signifie que vous avez atteint la dernière page et qu’aucune donnée supplémentaire n’est disponible dans votre plage temporelle.

​

endpoint de comptage

/search/:stream/counts

Modèle d’endpoint :

/search/fullarchive/accounts/:account_name/:label/counts.json

Cet endpoint renvoie des décomptes (volumes de données) pour la query spécifiée. Si aucune période n’est indiquée, les paramètres temporels prennent par défaut les 30 derniers jours. Les volumes de données sont renvoyés sous la forme d’un tableau horodaté, soit quotidien, horaire (par défaut) ou à la minute.

Remarque : Cette fonctionnalité peut également être obtenue à l’aide d’une requête GET, plutôt qu’un POST, en encodant les paramètres décrits ci-dessous dans l’URL.

Paramètres de requête pour les décomptes

Paramètres	Description	Obligatoire	Valeur d’exemple
query	L’équivalent d’une règle PowerTrack, jusqu’à 2 048 caractères (sans limite quant au nombre de clauses positives et négatives). Ce paramètre doit inclure TOUTES les parties de la règle PowerTrack, y compris tous les opérateurs ; aucune partie de la règle ne doit être séparée dans d’autres paramètres de la query. Remarque : Tous les opérateurs PowerTrack ne sont pas pris en charge. Consultez Available operators pour la liste des opérateurs pris en charge.	Oui	(snow OR cold OR blizzard) weather
fromDate	L’horodatage UTC le plus ancien (jusqu’au 21/03/2006) à partir duquel les Tweets seront fournis. L’horodatage est à la granularité de la minute et est inclusif (p. ex. 12:00 inclut la minute 00). Spécifié : En utilisant uniquement fromDate sans paramètre toDate, l’API renverra les décomptes (volumes de data) pour la query en remontant dans le temps, de maintenant jusqu’à fromDate. Si fromDate est antérieur de plus de 31 jours par rapport à maintenant, vous recevrez un jeton next pour parcourir votre requête par pages. Non spécifié : Si aucun fromDate n’est spécifié, l’API renverra les décomptes (volumes de data) pour les 30 jours précédant maintenant ou le toDate (s’il est spécifié). Si ni fromDate ni toDate n’est utilisé, l’API renverra les décomptes (volumes de data) pour les 30 jours les plus récents, à partir du moment de la requête, en remontant dans le temps.	Non	201207220000
toDate	L’horodatage UTC le plus récent jusqu’auquel les Tweets seront fournis. L’horodatage est à la granularité de la minute et n’est pas inclusif (p. ex. 11:59 n’inclut pas la 59e minute de l’heure). Spécifié : Utiliser uniquement toDate sans paramètre fromDate renverra les décomptes (volumes de data) les plus récents pour les 30 jours précédant toDate. Non spécifié : Si aucun toDate n’est spécifié, l’API renverra les décomptes (volumes de data) pour la query en remontant dans le temps jusqu’à fromDate. Si fromDate est à plus de 31 jours de maintenant, vous recevrez un jeton next pour parcourir votre requête par pages. Si ni fromDate ni toDate n’est utilisé, l’API renverra les décomptes (volumes de data) pour les 30 jours les plus récents, à partir du moment de la requête, en remontant dans le temps.	Non	201208220000
bucket	L’unité de temps pour laquelle les décomptes seront fournis. Les décomptes peuvent être renvoyés pour chaque jour, heure ou minute dans la période demandée. Par défaut, des décomptes horaires sont fournis. Options : ‘day’, ‘hour’, ‘minute’	Non	minute
next	Ce paramètre est utilisé pour obtenir la « page » suivante de résultats, comme décrit ICI. La valeur utilisée avec ce paramètre est extraite directement de la réponse de l’API et ne doit pas être modifiée.	Non	NTcxODIyMDMyODMwMjU1MTA0

Détails supplémentaires

Période disponible	30 jours : 31 derniers jours Archive complète : 21 mars 2006 - aujourd’hui
Format de query	Équivalent à une règle PowerTrack, jusqu’à 2 048 caractères. Remarque : Tous les opérateurs PowerTrack ne sont pas pris en charge. Consultez Available operators pour la liste des opérateurs pris en charge.
Limite de taux	Les partenaires seront soumis à des limites de taux à la minute et à la seconde. La limite de taux par minute varie selon le partenaire, comme spécifié dans votre contrat. Toutefois, ces limites par minute ne sont pas destinées à être consommées d’un seul coup. Quelle que soit votre limite de taux par minute, tous les partenaires seront plafonnés à un maximum de 20 requêtes par seconde, agrégées sur l’ensemble des requêtes de data et/ou de décomptes.
Précision des décomptes	Les décomptes fournis via cet endpoint reflètent le nombre de Tweets survenus et ne tiennent pas compte des événements de conformité ultérieurs (suppressions, scrub geos). Certains Tweets comptés peuvent ne pas être disponibles via l’endpoint data en raison d’actions de conformité des utilisateurs.

Exemples de requêtes et de réponses de comptage

Exemple de requête POST

• Les paramètres d’une requête POST sont envoyés dans un corps au format JSON, comme illustré ci-dessous.
• Toutes les parties de la règle PowerTrack recherchée (par ex. des mots-clés, d’autres opérateurs comme bounding_box:) doivent être placées dans le paramètre ‘query’.
• Ne séparez pas des parties de la règle en paramètres distincts dans l’URL de la requête.

Voici un exemple de commande POST (avec cURL) pour effectuer une requête initiale de comptage :

    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"}'

Si la réponse de comptage de l’API contient un jeton « next », voici une requête suivante correspondant à la requête initiale, avec le paramètre « next » défini sur le jeton fourni :

    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"}'

Exemple de requête GET

• Les paramètres d’une requête GET sont encodés dans l’URL à l’aide de l’encodage URL standard
• Toutes les parties de la règle PowerTrack faisant l’objet de la requête (par exemple des mots-clés, ou d’autres opérateurs comme bounding_box:) doivent être placées dans le paramètre « query »
• Ne segmentez pas des parties de la règle en paramètres distincts dans l’URL de la requête

Voici un exemple de commande GET (via cURL) pour effectuer une requête de comptage initial :

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

​

Exemples de réponses de comptage

Ci-dessous figure un exemple de réponse à une query de comptage (volume de données). Cet exemple de réponse inclut un jeton « next », ce qui signifie que la requête de comptage portait sur plus de 31 jours ou que la query soumise avait un volume suffisamment important pour déclencher une réponse partielle.

La valeur de l’élément « next » changera à chaque query et doit être traitée comme une chaîne opaque. L’élément « next » apparaîtra comme suit dans le corps de la réponse :

    {
      "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"
        }
    }

La réponse à une requête ultérieure pourrait ressembler à ceci (notez la nouvelle chronologie des comptes et la valeur « next » différente) :

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

Vous pouvez continuer à transmettre l’élément ‘next’ de votre précédente query jusqu’à avoir reçu tous les décomptes pour la période couverte par la query. Lorsque vous recevez une réponse qui n’inclut pas l’élément ‘next’, cela signifie que vous avez atteint la dernière page et qu’aucun décompte supplémentaire n’est disponible dans votre plage temporelle.

​

Codes de réponse HTTP

Statut	Texte	Description
200	OK	La requête a abouti. La réponse JSON sera similaire à ce qui suit :
400	Bad Request	En général, cette réponse survient en raison de JSON invalide dans la requête ou parce qu’aucun corps JSON n’a été envoyé.
401	Unauthorized	L’authentification HTTP a échoué en raison d’identifiants invalides. Connectez-vous à console.gnip.com avec vos identifiants pour vérifier que vous les utilisez correctement avec votre requête.
404	Not Found	La ressource est introuvable à l’URL cible de la requête, probablement parce qu’une URL incorrecte a été utilisée.
422	Unprocessable Entity	Renvoyé en raison de paramètres invalides dans le paramètre query — p. ex. des règles PowerTrack invalides.
429	Unknown Code	Votre App a dépassé la limite des demandes de connexion. Le message JSON correspondant sera similaire à ce qui suit :
500	Internal Server Error	Une erreur est survenue côté serveur. Réessayez votre requête en appliquant un backoff exponentiel.
502	Proxy Error	Une erreur est survenue côté serveur. Réessayez votre requête en appliquant un backoff exponentiel.
503	Service Unavailable	Une erreur est survenue côté serveur. Réessayez votre requête en appliquant un backoff exponentiel.