API de búsqueda: Enterprise

Ten en cuenta lo siguiente:

Hemos publicado una nueva versión de la búsqueda de Publicaciones y de los recuentos de Publicaciones en X API v2. Te recomendamos revisar las novedades de X API v2.

Estos endpoints se han actualizado para incluir metadatos de edición de Publicaciones. Obtén más información sobre estos metadatos en la página de fundamentos “Editar Publicaciones”. 

​

Descripción general

Enterprise

Las API empresariales están disponibles solo dentro de nuestros niveles de acceso gestionados. Para usar estas API, primero debes configurar una cuenta con nuestro equipo de ventas empresariales. Para obtener más información, consulta AQUÍ.

Puedes ver todas las opciones de búsqueda de Publicaciones de X API AQUÍ.

Hay dos API empresariales de búsqueda:

1. La 30-Day Search API proporciona datos de los 30 días anteriores.
2. La Full-Archive Search API proporciona acceso completo e inmediato al corpus completo de datos de X, que se remonta a la primera Publicación en marzo de 2006.

Estas API RESTful admiten una sola consulta de hasta 2.048 caracteres por solicitud. Las consultas se escriben con la sintaxis de reglas de PowerTrack; consulta Reglas y filtrado para más detalles. Los usuarios pueden especificar cualquier período de tiempo, con una granularidad de hasta un minuto. Sin embargo, las respuestas estarán limitadas al menor valor entre tu maxResults especificado o 31 días, e incluirán un next token para paginar el siguiente conjunto de resultados. Si no se especifican parámetros de tiempo, la API devolverá datos coincidentes de los 30 días más recientes.

Las API empresariales de búsqueda proporcionan acceso de baja latencia y alta fidelidad, basado en consultas, al archivo de Publicaciones con granularidad de un minuto. Los datos de Publicaciones se sirven en orden cronológico inverso, comenzando con la Publicación más reciente que coincida con tu consulta. Las Publicaciones están disponibles desde la API de búsqueda aproximadamente 30 segundos después de ser publicadas.

Estos endpoints de búsqueda proporcionan metadatos de Publicaciones editadas. Todos los objetos de Publicaciones creadas desde el 29 de septiembre de 2022 incluyen metadatos de edición de la Publicación, incluso si la Publicación nunca se editó. Cada vez que se edita una Publicación, se crea un nuevo ID de la Publicación. El historial de edición de una Publicación se documenta mediante una matriz de ID de Publicación, comenzando por el ID original.

Estos endpoints siempre devolverán la edición más reciente, junto con cualquier historial de edición. Cualquier Publicación recopilada después de su ventana de edición de 30 minutos representará su versión final. Para obtener más información sobre los metadatos de Editar Publicación, consulta la página Aspectos básicos de las Publicaciones editadas.

Las solicitudes incluyen un parámetro maxResults que especifica el número máximo de Publicaciones que se van a devolver por respuesta de la API. Si hay más Publicaciones asociadas con la consulta que esta cantidad máxima de resultados por respuesta, se incluye un next token en la respuesta. Estos next tokens se usan en solicitudes posteriores para paginar por todo el conjunto de Publicaciones asociadas con la consulta.

Estas API empresariales de búsqueda proporcionan un endpoint de counts que permite a los usuarios solicitar el volumen de datos asociado con su consulta. 

​

Tipos de solicitud

Las APIs de búsqueda para empresas admiten dos tipos de solicitudes:

​

Solicitudes de búsqueda (datos)

Las solicitudes de búsqueda a las APIs de búsqueda empresarial te permiten recuperar hasta 500 resultados por respuesta para un intervalo de tiempo determinado, con la posibilidad de paginar para obtener datos adicionales. Mediante el parámetro maxResults, puedes especificar tamaños de página más pequeños para casos de uso de visualización (permitiendo que tu usuario solicite más resultados según sea necesario) o tamaños de página más grandes (hasta 500) para extracciones de datos de mayor volumen. Los datos se entregan en orden cronológico inverso y cumplen con las normas de cumplimiento en el momento de la entrega.

​

Solicitudes de recuento (Post count)

Las solicitudes de recuento permiten recuperar recuentos de actividad histórica, que reflejan la cantidad de actividades que se produjeron y que coinciden con una consulta determinada durante el período de tiempo solicitado. La respuesta, en esencia, proporciona un histograma de recuentos, agrupados por día, hora o minuto (el intervalo predeterminado es hour). Es importante tener en cuenta que los resultados de recuento no siempre reflejan los eventos de cumplimiento (por ejemplo, eliminaciones de Publicaciones) que ocurren mucho después (más de 7 días) de que se publica una Publicación; por lo tanto, es de esperar que la métrica de recuento no siempre coincida con la de una solicitud de datos para la misma consulta.

Nota de facturación: cada solicitud – incluidas las solicitudes de paginación – realizada contra los endpoints de datos y de recuentos se contabiliza como una solicitud facturable. Por lo tanto, si hay varias páginas de resultados para una sola consulta, paginar a través de las X páginas de resultados equivaldría a X solicitudes a efectos de facturación.

​

Operadores disponibles

Las APIs de búsqueda Enterprise admiten reglas de hasta 2.048 caracteres. Las APIs de búsqueda Enterprise admiten los operadores que se enumeran a continuación. Para descripciones detalladas, consulta AQUÍ. 

Coincidencia con el contenido de la Publicación:	Coincidencia con cuentas de interés:	Atributos de la Publicación:	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 solo de negación)	* 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 incrustes/anides operadores: “#cats” se resolverá como cats con las APIs de búsqueda. El operador lang: y todos los operadores is: y has: no se pueden usar de forma independiente y deben combinarse con otra cláusula (por ejemplo, @XDevelopers has:links).    

Las APIs de búsqueda utilizan un conjunto limitado de operadores debido a la funcionalidad de tokenización y coincidencia. Las APIs Enterprise en tiempo real y las APIs Enterprise históricas por lotes proporcionan operadores adicionales. Consulta AQUÍ para obtener más detalles.

Para obtener más detalles, consulta la guía Introducción a los operadores.

​

Disponibilidad de datos / fechas importantes

Cuando utilices la Full-Archive search API, ten en cuenta que la plataforma X ha seguido evolucionando desde 2006. A medida que se fueron incorporando nuevas funciones, se añadieron nuevos metadatos a los objetos JSON subyacentes. Por ese motivo, es importante entender cuándo se añadieron los atributos de la Publicación sobre los que actúan los operadores de búsqueda. A continuación se muestran algunas de las fechas de origen más importantes de grupos clave de metadatos. Para obtener más información sobre cuándo se introdujeron por primera vez los atributos de la Publicación, consulta esta guía.  

• Primera Publicación: 21/3/2006
• Primeros Retweets nativos: 6/11/2009
• Primera Publicación con etiqueta geográfica: 19/11/2009
• URLs 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 de enriquecimiento de Profile Geo y filtrado: 17/2/2015

​

Actualizaciones de datos y mutabilidad

Con las APIs de búsqueda para empresas, algunos de los datos dentro de una Publicación son mutables, es decir, se pueden actualizar o cambiar después del archivado inicial.

Estos datos mutables se dividen en dos categorías:

• Metadatos del objeto de usuario:
  • El @handle del usuario (el id numérico nunca cambia)
  • Biografía
  • Cantidades: publicaciones, seguidores, seguidos, favoritos, Listas
  • Ubicación del perfil
  • Otros detalles como zona horaria e idioma
• Estadísticas de la Publicación, es decir, cualquier dato que pueda cambiarse en la plataforma mediante acciones de los usuarios (ejemplos a continuación):
  • Número de favoritos
  • Número de Retweets

En la mayoría de estos casos, las APIs de búsqueda devolverán los datos tal como existen en la plataforma en el momento de la consulta, en lugar del momento de generación de la Publicación. Sin embargo, en el caso de consultas que usan operadores de selección (por ejemplo, from, to, @, is:verified), esto puede no ser así. Los datos se actualizan en nuestro índice de forma periódica, con una frecuencia mayor para los períodos de tiempo más recientes. Como resultado, en algunos casos, los datos devueltos pueden no coincidir exactamente con los datos actuales tal como se muestran en X.com, sino que coinciden con los datos del momento en que se indexaron por última vez.

