API de búsqueda: Empresarial

Tenga en cuenta: Hemos lanzado una nueva versión de búsqueda de publicaciones y conteos de publicaciones en X API v2. Le animamos a que revise las novedades de la X API v2. Estos endpoints han sido actualizados para incluir metadatos de edición de publicaciones. Obtenga más información sobre estos metadatos en la página de fundamentos “Editar publicaciones”.

Descripción general

Empresarial Las API empresariales están disponibles únicamente dentro de nuestros niveles de acceso gestionados. Para usar estas API, primero debes configurar una cuenta con nuestro equipo de ventas para clientes empresariales. Para obtener más información, consulta AQUÍ. Puedes ver todas las opciones de búsqueda de Post de la X API AQUÍ. Hay dos API empresariales de búsqueda:

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

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

Tipos de solicitudes

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

Solicitudes de búsqueda (datos)

Las solicitudes de búsqueda a las APIs de búsqueda empresariales permiten recuperar hasta 500 resultados por respuesta para un período de tiempo dado, con la capacidad de paginar para obtener datos adicionales. Usando el parámetro maxResults, puede especificar tamaños de página más pequeños para casos de uso de visualización (permitiendo que su usuario solicite más resultados según sea necesario) o tamaños de página más grandes (hasta 500) para extracciones de datos mayores. Los datos se entregan en orden cronológico inverso y son conformes en el momento de la entrega.

Solicitudes de recuentos (Recuento de publicaciones)

Las solicitudes de recuentos permiten recuperar recuentos de actividad histórica, que indican el número de actividades que se produjeron y coinciden con una consulta determinada durante el período solicitado. La respuesta le proporcionará básicamente un histograma de recuentos, agrupados por día, hora o minuto (el bucket predeterminado es hour). Es importante tener en cuenta que los resultados de recuentos no siempre reflejan eventos de cumplimiento (por ejemplo, eliminaciones de Publicaciones) que se producen mucho después (7+ días) de que se publique una Publicación; por lo tanto, es de esperar que la métrica de recuentos 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 cuenta como una solicitud facturada. Por lo tanto, si hay múltiples páginas de resultados para una sola consulta, paginar a través de las X páginas de resultados equivaldría a X solicitudes para facturación.

Operadores disponibles

Las APIs de búsqueda empresarial admiten reglas con hasta 2.048 caracteres. Las APIs de búsqueda empresarial admiten los operadores listados a continuación. Para descripciones detalladas, consulte AQUÍ.


Coincidencia en contenidos de publicación:	Coincidencia en cuentas de interés:	Atributos de 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 (negation only operator)	* bounding_box:[west_long south_lat east_long north_lat] * point_radius:[lon lat radius] * has:geo * place: * place_country: * has:profile_geo * profile_country: * profile_region: * profile_locality:

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

Disponibilidad de datos / fechas importantes

Al usar la API de búsqueda Full-Archive, ten en cuenta que la plataforma X ha seguido evolucionando desde 2006. A medida que se agregaron nuevas funciones, se ha añadido nuevo metadato a los objetos JSON subyacentes. Por esa razón, es importante entender cuándo se agregaron los atributos de Publicación que utilizan los operadores de búsqueda. A continuación, se muestran algunas de las fechas de ‘nacimiento’ más fundamentales de grupos importantes de metadatos. Para obtener más información sobre cuándo se introdujeron por primera vez los atributos de Publicación, consulta esta guía.

Primera Publicación: 3/21/2006
Primeros Retuits Nativos: 11/6/2009
Primera Publicación Geolocalizada: 11/19/2009
URLs indexadas por primera vez para filtrado: 8/27/2011
Metadatos mejorados de expansión de URL (títulos y descripciones de sitios web): 12/1/2014
Metadatos de enriquecimiento geográfico del perfil y filtrado: 2/17/2015

Actualizaciones de datos y mutabilidad

Con las APIs de búsqueda empresariales, algunos de los datos dentro de una Publicación son mutables, es decir, pueden actualizarse o cambiarse después de su archivado inicial. Estos datos mutables se dividen en dos categorías:

Metadatos del objeto de usuario:
- @handle del usuario (el ID numérico nunca cambia)
- Descripción biográfica
- Contadores: estados, seguidores, amigos, favoritos, listas
- Ubicación del perfil
- Otros detalles como zona horaria e idioma
Estadísticas de Publicación - es decir, todo aquello que pueda cambiarse en la plataforma por acciones de los usuarios (ejemplos a continuación):
- Conteo de favoritos
- Conteo de retuits

En la mayoría de estos casos, las APIs de búsqueda devolverán los datos tal como existen en la plataforma en el tiempo de consulta, en lugar del tiempo 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 podría no ser así. Los datos se actualizan en nuestro índice de manera regular, con una frecuencia aumentada para los períodos de tiempo más recientes. Como resultado, en algunos casos, los datos devueltos podrían no coincidir exactamente con los datos actuales tal como se muestran en X.com, pero coinciden con los datos en el momento en que se indexaron por última vez. Tenga 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 IDs numéricos de usuario en lugar de @handles para estas consultas.

Solicitudes de un solo hilo vs. solicitudes multihilo

Cada cliente tiene un límite de tasa definido para su endpoint de búsqueda. El límite de tasa predeterminado por minuto para la búsqueda Full-Archive es de 120 solicitudes por minuto, lo que equivale a un promedio de 2 consultas por segundo (QPS). Este promedio de QPS significa que, en teoría, se pueden realizar 2 solicitudes a la API cada segundo. Dada la característica de paginación del producto, si una consulta de un año tiene un millón de Publicaciones asociadas, distribuidas de manera uniforme a lo largo del año, se requerirían más de 2.000 solicitudes (asumiendo un valor de ‘maxResults’ de 500) para recibir todos los datos. Asumiendo que toma dos segundos por respuesta, eso equivale a 4.000 segundos (o poco más de una hora) para extraer todos esos datos de manera serial/secuencial a través de un solo hilo (1 solicitud por segundo utilizando el token “next” de la respuesta anterior). ¡No está mal! Ahora considere la situación en la que se utilizan doce hilos paralelos para recibir datos. Asumiendo 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 más el límite de tasa por segundo para la única “tarea”. En otras palabras, podría ejecutar un hilo por 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 de manera equivalente al endpoint de conteos. Por ejemplo, si quisiera recibir conteos de Publicaciones para un período de dos años, podría realizar una solicitud de un solo hilo y paginar hacia atrás a través de los conteos 31 días a la vez. Asumiendo que toma 2 segundos por respuesta, tomaría aproximadamente 48 segundos para realizar las 24 solicitudes a la API y recuperar el conjunto completo de conteos. Sin embargo, también tiene la opción de realizar múltiples solicitudes de un mes a la vez. Al realizar 12 solicitudes por segundo, el conjunto completo de conteos podría recuperarse en aproximadamente 2 segundos.

Lógica de reintento

Si experimenta un error 503 con las APIs de búsqueda empresarial, es probable que se trate de un error transitorio que se puede resolver reintentando la solicitud un poco más tarde. Si la solicitud falla 4 veces consecutivas y ha esperado al menos 10 minutos entre fallos, siga estos pasos para solucionar el problema:

Reintente la solicitud después de reducir el intervalo de tiempo que abarca. Repita este proceso hasta llegar a una ventana de 6 horas si no tiene éxito.
Si está aplicando el operador OR a un gran número de términos, divídalos en reglas separadas y reintente cada una por separado.
Si está utilizando un gran número de exclusiones en su regla, reduzca el número de términos negados en la regla y reintente.

