Skip to main content
Las apps son contenedores para tus credenciales de la API. Cada app tiene sus propias claves, tokens y configuraciones.

Credenciales de la app

Cuando creas una app, puedes generar estas credenciales:
CredencialCaso de uso
API Key y SecretAutenticación con OAuth 1.0a. Se usan para firmar solicitudes o generar tokens de usuario.
Access Token y SecretRealizar solicitudes en nombre de tu propia cuenta (OAuth 1.0a).
Client ID y SecretAutenticación con OAuth 2.0. Se usan para el flujo de authorization code.
Bearer TokenAutenticación app-only para endpoints de datos públicos.
Elige OAuth 2.0 para nuevos proyectos. Ofrece scopes detallados y es obligatorio para los endpoints de contexto de usuario de la X API v2.

Crear una app

1

Abre la Developer Console

Ve a console.x.com e inicia sesión.
2

Haz clic en Create App

Ingresa un nombre, una descripción y un caso de uso para tu app.
3

Genera credenciales

Después de crearla, genera las claves y tokens que necesites.
4

Almacénalas de forma segura

Guarda las credenciales inmediatamente: solo se muestran una vez.

Permisos de la app (OAuth 1.0a)

Las apps de OAuth 1.0a tienen tres niveles de permisos:
  • Ver posts, usuarios y datos públicos
  • No se puede publicar, dar like ni modificar nada
  • No se puede acceder a los Mensajes Directos
Cambiar los permisos requiere que los usuarios vuelvan a autorizar tu app para obtener nuevos tokens con el alcance actualizado.

Tipos de app de OAuth 2.0

Al configurar OAuth 2.0, selecciona el tipo de tu app:
TipoClienteCaso de uso
Web AppConfidencialAplicaciones del lado del servidor que pueden almacenar secretos de forma segura
Automated App / BotConfidencialBots y servicios automatizados que se ejecutan en servidores
Native AppPúblicoApps móviles o de escritorio que no pueden proteger secretos
Single Page AppPúblicoApps JavaScript basadas en navegador
Los clientes confidenciales reciben un Client Secret. Los clientes públicos usan solo PKCE.

URLs de callback

Las URLs de callback (URIs de redirección) son obligatorias para los flujos de OAuth. Después de que un usuario autoriza tu app, es redirigido a tu URL de callback con un código de autorización.

Requisitos

  • Agrega las URLs de callback a la lista de permitidas de tu app en la Developer Console
  • Las URLs deben coincidir exactamente (incluidas las barras finales)
  • Máximo 10 URLs de callback por app
  • Usa https:// en producción
  • Para desarrollo local, usa http://127.0.0.1 (no localhost)

Protocolos no permitidos

Estos protocolos no se pueden usar: javascript, data, file, ftp, mailto, telnet y otros esquemas no estándar.
vbscript, javascript, vbs, data, mocha, keyword, livescript, ftp, file, gopher, acrobat, callto, daap, itpc, itms, firefoxurl, hcp, ldap, mailto, mmst, mmsu, msbd, rtsp, mso-offdap, snews, news, nntp, outlook, stssync, rlogin, telnet, tn3270, shell, sip

Mejores prácticas

Usa apps separadas

Crea apps diferentes para desarrollo, staging y producción.

Rota las credenciales

Regenera las claves periódicamente y si sospechas que están comprometidas.

Permisos mínimos

Solicita únicamente los permisos que realmente necesite tu app.

Monitorea el uso

Revisa la Developer Console con regularidad para rastrear el uso de la API.

Etiquetas de cuenta automatizada

Si tu app ejecuta una cuenta bot, puedes etiquetarla como automatizada:
  1. Ve a la Configuración de tu cuenta bot
  2. Selecciona Tu cuentaAutomatización
  3. Vincula tu cuenta administradora
Esto genera confianza con los usuarios y distingue a tu bot del spam.

Solución de problemas

Asegúrate de que tu URL de callback sea exactamente igual a la registrada en la Developer Console, incluido el protocolo y las barras finales. Codifica la URL en HTTP cuando la pases como parámetro de consulta.
{
  "errors": [{
    "code": 415,
    "message": "Callback URL not approved for this client application."
  }]
}
Si tu app aparece como suspendida, revisa tu correo electrónico para ver un aviso del equipo de la plataforma X. Usa el formulario de ayuda de la plataforma para apelar.