Ten en cuenta que este problema de inconsistencia solo se aplica a consultas donde el operador se aplica a datos mutables. Un ejemplo es el filtrado por nombres de usuario, y la mejor solución alternativa sería usar id numéricos de usuario en lugar de @handles para estas consultas.

​

Solicitudes de un solo hilo vs. de múltiples hilos

Cada cliente tiene un límite de frecuencia definido para su endpoint de búsqueda. El límite de frecuencia predeterminado por minuto para la búsqueda de archivo completo es de 120 solicitudes por minuto, para 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 consulta de un año tiene un millón de Publicaciones asociadas, distribuidas uniformemente a lo largo del año, se necesitarían más de 2,000 solicitudes (asumiendo un maxResults de 500) para recibir todos los datos. Suponiendo que se tarde dos segundos por respuesta, eso serían 4,000 segundos (o poco más de una hora) para extraer todos esos datos de forma serial/secuencial a través de un solo hilo (1 solicitud por segundo usando el token de “next” de la respuesta anterior). ¡Nada mal!

Ahora considere la situación en la que se utilizan doce hilos en paralelo para recibir datos. Suponiendo una distribución uniforme del millón de Publicaciones a lo largo del período de un año, podría dividir las solicitudes en doce hilos paralelos (multihilo) y aprovechar mejor el límite de frecuencia por segundo para un único “job”. En otras palabras, podría ejecutar un hilo por cada mes de interés y, al hacerlo, los datos 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 Publicaciones para un período de dos años, podría hacer una solicitud de un solo hilo y paginar hacia atrás por los conteos, 31 días a la vez. Suponiendo que se tarde 2 segundos por respuesta, llevaría aproximadamente 48 segundos hacer las 24 solicitudes a la API y recuperar el conjunto completo de conteos. Sin embargo, también tiene la opción de hacer varias solicitudes de un mes a la vez. Al hacer 12 solicitudes por segundo, el conjunto completo de conteos podría recuperarse en aproximadamente 2 segundos.

​

Lógica de reintento

Si experimentas un error 503 con las APIs de búsqueda empresariales, es probable que sea un error transitorio y pueda resolverse reintentando la solicitud poco tiempo después.

Si la solicitud falla 4 veces seguidas y has esperado al menos 10 minutos entre fallos, utiliza los siguientes pasos para solucionar el problema:

• Vuelve a intentar la solicitud después de reducir el intervalo de tiempo que abarca. Repite esto hasta llegar a una ventana de 6 horas si no tiene éxito.
• Si estás combinando un gran número de términos con el operador OR, divídelos en reglas separadas y vuelve a intentar cada una por separado.
• Si estás usando una gran cantidad de exclusiones en tu regla, reduce el número de términos negados en la regla y vuelve a intentar.

​

Guía de inicio rápido

​

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

La enterprise Search Posts: 30-Day API te ofrece Publicaciones realizadas en los últimos 30 días. Las Publicaciones se hacen coincidir y se devuelven según la consulta que especifiques en tu solicitud. Una consulta es una regla con la que defines qué debe contener la Publicación que recibes. En este tutorial, buscaremos Publicaciones originadas desde la cuenta de X @XDevelopers en inglés.

Las Publicaciones que recibes en tu payload pueden estar en un formato de data, que te proporciona el payload completo de la Publicación, o pueden estar en un formato de counts, que te ofrece datos numéricos sobre la cantidad de Publicaciones coincidentes. Usaremos cURL para realizar solicitudes a los endpoints de data y counts.

Necesitarás lo siguiente:

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

​

Acceder al endpoint de datos

El endpoint de datos nos proporcionará el payload completo de las Publicaciones coincidentes. Usaremos los operadores from: y lang: para encontrar Publicaciones en inglés publicadas por @XDevelopers. Para ver más operadores haz clic aquí.

cURL

cURL es una herramienta de línea de comandos para obtener o enviar archivos utilizando la sintaxis de URL.

Copia la siguiente solicitud cURL en tu línea de comandos después de actualizar lo siguiente:

• Username <USERNAME> p. ej. [e-mail]

• Account name <ACCOUNT-NAME> p. ej. john-doe

• Label <LABEL> p. ej. prod

• fromDate and toDate p. ej. "fromDate":"201811010000", "toDate":"201811122359"

Después de enviar tu solicitud, se te pedirá tu 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>"}'

Ejemplo de cURL

_Este es un ejemplo de solicitud cURL. Si intentas ejecutarla, no funcionará._

curl -X POST [e-mail] "https://gnip-api.x.com/search/30day/accounts/john-doe/prod.json" -d '{"query":"from:TwitterDev lang:en","maxResults":"500","fromDate":"201811100000","toDate":"201812012359"}'

​

Contenido de la respuesta del endpoint de datos

El contenido que recibes al hacer tu solicitud a la API se devuelve 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: \"La innovadora colaboración de crowdsourcing entre Tagboard, Twitter y TEGNA está sacando a la luz conversaciones relevantes a nivel local…",
			"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 de noticias, actualizaciones y eventos de la plataforma de 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": "\"La innovadora colaboración de crowdsourcing entre Tagboard, Twitter y TEGNA está sacando a la luz contenido relevante a nivel local… 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, negocio y producto en @Klout y para @LithiumTech; miembro del consejo de @BBI; asesor de @Insightpool. El peor dibujante de pizarras del mundo.",
					"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": "\"La innovadora colaboración de crowdsourcing entre Tagboard, Twitter y TEGNA está sacando a la luz conversaciones relevantes a nivel local en tiempo real y permite que los votantes hagan 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 ofrecer el mejor contenido electoral a los medios de noticias con Tagboard…",
									"description": "Por Tyler Singletary, director 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 counts

Con el endpoint counts, recuperaremos la cantidad de Publicaciones que se originan en la cuenta @XDevelopers en inglés, agrupadas por day.

cURL

cURL es una herramienta de línea de comandos para obtener o enviar archivos utilizando la sintaxis de URL.

Copia la siguiente solicitud cURL en tu línea de comandos después de realizar cambios en lo siguiente:

• Username <USERNAME> p. ej. [e-mail]

• Account name <ACCOUNT-NAME> p. ej. john-doe

• Label <LABEL> p. ej. prod

• fromDate and toDate p. ej. "fromDate":"201811010000", "toDate":"201811122359"

Después de enviar tu solicitud, se te pedirá tu 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"}'

Ejemplo de cURL

Este es un ejemplo de solicitud cURL. Si intentas ejecutarla, no funcionará.

curl -X POST [e-mail] "https://gnip-api.x.com/search/30day/accounts/john-doe/prod/counts.json" -d '{"query":"from:TwitterDev lang:en","fromDate":"201811100000","toDate":"201812012359","bucket":"day"}'

​

Carga útil de la respuesta del endpoint de conteos

El cuerpo de la respuesta que recibes de tu solicitud de API aparecerá 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 ya has accedido correctamente a la API enterprise Search Posts: 30-Day.

Artículos relacionados

• Introducción a los objetos de Publicación
• Operadores de búsqueda
• Objetos de Publicación y payloads

​

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

La enterprise Search Posts: Full-Archive API te proporciona acceso a Publicaciones desde la primera que se publicó en 2006. Las Publicaciones se comparan con la consulta que especifiques en tu solicitud y se te devuelven aquellas que coincidan. Una consulta es una regla en la que defines qué debe contener la Publicación que recibes. En este tutorial, buscaremos Publicaciones provenientes de la cuenta de X @XDevelopers en inglés.

Las Publicaciones que recibes en tu payload pueden estar en un formato de datos, que te proporciona el payload completo de la Publicación, o pueden estar en un formato de recuentos, que te da datos numéricos sobre el número de Publicaciones coincidentes. Usaremos cURL para realizar solicitudes a los endpoints de datos y de recuentos.

Necesitarás lo siguiente:

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

​

Acceder al endpoint de datos

El endpoint de datos nos proporcionará el payload completo de las Publicaciones que coincidan. Usaremos los operadores from: y lang: para encontrar Publicaciones publicadas por @XDevelopers en inglés. Para ver más operadores, haz clic aquí.

• cURL
• Ejemplo de cURL

cURL

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 actualizar lo siguiente:

• Username <USERNAME> p. ej. [e-mail]

• 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á tu 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>"}'

Ejemplo de cURL

Este es un ejemplo de solicitud de cURL. Si intentas ejecutarlo, no funcionará.