Inicio rápido

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

La enterprise Search Posts: 30-Day API te proporciona Posts publicados en los últimos 30 días. Los Posts se hacen coincidir y se te devuelven según la consulta que especifiques en tu solicitud. Una consulta es una regla en la que defines qué debe contener el Post que recibes. En este tutorial, buscaremos Posts que se originen en la cuenta de X @XDevelopers en inglés. Los Posts que recibes en tu payload pueden estar en un formato de data, que te proporciona el payload completo del Post, o en un formato de counts, que te proporciona recuentos numéricos de los Posts coincidentes. Usaremos cURL para realizar solicitudes a los endpoints de data y counts. 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 la cuenta
La etiqueta asociada con tu endpoint de búsqueda, tal como se muestra en console.gnip.com

Acceso al endpoint de datos

El endpoint de datos nos proporcionará la carga útil completa de las Publicaciones coincidentes. Usaremos los operadores from: y lang: para encontrar Publicaciones de @XDevelopers en inglés. Para más operadores, haga clic aquí.

cURL
Ejemplo de cURL

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

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

Después de enviar su solicitud, se le pedirá su contraseña.

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

Carga útil de la respuesta del endpoint de datos

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

{
	"results": [
		{
			"created_at": "Fri Nov 02 17:18:31 +0000 2018",
			"id": 1058408022936977409,
			"id_str": "1058408022936977409",
			"text": "RT @harmophone: \"The innovative crowdsourcing that the Tagboard, Twitter and TEGNA collaboration enables is surfacing locally relevant conv…",
			"source": "<a href=\"http:\/\/twitter.com\" rel=\"nofollow\">Twitter Web Client<\/a>",
			"truncated": false,
			"in_reply_to_status_id": null,
			"in_reply_to_status_id_str": null,
			"in_reply_to_user_id": null,
			"in_reply_to_user_id_str": null,
			"in_reply_to_screen_name": null,
			"user": {
				"id": 2244994945,
				"id_str": "2244994945",
				"name": "Twitter Dev",
				"screen_name": "TwitterDev",
				"location": "Internet",
				"url": "https:\/\/developer.x.com\/",
				"description": "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": "\"The innovative crowdsourcing that the Tagboard, Twitter and TEGNA collaboration enables is surfacing locally relev… https:\/\/t.co\/w46U5TRTzQ",
				"source": "<a href=\"http:\/\/twitter.com\" rel=\"nofollow\">Twitter Web Client<\/a>",
				"truncated": true,
				"in_reply_to_status_id": null,
				"in_reply_to_status_id_str": null,
				"in_reply_to_user_id": null,
				"in_reply_to_user_id_str": null,
				"in_reply_to_screen_name": null,
				"user": {
					"id": 175187944,
					"id_str": "175187944",
					"name": "Tyler Singletary",
					"screen_name": "harmophone",
					"location": "San Francisco, CA",
					"url": "http:\/\/medium.com\/@harmophone",
					"description": "SVP de Producto en @Tagboard. Hizo algo de Datos, negocios y producto en @Klout y para @LithiumTech; miembro de la junta de @BBI; asesor de @Insightpool. El peor dibujante en pizarra 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 recolección de datos masiva que permite la colaboración entre Tagboard, Twitter y TEGNA está revelando conversaciones localmente relevantes en tiempo real y permitiendo a los votantes hacer preguntas durante los debates,”  -- @adamostrow, @TEGNA\nAprende más: https:\/\/t.co\/ivAFtanfje",
					"display_text_range": [
						0,
						259
					],
					"entities": {
						"hashtags": [],
						"urls": [
							{
								"url": "https:\/\/t.co\/ivAFtanfje",
								"expanded_url": "https:\/\/blog.tagboard.com\/twitter-and-tagboard-collaborate-to-bring-best-election-content-to-news-outlets-with-tagboard-e85fc864bcf4",
								"display_url": "blog.tagboard.com\/twitter-and-ta…",
								"unwound": {
									"url": "https:\/\/blog.tagboard.com\/twitter-and-tagboard-collaborate-to-bring-best-election-content-to-news-outlets-with-tagboard-e85fc864bcf4",
									"status": 200,
									"title": "Twitter y Tagboard colaboran para llevar el mejor contenido electoral a los medios de noticias con Tagboard…",
									"description": "Por Tyler Singletary, Jefe de Producto, Tagboard"
								},
								"indices": [
									236,
									259
								]
							}
						],
						"user_mentions": [
							{
								"screen_name": "adamostrow",
								"name": "Adam Ostrow",
								"id": 5695942,
								"id_str": "5695942",
								"indices": [
									204,
									215
								]
							},
							{
								"screen_name": "TEGNA",
								"name": "TEGNA",
								"id": 34123003,
								"id_str": "34123003",
								"indices": [
									217,
									223
								]
							}
						],
						"symbols": []
					}
				},
				"quote_count": 0,
				"reply_count": 1,
				"retweet_count": 6,
				"favorite_count": 19,
				"entities": {
					"hashtags": [],
					"urls": [
						{
							"url": "https:\/\/t.co\/w46U5TRTzQ",
							"expanded_url": "https:\/\/twitter.com\/i\/web\/status\/1057384253116289025",
							"display_url": "twitter.com\/i\/web\/status\/1…",
							"indices": [
								117,
								140
							]
						}
					],
					"user_mentions": [],
					"symbols": []
				},
				"favorited": false,
				"retweeted": false,
				"possibly_sensitive": false,
				"filter_level": "low",
				"lang": "en"
			},
			"is_quote_status": false,
			"quote_count": 0,
			"reply_count": 0,
			"retweet_count": 0,
			"favorite_count": 0,
			"entities": {
				"hashtags": [],
				"urls": [],
				"user_mentions": [
					{
						"screen_name": "harmophone",
						"name": "Tyler Singletary",
						"id": 175187944,
						"id_str": "175187944",
						"indices": [
							3,
							14
						]
					}
				],
				"symbols": []
			},
			"favorited": false,
			"retweeted": false,
			"filter_level": "low",
			"lang": "en",
			"matching_rules": [
				{
					"tag": null
				}
			]
		}
	],
	"requestParameters": {
		"maxResults": 100,
		"fromDate": "201811010000",
		"toDate": "201811060000"
	}
}

Acceso al endpoint de conteos

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

cURL
cURL example

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

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

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

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

Carga útil de la respuesta del endpoint Counts

La carga útil 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 has accedido correctamente a la API Empresarial de búsqueda de Posts de 30 días.

Artículos referenciados

Primeros pasos con la búsqueda empresarial de Publicaciones: API de Archivo Completo

La API de búsqueda empresarial de Publicaciones: Archivo Completo le proporciona Publicaciones desde la primera publicada en 2006. Las Publicaciones se coinciden y se devuelven según la consulta que especifique en su solicitud. Una consulta es una regla mediante la cual define qué debe contener la Publicación que recibe. En este tutorial, buscaremos Publicaciones originarias de la cuenta de X @XDevelopers en inglés. Las Publicaciones que reciba en su carga útil pueden estar en un formato data, que le proporciona la carga útil completa de la Publicación, o puede estar en un formato counts que le da datos de conteo numérico de Publicaciones coincidentes. Usaremos cURL para realizar solicitudes a los endpoints data y counts. Necesitará lo siguiente:

Una cuenta empresarial
Su nombre de usuario, contraseña y nombre de cuenta
Etiqueta asociada con su endpoint de búsqueda, como se muestra en console.gnip.com

Acceso al endpoint de data

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

