API de Twitter con Go: cómo obtener datos de X en 2026 (guía)

Por Sorsa Editorial

Publicado en junio de 2026, actualizado en julio de 2026: refleja el precio de pago por uso vigente de X (incluidos los cambios de costo de escritura de abril de 2026) y el estado de las herramientas de Go, donde X publica SDKs oficiales solo para Python y TypeScript, no para Go. Actualización de julio de 2026: agregada la oferta inicial de 100 solicitudes gratis y refrescado el precio por solicitud de Sorsa a una base por cada 1,000.

Conclusión clave: No hay un SDK oficial de la API de X (Twitter) para Go en 2026; X publica SDKs oficiales solo para Python y TypeScript. Las vías prácticas en Go son una librería de comunidad con mantenimiento como gotwtr, net/http simple con un bearer token, o una API REST de terceros de solo lectura.

Si buscaste "twitter api golang" esperando un paquete oficial y con soporte, no lo hay. X publicó SDKs de primera parte para Python y TypeScript a finales de 2025 y dejó Go a la comunidad. La mayoría de los tutoriales de Go que rankean para esta consulta son peores que ausentes: enseñan dghubble/go-twitter, que solo habla la API v1.1 retirada, contra un precio que ya no existe.

Nosotros construimos y operamos Sorsa API, una API alternativa de Twitter/X, y Go es un encaje natural para la vía de solo lectura: devuelve perfiles, tweets, resultados de búsqueda y seguidores como JSON limpio que mapea directo a structs de Go, con una clave API en el encabezado ApiKey, sin negociación OAuth y sin aprobación de cuenta de desarrollador que esperar. En trabajo intensivo en lecturas resulta hasta unas 50 veces más barata que la API oficial de X: el precio por lotes empieza desde $0.02 por cada 1,000 tweets y desde $0.01 por cada 1,000 perfiles, el límite de tasa es fijo, de 20 solicitudes por segundo en todos los planes, y una cuenta nueva incluye 100 solicitudes gratis (por única vez, sin tarjeta, con cada endpoint incluido) antes de cualquier plan de pago. No todo proyecto encaja en ese molde: unos necesitan publicar, y otros necesitan la API oficial por cumplimiento. Esta guía cubre cada vía de Go con código funcional, precio vigente y un recolector concurrente que respeta el límite de tasa. También puedes probar llamadas sin escribir código en el playground de la API.

Contenido

• Qué cambió: la API de X y las herramientas de Go en 2026
• La mejor librería de Go para la API de X
• ¿Qué enfoque deberías usar?
• Método 1: una librería de comunidad (gotwtr)
• Método 2: net/http simple con un bearer token
• Método 3: una API REST de solo lectura
• ¿Hay un SDK oficial de Go para la API de X?
• Construir un recolector de datos concurrente en Go
• Comparación: tres vías, lado a lado
• Cómo obtener tus credenciales de API
• En la práctica: recortar el costo de un recolector en Go
• Preguntas frecuentes
• Cómo empezar