curl -X POST [e-mail] "https://gnip-api.x.com/search/fullarchive/accounts/john-doe/prod.json" -d '{"query":"from:TwitterDev lang:en","maxResults":"500","fromDate":"201802010000","toDate":"201802282359"}'

Carga útil de la respuesta del endpoint de datos

La carga útil que recibes al hacer tu solicitud a la API se mostrará en formato JSON, como se indica a continuación.

{
	"results": [
		{
			"created_at": "Fri Nov 02 17:18:31 +0000 2018",
			"id": 1058408022936977409,
			"id_str": "1058408022936977409",
			"text": "RT @harmophone: \"La innovadora colaboración de Tagboard, Twitter y TEGNA basada en crowdsourcing está sacando a la superficie conversaciones relevantes a nivel local conv…",
			"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 de 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": "\"La innovadora colaboración de Tagboard, Twitter y TEGNA basada en crowdsourcing está sacando a la superficie conversaciones relevantes a nivel local… 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ó en datos, negocio y producto en @Klout y para @LithiumTech; miembro del consejo de @BBI; asesor de @Insightpool. El peor usuario de pizarras del mundo.",
					"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": "\"La innovadora colaboración de Tagboard, Twitter y TEGNA basada en crowdsourcing está sacando a la superficie conversaciones relevantes a nivel local en tiempo real y permitiendo que los votantes hagan 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 ofrecer el mejor contenido electoral a los medios de noticias con Tagboard…",
									"description": "Por Tyler Singletary, director 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"
	}
}

​

Acceder al endpoint de counts

Con el endpoint de counts, obtendremos la cantidad de Publicaciones procedentes de la cuenta @XDevelopers en inglés, agrupadas por day.

cURL

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 cambios en lo siguiente:

• Username <USERNAME> p. ej. [e-mail]

• Account name <ACCOUNT-NAME> p. ej. john-doe

• Label <LABEL> p. ej. prod

• fromDate and toDate p. ej. "fromDate":"201802010000", "toDate":"201802282359"

Después de enviar tu solicitud, se te pedirá tu 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"}'

Ejemplo de cURL

_Esta es una solicitud de cURL de ejemplo. Si intentas ejecutarla, no funcionará._

curl -X POST [e-mail] "https://gnip-api.x.com/search/fullarchive/accounts/john-doe/prod/counts.json" -d '{"query":"from:TwitterDev lang:en","fromDate":"201802010000","toDate":"201802282359","bucket":"day"}'

​

Contenido de la respuesta del endpoint de recuentos

El contenido que recibes como respuesta a tu solicitud a la API se mostrará en formato JSON, como se indica 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"
	}
}

¡Muy bien! Ahora has accedido correctamente a la API enterprise Search Posts: Full-Archive.

Artículos relacionados

• Introducción a los objetos de Publicación
• Operadores de búsqueda
• Objetos de Publicación y cargas útiles

​

Guías

​

Cómo crear consultas de búsqueda

​

Operadores de Enterprise

A continuación se muestra la lista de todos los operadores compatibles con las API de búsqueda Enterprise de X:

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

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

Operador	Descripción
palabra clave	Coincide con una palabra clave tokenizada dentro del cuerpo o las URL de una Publicación. Se trata de una coincidencia tokenizada, lo que significa que tu cadena de palabra clave se comparará con el texto tokenizado del cuerpo de la Publicación; la tokenización se basa en caracteres del plano básico de Unicode de puntuación, símbolo y separador. Por ejemplo, una Publicación con el texto “I like coca-cola” se dividiría en los siguientes tokens: I, like, coca, cola. Estos tokens se compararían con la cadena de palabra clave utilizada en tu regla. Para hacer coincidir cadenas que contengan signos de puntuación (por ejemplo, coca-cola), símbolos o caracteres separadores, debes usar una coincidencia exacta entre comillas, como se describe a continuación. Nota: Con la Search API, los caracteres acentuados y especiales se normalizan a caracteres latinos estándar, lo que puede alterar 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 coincidirá tanto con las URL como con las URL expandidas dentro de una Publicación.
emoji	Coincide con un emoji dentro del cuerpo de una Publicación. Los emojis usan una coincidencia tokenizada, lo que significa que tu emoji se comparará con el texto tokenizado del cuerpo de la Publicación; la tokenización se basa en caracteres de puntuación, símbolos/emojis y separadores del plano básico Unicode. Por ejemplo, una Publicación con el texto “I like ” se dividiría en los siguientes tokens: I, like, . Estos tokens luego se compararían 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.
”coincidencia exacta de frase”	Coincide con la frase tokenizada y ordenada dentro del cuerpo o las URL de una Publicación. Esta es una coincidencia tokenizada, lo que significa que tu cadena de palabras clave se hará coincidir con el texto tokenizado del cuerpo de la Publicación; la tokenización se basa en caracteres de puntuación, símbolos y caracteres separadores del plano básico Unicode. Nota: La puntuación no se tokeniza, sino que se trata como espacios en blanco. Por ejemplo, la forma entre comillas “#hashtag” coincidirá con “hashtag” pero no con #hashtag (usa el operador de hashtag # sin comillas para hacer coincidir hashtags reales). Por ejemplo, la forma entre comillas “$cashtag” coincidirá con “cashtag” pero no con$cashtag (usa el operador de cashtag $ sin comillas para hacer coincidir cashtags reales). Por ejemplo, “Love Snow” coincidirá con “#love #snow” Por ejemplo, “#Love #Snow” coincidirá con “love snow” Nota: Este operador hará coincidir tanto las URL como las URL expandidas dentro de una Publicación.
”keyword1 keyword2”~N	También conocido como operador de proximidad, hace coincidir una Publicación donde las palabras clave no estén separadas por más de N tokens entre sí. Si las palabras clave están en el orden inverso, no pueden estar separadas por más de N-2 tokens entre sí. Puede incluir cualquier número de palabras clave entre comillas. N no puede ser mayor que 6. Tenga en cuenta que este operador solo está disponible en las APIs de búsqueda enterprise.
from:	Coincide con cualquier Publicación de un usuario específico. El valor debe ser el ID numérico de la cuenta de X del usuario o su nombre de usuario (sin incluir el carácter @). Consulte AQUÍ o AQUÍ para ver métodos para buscar IDs numéricos de cuentas de X.
to:	Coincide con cualquier Publicación que sea una respuesta a un usuario específico. El valor debe ser el id de cuenta numérico del usuario o su nombre de usuario (sin el carácter @). Consulta AQUÍ para conocer métodos para buscar ids de cuenta numéricos de X.
url:	Realiza una coincidencia por tokens (palabra clave/frase) en las URL expandidas de una Publicación (similar a url_contains). Los tokens y frases que contengan puntuación o caracteres especiales deben ir entre comillas dobles. Por ejemplo, url:“/developer”. Aunque generalmente no se recomienda, si quieres hacer coincidir un protocolo específico, enciérralo entre comillas dobles: url:“https://developer.x.com”. Nota: Cuando uses PowerTrack o Historical PowerTrack, este operador hará coincidir las URL contenidas en la Publicación original de una Publicación con cita. Por ejemplo, si tu regla incluye url:“developer.x.com” y una Publicación contiene esa URL, cualquier Tweet con cita de esa Publicación se incluirá en los resultados. Esto no ocurre cuando se usa la Search API.
#	Coincide con cualquier Publicación con el hashtag indicado. Este operador realiza una coincidencia exacta, NO tokenizada, lo que significa que la regla “2016” coincidirá con publicaciones que tengan exactamente el hashtag “2016”, pero no con aquellas que tengan el hashtag “2016election”. Nota: el operador de hashtag se basa en la extracción de entidades de X para hacer coincidir hashtags, en lugar de extraer el hashtag directamente del cuerpo de la Publicación. Consulta aquí para obtener más información sobre los atributos JSON de X Entities.
@	Coincide con cualquier Publicación que mencione el nombre de usuario indicado. El operador to: devuelve un subconjunto de los resultados del operador @mention.
$	Coincide con cualquier Publicación que contenga el «cashtag» especificado (donde el primer carácter del token es «$»). Ten en cuenta que el operador de cashtag se basa en la extracción de la entidad «symbols» de X para hacer coincidir los cashtags, en lugar de intentar extraer el cashtag del cuerpo de la Publicación. Consulta AQUÍ para obtener más información sobre los atributos JSON de X Entities. Ten en cuenta que este operador solo está disponible en las API de búsqueda de enterprise.
retweets_of:	Alias disponible: retweets_of_user: Coincide con las Publicaciones que son retweets de un usuario específico. Admite tanto nombres de usuario como id numéricos de cuentas de X (NO id de estado de Publicación). Consulte AQUÍ métodos para buscar id numéricos de cuentas de X.
lang:	Coincide con Publicaciones que han sido clasificadas por X como pertenecientes a un idioma en particular (si y solo si la Publicación ha sido clasificada). Es importante tener en cuenta que cada Publicación actualmente solo se clasifica en un idioma, por lo que combinar varios idiomas con un operador AND no producirá ningún resultado. Nota: si no se puede hacer ninguna clasificación de idioma, el resultado proporcionado es ‘und’ (por indefinido). La siguiente lista representa los idiomas actualmente admitidos y su correspondiente identificador de idioma BCP 47:

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 latinizado: hi-Latn	Panyabí: 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 Publicaciones etiquetadas con la ubicación especificada o con el id de lugar 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 obtener los id de lugar de X. Nota: Este operador no coincidirá con Retweets, ya que los lugares de los Retweets están asociados a la Publicación original. Tampoco coincidirá con los lugares asociados a la Publicación original de un Quote Tweet.
place_country:	Coincide con Publicaciones en las que el código de país asociado con un place etiquetado coincide con el código ISO alfa-2 de dos caracteres 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 los Retweets están asociados a la Publicación original. Tampoco coincidirá con los lugares asociados a la Publicación original de un Quote Tweet.
point_radius:[lon lat radius]	Coincide con la ubicación exacta (x,y) de la Publicación cuando está presente y, en X, con un polígono geográfico de “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, separados por espacios. Nota: Este operador no coincidirá con Retweets, ya que los lugares de los Retweets están asociados a la Publicación original. Tampoco coincidirá con los lugares asociados a la Publicación 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) de la Publicación cuando está presente y, en X, con un polígono geográfico de “Place”, cuando el Place está completamente contenido dentro de la región definida. * west_long y south_lat representan la esquina suroeste del bounding box, 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 bounding box, donde east_long es la longitud de ese punto y north_lat es la latitud. * El ancho y alto del bounding box 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, separados por espacios. Nota: Este operador no coincidirá con Retweets, ya que los lugares de los Retweets están asociados a la Publicación original. Tampoco coincidirá con los lugares asociados a la Publicación original de un Quote Tweet.
profile_country:	Coincidencia exacta con el campo “countryCode” del objeto “address” en el enriquecimiento 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 un operador para el campo “country” del objeto “address” para ser más conciso.
profile_region:	Coincide con el campo “region” del objeto “address” en el enriquecimiento Profile Geo. Es una coincidencia exacta de cadena completa. No es necesario escapar caracteres con una barra invertida. Por ejemplo, si se quiere hacer coincidir algo 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 Profile Geo. Es una coincidencia exacta de cadena completa. No es necesario escapar caracteres con una barra invertida. Por ejemplo, si se quiere hacer coincidir algo 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: Ningún operador con los prefijos is: o has: puede utilizarse de forma independiente cuando se usa la Search API; debe combinarse con otra cláusula.