cURL
Ejemplo de cURL

cURL
Ejemplo de 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:

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

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

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

Payload de la respuesta del endpoint de datos

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

{
	"results": [
		{
			"created_at": "Fri Nov 02 17:18:31 +0000 2018",
			"id": 1058408022936977409,
			"id_str": "1058408022936977409",
			"text": "RT @harmophone: \"The innovative crowdsourcing that the Tagboard, Twitter and TEGNA collaboration enables is surfacing locally relevant conv…",
			"source": "<a href=\"http:\/\/twitter.com\" rel=\"nofollow\">Twitter Web Client<\/a>",
			"truncated": false,
			"in_reply_to_status_id": null,
			"in_reply_to_status_id_str": null,
			"in_reply_to_user_id": null,
			"in_reply_to_user_id_str": null,
			"in_reply_to_screen_name": null,
			"user": {
				"id": 2244994945,
				"id_str": "2244994945",
				"name": "Twitter Dev",
				"screen_name": "TwitterDev",
				"location": "Internet",
				"url": "https:\/\/developer.x.com\/",
				"description": "Your official source for Twitter Platform news, updates & events. Need technical help? Visit 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": "\"The innovative crowdsourcing that the Tagboard, Twitter and TEGNA collaboration enables is surfacing locally relev… https:\/\/t.co\/w46U5TRTzQ",
				"source": "<a href=\"http:\/\/twitter.com\" rel=\"nofollow\">Twitter Web Client<\/a>",
				"truncated": true,
				"in_reply_to_status_id": null,
				"in_reply_to_status_id_str": null,
				"in_reply_to_user_id": null,
				"in_reply_to_user_id_str": null,
				"in_reply_to_screen_name": null,
				"user": {
					"id": 175187944,
					"id_str": "175187944",
					"name": "Tyler Singletary",
					"screen_name": "harmophone",
					"location": "San Francisco, CA",
					"url": "http:\/\/medium.com\/@harmophone",
					"description": "SVP Product at @Tagboard. Did some Data, biz, and product @Klout & for @LithiumTech; @BBI board member; @Insightpool advisor. World's worst whiteboarder.",
					"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": "\"The innovative crowdsourcing that the Tagboard, Twitter and TEGNA collaboration enables is surfacing locally relevant conversations in real-time and enabling voters to ask questions during debates,”  -- @adamostrow, @TEGNA\nLearn More: 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 and Tagboard Collaborate to Bring Best Election Content to News Outlets With Tagboard…",
									"description": "By Tyler Singletary, Head of Product, Tagboard"
								},
								"indices": [
									236,
									259
								]
							}
						],
						"user_mentions": [
							{
								"screen_name": "adamostrow",
								"name": "Adam Ostrow",
								"id": 5695942,
								"id_str": "5695942",
								"indices": [
									204,
									215
								]
							},
							{
								"screen_name": "TEGNA",
								"name": "TEGNA",
								"id": 34123003,
								"id_str": "34123003",
								"indices": [
									217,
									223
								]
							}
						],
						"symbols": []
					}
				},
				"quote_count": 0,
				"reply_count": 1,
				"retweet_count": 6,
				"favorite_count": 19,
				"entities": {
					"hashtags": [],
					"urls": [
						{
							"url": "https:\/\/t.co\/w46U5TRTzQ",
							"expanded_url": "https:\/\/twitter.com\/i\/web\/status\/1057384253116289025",
							"display_url": "twitter.com\/i\/web\/status\/1…",
							"indices": [
								117,
								140
							]
						}
					],
					"user_mentions": [],
					"symbols": []
				},
				"favorited": false,
				"retweeted": false,
				"possibly_sensitive": false,
				"filter_level": "low",
				"lang": "en"
			},
			"is_quote_status": false,
			"quote_count": 0,
			"reply_count": 0,
			"retweet_count": 0,
			"favorite_count": 0,
			"entities": {
				"hashtags": [],
				"urls": [],
				"user_mentions": [
					{
						"screen_name": "harmophone",
						"name": "Tyler Singletary",
						"id": 175187944,
						"id_str": "175187944",
						"indices": [
							3,
							14
						]
					}
				],
				"symbols": []
			},
			"favorited": false,
			"retweeted": false,
			"filter_level": "low",
			"lang": "en",
			"matching_rules": [
				{
					"tag": null
				}
			]
		}
	],
	"requestParameters": {
		"maxResults": 100,
		"fromDate": "201811010000",
		"toDate": "201811060000"
	}
}

Acceso al endpoint de conteos

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

cURL
cURL example

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

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

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

Carga útil de la respuesta del endpoint Counts

La carga útil 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 ha accedido con éxito a la API Empresarial de Búsqueda de Posts: Archivo Completo.

Artículos referenciados

Guías

Construir consultas de búsqueda

Operadores empresariales

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

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

