Search API: Enterprise

Tenga en cuenta: Hemos publicado una nueva versión de search Posts y Post counts en X API v2. Le recomendamos revisar las novedades de X API v2. Estos endpoints se han actualizado para incluir metadatos de edición de Post. Obtenga más información sobre estos metadatos en la página de fundamentos “Edit Posts”.

Descripción general

Enterprise Las APIs de Enterprise están disponibles únicamente dentro de nuestros niveles de acceso gestionados. Para usar estas APIs, primero debe configurar una cuenta con nuestro equipo de ventas de Enterprise. Para obtener más información, consulte AQUÍ. Puede ver todas las ofertas de búsqueda de Posts de X API AQUÍ. Existen dos APIs de búsqueda de Enterprise:

La 30-Day Search API proporciona datos de los 30 días anteriores.
La Full-Archive Search API proporciona acceso completo e instantáneo al corpus íntegro de datos de X que se remonta hasta el primer Post en marzo de 2006.

Estas APIs RESTful admiten una única query de hasta 2,048 caracteres por solicitud. Las queries se escriben con la sintaxis de reglas de PowerTrack; consulte Rules and filtering para más detalles. Los usuarios pueden especificar cualquier período de tiempo, con granularidad de un minuto. Sin embargo, las respuestas se limitarán al menor valor entre su maxResults especificado O 31 días e incluirán un token next para paginar el siguiente conjunto de resultados. Si no se especifican parámetros de tiempo, la API devolverá data coincidente de los 30 días más recientes. Las APIs de búsqueda de Enterprise proporcionan acceso de baja latencia, fidelidad completa y basado en query al archivo de Posts con granularidad de un minuto. Los datos de Post se entregan en orden cronológico inverso, comenzando con el Post más reciente que coincida con su query. Los Posts están disponibles en la search API aproximadamente 30 segundos después de su publicación. Estos endpoints de búsqueda proporcionan metadata de edición de Post. Todos los objetos de Posts creados desde el 29 de septiembre de 2022 incluyen metadata de edición de Post, incluso si el Post nunca fue editado. Cada vez que se edita un Post, se crea un nuevo ID de Post. El historial de ediciones de un Post se documenta mediante un arreglo de IDs de Post, comenzando con el ID original. Estos endpoints siempre devolverán la edición más reciente, junto con cualquier historial de ediciones. Cualquier Post recopilado después de su ventana de edición de 30 minutos representará su versión final. Para obtener más información sobre la metadata de Edit Post, consulte la página Edit Posts fundamentals. Las solicitudes incluyen un parámetro maxResults que especifica el número máximo de Posts a devolver por respuesta de la API. Si hay más Posts asociados con la query que este máximo de resultados por respuesta, se incluye un token next en la respuesta. Estos tokens next se utilizan en solicitudes posteriores para recorrer el conjunto completo de Posts asociados con la query. Estas APIs de búsqueda de Enterprise proporcionan un endpoint de counts que permite a los usuarios solicitar el volumen de data asociado con su query.

Tipos de solicitudes

Las API de búsqueda de Enterprise admiten dos tipos de solicitudes:

Solicitudes de búsqueda (data)

Las solicitudes de búsqueda a las API de búsqueda de Enterprise le permiten recuperar hasta 500 resultados por respuesta para un período determinado, con la posibilidad de paginar para obtener data adicional. Con el parámetro maxResults, puede especificar tamaños de página más pequeños para casos de uso de visualización (permitiendo que el usuario solicite más resultados según sea necesario) o tamaños de página más grandes (hasta 500) para extracciones de data de mayor volumen. La data se entrega en orden cronológico inverso y cumple con las políticas vigentes en el momento de la entrega.

Solicitudes de conteo (Post count)

Las solicitudes de conteo permiten recuperar conteos de actividad históricos, que reflejan la cantidad de actividades que coinciden con una determinada query durante el periodo solicitado. La respuesta esencialmente proporcionará un histograma de conteos, agrupados por día, hora o minuto (el intervalo predeterminado es hour). Es importante tener en cuenta que los resultados de conteo no siempre reflejan eventos de cumplimiento (p. ej., Posts delete) que ocurren mucho después (más de 7 días) de que se publica un Post; por lo tanto, es de esperar que la métrica de conteo no siempre coincida con la de una solicitud de data para la misma query. Nota sobre facturación: cada solicitud —incluidas las solicitudes de paginación— realizada contra los endpoints de data y de conteos se contabiliza como una solicitud facturable. Por lo tanto, si hay varias páginas de resultados para una sola query, paginar por las X páginas de resultados equivaldría a X solicitudes para la facturación.

Operadores disponibles

Las API de búsqueda de Enterprise admiten reglas de hasta 2.048 caracteres. Las API de búsqueda de Enterprise admiten los operadores enumerados a continuación. Para descripciones detalladas, consulte AQUÍ.


Coincidencia en el contenido de los Post:	Coincidencia en cuentas de interés:	Atributos de Post:	Operadores geoespaciales:
* keyword * “quoted phrase” * “keyword1 keyword2”~N * # * @ * $ * url: * lang:	* from: * to: * retweets_of:	* is:retweet * has:mentions * has:hashtags * has:media * has:videos * has:images * has:links * has:symbols * is:verified * -is:nullcast (operador de negación únicamente)	* 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:

Notas: No incruste/anide operadores. “#cats” se interpretará como cats en las API de búsqueda. El operador ‘lang:’ y todos los operadores ‘is:’ y ‘has:’ no se pueden usar por sí solos y deben combinarse con otra cláusula (p. ej., @XDevelopers has:links). Las API de búsqueda usan un conjunto limitado de operadores debido a la funcionalidad de tokenización y coincidencia. Las API de Enterprise en tiempo real y las históricas por lotes proporcionan operadores adicionales. Consulte AQUÍ para más detalles. Para más detalles, consulte la guía Introducción a los operadores.

Disponibilidad de datos / fechas importantes

Al usar la API de búsqueda de archivo completo, tenga en cuenta que la plataforma X ha seguido evolucionando desde 2006. A medida que se añadieron nuevas funciones, se incorporaron nuevos metadatos a los objetos JSON subyacentes. Por ese motivo, es importante entender cuándo se añadieron los atributos de Post en los que se basan los operadores de búsqueda. A continuación se muestran algunas de las fechas de origen más fundamentales de grupos importantes de metadatos. Para obtener más información sobre cuándo se introdujeron por primera vez los atributos de Post, consulte esta guía.

Primer Post: 21/3/2006
Primeros Retweets nativos: 6/11/2009
Primer Post con etiqueta geográfica: 19/11/2009
URL indexadas por primera vez para filtrado: 27/8/2011
Metadatos mejorados de expansión de URL (títulos y descripciones de sitios web): 1/12/2014
Metadatos y filtrado de enriquecimiento de perfil geográfico: 17/2/2015

Actualizaciones de datos y mutabilidad

Con las APIs de búsqueda de Enterprise, algunos de los datos dentro de un Post son mutables, es decir, pueden actualizarse o cambiar después del archivado inicial. Estos datos mutables se dividen en dos categorías:

Metadatos del objeto de usuario:
- @handle del usuario (el id numérico nunca cambia)
- Descripción de la biografía
- Recuentos: statuses, followers, friends, favorites, lists
- Ubicación del perfil
- Otros detalles como la zona horaria y el idioma
Estadísticas del Post, es decir, cualquier elemento que pueda modificarse en la plataforma por acciones de los usuarios (ejemplos a continuación):
- Recuento de favorites
- Recuento de Retweet

En la mayoría de estos casos, las APIs de búsqueda devolverán data tal como existe en la plataforma en el momento de la query, en lugar del momento de generación del Post. Sin embargo, en el caso de queries que usan operadores select (por ejemplo, from, to, @, is:verified), esto puede no ser así. Los datos se actualizan en nuestro índice de forma periódica, con una mayor frecuencia para los periodos más recientes. Como resultado, en algunos casos, los datos devueltos pueden no coincidir exactamente con los datos actuales mostrados en X.com, sino con los datos del momento en que se indexaron por última vez. Nota: este problema de inconsistencia solo aplica a queries en las que el operador se aplica a datos mutables. Un ejemplo es filtrar por nombres de usuario, y la mejor solución sería usar ids numéricos de usuario en lugar de @handles para estas queries.

Solicitudes de un solo subproceso vs. de múltiples subprocesos

Cada cliente tiene un límite de tasa definido para su endpoint de búsqueda. El límite de tasa predeterminado por minuto para la búsqueda de archivo completo es de 120 solicitudes por minuto, con un promedio de 2 consultas por segundo (QPS). Este QPS promedio significa que, en teoría, se pueden realizar 2 solicitudes a la API cada segundo. Dada la función de paginación del producto, si una query de un año tiene un millón de Posts asociados, distribuidos uniformemente a lo largo del año, se requerirían más de 2,000 solicitudes (suponiendo un ‘maxResults’ de 500) para recibir todos los data. Suponiendo que toma dos segundos por respuesta, eso son 4,000 segundos (o poco más de una hora) para extraer todos esos data de forma secuencial a través de un solo subproceso (1 solicitud por segundo utilizando el token “next” de la respuesta anterior). ¡Nada mal! Ahora considere la situación en la que se utilizan doce subprocesos en paralelo para recibir data. Suponiendo una distribución uniforme del millón de Posts durante el período de un año, podría dividir las solicitudes en doce subprocesos paralelos (multihilo) y aprovechar más del límite de tasa por segundo para el “trabajo” único. En otras palabras, podría ejecutar un subproceso por mes de interés y, al hacerlo, los data podrían recuperarse 12 veces más rápido (o ~6 minutos). Este ejemplo multihilo se aplica igualmente bien al endpoint de conteos. Por ejemplo, si quisiera recibir conteos de Posts para un período de dos años, podría realizar una solicitud de un solo subproceso y retroceder por las páginas de conteos en intervalos de 31 días. Suponiendo que toma 2 segundos por respuesta, tardaría aproximadamente 48 segundos en realizar las 24 solicitudes a la API y recuperar el conjunto completo de conteos. Sin embargo, también tiene la opción de realizar múltiples solicitudes de un mes a la vez. Al realizar 12 solicitudes por segundo, el conjunto completo de conteos podría recuperarse en aproximadamente 2 segundos.