Por ejemplo, @XDeevelopers has:links

has:geo	Coincide con Publicaciones que tienen datos de geolocalización específicos de la Publicación proporcionados por X. Estos pueden ser una coordenada “geo” de latitud-longitud o una “location” en forma de un “Place” de X, con el nombre para mostrar correspondiente, polígono geoespacial y otros campos. Nota: Cuando se usa la Search API, este operador debe utilizarse en combinación con otros operadores que no incluyan is: o has:.
has:profile_geo	Alias disponible: has:derived_user_geo Coincide con Publicaciones que tienen cualquier metadato de Profile Geo, independientemente del valor real. Nota: Cuando se utiliza la Search API, este operador debe usarse junto con otros operadores que no incluyan is: o has:.
has:links	Este operador identifica Publicaciones que contienen enlaces en el cuerpo del mensaje. Nota: Cuando uses la API de búsqueda, este operador debe utilizarse junto con otros operadores que no incluyan is: o has:.
is:retweet	Entregar solo retweets explícitos que coincidan con una regla. También se puede usar en forma negada para excluir de la entrega los retweets que coincidan con una regla, de modo que solo se entregue contenido original. Este operador busca únicamente Retweets verdaderos, que utilizan la funcionalidad de retweet de X. Los Quoted Tweets y Modified Posts que no usan la funcionalidad de retweet de X no coincidirán con este operador. Nota: Cuando se usa la Search API, este operador debe utilizarse junto con otros operadores que no incluyan is: o has:.
is:reply	Operador para filtrar Publicaciones en función de si son o no respuestas a otras Publicaciones. Devuelve solo respuestas explícitas que coincidan con una regla. También se puede negar para excluir de la entrega las respuestas que coincidan con una regla. Ten en cuenta que este operador está disponible para las búsquedas premium de pago y enterprise, y no está disponible en entornos de desarrollo Sandbox. Nota: Cuando uses la Search API, este operador debe usarse junto con otros operadores que no incluyan is: o has:.
is:quote	Devuelve solo Quote Tweets o Publicaciones que hacen referencia a otra Publicación, identificadas por “is_quote_status”:true en los payloads de las Publicaciones. También se puede negar para excluir Quote Tweets. Nota: Cuando se utiliza la Search API, este operador debe usarse junto con otros operadores que no incluyan is: o has:.
is:verified	Devuelve solo Publicaciones cuyo autor esté «verificado» por X. También se puede negar para excluir Publicaciones cuyo autor esté verificado. Nota: Cuando uses la Search API, este operador debe utilizarse junto con otros operadores que no incluyan is: o has:.
has:mentions	Devuelve Publicaciones que mencionan a otro usuario de X. Nota: Cuando uses la Search API, este operador debe usarse junto con otros operadores que no incluyan is: o has:.
has:hashtags	Devuelve Publicaciones que contienen un hashtag. Nota: Cuando uses la Search API, este operador debe utilizarse junto con otros operadores que no incluyan is: o has:.
has:media	Alias disponible: has:media_link Coincide con Publicaciones que contienen una URL multimedia clasificada por X. Por ejemplo, pic.x.com. Nota: Cuando se utiliza la Search API, este operador debe utilizarse junto con otros operadores que no incluyan is: o has:.
has:images	Coincide con Publicaciones que contienen una URL de contenido multimedia clasificada por X. Por ejemplo, pic.x.com. Nota: Cuando utilices la Search API, este operador debe usarse junto con otros operadores que no incluyan is: ni has:.
has:videos	Alias disponible: has:video_link Coincide con Publicaciones que contienen vídeos nativos de X, subidos directamente a X. No coincidirá con vídeos creados con Vine, Periscope o Publicaciones con enlaces a otros sitios de alojamiento de vídeo. Nota: Cuando se utilice la Search API, este operador debe usarse junto con otros operadores que no incluyan is: o has:.
has:symbols	Coincide con Publicaciones que contienen un símbolo de cashtag (con un carácter inicial «$»; por ejemplo,$tag). Ten en cuenta que este operador solo está disponible en las APIs de búsqueda de enterprise. Nota: Al usar la API de búsqueda, este operador debe utilizarse junto con otros operadores que no incluyan is: o has:.

​

Descripción general del producto

La búsqueda de archivo completo de nivel empresarial (Full-archive Search) se lanzó en agosto de 2015, y la versión de nivel premium se lanzó en febrero de 2018. Estos productos de búsqueda permiten a los clientes acceder de inmediato a cualquier Publicación disponible públicamente. Con Full-archive Search envías una sola consulta y recibes una respuesta al estilo RESTful clásico. Full-archive Search implementa paginación de hasta 500 Publicaciones por respuesta y admite un límite de frecuencia de hasta 60 solicitudes por minuto (rpm, requests per minute) para premium y 120 rpm para enterprise. Dadas estas características, Full-archive Search se puede usar para recuperar Publicaciones rápidamente y a gran escala usando solicitudes concurrentes.