Para 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 un Post. Es una coincidencia tokenizada, lo que significa que tu cadena de palabra clave se comparará con el texto tokenizado del cuerpo del Post; la tokenización se basa en caracteres de puntuación, símbolos y separadores del plano básico de Unicode. Por ejemplo, un Post con el texto “I like coca-cola” se dividiría en los siguientes tokens: I, like, coca, cola. Estos tokens se compararían luego con la cadena de palabra clave usada en tu regla. Para hacer coincidir cadenas que contengan caracteres de puntuación (por ejemplo, coca-cola), símbolos o 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 otros idiomas o arrojar resultados inesperados: Por ejemplo:“música”coincidirá con “music” y viceversa. Por ejemplo, expresiones comunes como”¡Feliz Año Nuevo!“en español, se indexaría como”Feliz Año Nuevo”, lo cual cambia el significado de la frase. Nota:Este operador hará coincidir tanto las URL como las URL descomprimidas dentro de un Post.
emoji	Coincide con un emoji dentro del cuerpo de un Post. Los emojis se evalúan mediante coincidencias tokenizadas, lo que significa que tu emoji se comparará con el texto tokenizado del cuerpo del Post; la tokenización se basa en caracteres del plano básico de Unicode correspondientes a puntuación, símbolos/emojis y separadores. Por ejemplo, un Post con el texto “I like” se dividiría en los siguientes tokens: I, like,. Estos tokens 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 presente en el cuerpo o en las URL de un Post. Se trata de una coincidencia tokenizada, lo que significa que tu cadena de palabras clave se comparará con el texto tokenizado del cuerpo del Post; la tokenización se basa en caracteres del plano básico de Unicode de puntuación, símbolos y separadores. Nota:La puntuación no se tokeniza y, en su lugar, se trata como espacio en blanco. Por ejemplo, “#hashtag” entre comillas coincidirá con “hashtag”, pero no con #hashtag (usa el operador de hashtag # sin comillas para hacer coincidir hashtags reales). Por ejemplo, “ $cashtag” entre comillas coincidirá con “cashtag”, pero no con$ cashtag (usa el operador de cashtag $ sin comillas para hacer coincidir cashtags reales). Por ejemplo:“Amar la nieve”hará coincidir”#amor #nieve” Por ejemplo,“#Amor #Nieve”hará coincidir”me encanta la nieve” Nota:Este operador coincidirá tanto con las URL como con las URL expandidas dentro de un Post.
”keyword1 keyword2”~N	Conocido comúnmente como operador de proximidad, esto coincide con un Post en el que las palabras clave están a no más de N tokens de distancia entre sí. Si las palabras clave están en orden inverso, no pueden estar separadas por más de N-2 tokens. Se 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 API de búsqueda de Enterprise.`Empresarial`APIs de búsqueda.
de:	Coincide con cualquier Post de un usuario específico. El valor debe ser el id de cuenta numérico de X del usuario o su nombre de usuario (sin el carácter @). ConsulteAquíoAquípara conocer métodos para buscar id numéricos de cuentas de X.
Para:	Coincide con cualquier Post 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 @). ConsulteAquísobre métodos para buscar id numéricos de cuentas de X.
url:	Realiza una coincidencia tokenizada (palabra clave/frase) en las URL expandidas de un Post (similar a url_contiene). Los tokens y las frases que incluyan signos de puntuación o caracteres especiales deben ir entre comillas dobles. Por ejemplo, url:“/desarrolladores”. Aunque por lo general no se recomienda, si quieres hacer coincidir un protocolo específico, enciérralo entre comillas dobles: url:“https://developer.x.com”. Nota:Al usar PowerTrack o Historical PowerTrack, este operador coincidirá con las URL contenidas en el Post original de un Post con cita. Por ejemplo, si tu regla incluye url:“developer.x.com”, y si una Publicación contiene esa URL, cualquier Tweet con cita de esa Publicación se incluirá en los resultados. Esto no sucede al usar la Search API.
#	Coincide con cualquier Post que incluya el hashtag indicado. Este operador realiza una coincidencia exacta, NO una coincidencia 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 X’usa la extracción de entidades para hacer coincidir los hashtags, en lugar de extraer el hashtag del propio cuerpo. ConsulteAquípara obtener más información sobre los atributos JSON de X Entities.
@	Coincide con cualquier Post que mencione el nombre de usuario indicado. El operador to: devuelve una coincidencia parcial del operador @mention.
$	Coincide con cualquier Post que contenga la “cashtag” especificada (donde el primer carácter del token es el símbolo “$”). Tenga en cuenta que el operador de cashtag depende de X’la extracción de entidades “symbols” de X para identificar cashtags, en lugar de intentar extraer el cashtag del propio cuerpo. VéaseAquípara obtener más información sobre los atributos JSON de X Entities. Tenga en cuenta que este operador solo está disponible en las API de búsqueda de Enterprise.`Empresarial`APIs de búsqueda.
Retweets_de:	Alias disponible: retuits_de_usuario: Coincide con los Posts que son retweets de un usuario especificado. Acepta tanto nombres de usuario como id numéricas de cuentas de X (NO id de estado de Post). ConsulteAquípara conocer métodos para buscar id de cuentas numéricas de X.
lang:	Coincide con Posts que han sido clasificados por X como pertenecientes a un idioma específico (si, y solo si, el Post ha sido clasificado). Es importante señalar que actualmente cada Post solo se clasifica en un idioma, por lo que combinar varios idiomas con AND no arrojará resultados. Nota:si no se puede determinar la clasificación de idioma, el resultado proporcionado es “und” (por undefined). La siguiente lista muestra los idiomas compatibles actualmente 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	Odia: 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 Posts etiquetados con la ubicación especificada o con el X place ID (ver ejemplos). Los nombres de lugares con varias palabras (“New York City”, “Palo Alto”) deben ir entre comillas. Nota: Consulta el endpoint público GET geo/search para saber cómo obtener X place IDs. Nota: Este operador no coincidirá con Retweets, ya que los lugares de un Retweet están asociados al Post original. Tampoco coincidirá con los lugares asociados al Post original de un Quote Tweet.
place_country:	Coincide con Posts en los que el código de país asociado a un place etiquetado coincide con el código ISO alfa-2 indicado. Los códigos ISO válidos pueden consultarse aquí: http://en.wikipedia.org/wiki/ISO_3166-1_alpha-2 Nota: Este operador no coincidirá con Retweets, ya que los lugares de un Retweet están asociados al Post original. Tampoco coincidirá con los lugares asociados al Post original de un Quote Tweet.
point_radius:[lon lat radius]	Coincide con la ubicación exacta (x, y) del Post cuando está presente y, en X, con un polígono geográfico “Place”, cuando el Place esté completamente contenido dentro de la región definida. * Las unidades de radio admitidas son millas (mi) y kilómetros (km). * El radio debe ser menor que 25 mi. * La longitud está en el rango de ±180. * La latitud está en el rango de ±90. * Todas las coordenadas están en grados decimales. * Los argumentos de la regla se incluyen entre corchetes y se separan por espacios. Nota: Este operador no coincidirá con Retweets, ya que los lugares de un Retweet están asociados al Post original. Tampoco coincidirá con los lugares asociados al Post original de un Quote Tweet.
bounding_box:[west_long south_lat east_long north_lat]	Alias disponible: geo_bounding_box: Coincide con la ubicación exacta (long, lat) del Post cuando está presente y, en X, con un polígono geográfico “Place”, cuando el Place esté completamente contenido dentro de la región definida. * west_long y south_lat representan la esquina suroeste del rectángulo delimitador, donde west_long es la longitud de ese punto y south_lat es la latitud. * east_long y north_lat representan la esquina noreste del rectángulo delimitador, donde east_long es la longitud de ese punto y north_lat es la latitud. * El ancho y la altura del rectángulo delimitador 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 y se separan por espacios. Nota: Este operador no coincidirá con Retweets, ya que los lugares de un Retweet están asociados al Post original. Tampoco coincidirá con los lugares asociados al Post original de un Quote Tweet.
profile_country:	Coincidencia exacta con el campo “countryCode” del objeto “address” en el enriquecimiento de Profile Geo. Utiliza un conjunto normalizado de códigos de país de dos letras, basado en la especificación ISO‑3166‑1‑alpha‑2. Este operador se proporciona en lugar de un operador para el campo “country” del objeto “address” para mayor concisión.
profile_region:	Coincide con el campo “region” del objeto “address” en el enriquecimiento de Profile Geo. Es una coincidencia exacta de cadena completa. No es necesario escapar caracteres con una barra invertida. Por ejemplo, si se desea hacer coincidir algo con una barra, usa “one/two”, no “one/two”. Usa comillas dobles para hacer coincidir subcadenas que contengan espacios o signos de puntuación.
profile_locality:	Coincide con el campo “locality” del objeto “address” en el enriquecimiento de Profile Geo. Es una coincidencia exacta de cadena completa. No es necesario escapar caracteres con una barra invertida. Por ejemplo, si se desea hacer coincidir algo con una barra, usa “one/two”, no “one/two”. Usa comillas dobles para hacer coincidir subcadenas que contengan espacios o signos de puntuación.

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