Lógica de reintentos

Si encuentra un error 503 con las API de búsqueda de Enterprise, probablemente sea transitorio y pueda resolverse volviendo a intentar la solicitud poco tiempo después. Si la solicitud falla 4 veces seguidas y ha esperado al menos 10 minutos entre cada intento fallido, siga estos pasos para solucionar el problema:

Vuelva a intentar la solicitud tras reducir el intervalo de tiempo que cubre. Repita esto hasta llegar a una ventana de 6 horas si no tiene éxito.
Si está uniendo un gran número de términos con OR, divídalos en reglas separadas y vuelva a intentar cada una por separado.
Si está utilizando un gran número de exclusiones en su regla, reduzca la cantidad de términos negados en la regla y vuelva a intentar.

Guía rápida

Introducción a la API enterprise Search Posts: 30-Day

La API enterprise Search Posts: 30-Day le proporciona Posts publicados en los últimos 30 días. Los Posts se hacen coincidir y se le devuelven según la query que especifique en su solicitud. Una query es una regla en la que define qué debe contener el Post que recibe. En este tutorial, buscaremos Posts originados desde la cuenta de X @XDevelopers en inglés. Los Posts que recibe en su payload pueden estar en formato data, que le proporciona el payload completo del Post, o pueden estar en formato counts, que le ofrece datos numéricos de conteo de los Posts coincidentes. Usaremos cURL para realizar solicitudes a los endpoints de data y counts. Necesitará lo siguiente:

Una cuenta Enterprise: https://developer.x.com/en/products/x-api/enterprise
Su nombre de usuario, contraseña y nombre de cuenta
La label asociada con su endpoint de búsqueda, tal como se muestra en console.gnip.com

Acceso al endpoint de data

El endpoint de data nos proporcionará el payload completo de Post de los Posts coincidentes. Usaremos los operadores from: y lang: para encontrar Posts publicados por @XDevelopers en inglés. Para ver más operadores, haz clic aquí.

cURL
cURL example

cURL es una herramienta de línea de comandos para obtener o enviar archivos utilizando la sintaxis de URL.Copia la siguiente solicitud de cURL en tu línea de comandos tras realizar los cambios en lo siguiente:

Username <USERNAME> p. ej., email@domain.com
Account name <ACCOUNT-NAME> p. ej., john-doe
Label <LABEL> p. ej., prod
fromDate y toDate p. ej., "fromDate":"201811010000", "toDate":"201811122359"

Tras enviar tu solicitud, se te pedirá la contraseña.

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

Carga útil de la respuesta del endpoint de datos

La carga útil que recibe de su solicitud a la API aparecerá en formato JSON, como se muestra a continuación.