Qué cambió: la API de X y las herramientas de Go en 2026 {#what-changed-the-x-api-and-go-tooling-in-2026}

Tres cosas cambiaron para quienes desarrollan en Go desde que se escribieron los tutoriales viejos. La API de X pasó al cobro de pago por uso sin nivel gratuito y cobra por recurso leído. Escribir se encareció tras la actualización de abril de 2026. Y X publicó sus primeros SDKs oficiales, pero solo para Python y TypeScript, así que quienes desarrollan en Go todavía dependen de librerías de comunidad o de HTTP crudo.

El pago por uso es lo predeterminado. No hay nivel gratuito ni plan Basic mensual para registros nuevos. Compras créditos y pagas por recurso: $0.005 por lectura de post, $0.010 por perfil de usuario y $0.010 por cada registro de seguidor o seguido. Leer los datos de tu propia cuenta cuesta $0.001 por recurso, y las cuentas estándar tienen tope de 2 millones de lecturas de posts al mes. Los números detrás de un presupuesto real están en nuestro desglose de precios de la API de X.

Escribir se encareció. Tras la actualización de abril de 2026, un post estándar cuesta $0.015 por solicitud y un post que contiene una URL cuesta $0.20. Las acciones de follow, like y cita de post se quitaron de los niveles de autoservicio y ahora requieren un contrato Enterprise.

Los SDKs oficiales llegaron solo para Python y TypeScript. A finales de 2025 X anunció XDKs de primera parte para esos dos lenguajes. No hay SDK oficial de Go. Las librerías de comunidad llenan el hueco, y la más fuerte para la API v2 es gotwtr, que cubre la superficie v2 completa con un bearer token de OAuth 2.0.

Las viejas librerías de Go están en su mayoría muertas. dghubble/go-twitter, la librería que casi todo tutorial viejo de Go usa, apunta a la API v1.1 que X retiró. Cualquier guía que llame a client.Statuses.Update o client.Search.Tweets con campos v1.1 está desactualizada.

La mejor librería de Go para la API de X {#the-best-go-library-for-the-x-api}

Para trabajo nuevo en v2 en Go, gotwtr es la mejor librería de propósito general: apunta a la API v2, se autentica con un bearer token de OAuth 2.0 y cubre usuarios, tweets, búsqueda, seguidores, cronologías y escrituras. No hay un SDK oficial de Go que preferir sobre ella. Para recolección de datos de solo lectura, muchos equipos de Go se saltan las librerías y llaman a una API REST de terceros con el paquete estándar net/http, que elimina OAuth por completo.

Así se comparan las opciones principales.

Cualquiera que sea la librería que elijas para la API oficial, el costo es idéntico, porque X cobra por recurso de su lado, no por librería. La variable que controlas es cuántos recursos extraes, que es donde los endpoints por lotes y una API de tarifa plana cambian las cuentas.

¿Qué enfoque deberías usar? {#which-approach-should-you-use}

Elige la vía antes de escribir código. Para leer y escribir contra la API v2 con una librería tipada, usa gotwtr. Para datos de solo lectura a volumen con configuración mínima, una API REST de terceros elimina OAuth y la cola de aprobación. Para control total sin dependencias, el paquete estándar net/http alcanza. La decisión es en su mayoría lectura contra escritura, y cuánto volumen extraes.

Si tu proyecto solo lee datos públicos, una API de terceros elimina el flujo OAuth: una clave en un encabezado y empiezas a extraer datos, sin solicitud de cuenta de desarrollador y sin compra de créditos. Si necesitas publicar o correr acciones de escritura, la API oficial a través de gotwtr es la vía; ningún proveedor de terceros publica en tu nombre. ¿Trabajas en otro lenguaje? Consulta la versión en Python de esta guía.

Método 1: una librería de comunidad (gotwtr) {#method-1-a-community-library-gotwtr}

gotwtr es un cliente de Go para la API de X v2. Se autentica con un bearer token de OAuth 2.0, devuelve respuestas tipadas y cubre el conjunto completo de endpoints v2. Es lo más cercano que Go tiene a un cliente de Twitter completo y vigente.

Instálalo:

go get github.com/sivchari/gotwtr

Busca los últimos siete días e imprime los resultados:

package main

import (
	"context"
	"fmt"
	"os"

	"github.com/sivchari/gotwtr"
)

func main() {
	client := gotwtr.New(os.Getenv("X_API_BEARER_TOKEN"))

	tsr, err := client.SearchRecentTweets(context.Background(), "golang lang:en", &gotwtr.SearchTweetsOption{
		TweetFields: []gotwtr.TweetField{gotwtr.TweetFieldAuthorID, gotwtr.TweetFieldCreatedAt},
		MaxResults:  20,
	})
	if err != nil {
		panic(err)
	}

	for _, t := range tsr.Tweets {
		fmt.Println(t.Text)
	}
}

Consulta tweets específicos por ID:

ts, err := client.RetrieveMultipleTweets(context.Background(), []string{"1782368585664626774"})
if err != nil {
	panic(err)
}

for _, t := range ts.Tweets {
	fmt.Println(t.Text)
}

gotwtr también cubre la consulta de usuario (RetrieveSingleUserWithUserName), las listas de seguidores y seguidos (Followers, Following), las cronologías de usuario (UserTweetTimeline), las escrituras (PostTweet) y el streaming filtrado o muestreado (ConnectToStream, VolumeStreams). Es la elección correcta cuando quieres acceso v2 tipado y también puedes escribir. Las contrapartidas: la mantiene la comunidad y no es de primera parte, todavía necesitas una cuenta de desarrollador de X de pago, y pagas el precio por recurso de X en cada llamada.

Método 2: net/http simple con un bearer token {#method-2-plain-nethttp-with-a-bearer-token}

Sin librería, sin wrapper. El paquete estándar net/http de Go y encoding/json alcanzan para llamar a la API de X v2 con un bearer token. Esta vía conviene a quienes quieren control total sobre las solicitudes y los structs de respuesta, o prefieren evitar dependencias de terceros.

Define un struct para los campos que quieres y consulta un perfil:

package main

import (
	"encoding/json"
	"fmt"
	"net/http"
	"os"
)

type userResponse struct {
	Data struct {
		ID            string `json:"id"`
		Username      string `json:"username"`
		Name          string `json:"name"`
		PublicMetrics struct {
			FollowersCount int `json:"followers_count"`
		} `json:"public_metrics"`
	} `json:"data"`
}

func main() {
	req, _ := http.NewRequest(http.MethodGet, "https://api.x.com/2/users/by/username/elonmusk", nil)

	q := req.URL.Query()
	q.Set("user.fields", "public_metrics,created_at")
	req.URL.RawQuery = q.Encode()
	req.Header.Set("Authorization", "Bearer "+os.Getenv("X_API_BEARER_TOKEN"))

	resp, err := http.DefaultClient.Do(req)
	if err != nil {
		panic(err)
	}
	defer resp.Body.Close()

	var u userResponse
	json.NewDecoder(resp.Body).Decode(&u)

	fmt.Printf("@%s has %d followers\n", u.Data.Username, u.Data.PublicMetrics.FollowersCount)
}

La API oficial pagina la búsqueda con un next_token en el meta de la respuesta. Recorre cada resultado con un guardián para que una consulta amplia no agote tu cuota:

func searchRecent(token, query string) ([]map[string]any, error) {
	var all []map[string]any
	nextToken := ""

	for {
		req, _ := http.NewRequest(http.MethodGet, "https://api.x.com/2/tweets/search/recent", nil)
		q := req.URL.Query()
		q.Set("query", query)
		q.Set("max_results", "100")
		q.Set("tweet.fields", "created_at,public_metrics")
		if nextToken != "" {
			q.Set("next_token", nextToken)
		}
		req.URL.RawQuery = q.Encode()
		req.Header.Set("Authorization", "Bearer "+token)

		resp, err := http.DefaultClient.Do(req)
		if err != nil {
			return nil, err
		}

		var body struct {
			Data []map[string]any `json:"data"`
			Meta struct {
				NextToken string `json:"next_token"`
			} `json:"meta"`
		}
		json.NewDecoder(resp.Body).Decode(&body)
		resp.Body.Close()

		all = append(all, body.Data...)
		if body.Meta.NextToken == "" {
			break
		}
		nextToken = body.Meta.NextToken
	}

	return all, nil
}

Esto funciona cuando quieres cero dependencias o estás depurando el comportamiento de la API. La desventaja es que tú eres dueño de la paginación, el manejo de códigos de estado, el límite de tasa y los reintentos. Para un trabajo puntual está bien; para un pipeline de producción terminas escribiendo un cliente pequeño propio. Esta vía todavía requiere una cuenta de desarrollador y créditos de pago por uso.

Método 3: una API REST de solo lectura {#method-3-a-read-only-rest-api}

Si un servicio de Go solo lee datos públicos de Twitter, una API REST de terceros se salta la API oficial por completo: sin OAuth, sin paso de solicitud, sin flujo de compra de créditos, solo una clave en un encabezado y JSON que decodifica directo a structs.

Esta es la vía práctica para obtener datos de X sin una cuenta de desarrollador. Así se ve con Sorsa, usando nada más que la librería estándar.

Obtén un perfil de usuario:

package main

import (
	"encoding/json"
	"fmt"
	"net/http"
	"os"
)

type sorsaUser struct {
	ID             string `json:"id"`
	Username       string `json:"username"`
	DisplayName    string `json:"display_name"`
	FollowersCount int    `json:"followers_count"`
}

func main() {
	req, _ := http.NewRequest(http.MethodGet, "https://api.sorsa.io/v3/info?username=elonmusk", nil)
	req.Header.Set("ApiKey", os.Getenv("SORSA_API_KEY"))

	resp, err := http.DefaultClient.Do(req)
	if err != nil {
		panic(err)
	}
	defer resp.Body.Close()

	var u sorsaUser
	json.NewDecoder(resp.Body).Decode(&u)

	fmt.Printf("@%s (%s): %d followers\n", u.Username, u.DisplayName, u.FollowersCount)
}

Busca tweets con el conjunto completo de operadores web. El endpoint de búsqueda devuelve unos 20 tweets por página y un next_cursor para la siguiente:

import "bytes"

type sorsaTweet struct {
	ID         string `json:"id"`
	FullText   string `json:"full_text"`
	LikesCount int    `json:"likes_count"`
}

type searchResponse struct {
	Tweets     []sorsaTweet `json:"tweets"`
	NextCursor string       `json:"next_cursor"`
}

func searchTweets(apiKey, query string) (*searchResponse, error) {
	payload, _ := json.Marshal(map[string]string{"query": query, "order": "latest"})

	req, _ := http.NewRequest(http.MethodPost, "https://api.sorsa.io/v3/search-tweets", bytes.NewReader(payload))
	req.Header.Set("ApiKey", apiKey)
	req.Header.Set("Content-Type", "application/json")

	resp, err := http.DefaultClient.Do(req)
	if err != nil {
		return nil, err
	}
	defer resp.Body.Close()

	var out searchResponse
	if err := json.NewDecoder(resp.Body).Decode(&out); err != nil {
		return nil, err
	}
	return &out, nil
}

Extrae una lista de seguidores. Una solicitud devuelve hasta 200 perfiles, así que una cuenta de 1,000 seguidores son cinco solicitudes en lugar de diez páginas paginadas:

type followersResponse struct {
	Users      []sorsaUser `json:"users"`
	NextCursor string      `json:"next_cursor"`
}

// GET https://api.sorsa.io/v3/followers?username=elonmusk returns up to 200 users

Para consultas complejas, combina operadores como lo harías en la búsqueda avanzada; la lista completa está en nuestra referencia de operadores de búsqueda. Cada respuesta de tweet carga el perfil del autor y las métricas públicas, así que traer listas de seguidores y leer números de engagement no suma llamadas extra. El encabezado es ApiKey, la URL base es https://api.sorsa.io/v3, y los nombres de campo coinciden exactamente con la documentación de la API. Para extraer hasta 100 tweets en una solicitud, envía sus IDs por POST a /tweet-info-bulk, que cuenta como una sola solicitud y devuelve objetos completos de tweets.

¿Hay un SDK oficial de Go para la API de X? {#is-there-an-official-go-sdk-for-the-x-api}

No. A 2026 X publica SDKs oficiales solo para Python y TypeScript; no hay SDK oficial de Go. La propia página de herramientas y librerías de X lista esos dos SDKs de primera parte más herramientas de desarrollo, y el generador de XDK de código abierto actualmente publica plantillas solo para Python y TypeScript, con Go documentado como un objetivo de contribución futura en lugar de un paquete lanzado.

Para Go, eso deja tres opciones reales, todas cubiertas arriba: la librería de comunidad gotwtr para acceso v2 tipado, net/http simple para control total, o una API de terceros de solo lectura para trabajo intensivo en lecturas. Para revisiones manuales rápidas sin escribir Go en absoluto, X también publica xurl, una herramienta de línea de comandos oficial estilo curl con OAuth integrado, útil para hurgar en los endpoints antes de conectarlos al código.

Si un SDK de Go llega más adelante, se generará a partir de la misma especificación OpenAPI que los de Python y TypeScript, así que su superficie se parecerá a esas. Hasta entonces, trata cualquier tutorial que afirme un "SDK oficial de Go" como inexacto.

Construir un recolector de datos concurrente en Go {#building-a-concurrent-data-collector-in-go}

La ventaja real de Go para la recolección de datos es la concurrencia, pero la concurrencia contra una API con límite de tasa necesita un regulador, o cambias errores 429 por velocidad. El patrón que funciona: reparte las solicitudes entre goroutines, contrólalas a través de un solo limitador de tasa dimensionado al límite de la API, y recolecta los resultados bajo un mutex. Contra un límite fijo de 20 solicitudes por segundo, un ticker que libera una ranura cada 50 milisegundos mantiene a cada goroutine dentro del presupuesto.

Este recolector trae tweets recientes para muchas consultas a la vez mientras se mantiene bajo el límite. Reutiliza la función searchTweets y el struct sorsaTweet del Método 3.

package main

import (
	"fmt"
	"sync"
	"time"
)

func collectForQueries(apiKey string, queries []string) map[string][]sorsaTweet {
	const ratePerSecond = 20
	ticker := time.NewTicker(time.Second / ratePerSecond) // one slot every 50ms
	defer ticker.Stop()

	results := make(map[string][]sorsaTweet)
	var mu sync.Mutex
	var wg sync.WaitGroup

	for _, query := range queries {
		wg.Add(1)
		go func(q string) {
			defer wg.Done()

			<-ticker.C // wait for a rate-limit slot before calling
			res, err := searchTweets(apiKey, q)
			if err != nil {
				return
			}

			mu.Lock()
			results[q] = res.Tweets
			mu.Unlock()
		}(query)
	}

	wg.Wait()
	return results
}

func main() {
	queries := []string{"golang", "rustlang", "typescript"}
	all := collectForQueries("YOUR_SORSA_API_KEY", queries)
	for q, tweets := range all {
		fmt.Printf("%s: %d tweets\n", q, len(tweets))
	}
}

El ticker hace el trabajo real: cada goroutine se bloquea en él, así que sin importar cuántas lances, las llamadas salen a la tasa permitida. Cuando reconstruimos nuestros propios recolectores, un límite fijo por segundo resultó más simple de ritmar que las ventanas por endpoint, porque un solo ticker cubre el cliente entero en lugar de presupuestos separados por endpoint. Para pasar de la primera página de cada consulta, sigue el next_cursor en la respuesta y detente en un valor vacío; la guía de paginación tiene el bucle, y el lado oficial está en nuestra referencia de límites de tasa de la API de X. Ante un 429, espera un segundo y reintenta la misma llamada.

Comparación: tres vías, lado a lado {#comparison-three-routes-side-by-side}

Las tres vías de Go se dividen en dos ejes: si puedes escribir, y cómo te cobran. Ambas vías de la API oficial necesitan una cuenta de desarrollador y cobran por recurso. Una API de solo lectura cambia el acceso de escritura por una sola clave y cobro de tarifa plana por solicitud.

La división te dice cuál elegir: si necesitas publicar o correr acciones de escritura, ese es territorio de la API oficial a través de gotwtr. Para acceso intensivo en lecturas a un precio de tarifa plana y predecible, una API de solo lectura es la vía más barata y simple, y devuelve los mismos datos públicos.

La brecha de costo en lecturas viene de la unidad de cobro. La API oficial cobra por cada post y cada perfil de autor en una respuesta; una API de tarifa plana cobra una solicitud sin importar cuántos elementos devuelva.

Para trabajo intensivo en lecturas el modelo por recurso es la forma cara de hacer un trabajo simple, y por eso una tarifa plana por solicitud gana en cuanto cruzas unas 10,000 lecturas al mes. Las escrituras son la excepción: publicar y los DMs viven solo en la API oficial, así que un servicio pesado en escrituras pertenece ahí sin importar el costo de lectura.

Cómo obtener tus credenciales de API {#how-to-get-your-api-credentials}

Para la API oficial, crea una cuenta de desarrollador en developer.x.com, acepta los términos de desarrollador, describe tu caso de uso y crea un Project y una App para generar un bearer token y credenciales OAuth. Compra créditos antes de tu primera llamada, porque no hay nivel gratuito. Para una API de terceros de solo lectura, regístrate, genera una clave y pásala en un encabezado, sin paso de solicitud ni aprobación y con 100 solicitudes gratis para probar antes de comprar nada.

Lee cualquiera de las credenciales desde el entorno, nunca desde el código fuente:

# .env or your shell environment
X_API_BEARER_TOKEN=your-x-bearer-token
SORSA_API_KEY=your-sorsa-api-key

En Go, léelas con os.Getenv como se muestra en los ejemplos de arriba; para cargar un archivo .env en desarrollo, un paquete como godotenv es opcional. Si estás portando código existente de la API oficial, la guía de migración desde la API oficial de X mapea los endpoints oficiales y los nombres de campo a sus equivalentes de tarifa plana para que cambies el transporte sin reescribir la lógica.

En la práctica: recortar el costo de un recolector en Go {#in-practice-cutting-the-cost-of-a-go-collector}

Un equipo de inteligencia de mercado de unas 12 personas llegó a nosotros corriendo un servicio de Go que rastreaba cuentas competidoras. Usaba una librería de la era v1.1, que se rompió cuando X retiró esos endpoints, así que el equipo lo reescribió contra la API v2 oficial con net/http simple. El código estaba limpio; la factura no. Cada corrida nocturna pagaba por lectura de post y por perfil de autor, y el tope mensual de 2 millones de lecturas de posts significaba que vigilaban el volumen a medida que crecía su lista de cuentas rastreadas.

El arreglo fue un cambio de transporte, no una reescritura. Conservaron la lógica de recolección con goroutines y la programación, apuntaron el cliente a los endpoints de búsqueda y /followers, y dejaron OAuth por un único encabezado ApiKey. Como cada solicitud devuelve hasta 20 tweets o 200 perfiles de seguidores en lugar de cobrar por recurso, la misma extracción nocturna costó una fracción de lo que costaba, unas 30 a 50 veces menos en las partes intensivas en lecturas, y un límite por segundo reemplazó al tope mensual como lo único contra lo que ritmar. Para una carga de solo lectura, el modelo por recurso había sido la forma cara de hacer un trabajo simple.

Preguntas frecuentes {#faq}

¿Hay un SDK oficial de la API de X (Twitter) para Go?

No. A 2026 X publica SDKs oficiales solo para Python y TypeScript; no hay SDK oficial de Go. La opción de comunidad con mantenimiento para la API v2 es gotwtr, que usa un bearer token de OAuth 2.0 y cubre usuarios, tweets, búsqueda, seguidores y cronologías. El generador de SDK de código abierto de X lista Go como objetivo futuro, pero no se ha lanzado ningún paquete de Go, así que trata cualquier afirmación de "SDK oficial de Go" como inexacta.

¿Cuál es la mejor librería de Go para la API de Twitter?

Para trabajo nuevo en v2, gotwtr es la mejor librería de Go de propósito general: apunta a la API v2, se autentica con un bearer token y cubre lecturas y escrituras. El paquete go-twitter más viejo de dghubble se cita mucho pero habla solo la API v1.1 retirada, así que no es apto para implementaciones nuevas. Para datos de solo lectura a volumen, muchos equipos de Go se saltan las librerías y llaman a una API REST de terceros con el paquete estándar net/http.

¿Cómo obtener tweets en Go sin una cuenta de desarrollador?

Llama a una API REST de terceros de solo lectura. Con Sorsa, te registras, obtienes una clave API, la pasas en el encabezado ApiKey y envías una solicitud con net/http; el JSON decodifica directo a structs de Go. No hay flujo OAuth, ni revisión de app, ni compra de créditos, y una cuenta nueva incluye 100 solicitudes gratis para empezar. Cada respuesta de tweet incluye el perfil del autor y las métricas públicas, así que una sola solicitud devuelve datos completos.

¿Cuánto cuesta la API de X para una app de Go en 2026?

En la API oficial de X pagas por recurso: $0.005 por lectura de post, $0.010 por perfil de usuario, $0.015 por post estándar y $0.20 por un post con URL, con un tope mensual de 2 millones de lecturas de posts. Una búsqueda que devuelve 20 tweets cuesta $0.30 una vez incluidos los perfiles de autor. Sorsa cobra por solicitud en cambio, lo que sale desde $0.02 por cada 1,000 tweets y desde $0.01 por cada 1,000 perfiles en endpoints por lotes, y una cuenta nueva incluye 100 solicitudes gratis.

¿Cómo manejar los límites de tasa de la API de X en Go?

La API oficial limita las solicitudes por ventana de 15 minutos (típicamente 300 a 900 según el endpoint) y devuelve un 429 cuando llegas a uno. En Go, controla las llamadas concurrentes a través de un solo limitador de tasa, como un time.Ticker o golang.org/x/time/rate, dimensionado al límite, para que las goroutines no lo excedan. Una API de tarifa plana como Sorsa usa un límite por segundo de 20 solicitudes, así que un ticker que libera una ranura cada 50 milisegundos te mantiene dentro del presupuesto.

¿Se puede usar net/http solo para llamar a la API de X en Go?

Sí. Los paquetes estándar net/http y encoding/json de Go pueden llamar a la API de X v2 con un bearer token en el encabezado Authorization y decodificar la respuesta en tus propios structs. Tú manejas la paginación, los códigos de estado y los reintentos, lo que está bien para unos pocos endpoints o un trabajo puntual. Para un pipeline más grande terminas escribiendo un cliente pequeño, momento en el que una librería o una API de terceros ahorra tiempo.

¿gotwtr admite la API de X v2?

Sí. gotwtr está construida para la API de X v2 y se autentica con un bearer token de OAuth 2.0. Cubre búsqueda, consulta de usuario, seguidores y seguidos, cronologías y acciones de escritura como publicar, y trajo cobertura completa de endpoints v2 en su línea 1.x. Requiere una cuenta de desarrollador de X de pago con créditos comprados, porque la API oficial no tiene nivel gratuito bajo el pago por uso.

Cómo empezar {#getting-started}

Elige una vía y corre uno de los ejemplos de arriba.

• Datos de solo lectura: toma una clave del panel de Sorsa, que incluye 100 solicitudes gratis y sin tarjeta, fíjala como SORSA_API_KEY y corre cualquier ejemplo del Método 3. Los datos estructurados de X aterrizan en tu terminal en menos de un minuto, y el inicio rápido recorre la primera llamada. Los planes y límites están en la página de precios.
• Leer y escribir: crea una cuenta de desarrollador en developer.x.com, compra créditos y corre gotwtr o los ejemplos de net/http con tu bearer token.
• Comparar proveedores: para una mirada más amplia a las opciones de solo lectura, consulta la comparación de alternativas a la API de Twitter, y para las contrapartidas del scraping administrado, nuestra guía de cómo scrapear X.

Revisado por Keksich, fundador de Sorsa, especialista en marketing e investigador de la API de X.

Cómo verificamos esta guía {#how-we-verified-this-guide}

Escribimos y verificamos esta guía en junio de 2026 mientras operábamos la API a diario. La ausencia de un SDK oficial de Go y la existencia de los SDKs de Python y TypeScript se confirmaron contra la documentación oficial de herramientas y librerías de X y su anuncio para desarrolladores de los XDKs. Los nombres de métodos de gotwtr y su cobertura v2 se revisaron contra su referencia de paquete en el índice de paquetes de Go. El precio de la API de X refleja el modelo de pago por uso vigente incluidos los cambios de costo de escritura de abril de 2026. El comportamiento de los endpoints de Sorsa, el agrupamiento por solicitud y el precio de los planes salen de la documentación de Sorsa API; más sobre el equipo en nuestra página Acerca de. Los números de versión de librerías y los conteos de estrellas se mueven, así que se describen en lugar de fijarse; para un precio vigente los docs dentro del producto son la fuente de verdad.