A diferencia de Historical PowerTrack, cuyo archivo se basa en un conjunto de archivos planos de Publicaciones en disco, el archivo de Publicaciones de Full-archive Search se parece más a una base de datos en línea. Como todas las bases de datos, admite realizar consultas sobre su contenido. También hace uso de un índice para habilitar la recuperación de datos de alto rendimiento. Con los endpoints de Full-archive Search, el lenguaje de consulta está compuesto por PowerTrack Operators, y cada uno de estos operadores corresponde a un atributo JSON de la Publicación que está indexado.

Además, al igual que Historical PowerTrack, hay atributos de la Publicación que son actuales al momento en que se hace una consulta. Por ejemplo, si hoy estás usando Search API para acceder a una Publicación publicada en 2010, la descripción del perfil del usuario, la ubicación ‘home’ de la cuenta, el nombre para mostrar y las métricas de la Publicación para los recuentos de favoritos y Retweets 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 búsqueda de archivo completo empiezan a hacer coincidencias. En algunos casos, la coincidencia de Operadores comenzó mucho después de que una «convención de comunicación» se volviera común en X. Por ejemplo, las @Respuestas surgieron como una 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 coincidencias sobre @Respuestas en 2006 requiere examinar el cuerpo de la Publicación, 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 (un producto 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 Publicación que se completan retroactivamente mientras se genera el índice de búsqueda.
• 13 de julio - has:mentions empieza a devolver coincidencias.
• 6 de octubre - has:symbols. Los $cashtags (o símbolos) para hablar de símbolos bursátiles no se popularizan hasta principios de 2009. Hasta entonces, la mayoría de los usos probablemente eran jerga (por ejemplo,$slang).
• 26 de octubre - has:links empieza a devolver coincidencias.
• 23 de noviembre - has:hashtags empieza a devolver coincidencias.

​

2007

• 30 de enero - primera @reply de primera clase (in_reply_to_user_id), reply_to_status_id: empieza 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. Ten en cuenta que este operador empieza a coincidir con el lanzamiento en versión “beta” de los Retweets oficiales y su patrón “Via @”. Durante este período beta, el verbo de la Publicación es ‘post’ y la Publicación original no se incluye en la carga útil.
• 13 de agosto - Se lanza la versión final de los Retweets oficiales con el patrón “RT @”, con el verbo configurado como ‘share’ y el atributo ‘retweet_status’ que contiene la Publicación original (lo que aproximadamente duplica el tamaño de la carga útil JSON).

​

2010

• 6 de marzo - los operadores de geolocalización has:geo, bounding_box: y point_radius: comienzan a generar coincidencias.
• 28 de agosto - has:videos (hasta febrero de 2015, este operador genera coincidencias en Publicaciones con enlaces a sitios de alojamiento de video seleccionados como youtube.com, vimeo.com y vivo.com).

​

2011

• 20 de julio - has:media y has:images comienzan a devolver coincidencias. Las fotos nativas se anuncian oficialmente el 9 de agosto de 2010.

​

2014

• 3 de diciembre: (aproximadamente) Algunos metadatos de URL mejorados con title y descripción HTML empiezan a incluirse en los payloads. Los metadatos mejorados se consolidaron más plenamente en mayo de 2016.

​

2015

• 10 de febrero: has:videos devuelve coincidencias para videos «nativos» de X.
• 17 de febrero: los operadores has:profile_geo, profile_country:, profile_region:, profile_locality: Profile Geo comienzan a devolver coincidencias.
• 17 de febrero: los operadores de geolocalización de Publicación place_country: y place: comienzan a devolver coincidencias.

​

2016

• 1 de mayo: Metadatos de URL mejorados pasaron a estar más ampliamente disponibles y se anunciaron oficialmente como parte del lanzamiento de Gnip 2.0 en agosto de 2016. No hay Operadores asociados a estos metadatos en las Search APIs.

​

2017

• 22 de febrero: los metadatos de encuestas están disponibles en formato nativo enriquecido. No hay Operators asociados para estos metadatos.

​

2022

• 27 de septiembre: todos los objetos de Publicación creados a partir de esta fecha disponen de metadatos de Publicación editada. Todos los endpoints Enterprise que proporcionan objetos de Publicación se actualizaron para incluir 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 Publicaciones que se hayan creado antes del 27 de septiembre de 2022. Actualmente, no hay operadores de Enterprise disponibles que se correspondan con estos metadatos. Para obtener más información sobre los metadatos de Publicación editada, consulta la página Conceptos básicos sobre la edición de Publicaciones.

​

2022

• 29 de septiembre: todos los objetos de Publicación creados desde esta fecha disponen de metadatos de Publicación editada. Todos los endpoints de Enterprise que proporcionan objetos de Publicación 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 las Publicaciones que se hayan creado 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 Publicación editada, consulta la página Fundamentos de Publicaciones editadas.

​

Consejos de filtrado

Dada toda la información anterior sobre las cronologías, está claro que hay muchos detalles que tener en cuenta al escribir filtros para las APIs de búsqueda. Hay dos aspectos clave que debes considerar:

• Algunos metadatos tienen fechas de inicio, por lo que los filtros pueden producir falsos negativos. Estas búsquedas incluyen operadores que dependen de metadatos que no existieron durante todo o parte del período de búsqueda. Por ejemplo, si estás buscando Publicaciones con el operador has:images, no obtendrás coincidencias para períodos anteriores a julio de 2011. Esto se debe a que ese operador coincide con fotos nativas (adjuntas a una Publicación mediante la interfaz de usuario de X). Para obtener un conjunto de datos más completo de Publicaciones que comparten fotos, los filtros anteriores a julio de 2011 tendrían que contener cláusulas de reglas que coincidan con URL comunes de alojamiento de fotos.
• Algunos metadatos se han rellenado retrospectivamente con metadatos de un momento posterior al momento en que se publicó la Publicación en X.

Hay varios tipos de atributos en los que suele centrarse la atención al crear consultas de PowerTrack:

• Perfiles de X
• Publicaciones originales o compartidas
• Clasificación del idioma de la Publicación
• Publicaciones con georreferenciación
• Contenido multimedia de enlaces compartidos

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

​

Perfiles de X

Las APIs de búsqueda devuelven Publicaciones históricas con los datos del perfil de usuario tal como están en el momento de la obtención. Si solicitas una Publicación de 2014, los metadatos del perfil del usuario reflejarán cómo está en el momento de la consulta.

​

Publicaciones originales y Retweets

El operador PowerTrack _is:retweet_ permite a los usuarios incluir o excluir Retweets. Los usuarios de este operador necesitan contar con dos estrategias para identificar (o no identificar) Retweets en los datos anteriores a agosto de 2009. Antes de agosto de 2009, es necesario revisar el propio mensaje de la Publicación, utilizando coincidencia de frase exacta, para encontrar coincidencias con el patrón “@RT ” (en realidad, si se están filtrando Retweets de entre mayo y agosto de 2009, se debería incluir el patrón “Via @”). Para periodos posteriores a agosto de 2009, el operador is:retweet está disponible.

​

Clasificaciones del idioma de las Publicaciones

Para filtrar según la clasificación del idioma de una Publicación, los productos históricos de X son bastante diferentes entre sí. Cuando se creó el archivo de búsqueda, todas las Publicaciones se completaron de forma retroactiva con la clasificación de idioma de X. Por lo tanto, el operador lang: está disponible para todo el archivo de Publicaciones.

​

Georreferenciación de Publicaciones

Hay tres formas principales de georreferenciar Publicaciones:

• Referencias geográficas en el mensaje de la Publicación. Buscar coincidencias basadas en referencias geográficas en el mensaje de la Publicación, aunque a menudo sea el método más desafiante ya que depende del conocimiento local, es una opción para todo el archivo de Publicaciones. Aquí hay un ejemplo de coincidencia georreferenciada de 2006 para el área de San Francisco basada en un filtro de «golden gate».

• Publicaciones geolocalizadas por el usuario. Con las APIs de búsqueda, la capacidad de empezar a buscar coincidencias en Publicaciones con algunos Geo Operators 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 Profile Geo Operators están disponibles tanto en Historical PowerTrack como en las APIs de búsqueda. Con las APIs de búsqueda, estos metadatos de Profile Geo están disponibles a partir de febrero de 2015. Para Publicaciones publicadas antes de que los metadatos de Profile Geo estuvieran disponibles, está disponible el operador bio_location: que se puede usar para buscar coincidencias con entradas de usuario no normalizadas.

​

Enlaces compartidos y contenido multimedia

En marzo de 2012 se introdujo el enriquecimiento de URL ampliada. Antes de ese momento, las cargas útiles de la Publicación incluían solo la URL proporcionada por el usuario. Por ello, si el usuario incluía una URL acortada, podía resultar difícil hacer coincidir 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 mejorada. Esta versión mejorada proporciona el título y la descripción HTML de un sitio web en la carga útil de la Publicación, junto con operadores para hacer coincidencias basadas en ellos. Estos metadatos comienzan a aparecer en diciembre de 2014.

En septiembre de 2016, X introdujo los “archivos adjuntos nativos”, en los que un enlace compartido final no cuenta para el límite de 140 caracteres de la Publicación. Ambos enriquecimientos de URL siguen aplicándose a estos enlaces compartidos.

A continuación se indican los momentos en que los operadores de búsqueda relacionados comienzan a coincidir:

• 26 de octubre de 2006 - has:links
• 20 de julio de 2011 - has:images y has:media
• agosto de 2011 - url: con el enriquecimiento de Expanded URLs Ya desde septiembre de 2006, (url:"spotify.com" OR url:gnip OR url:microsoft OR url:google OR url:youtube) coincide con http://x.com/Adam/statuses/16602, aunque no haya metadatos urls[] en twitter_entities ni en objetos gnip. “youtube.com” es un ejemplo de contenido de mensaje que, sin ningún metadato urls[], coincide con url:youtube.
• 10 de febrero de 2015 - has:videos para vídeos nativos. Entre 2010/08/28 y 2015/02/10, este operador coincide con Publicaciones con enlaces a determinados sitios de alojamiento de vídeo como youtube.com, vimeo.com y vivo.com.
• 1 de mayo de 2016 - url_title: y url_description:, basados en el enriquecimiento de Enhanced URLs, disponibles de forma 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 Publicaciones

El número de Publicaciones que recibo del endpoint de datos no coincide con el número de Publicaciones identificadas por el endpoint de recuentos. ¿Por qué sucede esto?

Existe una diferencia conocida entre los resultados proporcionados por el endpoint de recuentos y el endpoint de datos. Es posible que veas una discrepancia en tus resultados porque el endpoint de recuentos se ejecuta antes de aplicar los procesos de cumplimiento (es decir, no tiene en cuenta elementos como Publicaciones eliminadas, scrub geo, etc.), mientras que el endpoint de datos aplica el cumplimiento en el momento de la entrega y contempla todos los eventos de cumplimiento.

No recibí una Publicación que debería corresponder a mi consulta. ¿Por qué?

Hay varias razones por las que esto podría haber sucedido, entre ellas:

1. la Publicación que esperabas ver es de una cuenta protegida
2. porque el endpoint de datos contempla todos los eventos de cumplimiento (lo que significa que las Publicaciones eliminadas, las geolocalizaciones depuradas, etc. no se incluirán en la respuesta).

Mi consulta coincidió con una Publicación pero incluye una palabra clave que negué. ¿Por qué ocurre esto?

Es probable que esto se deba a un uso incorrecto de nuestro sistema de reglas y filtrado premium. Consulta nuestra documentación aquí y asegúrate de comprender las restricciones relacionadas con la creación de reglas.

¿Hay alguna librería que pueda usar para empezar a usar las APIs de búsqueda de Publicaciones?

Sí, los hay, entre ellos:

• Tweepy - útil para usar el producto estándar de búsqueda de Publicaciones (Python)
• X API - útil para usar las APIs estándar de búsqueda de Publicaciones (Python)
• Search Posts Python y Search Posts Ruby - dos herramientas muy útiles que se pueden usar con las APIs de búsqueda de Publicaciones de nivel enterprise (y v2)

Todas las bibliotecas que admitimos directamente se pueden encontrar en nuestra página de GitHub de xdevplatform: https://github.com/xdevplatform.

Existen otras bibliotecas de terceros que también pueden ser útiles; sin embargo, ten en cuenta que es posible que algunas de ellas no funcionen con nuestros productos premium y enterprise.

¿Alguna vez recibiré un volumen de Publicaciones inferior al valor que establecí como `maxResults` en mi solicitud al endpoint de datos?

Sí. Nuestro endpoint de datos pagina según el maxResults especificado o después de 30 días.

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

¿En qué orden se devuelven las Publicaciones que coinciden?

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

¿Cómo afectan las Publicaciones editadas a mi uso y a mi facturación?

Solo la Publicación original contará para efectos de facturación. Cualquier edición posterior se ignorará y no se tendrá en cuenta en tu conteo total de actividad. 

Enterprise

Estoy interesado en obtener más información sobre los precios de la Search Post API para empresas (enterprise) y en solicitar este servicio. ¿Cómo puedo hacerlo?

Nuestras soluciones empresariales se personalizan con precios previsibles para satisfacer las necesidades de tu empresa. Envía tu solicitud aquí para obtener más información.

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

• Consulta la documentación de nuestras APIs empresariales de Search Post aquí
• Puedes encontrar información útil sobre reglas y filtrado aquí
• Puedes encontrar información útil sobre el uso del endpoint de datos aquí
• Puedes encontrar información útil sobre el uso del endpoint de recuentos aquí
• Puedes encontrar una lista de operadores disponibles aquí

He superado mi límite mensual de solicitudes, pero necesito acceder a más datos. ¿Qué puedo hacer?

Ponte en contacto con tu gerente de cuenta en X, quien podrá ayudarte con esto.

​

Guía para la resolución de errores

Código 404 - No encontrado

1. Asegúrate de estar usando los parámetros correctos para cada endpoint (por ejemplo, el campo buckets solo se puede usar con el endpoint de counts, no con el endpoint de data).
2. Verifica que los campos :product :account_name y :label sean correctos. Puedes encontrar el campo :label en la GNIP Console (solo para clientes empresariales).

​

Referencia de la API

​

APIs de búsqueda para empresas

Hay dos APIs de búsqueda para empresas:

• 30-Day Search API: proporciona Tweets publicados en los últimos 30 días.
• Full-Archive Search API: proporciona Tweets desde 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 se aplica a ambas. Ten en cuenta que, para los Tweets creados a partir del 29 de septiembre de 2022, los objetos Tweet incluirán metadatos de edición del Tweet que describen su historial de ediciones. Consulta la página de fundamentos “Edit Tweets” para más detalles.

A continuación encontrarás detalles importantes que necesitas al integrarte con las APIs de búsqueda para empresas:

• Métodos para solicitar datos y recuentos de Tweets
• Autenticación
• Paginación
• Parámetros de solicitudes de API y ejemplos de solicitudes
• Cuerpos JSON de las respuestas de API y ejemplos de respuestas
• Códigos de respuesta HTTP

Las APIs para empresas proporcionan acceso de baja latencia, alta fidelidad y basado en consultas al archivo de Tweets. La única diferencia entre las dos APIs es el intervalo de tiempo que puedes buscar, ya sea los 30 días anteriores o desde 2006. Los intervalos de tiempo se pueden especificar con granularidad de minutos. Los datos de Tweets se sirven en orden cronológico inverso, comenzando con el Tweet más reciente que coincida con tu consulta. Los Tweets están disponibles desde la API de búsqueda aproximadamente 30 segundos después de ser publicados.

​

Methods

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

Method	Description
POST /search/:product/accounts/:account_name/:label	Recupera Tweets de los últimos 30 días que coincidan con la regla de PowerTrack especificada.
POST /search/:product/accounts/:account_name/:label/counts	Recupera la cantidad de Tweets de los últimos 30 días que coincidan con la regla de PowerTrack especificada.

Donde:

• :product indica el endpoint de búsqueda al que estás haciendo solicitudes, ya sea 30day o fullarchive.
• :account_name es el nombre (sensible a mayúsculas y minúsculas) asociado con tu cuenta, tal como se muestra en console.gnip.com
• :label es la etiqueta (sensible a mayúsculas y minúsculas) asociada con tu 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 producción), 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