has:geo	Coincide con Posts que tienen datos de geolocalización específicos del Post proporcionados por X. Esto puede ser una coordenada “geo” de latitud y longitud, o una “ubicación” en forma de un X “Place”, con el nombre para mostrar correspondiente, polígono geográfico y otros campos.«Place», con el nombre para mostrar correspondiente, polígono geográfico y otros campos. Nota:Al usar la API de búsqueda, este operador debe emplearse junto con otros operadores que no’no incluye`is:`o`tiene:`.
has:profile_geo	Alias disponible: has:derived_usuario_geo Coincide con los Posts que tengan cualquieraGeolocalización de perfilmetadatos, independientemente del valor concreto. Nota:Al usar la API de búsqueda, este operador debe emplearse junto con otros operadores que no’t incluyen`is:`o`tiene:`.
has:links	Este operador coincide con Posts que incluyen enlaces en el cuerpo del mensaje. Nota:Al utilizar la API de búsqueda, este operador debe emplearse junto con otros operadores que no’no incluye`is:`o`tiene:`.
is:retweet	Entregar solo Retweets explícitos que coincidan con una regla. También puede negarse para excluir de la entrega los Retweets que coincidan con una regla y entregar únicamente contenido original. Este operador busca únicamente Retweets auténticos, que usan X’funcionalidad de retweet. Tweets citados y publicaciones modificadas que no usan X’La funcionalidad de retweet de s no coincidirá con este operador. Nota:Al usar la API de Búsqueda, este operador debe utilizarse junto con otros operadores que no’no incluye`es:`o`tiene:`.
es:respuesta	Un operador para filtrar Posts según si son o no respuestas a otros Posts. Entrega solo las respuestas explícitas que coincidan con una regla. También puede negarse para excluir de la entrega las respuestas que coincidan con una regla. Tenga en cuenta que este operador está disponible para búsquedas de pago en los niveles Premium y Empresarial, y no está disponible en entornos de desarrollo Sandbox. Nota:Al usar la API de búsqueda, este operador debe emplearse junto con otros operadores que no’no incluye`is:`o`tiene:`.
is:quote	Entrega únicamente Quote Tweets o Posts que hacen referencia a otro Post, según lo identificado por el”es_cita textual_estado”:true en cargas útiles de Post. También puede negarse para excluir los Quote Tweets. Nota:Al usar la API de búsqueda, este operador debe emplearse junto con otros operadores que no’no incluye`is:`o`tiene:`.
es:verificado	Entregar solo Posts cuyo autor esté “verificado” por X. También se puede negar para excluir Posts cuyo autor esté verificado. Nota:Al usar la API de búsqueda, este operador debe emplearse junto con otros operadores que no’t incluyen`is:`o`tiene:`.
has:mentions	Coincide con Posts que mencionan a otro usuario de X. Nota:Al usar la API de Búsqueda, este operador debe emplearse junto con otros operadores que no’no incluye`is:`o`tiene:`.
has:hashtags	Coincide con los Posts que contienen un hashtag. Nota:Al usar la API de búsqueda, este operador debe utilizarse junto con otros operadores que no’t incluyen`is:`o`tiene:`.
has:media	Alias disponible: has:media_vínculo Coincide con Posts que contienen una URL de contenido multimedia clasificada por X. Por ejemplo, pic.x.com. Nota:Al usar la API de búsqueda, este operador debe emplearse junto con otros operadores que no’no incluye`is:`o`tiene:`.
has:images	Coincide con Posts que contienen una URL de medios clasificada por X. Por ejemplo, pic.x.com. Nota:Al usar la API de búsqueda, este operador debe emplearse junto con otros operadores que no’t incluyen`es:`o`tiene:`.
has:videos	Alias disponible: has:video_vínculo Coincide con Posts que contienen videos nativos de X, subidos directamente a X. Esto no coincidirá con videos creados con Vine, Periscope, ni con Posts con enlaces a otros sitios de alojamiento de videos. Nota:Al usar la API de búsqueda, este operador debe emplearse junto con otros operadores que no’no incluye`es:`o`tiene:`.
has:symbols	Coincide con los Posts que contienen un símbolo de cashtag (con un carácter « $» inicial; por ejemplo,$ tag). Tenga en cuenta que este operador solo está disponible en las`Empresarial`APIs de búsqueda. Nota:Al usar la API de búsqueda, este operador debe utilizarse junto con otros operadores que no’no incluye`is:`o`has:`.

Descripción del producto

La búsqueda de archivo completo de nivel Empresarial 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 Post disponible públicamente. Con Full-archive Search envías una única consulta y recibes una respuesta al estilo RESTful clásico. Full-archive Search implementa paginación de hasta 500 Posts por respuesta y admite un límite de hasta 60 solicitudes por minuto (rpm) para premium y 120 rpm para Empresarial. Con estos parámetros, Full-archive Search puede usarse para recuperar Posts rápidamente y, a gran escala, mediante solicitudes concurrentes. A diferencia de Historical PowerTrack, cuyo archivo se basa en un conjunto de archivos planos de Posts en disco, el archivo de Posts de Full-archive Search es muy parecido a una base de datos en línea. Como en todas las bases de datos, admite realizar consultas sobre su contenido. También utiliza un índice para habilitar una 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 Operators corresponde a un atributo JSON de Post que está indexado. Además, al igual que Historical PowerTrack, hay atributos de Post que se actualizan al momento en que se realiza una consulta. Por ejemplo, si hoy usas Search API para acceder a un Post publicado en 2010, la descripción del perfil del usuario, la ubicación “home” de la cuenta, el nombre para mostrar y las métricas del Post para los conteos de Favoritos y Retweets se actualizarán a los valores actuales 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 hiciera común en X. Por ejemplo, las @Replies surgieron como una convención de uso en 2006, pero no se convirtieron en un objeto o evento de primera clase con JSON “de soporte” hasta principios de 2007. En consecuencia, hacer coincidir @Replies en 2006 requiere examinar el cuerpo del Post, en lugar de depender de los operadores de PowerTrack to: e in_reply_to_status_id:. Los detalles proporcionados aquí se generaron utilizando la búsqueda de archivo completo (resultado de cientos de búsquedas). Esta cronología no es 100% completa ni precisa. Si identifica otra “fecha de nacimiento” de filtrado/metadatos fundamental para su caso de uso, háganoslo saber. Tenga en cuenta que el índice de búsqueda subyacente puede reconstruirse. En consecuencia, estos detalles de la cronología están sujetos a cambios.

2006

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

2007

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

2009

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

2010

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

2011

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

2014

3 de diciembre - (Aproximadamente) algunos metadatos de URL mejorados con título 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 coincide con videos nativos de X.
17 de febrero: has:profile_geo, profile_country:, profile_region:, profile_locality: comienzan a coincidir los operadores de Profile Geo.
17 de febrero: los operadores de geolocalización de Post place_country: y place: comienzan a coincidir.

2016

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

2017

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

2022

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

2022

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

Consejos de filtrado

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

Algunos metadatos tienen fechas de “nacimiento”, 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 buscas Posts con el operador has:images, no tendrás coincidencias en períodos anteriores a julio de 2011. Esto se debe a que ese operador coincide con fotos nativas (adjuntas a un Post mediante la interfaz de usuario de X). Para obtener un conjunto de datos más completo de Posts con fotos compartidas, los filtros anteriores a julio de 2011 tendrían que incluir cláusulas de reglas que coincidan con URL comunes de alojamiento de fotos.
Algunos metadatos se han rellenado retrospectivamente con información de un momento posterior al en que se publicó el Post.

Hay varios tipos de atributos en los que se suele poner el foco al crear consultas de PowerTrack:

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

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

Perfiles de X

Las APIs de búsqueda devuelven Posts históricos con los datos del perfil del usuario tal como están en el momento de la recuperación. Si solicitas un Post de 2014, los metadatos del perfil del usuario reflejarán cómo existen en el momento de la consulta.

Publicaciones originales y Retweets

El operador de PowerTrack _is:retweet_ permite incluir o excluir Retweets. Quienes usen este operador deben aplicar dos estrategias para identificar (o no) Retweets en los datos anteriores a agosto de 2009. Antes de esa fecha, es necesario revisar el propio mensaje de la Publicación, usando coincidencia de frase exacta, para detectar el patrón “RT @” (de hecho, si filtras Retweets entre mayo y agosto de 2009, también deberías incluir el patrón “Vía @”). Para los periodos posteriores a agosto de 2009, el operador is:retweet está disponible.

Clasificaciones de idioma de los Posts

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

Georreferenciación de Posts