{
	"results": [
		{
			"created_at": "Fri Nov 02 17:18:31 +0000 2018",
			"id": 1058408022936977409,
			"id_str": "1058408022936977409",
			"text": "RT @harmophone: \"El crowdsourcing innovador que permite la colaboración de Tagboard, Twitter y TEGNA está sacando a la luz conversaciones localmente relevantes…",
			"source": "<a href=\"http:\/\/twitter.com\" rel=\"nofollow\">Cliente Web de 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": "Tu fuente oficial para noticias, actualizaciones y eventos de la Plataforma Twitter. ¿Necesitas ayuda técnica? Visita 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": "\"El crowdsourcing innovador que permite la colaboración de Tagboard, Twitter y TEGNA está sacando a la luz conversaciones localmente relevantes… https:\/\/t.co\/w46U5TRTzQ",
				"source": "<a href=\"http:\/\/twitter.com\" rel=\"nofollow\">Cliente Web de 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": "SVP de Producto en @Tagboard. Trabajé con datos, negocios y producto en @Klout y para @LithiumTech; miembro del consejo de @BBI; asesor de @Insightpool. El peor del mundo dibujando en pizarras.",
					"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": "\"El crowdsourcing innovador que permite la colaboración de Tagboard, Twitter y TEGNA está sacando a la luz conversaciones localmente relevantes en tiempo real y permitiendo a los votantes hacer preguntas durante los debates,\" -- @adamostrow, @TEGNA\nMás información: 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 y Tagboard colaboran para llevar el mejor contenido electoral a medios de comunicación con Tagboard…",
									"description": "Por Tyler Singletary, Jefe de Producto, 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"
	}
}

Acceso al endpoint de counts

Con el endpoint de counts, obtendremos la cantidad de Posts originados desde la cuenta @XDevelopers en inglés, agrupados por day.

cURL
cURL example

cURL es una herramienta de línea de comandos para obtener o enviar archivos usando la sintaxis de URL.Copia la siguiente solicitud cURL en tu línea de comandos después de realizar los siguientes cambios:

Nombre de usuario <USERNAME>, p. ej., email@domain.com
Nombre de la cuenta <ACCOUNT-NAME>, p. ej., john-doe
Etiqueta <LABEL>, p. ej., prod
fromDate y toDate, p. ej., "fromDate":"201811010000", "toDate":"201811122359"

Después de enviar tu solicitud, se te solicitará la contraseña.

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

Carga útil de la respuesta del endpoint de conteos

La carga útil que obtienes de tu solicitud a la API se presentará en formato JSON, como se muestra a continuación.

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

¡Buen trabajo! Ahora has accedido correctamente a la API Enterprise Search Posts: 30-Day.

Artículos de referencia

Introducción a enterprise Search Posts: Full-Archive API

La enterprise Search Posts: Full-Archive API proporciona Posts desde el primero publicado en 2006. Los Posts se determinan y se le devuelven según la query que especifique en su solicitud. Una query es una regla en la que define qué debe contener el Post que recibe. En este tutorial, buscaremos Posts que se originan en la cuenta de X @XDevelopers en inglés. Los Posts que recibe en su payload pueden estar en formato data, que proporciona el payload completo del Post, o en formato counts, que brinda datos numéricos de los Posts coincidentes. Usaremos cURL para realizar solicitudes a los endpoints de data y de counts. Necesitará lo siguiente:

[Una cuenta enterprise]https://developer.x.com/en/products/x-api/enterprise
Su nombre de usuario, contraseña y nombre de cuenta
La etiqueta asociada con su endpoint de búsqueda, tal como se muestra en console.gnip.com

cURL
cURL example

cURL es una herramienta de línea de comandos para obtener o enviar archivos usando la sintaxis de URL.Copia la siguiente solicitud cURL en tu línea de comandos tras realizar los cambios en lo siguiente:

Username <USERNAME> p. ej., email@domain.com
Account name <ACCOUNT-NAME> p. ej., john-doe
Label <LABEL> p. ej., prod
fromDate y toDate p. ej., "fromDate":"201802010000", "toDate":"201802282359"

Después de enviar tu solicitud, se te pedirá la contraseña.

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

Carga útil de la respuesta del endpoint de datos

La carga útil que obtienes de tu solicitud a la API aparecerá en formato JSON, como se muestra a continuación.

{
	"results": [
		{
			"created_at": "Fri Nov 02 17:18:31 +0000 2018",
			"id": 1058408022936977409,
			"id_str": "1058408022936977409",
			"text": "RT @harmophone: \"El crowdsourcing innovador que permite la colaboración de Tagboard, Twitter y TEGNA está sacando a la luz conversaciones localmente relevantes…",
			"source": "<a href=\"http:\/\/twitter.com\" rel=\"nofollow\">Cliente Web de 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": "Tu fuente oficial para noticias, actualizaciones y eventos de la Plataforma Twitter. ¿Necesitas ayuda técnica? Visita 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": "\"El crowdsourcing innovador que permite la colaboración de Tagboard, Twitter y TEGNA está sacando a la luz conversaciones localmente relevantes… https:\/\/t.co\/w46U5TRTzQ",
				"source": "<a href=\"http:\/\/twitter.com\" rel=\"nofollow\">Cliente Web de 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": "SVP de Producto en @Tagboard. Trabajé con datos, negocios y producto en @Klout y para @LithiumTech; miembro del consejo de @BBI; asesor de @Insightpool. El peor del mundo dibujando en pizarras.",
					"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": "\"El crowdsourcing innovador que permite la colaboración de Tagboard, Twitter y TEGNA está sacando a la luz conversaciones localmente relevantes en tiempo real y permitiendo a los votantes hacer preguntas durante los debates,\" -- @adamostrow, @TEGNA\nMás información: 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 y Tagboard colaboran para llevar el mejor contenido electoral a medios de comunicación con Tagboard…",
									"description": "Por Tyler Singletary, Jefe de Producto, 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"
	}
}

Acceso al endpoint de counts

Con el endpoint de counts, recuperaremos la cantidad de Posts originados desde la cuenta @XDevelopers en inglés, agrupados por day.

cURL
cURL example

Nombre de usuario <USERNAME> p. ej., email@domain.com
Nombre de la cuenta <ACCOUNT-NAME> p. ej., john-doe
Etiqueta <LABEL> p. ej., prod
fromDate y toDate p. ej., "fromDate":"201802010000", "toDate":"201802282359"

Después de enviar tu solicitud, se te pedirá la contraseña.

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

Cuerpo de la respuesta del endpoint Counts

El payload que obtienes de tu solicitud a la API se presenta en formato JSON, como se muestra a continuación.

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

¡Buen trabajo! Ahora has accedido correctamente a la API de Enterprise Search Posts: Full-Archive.

Artículos de referencia

Guías

Creación de consultas de búsqueda

Operadores de Enterprise

A continuación se muestra una lista de todos los operadores admitidos en las API de búsqueda de Enterprise de X:

API de búsqueda de 30 días de Enterprise
API de búsqueda de archivo completo de Enterprise

Para una comparación en paralelo de los operadores disponibles por producto, consulte AQUÍ.

Operador	Descripción
keyword	Busca una palabra clave tokenizada dentro del cuerpo o las URL de un Post. Esta es una búsqueda tokenizada, lo que significa que tu cadena de palabra clave se comparará con el texto tokenizado del cuerpo del Post: la tokenización se basa en signos de puntuación, símbolos y caracteres separadores del plano básico Unicode. Por ejemplo, un Post con el texto “I like coca-cola” se dividiría en los siguientes tokens: I, like, coca, cola. Estos tokens se compararían luego con la cadena de palabra clave utilizada en tu regla. Para buscar cadenas que contienen signos de puntuación (por ejemplo, coca-cola), símbolos o caracteres separadores, debes usar una búsqueda exacta entre comillas como se describe a continuación. Nota: Con la API de búsqueda, los caracteres acentuados y especiales se normalizan a caracteres latinos estándar, lo que puede cambiar significados en idiomas extranjeros o devolver resultados inesperados: Por ejemplo, “músic” coincidirá con “music” y viceversa. Por ejemplo, frases comunes como “Feliz Año Nuevo!” en español, se indexarían como “Feliz Ano Nuevo”, lo que cambia el significado de la frase. Nota: Este operador buscará tanto en las URL como en las URL expandidas dentro de un Post.
emoji	Busca un emoji dentro del cuerpo de un Post. Los emojis son una búsqueda tokenizada, lo que significa que tu emoji se comparará con el texto tokenizado del cuerpo del Post: la tokenización se basa en signos de puntuación, símbolos/emojis y caracteres separadores del plano básico Unicode. Por ejemplo, un Post con el texto “I like ” se dividiría en los siguientes tokens: I, like, . Estos tokens se compararían luego con el emoji utilizado en tu regla. Ten en cuenta que si un emoji tiene una variante, debes usar “comillas” para agregarlo a una regla.
”exact phrase match”	Busca la frase tokenizada y ordenada dentro del cuerpo o las URL de un Post. Esta es una búsqueda tokenizada, lo que significa que tu cadena de palabra clave se comparará con el texto tokenizado del cuerpo del Post: la tokenización se basa en signos de puntuación, símbolos y caracteres separadores del plano básico Unicode. Nota: Los signos de puntuación no se tokenizan y en su lugar se tratan como espacios en blanco. Por ejemplo, “#hashtag” entre comillas coincidirá con “hashtag” pero no con #hashtag (usa el operador hashtag # sin comillas para buscar hashtags reales). Por ejemplo, “ $cashtag" entre comillas coincidirá con "cashtag" pero no con$ cashtag (usa el operador cashtag $ sin comillas para buscar cashtags reales). Por ejemplo, “Love Snow” coincidirá con “#love #snow” Por ejemplo, “#Love #Snow” coincidirá con “love snow” Nota: Este operador buscará tanto en las URL como en las URL expandidas dentro de un Post.
”keyword1 keyword2”~N	Comúnmente conocido como operador de proximidad, busca un Post donde las palabras clave no estén separadas por más de N tokens entre sí. Si las palabras clave están en orden inverso, no pueden estar separadas por más de N-2 tokens entre sí. Puede tener cualquier número de palabras clave entre comillas. N no puede ser mayor que 6. Ten en cuenta que este operador solo está disponible en las API de búsqueda `enterprise`.
from:	Busca cualquier Post de un usuario específico. El valor debe ser el id numérico de cuenta de X del usuario o el nombre de usuario (excluyendo el carácter @). Consulta AQUÍ o AQUÍ para métodos de búsqueda de id numéricos de cuenta de X.
to:	Busca cualquier Post que sea una respuesta a un usuario en particular. El valor debe ser el id numérico de cuenta del usuario o el nombre de usuario (excluyendo el carácter @). Consulta AQUÍ para métodos de búsqueda de id numéricos de cuenta de X.
url:	Realiza una búsqueda tokenizada (palabra clave/frase) en las URL expandidas de un Post (similar a url_contains). Los tokens y frases que contienen signos de puntuación o caracteres especiales deben estar entre comillas dobles. Por ejemplo, url:“/developer”. Aunque generalmente no se recomienda, si quieres buscar un protocolo específico, enciérralo entre comillas dobles: url:“https://developer.x.com”. Nota: Al usar PowerTrack o Historical PowerTrack, este operador buscará en las URL contenidas dentro del Post original de un Quote Post. Por ejemplo, si tu regla incluye url:“developer.x.com”, y un Post contiene esa URL, cualquier Quote Tweet de ese Post se incluirá en los resultados. Este no es el caso al usar la API de búsqueda.
#	Busca cualquier Post con el hashtag dado. Este operador realiza una búsqueda exacta, NO una búsqueda tokenizada, lo que significa que la regla “2016” coincidirá con Posts que tengan el hashtag exacto “2016”, pero no con aquellos que tengan el hashtag “2016election” Nota: el operador hashtag depende de la extracción de entidades de X para buscar hashtags, en lugar de extraer el hashtag del cuerpo mismo. Consulta AQUÍ para más información sobre los atributos JSON de entidades de X.
@	Busca cualquier Post que mencione el nombre de usuario dado. El operador to: devuelve un subconjunto de resultados del operador @mention.
$	Busca cualquier Post que contenga el ‘cashtag’ especificado (donde el carácter inicial del token es el carácter ’$’). Ten en cuenta que el operador cashtag depende de la extracción de entidades ‘symbols’ de X para buscar cashtags, en lugar de intentar extraer el cashtag del cuerpo mismo. Consulta AQUÍ para más información sobre los atributos JSON de entidades de X. Ten en cuenta que este operador solo está disponible en las API de búsqueda `enterprise`.
retweets_of:	Alias disponible: retweets_of_user: Busca Posts que son Retweets de un usuario especificado. Acepta tanto nombres de usuario como id numéricos de cuenta de X (NO id de estado de Post). Consulta AQUÍ para métodos de búsqueda de id numéricos de cuenta de X.
lang:	Busca Posts que han sido clasificados por X como de un idioma particular (si, y solo si, el Post ha sido clasificado). Es importante tener en cuenta que cada Post actualmente solo se clasifica como de un idioma, por lo que usar AND con múltiples idiomas no producirá resultados. Nota: si no se puede realizar una clasificación de idioma, el resultado proporcionado es ‘und’ (por indefinido). La lista a continuación representa los idiomas actualmente compatibles y su identificador de idioma BCP 47 correspondiente:


Amhárico: am	Alemán: de	Malabar: ml	Eslovaco: sk
Árabe: ar	Griego: el	Maldivo: dv	Esloveno: sl
Armenio: hy	Guyaratí: gu	Maratí: mr	Kurdo soraní: ckb
Vasco: eu	Criollo haitiano: ht	Nepalí: ne	Español: es
Bengalí: bn	Hebreo: iw	Noruego: no	Sueco: sv
Bosnio: bs	Hindi: hi	Oriya: or	Tagalo: tl
Búlgaro: bg	Hindi romanizado: hi-Latn	Punyabí: pa	Tamil: ta
Birmano: my	Húngaro: hu	Pastún: ps	Telugu: te
Croata: hr	Islandés: is	Persa: fa	Tailandés: th
Catalán: ca	Indonesio: in	Polaco: pl	Tibetano: bo
Checo: cs	Italiano: it	Portugués: pt	Chino tradicional: zh-TW
Danés: da	Japonés: ja	Rumano: ro	Turco: tr
Neerlandés: nl	Canarés: kn	Ruso: ru	Ucraniano: uk
Inglés: en	Jemer: km	Serbio: sr	Urdu: ur
Estonio: et	Coreano: ko	Chino simplificado: zh-CN	Uigur: ug
Finés: fi	Lao: lo	Sindhi: sd	Vietnamita: vi
Francés: fr	Letón: lv	Cingalés: si	Galés: cy
Georgiano: ka	Lituano: lt


place:	Coincide con Posts etiquetados con la ubicación especificada o con el place ID de X (consulta los ejemplos). Los nombres de lugares con varias palabras (“New York City”, “Palo Alto”) deben ir entre comillas. Nota: Consulta el endpoint público de la API GET geo/search para saber cómo obtener place IDs de X. Nota: Este operador no coincidirá con Retweets, ya que los lugares de un Retweet están asociados al Post original. Tampoco coincidirá con los lugares asociados al Post original de un Quote Tweet.
place_country:	Coincide con Posts donde el código de país asociado a un place etiquetado coincide con el código ISO alfa-2 proporcionado. Puedes encontrar códigos ISO válidos aquí: http://en.wikipedia.org/wiki/ISO_3166-1_alpha-2 Nota: Este operador no coincidirá con Retweets, ya que los lugares de un Retweet están asociados al Post original. Tampoco coincidirá con los lugares asociados al Post original de un Quote Tweet.
point_radius:[lon lat radius]	Coincide con la ubicación exacta (x, y) del Post cuando está presente y, en X, con un polígono geográfico “Place”, cuando el Place está completamente contenido dentro de la región definida. * Las unidades de radio admitidas son millas (mi) y kilómetros (km). * El radio debe ser menor que 25 mi. * La longitud está en el rango de ±180. * La latitud está en el rango de ±90. * Todas las coordenadas están en grados decimales. * Los argumentos de la regla se incluyen entre corchetes, delimitados por espacios. Nota: Este operador no coincidirá con Retweets, ya que los lugares de un Retweet están asociados al Post original. Tampoco coincidirá con los lugares asociados al Post original de un Quote Tweet.
bounding_box:[west_long south_lat east_long north_lat]	Alias disponible: geo_bounding_box: Coincide con la ubicación exacta (long, lat) del Post cuando está presente y, en X, con un polígono geográfico “Place”, cuando el Place está completamente contenido dentro de la región definida. * west_long y south_lat representan la esquina suroeste del rectángulo envolvente, donde west_long es la longitud de ese punto y south_lat es la latitud. * east_long y north_lat representan la esquina noreste del rectángulo envolvente, donde east_long es la longitud de ese punto y north_lat es la latitud. * El ancho y el alto del rectángulo envolvente deben ser menores que 25 mi. * La longitud está en el rango de ±180. * La latitud está en el rango de ±90. * Todas las coordenadas están en grados decimales. * Los argumentos de la regla se incluyen entre corchetes, delimitados por espacios. Nota: Este operador no coincidirá con Retweets, ya que los lugares de un Retweet están asociados al Post original. Tampoco coincidirá con los lugares asociados al Post original de un Quote Tweet.
profile_country:	Coincidencia exacta con el campo “countryCode” del objeto “address” en el enriquecimiento de Profile Geo. Utiliza un conjunto normalizado de códigos de país de dos letras, basado en la especificación ISO-3166-1-alpha-2. Este operador se proporciona en lugar de uno para el campo “country” del objeto “address” para ser más concisos.
profile_region:	Coincide con el campo “region” del objeto “address” en el enriquecimiento de Profile Geo. Es una coincidencia exacta de la cadena completa. No es necesario escapar caracteres con una barra invertida. Por ejemplo, si se busca una coincidencia con una barra, usa “one/two”, no “one/two”. Usa comillas dobles para hacer coincidir subcadenas que contengan espacios en blanco o signos de puntuación.
profile_locality:	Coincide con el campo “locality” del objeto “address” en el enriquecimiento de Profile Geo. Es una coincidencia exacta de la cadena completa. No es necesario escapar caracteres con una barra invertida. Por ejemplo, si se busca una coincidencia con una barra, usa “one/two”, no “one/two”. Usa comillas dobles para hacer coincidir subcadenas que contengan espacios en blanco o signos de puntuación.

NOTA: Los operadores is: y has: no pueden usarse de forma independiente en la API de Search; deben combinarse con otra cláusula.Por ejemplo, @XDeevelopers has:links


has:geo	Coincide con Posts que tienen datos de geolocalización específicos del Post proporcionados por X. Esto puede ser coordenadas “geo” de latitud-longitud, o una “ubicación” en forma de un “Place” de X, con el nombre de visualización correspondiente, polígono geográfico y otros campos. Nota: Al usar la API de búsqueda, este operador debe usarse junto con otros operadores que no incluyan `is:` o `has:`.
has:profile_geo	Alias disponible: has:derived_user_geo Coincide con Posts que tienen cualquier metadata de Profile Geo, independientemente del valor real. Nota: Al usar la API de búsqueda, este operador debe usarse junto con otros operadores que no incluyan `is:` o `has:`.
has:links	Este operador coincide con Posts que contienen enlaces en el cuerpo del mensaje. Nota: Al usar la API de búsqueda, este operador debe usarse junto con otros operadores que no incluyan `is:` o `has:`.
is:retweet	Entrega solo retweets explícitos que coincidan con una regla. También puede negarse para excluir retweets que coincidan con una regla de la entrega y solo se entrega contenido original. Este operador busca solo Retweets verdaderos, que usan la funcionalidad de retweet de X. Los Tweets citados y Posts modificados que no usan la funcionalidad de retweet de X no coincidirán con este operador. Nota: Al usar la API de búsqueda, este operador debe usarse junto con otros operadores que no incluyan `is:` o `has:`.
is:reply	Un operador para filtrar Posts según si son o no respuestas a Posts. Entrega solo respuestas explícitas que coincidan con una regla. También puede negarse para excluir respuestas que coincidan con una regla de la entrega. Tenga en cuenta que este operador está disponible para búsqueda premium y Enterprise pagada y no está disponible en entornos de desarrollo Sandbox. Nota: Al usar la API de búsqueda, este operador debe usarse junto con otros operadores que no incluyan `is:` o `has:`.
is:quote	Entrega solo Quote Tweets, o Posts que referencian otro Post, identificados por el “is_quote_status”:true en las cargas útiles de Post. También puede negarse para excluir Quote Tweets. Nota: Al usar la API de búsqueda, este operador debe usarse junto con otros operadores que no incluyan `is:` o `has:`.
is:verified	Entrega solo Posts donde el autor está “verificado” por X. También puede negarse para excluir Posts donde el autor está verificado. Nota: Al usar la API de búsqueda, este operador debe usarse junto con otros operadores que no incluyan `is:` o `has:`.
has:mentions	Coincide con Posts que mencionan a otro usuario de X. Nota: Al usar la API de búsqueda, este operador debe usarse junto con otros operadores que no incluyan `is:` o `has:`.
has:hashtags	Coincide con Posts que contienen un hashtag. Nota: Al usar la API de búsqueda, este operador debe usarse junto con otros operadores que no incluyan `is:` o `has:`.
has:media	Alias disponible: has:media_link Coincide con Posts que contienen una URL de medios clasificada por X. Por ejemplo, pic.x.com. Nota: Al usar la API de búsqueda, este operador debe usarse junto con otros operadores que no incluyan `is:` o `has:`.
has:images	Coincide con Posts que contienen una URL de medios clasificada por X. Por ejemplo, pic.x.com. Nota: Al usar la API de búsqueda, este operador debe usarse junto con otros operadores que no incluyan `is:` o `has:`.
has:videos	Alias disponible: has:video_link Coincide con Posts que contienen videos nativos de X, subidos directamente a X. Esto no coincidirá con videos creados con Vine, Periscope, o Posts con enlaces a otros sitios de alojamiento de videos. Nota: Al usar la API de búsqueda, este operador debe usarse junto con otros operadores que no incluyan `is:` o `has:`.
has:symbols	Coincide con Posts que contienen un símbolo cashtag (con un carácter ‘ $' inicial. Por ejemplo,$ tag). Tenga en cuenta que este operador solo está disponible en las APIs de búsqueda `Enterprise`. Nota: Al usar la API de búsqueda, este operador debe usarse junto con otros operadores que no incluyan `is:` o `has:`.

Descripción del producto

La Full-archive Search de nivel Enterprise se lanzó en agosto de 2015 y la versión de nivel premium en febrero de 2018. Estos productos de búsqueda permiten a los clientes acceder de inmediato a cualquier Post disponible públicamente. Con Full-archive Search, envía una única query y recibe una respuesta en el estilo RESTful clásico. Full-archive Search implementa paginación de hasta 500 Posts por respuesta y admite hasta 60 solicitudes por minuto (rpm) para premium y 120 rpm para Enterprise. Dado lo anterior, Full-archive Search puede usarse para recuperar Posts rápidamente y a gran escala mediante solicitudes concurrentes. A diferencia de Historical PowerTrack, cuyo archivo se basa en un conjunto de archivos planos de Post en disco, el archivo de Posts de Full-archive Search es muy parecido a una base de datos en línea. Como en todas las bases de datos, admite realizar consultas sobre su contenido. También utiliza un índice para habilitar la recuperación de data de alto rendimiento. Con los endpoints de Full-archive Search, el lenguaje de consulta está compuesto por PowerTrack Operators, y cada uno de estos Operators corresponde a un atributo JSON de Post que está indexado. Además, al igual que Historical PowerTrack, hay atributos de Post que son actuales al momento en que se realiza una query. Por ejemplo, si está utilizando Search API para acceder hoy a un Post publicado en 2010, la descripción del perfil del usuario, la ubicación “home” de la cuenta, el nombre para mostrar y las metrics de Post para los conteos de likes y Retweet se actualizarán a los valores de hoy y no a los que tenían en 2010.

Cronologías de metadatos

A continuación se muestra una cronología de cuándo los operadores del endpoint de Full-archive search empiezan a aplicar coincidencias. En algunos casos, la coincidencia por parte de los operadores comenzó mucho después de que una “convención de comunicación” se volviera común en X. Por ejemplo, las @Replies surgieron como convención de los usuarios en 2006, pero no se convirtieron en un objeto de primera clase o evento con JSON de “soporte” hasta principios de 2007. En consecuencia, hacer coincidir @Replies en 2006 requiere examinar el cuerpo del Post, en lugar de depender de los operadores de PowerTrack to: e in_reply_to_status_id:. Los detalles proporcionados aquí se generaron utilizando Full-Archive Search (resultado de cientos de búsquedas). Esta cronología no es 100% completa ni precisa. Si identifica otra “fecha de nacimiento” de filtrado/metadatos fundamental para su caso de uso, háganoslo saber. Tenga en cuenta que el índice de búsqueda subyacente puede reconstruirse. En consecuencia, estos detalles de la cronología están sujetos a cambios.

2006

26 de marzo - lang:. Un ejemplo de metadatos de Post que se rellenan retrospectivamente mientras se genera el índice de búsqueda.
13 de julio - has:mentions empieza a coincidir.
6 de octubre - has:symbols. Los $cashtags (o símbolos) para hablar de símbolos bursátiles no se vuelven comunes hasta principios de 2009. Hasta entonces, la mayoría de los usos probablemente eran jerga (p. ej.,$ slang).
26 de octubre - has:links empieza a coincidir.
23 de noviembre - has:hashtags empieza a coincidir.

2007

30 de enero: Primera @reply de primera clase (in_reply_to_user_id); reply_to_status_id: comienza a coincidir.
23 de agosto: Los hashtags surgen como una convención común para organizar temas y conversaciones. Primer uso real una semana después.

2009

15 de mayo - is:retweet. Tenga en cuenta que este Operador comienza a aplicarse con el lanzamiento “beta” de los Retweets oficiales y su patrón “Via @”. Durante este período beta, el verbo del Post es “post” y el Post original no se incluye en el payload.
13 de agosto - Se lanza la versión final de los Retweets oficiales con el patrón “RT @”, un verbo establecido en “share” y el atributo “retweet_status” que contiene el Post original (lo que aproximadamente duplica el tamaño del payload JSON).

2010

6 de marzo: los operadores geográficos has:geo, bounding_box: y point_radius: comienzan a aplicar coincidencias.
28 de agosto: has:videos (Hasta febrero de 2015, este operador coincide con Posts que contienen enlaces a sitios seleccionados de alojamiento de video como youtube.com, vimeo.com y vivo.com).

2011

20 de julio: has:media y has:images comienzan a hacer coincidencia. Las fotos nativas se anunciaron oficialmente el 9 de agosto de 2010.

2014

3 de diciembre - (Aproximadamente) Algunos Enhanced URL metadata con título y descripción HTML comienzan a incluirse en los payloads. Los metadatos mejorados se consolidaron más plenamente en mayo de 2016.

2015

10 de febrero: has:videos coincide con los videos “nativos” de X.
17 de febrero: has:profile_geo, profile_country:, profile_region:, profile_locality: Los operadores de Profile Geo comienzan a aplicar coincidencias.
17 de febrero: Los operadores de geolocalización de Post place_country: y place: comienzan a aplicar coincidencias.

2016

1 de mayo: Metadatos de URL mejorados disponibles de forma más amplia, y anunciados oficialmente como parte del lanzamiento de Gnip 2.0 en agosto de 2016. No hay operadores asociados para estos metadatos en las APIs de búsqueda.

2017

22 de febrero: Los metadatos de las encuestas están disponibles en formato nativo enriquecido. No hay operadores asociados para estos metadatos.

2022

27 de septiembre: Todos los Objetos de Post creados desde esta fecha tienen disponible la metadatos de Post editado. Todos los endpoints de Enterprise que proporcionan Objetos de Post se actualizaron para ofrecer estos metadatos a partir de esta fecha. Los metadatos de edición proporcionados incluyen los objetos edit_history y edit_controls. Estos metadatos no se devolverán para Posts creados antes del 27 de septiembre de 2022. Actualmente, no hay Operadores de Enterprise disponibles que coincidan con estos metadatos. Para obtener más información sobre los metadatos de Edit Post, consulta la página Edit Posts fundamentals.

2022

29 de septiembre: todos los objetos de Post creados desde esta fecha tienen disponible los metadatos de Post editado. Todos los endpoints de Enterprise que proporcionan objetos de Post se actualizaron para ofrecer estos metadatos a partir de esta fecha. Los metadatos de edición proporcionados incluyen los objetos edit_history y edit_controls. Estos metadatos no se devolverán para Posts creados antes del 27 de septiembre de 2022. Actualmente, no hay Operadores de Enterprise disponibles que coincidan con estos metadatos. Para obtener más información sobre los metadatos de Edit Post, consulta la página Fundamentos de edición de Posts.

Consejos de filtrado

Con toda la información de la cronología anterior, está claro que hay muchos detalles que considerar al escribir filtros para las Search APIs. Hay dos aspectos clave a tener en cuenta:

Algunos metadatos tienen fechas de “origen”, por lo que los filtros pueden producir falsos negativos. Estas búsquedas incluyen operadores que dependen de metadatos que no existían durante todo o parte del período de búsqueda. Por ejemplo, si busca Posts con el operador has:images, no obtendrá coincidencias en períodos anteriores a julio de 2011. Esto se debe a que ese operador hace coincidir fotos nativas (adjuntas a un Post usando la interfaz de usuario de X). Para obtener un conjunto de datos más completo de Posts de compartición de fotos, los filtros anteriores a julio de 2011 deberían incluir cláusulas de regla que coincidan con URLs comunes de alojamiento de fotos.
Algunos metadatos se han rellenado a posteriori con información de un momento posterior al que se publicó el Post en X.

Hay varios tipos de atributos en los que comúnmente se pone el foco al crear consultas de PowerTrack:

Perfiles de X
Posts originales o compartidos
Clasificación del idioma del Post
Georreferenciación de Posts
Medios de enlaces compartidos

Algunos de estos tienen un comportamiento específico del producto, mientras que otros tienen un comportamiento idéntico. Consulte a continuación para más detalles.

Perfiles de X

Las APIs de Search ofrecen Posts históricos junto con los datos del perfil del usuario tal como están en el momento de la recuperación. Si solicitas un Post de 2014, los metadatos del perfil del usuario reflejarán su estado en el momento de la query.

Posts originales y Retweets

El operador de PowerTrack _is:retweet_ permite incluir o excluir Retweets. Quienes lo utilicen necesitan dos estrategias para identificar (o no) Retweets en los datos anteriores a agosto de 2009. Antes de esa fecha, es necesario revisar el contenido del propio Post y buscar coincidencias exactas con el patrón “@RT ” (de hecho, si filtras Retweets entre mayo y agosto de 2009, también debes incluir el patrón “Via @”). Para los periodos posteriores a agosto de 2009, el operador is:retweet está disponible.

Clasificaciones de idioma de los Post

Para filtrar por la clasificación de idioma de un Post, los productos históricos de X difieren notablemente. Cuando se creó el archivo de búsqueda, todos los Posts se rellenaron retroactivamente con la clasificación de idioma de X. Por lo tanto, el operador lang: está disponible para todo el archivo de Posts.

Georreferenciación de Posts

Hay tres formas principales de georreferenciar Posts:

Referencias geográficas en el mensaje del Post. La coincidencia basada en referencias geográficas en el mensaje del Post, aunque a menudo es el método más desafiante porque depende del conocimiento local, es una opción para todo el archivo de Posts. Aquí hay un ejemplo de coincidencia georreferenciada de 2006 para el área de San Francisco basada en un filtro de ‘golden gate’.
Posts geotagueados por el usuario. Con las API de búsqueda, la posibilidad de empezar a hacer coincidencias en Posts con algunos Operadores Geo comenzó en marzo de 2010, y con otros en febrero de 2015:
- 6 de marzo de 2010: has:geo, bounding_box: y point_radius:
- 17 de febrero de 2015: place_country: y place:
Ubicación “home” del perfil de la cuenta establecida por el usuario. Los Operadores Geo de Perfil están disponibles tanto en Historical PowerTrack como en las API de búsqueda. Con las API de búsqueda, estos metadatos de Perfil Geo están disponibles a partir de febrero de 2015. Para Posts publicados antes de que los metadatos de Perfil Geo estuvieran disponibles, está disponible el operador bio_location:, que puede usarse para hacer coincidencias con entradas de usuario no normalizadas.

Enlaces y contenido multimedia compartidos

En marzo de 2012 se introdujo el enriquecimiento de URL ampliada. Antes de esa fecha, las cargas útiles de los Posts incluían solo la URL tal como la proporcionaba el usuario. Por lo tanto, si el usuario incluía una URL acortada, podía resultar difícil hacer coincidencias con las URL (ampliadas) de interés. Con las Search APIs, estos metadatos están disponibles a partir de marzo de 2012. En julio de 2016 se introdujo el enriquecimiento de URL mejoradas. Esta versión mejorada incorpora el título y la descripción HTML de un sitio web en la carga útil del Post, junto con Operators para hacer coincidencias con ellos. Estos metadatos comienzan a aparecer en diciembre de 2014. En septiembre de 2016, X introdujo los “native attachments”, donde un enlace compartido final no se contabiliza dentro del límite de 140 caracteres del Post. Ambos enriquecimientos de URL siguen aplicándose a estos enlaces compartidos. A continuación se indica cuándo empiezan a hacer coincidencias los Search Operators relacionados:

26 de octubre de 2006 - has:links
20 de julio de 2011 - has:images y has:media
Agosto de 2011 - url: con el enriquecimiento Expanded URLs Ya en septiembre de 2006, (url:"spotify.com" OR url:gnip OR url:microsoft OR url:google OR url:youtube) hace coincidencia con http://x.com/Adam/statuses/16602, aunque no hay metadatos urls[] en twitter_entities ni en los objetos gnip. “youtube.com” es un ejemplo de contenido del mensaje que, sin ningún metadato urls[], hace coincidencia con url:youtube.
10 de febrero de 2015 - has:videos para videos nativos. Entre 2010/08/28 y 2015/02/10, este Operator hace coincidencia con Posts con enlaces a sitios de alojamiento de video seleccionados, como youtube.com, vimeo.com y vivo.com.
1 de mayo de 2016 - url_title: y url_description:, basados en el enriquecimiento Enhanced URLs, disponibilidad general. Los primeros metadatos de Enhanced URL comenzaron a aparecer en diciembre de 2014.

Preguntas frecuentes (FAQ)

Preguntas generales sobre la API de búsqueda de Posts

La cantidad de Posts que recibo con el endpoint data no coincide con la cantidad de Posts identificados por el endpoint de recuentos. ¿Por qué ocurre esto?

Existe una diferencia conocida entre los resultados que proporciona el endpoint de conteos y el endpoint de data. Puede observar una discrepancia en sus resultados porque el endpoint de conteos es previo a la conformidad (es decir, no contempla elementos como Posts eliminados, scrub_geo, etc.), mientras que el endpoint de data es conforme en el momento de la entrega y contempla todos los eventos de conformidad.

No recibí un Post que debería coincidir con mi parámetro query. ¿Por qué?

Hay algunas razones por las que esto podría haber ocurrido, entre ellas:

el Post que esperabas ver pertenece a una cuenta protegida
el endpoint de data considera todos los eventos de cumplimiento (lo que significa que los Posts eliminados, las geolocalizaciones depuradas, etc., no se incluirán en la respuesta).

Mi query coincidió con un Post pero includes una palabra clave que negué. ¿Por qué está sucediendo esto?

Es probable que esto se deba a un uso incorrecto de nuestras reglas premium y del filtrado. Por favor, revisa nuestra documentación aquí y asegúrate de comprender las restricciones relativas a la creación de reglas.

¿Existen bibliotecas que pueda usar para comenzar a utilizar las APIs de Search Post?

Sí, existen, entre ellas:

Tweepy - ideal para usar el producto estándar de búsqueda/Posts (Python)
X API - ideal para usar las APIs estándar de Search Post (Python)
Search Posts Python y Search Posts Ruby - dos herramientas muy útiles para usar con las APIs de Search Post de Enterprise (¡y v2!)

Todas las bibliotecas que admitimos directamente se encuentran en nuestra página de GitHub de xdevplatform: https://github.com/xdevplatform.Hay otras bibliotecas de terceros que también pueden ser útiles; sin embargo, tenga en cuenta que algunas pueden no funcionar con nuestros productos premium y Enterprise.

¿Recibiré alguna vez un volumen de Posts menor que el valor que establecí como `maxResults` en mi solicitud al endpoint de datos?

Sí. Nuestro endpoint de data pagina según el maxResults especificado o después de 30 días.Por ejemplo, si tienes 800 Posts en un período de 30 días, tendrás que hacer dos solicitudes para obtener los resultados completos, porque el número máximo de Posts que se pueden devolver por solicitud es 500 (maxResults). Y si solo tienes 400 Posts en el primer mes y luego 100 Posts en el segundo, también tendrás que usar dos solicitudes para obtener los resultados completos, porque la paginación se realiza después de un período de 30 días incluso si la primera solicitud devuelve menos Posts que el maxResults especificado.

¿En qué orden se devuelven los Posts coincidentes?

Los Posts se devuelven en orden cronológico inverso. Por ejemplo, la primera página de resultados mostrará los Posts más recientes que coincidan con la query; la paginación continuará hasta que las fechas de publicación de los resultados alcancen el fromDate solicitado inicialmente.

¿Cómo afectan los Edit Posts a mi uso y facturación?

Solo el Post original contará a efectos de facturación. Cualquier edición posterior se ignorará y no se sumará a su recuento general de actividad. Enterprise

Me interesa conocer más sobre los precios de la API de Search Post para Enterprise y solicitar esta oferta. ¿Cómo puedo hacerlo?

Nuestras soluciones Enterprise se personalizan con precios predecibles para satisfacer las necesidades de su empresa. Solicite más información aquí.

¿Cómo creo un conjunto de reglas que se ajuste a mi caso de uso?

Consulte nuestra documentación de las APIs de búsqueda de Post para Enterprise aquí
Puede encontrar información útil sobre reglas y filtrado aquí
Puede encontrar información útil sobre el uso del endpoint data aquí
Puede encontrar información útil sobre el uso del endpoint counts aquí
Puede encontrar una lista de operadores disponibles aquí

He superado mis topes/límites de solicitudes del mes, pero necesito acceder a más data; ¿qué puedo hacer?

Póngase en contacto con su gerente de cuenta en X, quien podrá ayudarle con esto.

Guía de resolución de errores

Código 404 - No encontrado

Asegúrate de usar los parámetros correctos para cada endpoint (p. ej., el campo buckets solo puede usarse con el endpoint de counts, no con el endpoint de data).
Verifica que los campos :product, :account_name y :label sean correctos. Puedes encontrar tu campo :label en la GNIP Console (solo para clientes Enterprise).

Referencia de API

APIs de búsqueda Enterprise

Hay dos APIs de búsqueda Enterprise:

30-Day Search API: proporciona Tweets publicados en los últimos 30 días.
Full-Archive Search API: proporciona Tweets desde tan atrás como 2006, comenzando con el primer Tweet publicado en marzo de 2006.

Estas APIs de búsqueda comparten un diseño común y la documentación a continuación aplica a ambas. Tenga en cuenta que, para los Tweets creados a partir del 29 de septiembre de 2022, los objetos Tweet incluirán metadatos de edición de Tweet que describen su historial de ediciones. Consulte la página de fundamentos “Edit Tweets” para más detalles. A continuación encontrará detalles importantes necesarios al integrarse con las APIs de búsqueda Enterprise:

Métodos para solicitar datos y conteos de Tweets
Autenticación
Paginación
Parámetros de solicitud de la API y solicitudes de ejemplo
Cargas JSON de respuesta de la API y respuestas de ejemplo
Códigos de respuesta HTTP

Las APIs Enterprise proporcionan acceso de baja latencia y alta fidelidad, basado en query, al archivo de Tweets. La única diferencia entre ambas APIs es el período que puede buscar, ya sea los 30 días previos o desde tan atrás como 2006. Los períodos pueden especificarse con granularidad de minutos. Los datos de Tweet se entregan en orden cronológico inverso, comenzando con el Tweet más reciente que coincide con su query. Los Tweets están disponibles en la API de búsqueda aproximadamente 30 segundos después de publicarse.

Métodos

El URI base para la búsqueda de Enterprise es https://gnip-api.x.com/search/.

Método	Descripción
POST /search/:product/accounts/:account_name/:label	Recupera Tweets de los últimos 30 días que coinciden con la regla de PowerTrack especificada.
POST /search/:product/accounts/:account_name/:label/counts	Recupera el número de Tweets de los últimos 30 días que coinciden con la regla de PowerTrack especificada.

Donde:

:product indica el endpoint de búsqueda al que realiza solicitudes, ya sea 30day o fullarchive.
:account_name es el nombre (sensible a mayúsculas y minúsculas) asociado con su cuenta, tal como se muestra en console.gnip.com
:label es la etiqueta (sensible a mayúsculas y minúsculas) asociada con su endpoint de búsqueda, tal como se muestra en console.gnip.com

Por ejemplo, si la cuenta TwitterDev tiene el producto de búsqueda de 30 días con una etiqueta ‘prod’ (abreviatura de production), los endpoints de búsqueda serían:

Endpoint de datos: https://gnip-api.x.com/search/30day/accounts/TwitterDev/prod.json
Endpoint de conteos: https://gnip-api.x.com/search/30day/accounts/TwitterDev/prod/counts.json

Su endpoint completo de la API de búsqueda de Enterprise se muestra en https://console.gnip.com. A continuación se muestran varias solicitudes de ejemplo con una utilidad HTTP sencilla llamada curl. Estos ejemplos utilizan URL con :product, :account_name y :label. Para usar estos ejemplos, asegúrese de actualizar las URL con sus datos.

Autenticación

Todas las solicitudes a las APIs de búsqueda de Enterprise deben usar la autenticación básica de HTTP (HTTP Basic Authentication), construida a partir de una combinación válida de dirección de correo electrónico y contraseña utilizada para iniciar sesión en su cuenta en https://console.gnip.com. Las credenciales deben enviarse en el encabezado Authorization de cada solicitud.

Comportamiento de solicitud/respuesta

Con los parámetros fromDate y toDate, puedes solicitar cualquier periodo de tiempo que la API admita. La API de búsqueda de 30 días proporciona Tweets de los 31 días más recientes (aunque se denomine “API de 30 días”, pone a disposición 31 días para permitir solicitudes de mes completo). La API de búsqueda de archivo completo proporciona Tweets desde el primer Tweet (21 de marzo de 2006). Sin embargo, una única respuesta estará limitada al menor valor entre tu maxResults especificado o 31 días. Si los datos coincidentes o tu rango de tiempo superan tu maxResults especificado o 31 días, recibirás un token next que debes usar para paginar el resto de tu rango de tiempo. Por ejemplo, supongamos que estás usando la búsqueda de archivo completo y quieres todos los Tweets que coincidan con tu query desde el 1 de enero de 2017 hasta el 30 de junio de 2017. Especificarás ese periodo completo de seis meses en tu solicitud usando los parámetros fromDate y toDate. La API de búsqueda responderá con la primera “página” de Tweets, con la cantidad de Tweets que coincida con tu parámetro maxResults (que por defecto es 100). Suponiendo que haya más Tweets (y lo más probable es que los haya), la API también proporcionará un token next que te permitirá solicitar la siguiente “página” de data. Este proceso se repetirá hasta que la API deje de devolver un token next. Consulta la siguiente sección para más detalles.

Paginación

Al realizar solicitudes de data y de conteo, es probable que haya más data de la que puede devolverse en una sola respuesta. En ese caso, la respuesta incluirá un token “next”. El token “next” se proporciona como un atributo JSON de nivel raíz. Siempre que se proporcione un token “next”, habrá data adicional por recuperar, por lo que deberá seguir realizando solicitudes a la API. Nota: El comportamiento del token “next” difiere ligeramente entre las solicitudes de data y las de conteo; a continuación se describen ambas, con respuestas de ejemplo en la sección API Reference.

Paginación de datos

Es probable que las solicitudes generen más datos de los que se pueden devolver en una sola respuesta. Cada solicitud incluye un parámetro que define el número máximo de Tweets a devolver por solicitud. El parámetro maxResults tiene un valor predeterminado de 100 y puede establecerse en un rango de 10 a 500. Si tu query coincide con más Tweets que el valor de maxResults usado en la solicitud, la respuesta incluirá un token next (como un atributo JSON de nivel raíz). Este token next se utiliza en la solicitud siguiente para recuperar la siguiente parte de los Tweets que coinciden con esa query (es decir, la siguiente “página”). Se seguirán proporcionando tokens next hasta que hayas llegado a la última “página” de resultados para esa query, momento en el que no se proporcionará un token next. Para solicitar la siguiente “página” de datos, debes realizar exactamente la misma query que la original, incluidos los parámetros query, toDate y fromDate, si se usaron, y además incluir un parámetro de solicitud next con el valor devuelto en la respuesta anterior. Esto puede utilizarse tanto con una solicitud GET como POST. Sin embargo, en el caso de una solicitud GET, el parámetro next debe ir codificado en la URL. Puedes seguir pasando el elemento next de tu query anterior hasta que hayas recibido todos los Tweets del período cubierto por tu query. Cuando recibas una respuesta que no incluya un elemento next, significa que has llegado a la última página y no hay datos adicionales disponibles para la query y el intervalo de tiempo especificados.

Paginación de recuentos

El endpoint ‘counts’ proporciona volúmenes de Tweets asociados con una query en base diaria, por hora o por minuto. El endpoint de la API ‘counts’ devolverá un arreglo con marca de tiempo de recuentos para un máximo de 31 días de carga de recuentos. Si solicita más de 31 días de recuentos, se le proporcionará un token ‘next’. Al igual que con los tokens ‘next’ de data, debe realizar la misma query exacta que la original y también incluir un parámetro de solicitud ‘next’ configurado con el valor de la respuesta anterior. Además de solicitar más de 31 días de recuentos, hay otro escenario en el que se proporciona un token ‘next’. Para queries de mayor volumen, existe la posibilidad de que la generación de recuentos tome suficiente tiempo como para activar un tiempo de espera de la respuesta. Cuando esto ocurra, recibirá menos de 31 días de recuentos, pero se le proporcionará un token ‘next’ para continuar realizando solicitudes hasta obtener toda la carga de recuentos. Importante: Los tiempos de espera solo emiten “buckets” completos; por lo tanto, 2,5 días darían como resultado 2 “buckets” de día completos.

Notas adicionales

Al usar fromDate o toDate en una solicitud de búsqueda, solo obtendrá resultados dentro de su rango temporal. Cuando alcance el último grupo de resultados dentro de ese rango, no recibirá un token “next”.
El elemento “next” se puede usar con cualquier valor de maxResults entre 10 y 500 (valor predeterminado: 100). maxResults determina cuántos Tweets se devuelven en cada respuesta, pero no impide que eventualmente obtenga todos los resultados.
El elemento “next” no caduca. Varias solicitudes que usen la misma query “next” recibirán los mismos resultados, independientemente de cuándo se haga la solicitud.
Al paginar los resultados con el parámetro “next”, puede encontrar duplicados en los límites de la query. Su aplicación debe tolerarlos.

Endpoint de datos

POST /search/:product/:label

Patrón del endpoint:

Este endpoint devuelve data para la query y el periodo de tiempo especificados. Si no se especifica un periodo de tiempo, los parámetros de tiempo tendrán por defecto los últimos 30 días. Nota: Esta funcionalidad también puede realizarse mediante una solicitud GET, en lugar de POST, codificando en la URL los parámetros descritos a continuación.

Parámetros de solicitud de datos

Parámetros	Descripción	Obligatorio	Valor de ejemplo
query	Equivale a una regla de PowerTrack, con hasta 2.048 caracteres (sin límites en la cantidad de cláusulas positivas o negativas). Este parámetro debe incluir TODAS las partes de la regla de PowerTrack, incluidos todos los operadores; no se deben separar partes de la regla en otros parámetros de la query. Nota: No todos los operadores de PowerTrack son compatibles. Los operadores compatibles se enumeran AQUÍ.	Sí	(snow OR cold OR blizzard) weather
tag	Las etiquetas pueden usarse para segmentar las reglas y sus datos coincidentes en diferentes grupos lógicos. Si se proporciona una etiqueta de regla, esta se incluye en el atributo ‘matching_rules’. Se recomienda asignar UUID específicos de regla a las etiquetas y mantener los mapeos deseados del lado del cliente.	No	8HYG54ZGTU
fromDate	La marca de tiempo UTC más antigua (hasta el 21/03/2006 con la búsqueda de archivo completo) desde la cual se proporcionarán los Tweets. La marca de tiempo tiene granularidad de minutos y es inclusiva (p. ej., 12:00 incluye el minuto 00). Especificado: Usar solo fromDate sin el parámetro toDate entregará resultados para la query retrocediendo en el tiempo desde now( ) hasta fromDate. No especificado: Si no se especifica fromDate, la API entregará todos los resultados de los 30 días anteriores a now( ) o a toDate (si se especifica). Si no se usa ni el parámetro fromDate ni toDate, la API entregará todos los resultados de los 30 días más recientes, comenzando en el momento de la solicitud y yendo hacia atrás.	No	201207220000
toDate	La marca de tiempo UTC más reciente hasta la cual se proporcionarán los Tweets. La marca de tiempo tiene granularidad de minutos y no es inclusiva (p. ej., 11:59 no incluye el minuto 59 de la hora). Especificado: Usar solo toDate sin el parámetro fromDate entregará los 30 días más recientes de datos anteriores a toDate. No especificado: Si no se especifica toDate, la API entregará todos los resultados desde now( ) para la query retrocediendo en el tiempo hasta fromDate. Si no se usa ni fromDate ni toDate, la API entregará todos los resultados de todo el índice de 30 días, comenzando en el momento de la solicitud y yendo hacia atrás.	No	201208220000
maxResults	El número máximo de resultados de búsqueda que se devolverán en una solicitud. Un número entre 10 y el límite del sistema (actualmente 500). De forma predeterminada, la respuesta de una solicitud devolverá 100 resultados.	No	500
next	Este parámetro se usa para obtener la siguiente “página” de resultados, como se describe AQUÍ. El valor usado con el parámetro se toma directamente de la respuesta proporcionada por la API y no debe modificarse.	No	NTcxODIyMDMyODMwMjU1MTA0

Detalles adicionales


Periodo de disponibilidad	30 días: últimos 31 días Archivo completo: 21 de marzo de 2006 - presente
Formato de query	Equivalente a una regla de PowerTrack, con hasta 2.048 caracteres (y sin límites en la cantidad de cláusulas positivas o negativas). Nota: No todos los operadores de PowerTrack son compatibles. Consulta Available operators para ver la lista de operadores compatibles.
Límite de tasa	Los partners estarán sujetos a límites de tasa con granularidad por minuto y por segundo. El límite por minuto variará según el partner, tal como se especifica en tu contrato. Sin embargo, estos límites por minuto no están pensados para consumirse en una sola ráfaga. Independientemente de tu límite por minuto, todos los partners estarán limitados a un máximo de 20 solicitudes por segundo, agregadas entre todas las solicitudes de data y/o recuentos.
Cumplimiento	Toda la data entregada a través de la Full-Archive Search API cumple con las políticas al momento de la entrega.
Disponibilidad en tiempo real	La data está disponible en el índice dentro de los 30 segundos posteriores a su generación en la plataforma de Twitter

Ejemplos de solicitudes y respuestas de data

Ejemplo de solicitud POST

Los parámetros de una solicitud POST se envían en un cuerpo con formato JSON, como se muestra a continuación.
Todas las partes de la regla de PowerTrack que se desea consultar (p. ej., palabras clave u otros operadores como bounding_box:) deben colocarse en el parámetro ‘query’.
No separe partes de la regla como parámetros independientes en la URL de la consulta.

A continuación se muestra un ejemplo de comando POST (con cURL) para realizar una solicitud inicial 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 respuesta de la API incluye un token ‘next’, a continuación se muestra una solicitud subsiguiente que es la misma solicitud original, con el parámetro ‘next’ configurado en el token proporcionado:

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

Ejemplo de solicitud GET

Los parámetros en una solicitud GET se codifican en la URL mediante la codificación estándar de URL.
Todas las partes de la regla de PowerTrack que se van a consultar (p. ej., palabras clave u otros operadores como bounding_box:) deben incluirse en el parámetro ‘query’.
No divida partes de la regla en parámetros independientes dentro de la URL de la consulta.

A continuación se muestra un ejemplo de comando GET (con cURL) para realizar una solicitud inicial de data:

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

Ejemplos de respuestas de data

Tenga en cuenta que, para los Tweets creados a partir del 29 de septiembre de 2022, los objetos de Tweet incluirán metadatos de edición de Tweet que describen su historial de ediciones. Consulte la página de fundamentos “Edit Tweets” para obtener más detalles. A continuación se muestra un ejemplo de respuesta a una query de data. Este ejemplo supone que había más de ‘maxResults’ Tweets disponibles, por lo que se proporciona un token ‘next’ para solicitudes posteriores. Si ‘maxResults’ o menos Tweets están asociados con su query, no se incluirá ningún token ‘next’ en la respuesta. El valor del elemento ‘next’ cambiará con cada query y debe tratarse como una cadena opaca. El elemento ‘next’ tendrá el siguiente aspecto en el cuerpo de la respuesta:

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

La respuesta a una solicitud posterior podría verse así (observe los nuevos Tweets y el valor diferente de “next”):

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

Puede seguir pasando el elemento “next” de su query anterior hasta que haya recibido todos los Tweets del periodo de tiempo cubierto por su query. Cuando reciba una respuesta que no incluya un elemento “next”, significa que ha llegado a la última página y no hay data adicional disponible en su intervalo de tiempo.

endpoint de conteos

/search/:stream/counts

Patrón del endpoint:

/search/fullarchive/accounts/:account_name/:label/counts.json Este endpoint devuelve datos de conteo (volúmenes de datos) para la query especificada. Si no se especifica un periodo de tiempo, los parámetros de tiempo tendrán como valor predeterminado los últimos 30 días. Los volúmenes de datos se devuelven como un arreglo con marca de tiempo, ya sea diario, por hora (predeterminado) o por minuto. Nota: Esta funcionalidad también puede realizarse mediante una solicitud GET, en lugar de una POST, codificando en la URL los parámetros descritos a continuación.

Parámetros de la solicitud de conteos

Parámetros	Descripción	Obligatorio	Valor de ejemplo
query	Equivale a una regla de PowerTrack, con hasta 2,048 caracteres (y sin límites en la cantidad de cláusulas positivas y negativas). Este parámetro debe incluir TODAS las partes de la regla de PowerTrack, incluidos todos los operadores; no se deben separar porciones de la regla en otros parámetros de la query. Nota: No todos los operadores de PowerTrack son compatibles. Consulta Available operators para ver la lista de operadores compatibles.	Sí	(snow OR cold OR blizzard) weather
fromDate	La marca de tiempo UTC más antigua (hasta el 21/03/2006) a partir de la cual se proporcionarán los Tweets. La marca de tiempo tiene granularidad de minuto y es inclusiva (es decir, 12:00 incluye el minuto 00). Especificado: Si solo se usa fromDate sin el parámetro toDate, la API devolverá datos de conteos (volúmenes de data) para la query retrocediendo en el tiempo desde ahora hasta fromDate. Si fromDate es anterior a 31 días desde ahora ( ), recibirás un token next para paginar la solicitud. No especificado: Si no se especifica fromDate, la API devolverá conteos (volúmenes de data) de los 30 días anteriores a ahora ( ) o a toDate (si se especifica). Si no se usan los parámetros fromDate ni toDate, la API devolverá conteos (volúmenes de data) de los 30 días más recientes, comenzando en el momento de la solicitud y retrocediendo.	No	201207220000
toDate	La marca de tiempo UTC más reciente hasta la cual se proporcionarán los Tweets. La marca de tiempo tiene granularidad de minuto y no es inclusiva (es decir, 11:59 no incluye el minuto 59 de la hora). Especificado: Si solo se usa toDate sin el parámetro fromDate, se devolverán los conteos más recientes (volúmenes de data) de los 30 días anteriores a toDate. No especificado: Si no se especifica toDate, la API devolverá conteos (volúmenes de data) para la query retrocediendo en el tiempo hasta fromDate. Si fromDate es anterior a 31 días desde ahora ( ), recibirás un token next para paginar la solicitud. Si no se usan los parámetros fromDate ni toDate, la API devolverá conteos (volúmenes de data) de los 30 días más recientes, comenzando en el momento de la solicitud y retrocediendo.	No	201208220000
bucket	La unidad de tiempo para la cual se proporcionarán los datos de conteo. Los datos de conteo pueden devolverse por cada día, hora o minuto en el período solicitado. De forma predeterminada, se proporcionarán conteos por hora. Opciones: ‘day’, ‘hour’, ‘minute’	No	minute
next	Este parámetro se usa para obtener la siguiente “página” de resultados, como se describe AQUÍ. El valor utilizado con el parámetro se toma directamente de la respuesta proporcionada por la API y no debe modificarse.	No	NTcxODIyMDMyODMwMjU1MTA0

Detalles adicionales


Periodo disponible	30 días: últimos 31 días Archivo completo: 21 de marzo de 2006 - presente
Formato de query	Equivale a una regla de PowerTrack, con hasta 2,048 caracteres. Nota: No todos los operadores de PowerTrack son compatibles. Consulta Available operators para ver la lista de operadores compatibles.
Límite de tasa	Los partners estarán sujetos a límite de tasa con granularidad tanto por minuto como por segundo. El límite de tasa por minuto variará según el partner, tal como se especifique en tu contrato. Sin embargo, estos límites por minuto no están pensados para usarse en una sola ráfaga. Independientemente de tu límite de tasa por minuto, todos los partners estarán limitados a un máximo de 20 solicitudes por segundo, agregado en todas las solicitudes de data y/o conteos.
Precisión del conteo	Los conteos entregados a través de este endpoint reflejan la cantidad de Tweets que se produjeron y no reflejan eventos de cumplimiento posteriores (eliminaciones, scrub geos). Algunos Tweets contabilizados pueden no estar disponibles mediante el endpoint de data debido a acciones de cumplimiento del usuario.

Ejemplos de solicitudes y respuestas de recuentos

Ejemplo de solicitud POST

Los parámetros de una solicitud POST se envían en un cuerpo con formato JSON, como se muestra a continuación.
Todas las partes de la regla de PowerTrack que se van a consultar (p. ej., palabras clave u otros operadores como bounding_box:) deben incluirse en el parámetro ‘query’.
No separe partes de la regla como parámetros independientes en la URL de la query.

A continuación se muestra un ejemplo de comando POST (con cURL) para realizar una solicitud inicial de recuentos:

    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 respuesta de recuentos de la API incluye un token “next”, a continuación se muestra una solicitud posterior que corresponde a la solicitud original, con el parámetro “next” establecido en el token proporcionado:

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

Ejemplo de solicitud GET

Los parámetros en una solicitud GET se codifican en la URL, utilizando la codificación estándar de URL
Todos los componentes de la regla de PowerTrack que se están consultando (p. ej., palabras clave, otros operadores como bounding_box:) deben colocarse en el parámetro ‘query’
No separe componentes de la regla como parámetros individuales en la URL de la consulta

A continuación, se muestra un comando GET de ejemplo (usando cURL) para realizar una solicitud inicial de recuentos:

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

Ejemplos de respuestas de conteos

A continuación se muestra un ejemplo de respuesta a una consulta de conteos (volumen de datos). Este ejemplo de respuesta incluye un token “next”, lo que significa que la solicitud de conteos abarcó más de 31 días o que la query enviada tenía un volumen lo suficientemente grande como para generar una respuesta parcial. El valor del elemento “next” cambiará con cada query y debe tratarse como una cadena opaca. El elemento “next” tendrá el siguiente aspecto en el cuerpo de la respuesta:

    {
      "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 respuesta a una solicitud posterior podría verse como la siguiente (observe la nueva cronología de recuentos y el valor diferente de “next”):

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

Puede seguir pasando el elemento ‘next’ de su query anterior hasta recibir todos los recuentos del período de la query. Cuando reciba una respuesta que no incluya un elemento ‘next’, significará que llegó a la última página y no hay recuentos adicionales disponibles en su rango temporal.

Códigos de respuesta HTTP

Estado	Texto	Descripción
200	OK	La solicitud se completó correctamente. La respuesta JSON será similar a la siguiente:
400	Bad Request	Generalmente, esta respuesta se debe a la presencia de JSON no válido en la solicitud o a que no se envió ningún payload JSON.
401	Unauthorized	La autenticación HTTP falló debido a credenciales no válidas. Inicie sesión en console.gnip.com con sus credenciales para asegurarse de que las está usando correctamente en su solicitud.
404	Not Found	El recurso no se encontró en la URL a la que se envió la solicitud, probablemente porque se utilizó una URL incorrecta.
422	Unprocessable Entity	Se devuelve debido a parámetros no válidos en la query; p. ej., reglas de PowerTrack no válidas.
429	Unknown Code	Su App ha excedido el límite de solicitudes de conexión. El mensaje JSON correspondiente será similar al siguiente:
500	Internal Server Error	Ocurrió un error en el servidor. Reintente la solicitud usando un patrón de backoff exponencial.
502	Proxy Error	Ocurrió un error en el servidor. Reintente la solicitud usando un patrón de backoff exponencial.
503	Service Unavailable	Ocurrió un error en el servidor. Reintente la solicitud usando un patrón de backoff exponencial.

Descripción general

Posts

Usuarios

Mensajes directos

Likes

List

Spaces

Comunidades

Notas de la comunidad

Tendencias

Multimedia

Uso

Conexiones de stream

Cumplimiento

Enterprise v2

Streams de likes

GNIP 2.0

​Descripción general

​Tipos de solicitudes

​Solicitudes de búsqueda (data)

​Solicitudes de conteo (Post count)

​Operadores disponibles

​Disponibilidad de datos / fechas importantes

​Actualizaciones de datos y mutabilidad

​Solicitudes de un solo subproceso vs. de múltiples subprocesos

​Lógica de reintentos

​Guía rápida

​Introducción a la API enterprise Search Posts: 30-Day

​Acceso al endpoint de data

​Carga útil de la respuesta del endpoint de datos

​Acceso al endpoint de counts

​Carga útil de la respuesta del endpoint de conteos

Artículos de referencia

​Introducción a enterprise Search Posts: Full-Archive API

​Acceder al endpoint de data

Carga útil de la respuesta del endpoint de datos

​Acceso al endpoint de counts

​Cuerpo de la respuesta del endpoint Counts

Artículos de referencia

​Guías

​Creación de consultas de búsqueda

​Operadores de Enterprise

​Descripción del producto

​Cronologías de metadatos

​2006

​2007

​2009

​2010

​2011

​2014

​2015

​2016

​2017

​2022

​2022

​Consejos de filtrado

​Perfiles de X

​Posts originales y Retweets

​Clasificaciones de idioma de los Post

​Georreferenciación de Posts

​Enlaces y contenido multimedia compartidos

​Preguntas frecuentes (FAQ)

​Preguntas generales sobre la API de búsqueda de Posts

​Guía de resolución de errores

​Referencia de API

​APIs de búsqueda Enterprise

​Métodos

​Autenticación

​Comportamiento de solicitud/respuesta

​Paginación

Paginación de datos

Paginación de recuentos

Notas adicionales

​Endpoint de datos

POST /search/:product/:label

Patrón del endpoint:

Parámetros de solicitud de datos

Detalles adicionales

Ejemplos de solicitudes y respuestas de data

Ejemplo de solicitud POST

Descripción general

Tipos de solicitudes

Solicitudes de búsqueda (data)

Solicitudes de conteo (Post count)

Operadores disponibles

Disponibilidad de datos / fechas importantes

Actualizaciones de datos y mutabilidad

Solicitudes de un solo subproceso vs. de múltiples subprocesos

Lógica de reintentos

Guía rápida

Introducción a la API enterprise Search Posts: 30-Day

Acceso al endpoint de data

Carga útil de la respuesta del endpoint de datos

Acceso al endpoint de counts

Carga útil de la respuesta del endpoint de conteos

Introducción a enterprise Search Posts: Full-Archive API

Acceder al endpoint de data

Acceso al endpoint de counts

Cuerpo de la respuesta del endpoint Counts

Guías

Creación de consultas de búsqueda

Operadores de Enterprise

Descripción del producto

Cronologías de metadatos

2006

2007

2009

2010

2011

2014

2015

2016

2017

2022

2022

Consejos de filtrado

Perfiles de X

Posts originales y Retweets

Clasificaciones de idioma de los Post

Georreferenciación de Posts

Enlaces y contenido multimedia compartidos

Preguntas frecuentes (FAQ)

Preguntas generales sobre la API de búsqueda de Posts

Guía de resolución de errores

Referencia de API

APIs de búsqueda Enterprise

Métodos

Autenticación

Comportamiento de solicitud/respuesta

Paginación

Endpoint de datos

endpoint de conteos

Ejemplos de respuestas de conteos

Códigos de respuesta HTTP