Tu endpoint completo de la API de búsqueda empresarial se muestra en https://console.gnip.com.

A continuación se muestran varios ejemplos de solicitudes utilizando una sencilla utilidad HTTP llamada curl. Estos ejemplos usan URL con :product, :account_name y :label. Para usar estos ejemplos, asegúrate de actualizar las URL con tus propios datos.

​

Autenticación

Todas las solicitudes a las APIs de búsqueda para empresas deben utilizar Basic Authentication de HTTP, formada a partir de una combinación válida de dirección de correo electrónico y contraseña que utilizas para iniciar sesión en tu cuenta en https://console.gnip.com. Las credenciales deben enviarse en la cabecera Authorization de cada solicitud.

​

Comportamiento de solicitud/respuesta

Usando los parámetros fromDate y toDate, puedes solicitar cualquier período 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 denomina API de “30 días”, pone a disposición 31 días para permitir que los usuarios realicen solicitudes que abarquen meses completos). La API de búsqueda de archivo completo proporciona Tweets hasta el primer Tweet publicado (21 de marzo de 2006). Sin embargo, una sola respuesta estará limitada al menor valor entre el maxResults que especifiques y 31 días. Si los datos que coincidan con tu consulta o tu rango temporal superan el maxResults que especificaste o 31 días, recibirás un token “next” que debes usar para paginar el resto de tu rango de tiempo especificado.