Hay tres formas principales de georreferenciar Posts:

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

Enlaces y contenido multimedia compartidos

En marzo de 2012 se introdujo el enriquecimiento de URL ampliada. Antes de ese momento, las cargas útiles de Post incluían únicamente la URL tal como la proporcionaba el usuario. Por lo tanto, si el usuario incluía una URL acortada, puede resultar difícil hacer coincidir las URL (expandidas) de interés. Con las API de Búsqueda, 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 incorpora el título y la descripción HTML de un sitio web en la carga útil del Post, junto con operadores para hacer coincidencias en función de ellos. Estos metadatos comienzan a aparecer en diciembre de 2014. En septiembre de 2016, X introdujo los “adjuntos nativos”, por los que un enlace compartido al final no cuenta para el límite de 140 caracteres del Post. Ambos enriquecimientos de URL siguen aplicándose a estos enlaces compartidos. A continuación, se indica cuándo comienzan a coincidir los operadores de búsqueda relacionados:

26 de octubre de 2006 - has:links
20 de julio de 2011 - has:images y has:media
Agosto de 2011 - url: con el enriquecimiento de URLs ampliadas. Ya en 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 hay metadatos urls[] en twitter_entities ni en los 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 videos nativos. Entre 2010/08/28 y 2015/02/10, este operador coincide con Posts que contienen enlaces a sitios seleccionados de alojamiento de video, como youtube.com, vimeo.com y vivo.com.
1 de mayo de 2016 - url_title: y url_description:, basados en el enriquecimiento de URLs mejoradas, disponibilidad general. Los primeros metadatos de URL mejorada comenzaron a aparecer en diciembre de 2014.

Preguntas frecuentes (FAQ)

Preguntas generales sobre la API de búsqueda de Posts

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

Existe una diferencia conocida entre los resultados que proporciona el endpoint de conteos y el endpoint de data. Es posible que observe una discrepancia en sus resultados porque el endpoint de conteos es previo al cumplimiento (es decir, no contempla elementos como Posts eliminados, scrub_geo, etc.), mientras que el endpoint de data cumple con las normas en el momento de la entrega y tiene en cuenta todos los eventos de cumplimiento.

No recibí un Post que debería coincidir con mi consulta. ¿Por qué?

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

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

Mi consulta coincide con un Post pero incluye una palabra clave que excluí. ¿Por qué sucede esto?

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

¿Hay bibliotecas que pueda usar para empezar a utilizar las APIs de búsqueda de Post?

Sí, existen, entre ellas:

Tweepy - ideal para usar el producto estándar de búsqueda/Posts (Python)
X API - ideal para usar las API estándar de Search Post (Python)
Search Posts Python y Search Posts Ruby - dos herramientas recomendadas que pueden utilizarse con las API de Search Post de nivel Empresarial (¡y v2!)

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

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

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

¿En qué orden se devuelven los Posts coincidentes?

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

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

Solo el Post original contará a efectos de facturación. Cualquier edición posterior se ignorará y no se incluirá en tu recuento total de actividad. Empresarial

Estoy interesado en obtener más información sobre los precios de la Search Post API en el plan Empresarial y en solicitar este servicio. ¿Cómo puedo hacerlo?

Nuestras soluciones empresariales se adaptan a tus necesidades, con precios previsibles. Solicita más información aquí.

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

Consulta nuestra documentación de las API empresariales de búsqueda de Post aquí
Encontrarás información útil sobre reglas y filtrado aquí
Encontrarás información útil sobre el uso del endpoint data aquí
Encontrarás información útil sobre el uso del endpoint counts aquí
Puedes consultar una lista de operadores disponibles aquí

He superado los límites de solicitudes de este mes, pero necesito acceder a más datos. ¿Qué puedo hacer?

Comunícate con tu Account Manager en X, quien podrá ayudarte con esto.

Guía de resolución de errores

Código 404 - No encontrado

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

Referencia de API

APIs de búsqueda Empresarial

Hay dos APIs de búsqueda Empresarial:

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. Tenga en cuenta que, para los Tweets creados a partir del 29 de septiembre de 2022, los objetos Tweet incluirán metadatos de edición que describen su historial de ediciones. Consulte la página de fundamentos “Edit Tweets” para más detalles. A continuación encontrará detalles importantes necesarios para la integración con las APIs de búsqueda Empresarial:

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

Las APIs Empresariales proporcionan acceso de baja latencia, de alta fidelidad y basado en consultas al archivo de Tweets. La única diferencia entre ambas APIs es el intervalo temporal que se puede consultar, ya sea los 30 días anteriores o desde 2006. Los intervalos se pueden especificar con granularidad de minutos. Los datos de Tweets se entregan en orden cronológico inverso, comenzando por el Tweet más reciente que coincida con su consulta. Los Tweets están disponibles en la API de búsqueda aproximadamente 30 segundos después de su publicación.

Métodos

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

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

Donde:

:product indica el endpoint de búsqueda al que se envían las solicitudes, ya sea 30day o fullarchive.
:account_name es el nombre (sensible a mayúsculas y minúsculas) asociado a tu cuenta, tal como se muestra en console.gnip.com
:label es la etiqueta (sensible a mayúsculas y minúsculas) asociada a 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 varias solicitudes de ejemplo usando 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 datos.

Autenticación

Todas las solicitudes a las API de búsqueda Empresarial deben usar HTTP con Autenticación Básica, construida a partir de una combinación válida de dirección de correo electrónico y contraseña utilizada para iniciar sesión en su cuenta en https://console.gnip.com. Las credenciales deben enviarse en el encabezado Authorization de cada solicitud.

Comportamiento de solicitud/respuesta

Con los parámetros fromDate y toDate, puede solicitar cualquier periodo de tiempo que admita la API. 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”, ofrece 31 días para permitir realizar solicitudes de mes completo). La API de búsqueda de archivo completo proporciona Tweets desde el primer Tweet (21 de marzo de 2006). Sin embargo, una sola respuesta estará limitada al menor valor entre su maxResults especificado o 31 días. Si los datos coincidentes o su rango temporal superan su maxResults especificado o 31 días, recibirá un token next que debe usar para paginar el resto de su rango temporal especificado. Por ejemplo, supongamos que usa la búsqueda de archivo completo y desea todos los Tweets que coincidan con su consulta desde el 1 de enero de 2017 hasta el 30 de junio de 2017. Especificará ese periodo completo de seis meses en su solicitud con los parámetros fromDate y toDate. La API de búsqueda responderá con la primera “página” de Tweets, con la cantidad de Tweets que coincida con su parámetro maxResults (que de forma predeterminada es 100). Suponiendo que haya más Tweets (y lo más probable es que los haya), la API también proporcionará un token next que le permite solicitar la siguiente “página” de data. Este proceso se repite hasta que la API ya no devuelva un token next. Consulte la siguiente sección para más detalles.

Paginación

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

Paginación de datos

Es probable que las solicitudes de datos generen más información de la que puede devolverse en una sola respuesta. Cada solicitud de datos incluye un parámetro que establece la cantidad máxima de Tweets a devolver por solicitud. El parámetro maxResults tiene un valor predeterminado de 100 y puede configurarse entre 10 y 500. Si tu consulta devuelve más Tweets que el valor indicado en el parámetro ‘maxResults’ de la solicitud, la respuesta incluirá un token ‘next’ (como atributo JSON de nivel raíz). Este token ‘next’ se usa en la solicitud siguiente para recuperar el siguiente segmento de Tweets que coinciden con esa consulta (es decir, la siguiente “página”). Se seguirán proporcionando tokens ‘next’ hasta que llegues a 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 usaron, y además incluir un parámetro de solicitud ‘next’ establecido con el valor de la respuesta anterior. Esto puede utilizarse con una solicitud GET o POST. Sin embargo, en el caso de una solicitud GET, el parámetro ‘next’ debe ir codificado en la URL. Puedes seguir pasando el elemento ‘next’ de tu consulta anterior hasta que hayas recibido todos los Tweets del período cubierto por tu consulta. Cuando recibas una respuesta que no incluya un elemento ‘next’, significa que has llegado a la última página y no hay datos adicionales disponibles para la consulta y el intervalo de tiempo especificados.

Paginación de conteos

El endpoint ‘counts’ proporciona volúmenes de Tweet asociados a una consulta con granularidad diaria, por hora o por minuto. El endpoint de la API ‘counts’ devolverá un arreglo de conteos con marca de tiempo para un máximo de 31 días de conteos. Si solicita más de 31 días de conteos, se le proporcionará un token ‘next’. Al igual que con los tokens ‘next’ de data, debe realizar exactamente la misma consulta que la original e incluir también un parámetro de solicitud ‘next’ establecido con el valor de la respuesta anterior. Además de solicitar más de 31 días de conteos, 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 conteos tarde lo suficiente como para activar un tiempo de espera de la respuesta. Cuando esto ocurre, recibirá menos de 31 días de conteos, pero se le proporcionará un token ‘next’ para continuar realizando solicitudes hasta obtener toda la carga de conteos. Importante: Los tiempos de espera solo devuelven “buckets” completos; por lo tanto, 2,5 días resultarían en 2 “buckets” completos de día.

Notas adicionales

Cuando uses fromDate o toDate en una solicitud de búsqueda, solo obtendrás resultados dentro de tu rango temporal. Al llegar al último grupo de resultados dentro de ese rango, no recibirás un token “next”.
El elemento “next” puede usarse con cualquier valor de maxResults entre 10 y 500 (el valor predeterminado es 100). maxResults determina cuántos Tweets se devuelven en cada respuesta, pero no impide que eventualmente obtengas todos los resultados.
El elemento “next” no caduca. Varias solicitudes que usen la misma consulta “next” recibirán los mismos resultados, sin importar cuándo se realice la solicitud.
Al paginar los resultados usando el parámetro “next”, podrías encontrar duplicados en los límites de la consulta. Tu App debe tolerarlos.

Endpoint de Data

POST /search/:product/:label

Patrón de endpoint:

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

Parámetros de la solicitud de datos

Parámetros	Descripción	Obligatorio	Valor de ejemplo
query	Equivale a una regla de PowerTrack, con hasta 2.048 caracteres (sin límites en la cantidad de cláusulas positivas y negativas). Este parámetro debe incluir TODAS las partes de la regla de PowerTrack, incluidos todos los operadores; no se deben separar partes de la regla en otros parámetros de la consulta. Nota: No todos los operadores de PowerTrack son compatibles. Los operadores compatibles se enumeran AQUÍ.	Sí	(snow OR cold OR blizzard) weather
tag	Las etiquetas pueden usarse para segmentar reglas y sus datos coincidentes en diferentes grupos lógicos. Si se proporciona una etiqueta de regla, esta se incluye en el atributo ‘matching_rules’. Se recomienda asignar UUID específicos de cada regla a las etiquetas de regla y mantener los mapeos deseados 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) 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 entregará resultados para la consulta retrocediendo 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 usa ni fromDate ni toDate, la API entregará todos los resultados de los 30 días más recientes, comenzando en el momento de la solicitud y yendo hacia atrás.	No	201207220000
toDate	La marca de tiempo UTC más reciente hasta la cual se proporcionarán los Tweets. La marca de tiempo tiene granularidad de minutos y no es inclusiva (es decir, 11:59 no incluye el minuto 59 de la hora). Especificado: Usar solo toDate sin el parámetro fromDate entregará los 30 días más recientes de datos previos a toDate. No especificado: Si no se especifica un toDate, la API entregará todos los resultados desde now( ) para la consulta retrocediendo en el tiempo hasta fromDate. Si no se usa ni 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 yendo hacia atrás.	No	201208220000
maxResults	El número máximo de resultados de búsqueda que se devolverán en una solicitud. Un número entre 10 y el límite del sistema (actualmente 500). De forma predeterminada, la respuesta de una solicitud devolverá 100 resultados.	No	500
next	Este parámetro se utiliza 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 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 (y sin límites en la cantidad de cláusulas positivas y negativas). Nota: No todos los operadores de PowerTrack son compatibles. Consulta los operadores disponibles para ver la lista de operadores compatibles.
Límite de velocidad	Los socios estarán sujetos a límites de velocidad con granularidad por minuto y por segundo. El límite por minuto variará según el socio, según lo especificado en tu contrato. Sin embargo, estos límites por minuto no están destinados a usarse en una sola ráfaga. Independientemente de tu límite por minuto, todos los socios estarán limitados a un máximo de 20 solicitudes por segundo, agregado en todas las solicitudes de data y/o conteos.
Cumplimiento	Toda la data entregada a través de la Full-Archive Search API cumple en el momento de la entrega.
Disponibilidad en tiempo real	La data está disponible en el índice dentro de los 30 segundos posteriores a su generación en la plataforma de X

Ejemplos de solicitudes y respuestas de data

Ejemplo de solicitud POST

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