Por ejemplo, supongamos que estás usando la búsqueda de archivo completo y quieres todos los Tweets que coincidan con tu consulta desde el 1 de enero de 2017 hasta el 30 de junio de 2017. Especificarás ese período 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 el número de Tweets que coincidan con tu parámetro maxResults (que tiene un valor predeterminado de 100). Suponiendo que haya más Tweets (y muy probablemente los haya), la API también proporcionará un token “next” que te permite realizar una solicitud para la siguiente “página” de datos. Este proceso se repite hasta que la API ya no devuelva un token “next”. Consulta la siguiente sección para obtener más detalles.

​

Paginación

Al realizar solicitudes tanto de datos como de recuentos, es probable que haya más datos de los que se pueden devolver en una sola respuesta. Cuando ese sea el caso, la respuesta incluirá un token ‘next’. El token ‘next’ se proporciona como un atributo JSON de nivel raíz. Siempre que se incluya un token ‘next’, habrá datos adicionales que recuperar, por lo que deberás seguir haciendo solicitudes a la API.

Nota: El comportamiento del token ‘next’ difiere ligeramente entre las solicitudes de datos y las de recuentos, y ambos se describen a continuación, con respuestas de ejemplo proporcionadas en la sección de Referencia de la API.

Paginación de datos

Es probable que las solicitudes de datos generen más datos de los que se pueden devolver en una sola respuesta. Cada solicitud de datos incluye un parámetro que establece el número máximo de Tweets que se devolverán por solicitud. Este parámetro maxResults tiene un valor predeterminado de 100 y se puede configurar en un rango de 10 a 500. Si tu consulta recupera más Tweets que el valor del parámetro 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 posterior para recuperar la siguiente parte de los Tweets que coinciden con esa consulta (es decir, la siguiente “página”). Se seguirán proporcionando tokens next hasta que hayas alcanzado la última “página” de resultados para esa consulta, momento en el cual ya no se proporcionará ningún token next.

Para solicitar la siguiente “página” de datos, debes realizar exactamente la misma consulta que la original, incluidos los parámetros query, toDate y fromDate, si se utilizan, y también incluir un parámetro de solicitud next establecido con el valor de la respuesta anterior. Esto se puede utilizar tanto con una solicitud GET como con una POST. Sin embargo, el parámetro next debe estar codificado en la URL en el caso de una solicitud GET.

Puedes seguir incluyendo el elemento next de tu consulta anterior hasta que hayas recibido todos los Tweets del período de tiempo cubierto por tu consulta. Cuando recibas una respuesta que no incluya un elemento next, significa que has alcanzado la última página y no hay datos adicionales disponibles para la consulta y el intervalo de tiempo especificados.

Paginación de counts

El endpoint de counts proporciona volúmenes de Tweets asociados con una consulta, con granularidad diaria, por hora o por minuto. El endpoint de la API de counts devolverá un arreglo con marcas de tiempo de counts para una carga útil máxima de 31 días de counts. Si solicitas más de 31 días de counts, se te proporcionará un token next. Al igual que con los tokens next de datos, debes realizar exactamente la misma consulta que la original e incluir también un parámetro de solicitud next establecido en el valor de la respuesta anterior.

Además de solicitar más de 31 días de counts, hay otro escenario en el que se proporciona un token next. Para consultas de mayor volumen, existe la posibilidad de que la generación de counts tarde lo suficiente como para activar un tiempo de espera (timeout) de la respuesta. Cuando esto ocurra, recibirás menos de 31 días de counts, pero se te proporcionará un token next para que puedas seguir realizando solicitudes hasta obtener la carga útil completa de counts. Importante: Los tiempos de espera solo devolverán “buckets” completos; por lo tanto, 2,5 días darían como resultado 2 “buckets” de día completos.

Notas adicionales

• Cuando uses un fromDate o toDate en una solicitud de búsqueda, solo obtendrás resultados dentro de tu intervalo de tiempo. Cuando llegues al último grupo de resultados dentro de tu intervalo de tiempo, no recibirás un token ‘next’.
• El elemento ‘next’ se puede usar con cualquier valor de maxResults entre 10 y 500 (con un valor predeterminado de 100). maxResults determina cuántos Tweets se devuelven en cada respuesta, pero no impide que finalmente obtengas todos los resultados.
• El elemento ‘next’ no caduca. Múltiples solicitudes que usen la misma consulta ‘next’ recibirán los mismos resultados, independientemente de cuándo se realice la solicitud.
• Al paginar los resultados usando el parámetro ‘next’, puedes encontrar duplicados en los límites de la consulta. Tu aplicación debe ser tolerante a estos.

​

Endpoint de datos

POST /search/:product/:label

Patrón de endpoint:

Este endpoint devuelve datos para la consulta y el período de tiempo especificados. Si no se especifica un período de tiempo, los parámetros de tiempo usarán de forma predeterminada los últimos 30 días. Nota: Esta funcionalidad también se puede lograr mediante una solicitud GET, en lugar de una POST, incluyendo en la URL los parámetros descritos a continuación.

Parámetros de la solicitud de datos

Parameters	Description	Required	Sample Value
query	El equivalente a una sola 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, y no se deben separar partes de la regla en otros parámetros de la query. Nota: No se admiten todos los operadores de PowerTrack. Los operadores admitidos se enumeran AQUÍ.	Sí	(snow OR cold OR blizzard) weather
tag	Las etiquetas (tags) se pueden utilizar para segregar reglas y sus datos coincidentes en diferentes grupos lógicos. Si se proporciona una rule tag, la rule tag se incluye en el atributo ‘matching_rules’. Se recomienda asignar UUID específicos de cada regla a las rule tags y mantener las asignaciones deseadas en el 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 Full-Archive) a partir de la cual se proporcionarán los Tweets. La marca de tiempo tiene granularidad de minutos y es inclusiva (es decir, 12:00 incluye el minuto 00). Especificado: Usar solo fromDate sin el parámetro toDate proporcionará resultados para la query hacia atrás en el tiempo desde now( ) hasta fromDate. No especificado: Si no se especifica un fromDate, la API entregará todos los resultados de los 30 días anteriores a now( ) o a toDate (si se especifica). Si no se utiliza 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 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 (es decir, 11:59 no incluye el minuto 59 de la hora). Especificado: Usar solo toDate sin el parámetro fromDate entregará los datos de los 30 días más recientes anteriores a toDate. No especificado: Si no se especifica un toDate, la API entregará todos los resultados desde now( ) para la query hacia atrás en el tiempo hasta fromDate. Si no se utiliza ni el parámetro fromDate ni toDate, la API entregará todos los resultados para todo el índice de 30 días, comenzando en el momento de la solicitud y 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 utiliza para obtener la siguiente “página” de resultados, como se describe AQUÍ. El valor utilizado con el parámetro se extrae directamente de la respuesta proporcionada por la API y no debe modificarse.	No	NTcxODIyMDMyODMwMjU1MTA0

Detalles adicionales