A continuación se muestra un comando POST de ejemplo (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 datos de la API incluye un token ‘next’, a continuación se muestra una solicitud posterior que replica 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 en 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 consultan (p. ej., palabras clave u otros operadores como bounding_box:) deben incluirse en el parámetro “query”.
No separe partes de la regla como parámetros independientes en la URL de la consulta.

A continuación, se muestra un ejemplo de comando GET (con 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 data

Tenga en cuenta que, para los Tweets creados a partir del 29 de septiembre de 2022, los objetos Tweet incluirán metadatos de edición del Tweet que describen su historial de ediciones. Consulte la página de conceptos básicos “Edit Tweets” para obtener más detalles. A continuación se muestra un ejemplo de respuesta a una consulta de data. Este ejemplo supone que había más Tweets disponibles que ‘maxResults’, por lo que se proporciona un token ‘next’ para solicitudes posteriores. Si ‘maxResults’ o menos Tweets están asociados con su 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’ tendrá el siguiente aspecto en el cuerpo de la respuesta:

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

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

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

Puedes seguir pasando el elemento ‘next’ de tu consulta anterior hasta haber 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 llegado a la última página y no hay datos adicionales disponibles para tu intervalo de tiempo.

Endpoint de recuentos

/search/:stream/counts

Patrón del endpoint:

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

Parámetros de la solicitud de conteos

Parámetros	Descripción	Requerido	Valor de ejemplo
query	Equivale a una regla de PowerTrack, con hasta 2,048 caracteres (y sin límite en el número de cláusulas positivas y negativas). Este parámetro debe incluir TODAS las partes de la regla de PowerTrack, incluidos todos los operadores; no se deben separar partes de la regla en otros parámetros de la consulta. Nota: No todos los operadores de PowerTrack son compatibles. Consulta los operadores disponibles para ver la lista de operadores compatibles.	Sí	(snow OR cold OR blizzard) weather
fromDate	La marca de tiempo UTC más antigua (hasta el 21/3/2006) desde la cual se proporcionarán los Tweets. La marca de tiempo tiene granularidad de minuto y es inclusiva (p. ej., 12:00 incluye el minuto 00). Especificado: Usar solo fromDate sin el parámetro toDate hará que la API entregue conteos (volúmenes de datos) para la consulta yendo hacia atrás en el tiempo desde ahora hasta fromDate. Si fromDate es anterior a 31 días desde ahora ( ), recibirás un token next para paginar tu solicitud. No especificado: Si no se especifica fromDate, la API entregará conteos (volúmenes de datos) para los 30 días previos a ahora ( ) o a toDate (si se especifica). Si no se usa ni el parámetro fromDate ni toDate, la API entregará conteos (volúmenes de datos) 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 minuto y no es inclusiva (p. ej., 11:59 no incluye el minuto 59 de la hora). Especificado: Usar solo toDate sin el parámetro fromDate entregará los conteos (volúmenes de datos) más recientes de los 30 días previos a toDate. No especificado: Si no se especifica toDate, la API entregará conteos (volúmenes de datos) para la consulta yendo hacia atrás en el tiempo hasta fromDate. Si fromDate es más de 31 días desde ahora ( ), recibirás un token next para paginar tu solicitud. Si no se usa ni el parámetro fromDate ni toDate, la API entregará conteos (volúmenes de datos) de los 30 días más recientes, comenzando en el momento de la solicitud y 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 periodo 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 toma directamente de la respuesta de la API y no debe modificarse.	No	NTcxODIyMDMyODMwMjU1MTA0

Detalles adicionales


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

Ejemplos de solicitudes y respuestas de conteo

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.
Todas las partes de la regla de PowerTrack que se van a consultar (p. ej., palabras clave u otros operadores como bounding_box:) deben colocarse en el parámetro ‘query’.
No separe partes de la regla como parámetros independientes en la URL de la consulta.

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

    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 corresponde a la solicitud original, con el parámetro “next” establecido en el token proporcionado:

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

Ejemplo de solicitud GET

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

A continuación se muestra un ejemplo de comando GET (con 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 conteo

A continuación se muestra un ejemplo de respuesta a una consulta de conteo (volumen de datos). Este ejemplo de respuesta incluye un token “next”, lo que significa que la solicitud de conteo abarcaba más de 31 días o que la consulta enviada tenía un volumen suficientemente grande como para generar 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 verse así (observe la nueva línea de tiempo de conteos y el valor diferente de ‘next’):

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

Puede seguir pasando el elemento ‘next’ de su consulta anterior hasta que haya recibido todos los conteos del período de la consulta. Cuando reciba una respuesta que no incluya un elemento ‘next’, significará que ha llegado a la última página y no hay conteos adicionales disponibles en su intervalo de tiempo.

Códigos de respuesta HTTP

Estado	Texto	Descripción
200	OK	La solicitud se completó correctamente. La respuesta JSON será similar a lo siguiente:
400	Solicitud incorrecta	Generalmente, esta respuesta se debe a JSON no válido en la solicitud o a que no se envió ningún payload JSON.
401	No autorizado	La autenticación HTTP falló debido a credenciales no válidas. Inicia sesión en console.gnip.com con tus credenciales para confirmar que las usas correctamente en tu solicitud.
404	No encontrado	No se encontró el recurso en la URL a la que se envió la solicitud, probablemente porque se usó una URL incorrecta.
422	Entidad no procesable	Se devuelve debido a parámetros no válidos en la consulta (p. ej., reglas de PowerTrack no válidas).
429	Código desconocido	Tu App ha superado el límite de solicitudes de conexión. El mensaje JSON correspondiente será similar a lo siguiente:
500	Error interno del servidor	Ocurrió un error del lado del servidor. Vuelve a intentar la solicitud usando un patrón de backoff exponencial.
502	Error de proxy	Ocurrió un error del lado del servidor. Vuelve a intentar la solicitud usando un patrón de backoff exponencial.
503	Servicio no disponible	Ocurrió un error del lado del servidor. Vuelve a intentar la solicitud usando un patrón de backoff exponencial.

Descripción general

Posts

Usuarios

Mensajes Directos

Me gusta

Listas

Espacios

Comunidades

Notas de la comunidad

Tendencias

Multimedia

Actividad de X

Uso

Conexiones de streaming

Cumplimiento normativo

Empresarial v2

Flujos de “Me gusta”

GNIP 2.0

​Descripción general

​Tipos de solicitudes

​Solicitudes de búsqueda (datos)

​Solicitudes de recuentos (Recuento de publicaciones)

​Operadores disponibles

​Disponibilidad de datos / fechas importantes

​Actualizaciones de datos y mutabilidad

​Solicitudes de un solo hilo vs. solicitudes multihilo

​Lógica de reintento

​Inicio rápido

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

​Acceso al endpoint de datos

​Carga útil de la respuesta del endpoint de datos

​Acceso al endpoint de conteos

​Carga útil de la respuesta del endpoint Counts

Artículos referenciados

​Primeros pasos con la búsqueda empresarial de Publicaciones: API de Archivo Completo

​Acceso al endpoint de data

Payload de la respuesta del endpoint de datos

​Acceso al endpoint de conteos

​Carga útil de la respuesta del endpoint Counts

Artículos referenciados

​Guías

​Construir consultas de búsqueda

​Operadores empresariales

​Descripción del producto

​Cronologías de metadatos

​2006

​2007

​2009

​2010

​2011

​2014

​2015

​2016

​2017

​2022

​2022

​Consejos de filtrado

​Perfiles de X

​Publicaciones originales y Retweets

​Clasificaciones de idioma de los Posts

​Georreferenciación de Posts

​Enlaces y contenido multimedia compartidos

​Preguntas frecuentes (FAQ)

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

​Guía de resolución de errores

​Referencia de API

​APIs de búsqueda Empresarial

​Métodos

​Autenticación

​Comportamiento de solicitud/respuesta

​Paginación

Paginación de datos

Paginación de conteos

Notas adicionales

​Endpoint de Data

POST /search/:product/:label

Patrón de endpoint:

Parámetros de la solicitud de datos

Detalles adicionales

Ejemplos de solicitudes y respuestas de data

Descripción general

Tipos de solicitudes

Solicitudes de búsqueda (datos)

Solicitudes de recuentos (Recuento de publicaciones)

Operadores disponibles

Disponibilidad de datos / fechas importantes

Actualizaciones de datos y mutabilidad

Solicitudes de un solo hilo vs. solicitudes multihilo

Lógica de reintento

Inicio rápido

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

Acceso al endpoint de datos

Carga útil de la respuesta del endpoint de datos

Acceso al endpoint de conteos

Carga útil de la respuesta del endpoint Counts

Primeros pasos con la búsqueda empresarial de Publicaciones: API de Archivo Completo

Acceso al endpoint de data

Acceso al endpoint de conteos

Carga útil de la respuesta del endpoint Counts

Guías

Construir consultas de búsqueda

Operadores empresariales

Descripción del producto

Cronologías de metadatos

2006

2007

2009

2010

2011

2014

2015

2016

2017

2022

2022

Consejos de filtrado

Perfiles de X

Publicaciones originales y Retweets

Clasificaciones de idioma de los Posts

Georreferenciación de Posts

Enlaces y contenido multimedia compartidos

Preguntas frecuentes (FAQ)

Preguntas generales sobre la API de búsqueda de Posts

Guía de resolución de errores

Referencia de API

APIs de búsqueda Empresarial

Métodos

Autenticación

Comportamiento de solicitud/respuesta

Paginación

Endpoint de Data

Endpoint de recuentos

Ejemplos de respuestas de conteo

Códigos de respuesta HTTP