Available Timeframe	30-Day: últimos 31 días Full-Archive: 21 de marzo de 2006 - actualidad
Query Format	El equivalente a una regla de PowerTrack, con hasta 2.048 caracteres (y sin límites en la cantidad de cláusulas positivas y negativas). Nota: No todos los operadores de PowerTrack son compatibles. Consulta Available operators para ver la lista de operadores compatibles.
Rate Limit	Los socios estarán sujetos a límites de tasa tanto a nivel de minuto como de segundo. El límite de tasa por minuto variará según el socio, tal como se especifique en su contrato. Sin embargo, estos límites de tasa por minuto no están pensados para utilizarse en una sola ráfaga. Independientemente de su límite de tasa por minuto, todos los socios estarán limitados a un máximo de 20 solicitudes por segundo, agregado entre todas las solicitudes de datos y/o conteos.
Compliance	Todos los datos entregados a través de Full-Archive Search API cumplen las normas en el momento de la entrega.
Realtime Availability	Los datos están disponibles en el índice en un plazo de 30 segundos desde su generación en la plataforma X

Ejemplos de solicitudes de datos y sus respuestas

Ejemplo de solicitud POST

• Los parámetros en una solicitud POST se envían en el cuerpo de la solicitud con formato JSON, como se muestra a continuación.
• Todas las partes de la regla de PowerTrack que se estén consultando (por ejemplo, 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 (usando cURL) para realizar una solicitud inicial de datos:

    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 posterior que es igual 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.json" -d '{"query":"from:twitterDev","maxResults":500,"fromDate":"yyyymmddhhmm","toDate":"yyyymmddhhmm",
    "next":"NTcxODIyMDMyODMwMjU1MTA0"}'

Ejemplo de solicitud GET

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

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

    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 datos

Ten 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 del Tweet que describen su historial de edición. Consulta la página de fundamentos “Edit Tweets” para obtener más información.

A continuación se muestra un ejemplo de respuesta a una consulta de datos. Este ejemplo asume que había más Tweets disponibles que el valor de ‘maxResults’, por lo que se proporciona un token ‘next’ para solicitudes posteriores. Si ‘maxResults’ o menos Tweets están asociados con tu consulta, no se incluirá ningún token ‘next’ en la respuesta. El valor del elemento ‘next’ cambiará con cada consulta y debe tratarse como una cadena opaca. El elemento ‘next’ se verá de la siguiente manera 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 como la siguiente (ten en cuenta 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 enviando el elemento ‘next’ de su consulta anterior hasta que haya recibido todos los Tweets del período de tiempo cubierto por su consulta. Cuando reciba una respuesta que no incluya un elemento ‘next’, significa que ha llegado a la última página y no hay datos adicionales disponibles en su intervalo de tiempo.

​

Endpoint de recuentos

/search/:stream/counts

Patrón de endpoint:

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

Este endpoint devuelve datos de recuentos (volúmenes de datos) para la consulta especificada. Si no se especifica un período 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 array con marca de tiempo de forma diaria, por hora (predeterminado) o por minuto.

Nota: Esta funcionalidad también se puede realizar mediante una solicitud GET, en lugar de 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	El equivalente 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, y las partes de la regla no deben separarse en otros parámetros de la consulta. Nota: No todos los operadores de PowerTrack son compatibles. Consulta Operadores disponibles para ver una lista de los 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 se usa solo fromDate sin el parámetro toDate, la API entregará datos de conteo (volúmenes de datos) para la consulta hacia atrás en el tiempo desde ahora hasta fromDate. Si fromDate es anterior a 31 días a partir de ahora( ), recibirás un next token para paginar tu solicitud. No especificado: Si no se especifica un fromDate, la API entregará conteos (volúmenes de datos) para los 30 días previos a ahora( ) o al toDate (si se especifica). Si no se usa ni el parámetro fromDate ni toDate, la API entregará conteos (volúmenes de datos) para 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 minuto y no es inclusiva (es decir, 11:59 no incluye el minuto 59 de la hora). Especificado: Si se usa solo toDate sin el parámetro fromDate, se entregarán los conteos (volúmenes de datos) más recientes para los 30 días previos a toDate. No especificado: Si no se especifica un toDate, la API entregará conteos (volúmenes de datos) para la consulta hacia atrás en el tiempo hasta fromDate. Si fromDate es más de 31 días a partir de ahora( ), recibirás un next token para paginar tu solicitud. Si no se usa ni el parámetro fromDate ni toDate, la API entregará conteos (volúmenes de datos) para los 30 días más recientes, comenzando en el momento de la solicitud y yendo hacia atrás.	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 intervalo de tiempo 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 usado con el parámetro se extrae directamente de la respuesta proporcionada por la API y no debe modificarse.	No	NTcxODIyMDMyODMwMjU1MTA0

Detalles adicionales

Periodo de tiempo disponible	30 días: últimos 31 días Archivo completo: 21 de marzo de 2006 - presente
Formato de consulta	Equivalente a una regla de PowerTrack, con hasta 2.048 caracteres. Nota: No todos los operadores de PowerTrack son compatibles. Consulta Operadores disponibles para ver una lista de los operadores compatibles.
Límite de tasa	Los socios estarán sujetos a límites de tasa tanto a nivel de minuto como de segundo. El límite de tasa por minuto variará según el socio, tal como se especifica en su contrato. Sin embargo, estos límites de tasa por minuto no están pensados para utilizarse en un único pico. Independientemente de su límite de tasa por minuto, todos los socios estarán limitados a un máximo de 20 solicitudes por segundo, agregadas entre todas las solicitudes de datos y/o conteos.
Precisión del conteo	Los conteos entregados a través de este endpoint reflejan el número de Tweets que se publicaron y no reflejan ningún evento de cumplimiento posterior (eliminaciones, scrub geos). Es posible que algunos Tweets contabilizados no estén disponibles a través del endpoint de datos debido a acciones de cumplimiento del usuario.

Ejemplos de solicitudes y respuestas de recuento

Ejemplo de solicitud POST

• Los parámetros en una solicitud POST se envían en un cuerpo con formato JSON, como se muestra a continuación.
• Todos los componentes de la regla de PowerTrack que se esté consultando (por ejemplo, palabras clave u otros operadores como bounding_box:) deben incluirse en el parámetro ‘query’.
• No separe componentes de la regla como parámetros independientes en la URL de consulta.

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

    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 conteos de la API incluye un token ‘next’, a continuación se muestra una solicitud posterior que es 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 de una solicitud GET se codifican en la URL, utilizando la codificación URL estándar
• Todas las partes de la regla de PowerTrack que se van a consultar (por ejemplo, palabras clave, otros operadores como bounding_box:) deben colocarse en el parámetro ‘query’
• No separe las partes de la regla como parámetros independientes en la URL de la consulta

Aquí hay un ejemplo de comando GET (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). Esta respuesta de ejemplo incluye un token ‘next’, lo que significa que la solicitud de conteos abarcó más de 31 días o que la consulta enviada tenía un volumen lo suficientemente grande asociado como para activar una respuesta parcial.

El valor del elemento ‘next’ cambiará con cada consulta 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 tener el siguiente aspecto (observe la nueva línea temporal 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 continuar pasando el elemento ‘next’ de su consulta anterior hasta que haya recibido todos los recuentos del período de tiempo de la consulta. Cuando reciba una respuesta que no incluya un elemento ‘next’, significa que ha llegado a la última página y no hay recuentos adicionales disponibles en su intervalo de tiempo.

​

Códigos de respuesta HTTP

Estado	Texto	Descripción
200	OK	La solicitud se realizó correctamente. La respuesta JSON será similar a la siguiente:
400	Bad Request	Generalmente, esta respuesta se produce debido a la presencia de JSON no válido en la solicitud, o cuando la solicitud se envía sin ningún cuerpo JSON.
401	Unauthorized	La autenticación HTTP falló debido a credenciales no válidas. Inicia sesión en console.gnip.com con tus credenciales para asegurarte de que las estás utilizando correctamente en tu 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 consulta; por ejemplo, reglas de PowerTrack no válidas.
429	Código desconocido	Tu aplicación ha superado el límite de solicitudes de conexión. El mensaje JSON correspondiente será similar al siguiente:
500	Internal Server Error	Se produjo un error en el servidor. Vuelve a intentar tu solicitud utilizando un patrón de backoff exponencial.
502	Proxy Error	Se produjo un error en el servidor. Vuelve a intentar tu solicitud utilizando un patrón de backoff exponencial.
503	Service Unavailable	Se produjo un error en el servidor. Vuelve a intentar tu solicitud utilizando un patrón de backoff exponencial.