Si ya tienes Apps, puedes verlas, editarlas o eliminarlas a través de la página de Apps del Portal de desarrolladores.
Para acceder a la X API y a la X Ads API se requiere un conjunto de credenciales de Autenticación, también conocidas como keys y tokens, que debes enviar con cada solicitud. Estas credenciales pueden presentarse de distintas formas según el tipo de Autenticación que exija el endpoint específico que estés utilizando.
A continuación se muestran las diferentes credenciales que puedes generar en tu App y cómo usarlas:
-
API Key and Secret: Básicamente, el nombre de usuario y la contraseña de tu App. Las usarás para autenticar solicitudes que requieren Contexto de usuario de OAuth 1.0a, o para generar otros tokens como user Access Tokens o App Access Token.
-
Access Token and Secret: En general, los Access Tokens representan al usuario en cuyo nombre realizas la solicitud. Los que puedes generar a través del Portal de desarrolladores representan al usuario propietario de la App. Los usarás para autenticar solicitudes que requieren Contexto de usuario de OAuth 1.0a. Si deseas realizar solicitudes en nombre de otro usuario, deberás usar el flujo OAuth de 3 patas para que te autorice.
-
Client ID and Client Secret: Estas credenciales se usan para obtener un user Access Token con Autenticación OAuth 2.0. De forma similar a OAuth 1.0a, los user Access Tokens se usan para autenticar solicitudes que proporcionan información privada de la cuenta de un usuario o realizan acciones en nombre de otra cuenta, pero con un alcance detallado para un mayor control sobre el acceso que tiene la aplicación cliente al usuario.
-
App only Access Token: Usarás este token al realizar solicitudes a endpoints que responden con información disponible públicamente en X.
Además de generar las keys y tokens necesarios para realizar solicitudes a la X API, también podrás establecer permisos de acceso, documentar el caso de uso o propósito de la App, definir una URL de callback y modificar otros ajustes relacionados con tu entorno de desarrollador de la App desde el panel de administración.
Puedes utilizar Apps y Proyectos para organizar tu trabajo con la X Developer Platform por casos de uso. Cada Proyecto puede incluir una App con el plan de X API Gratis, hasta dos Apps con el plan Básico y hasta tres Apps con el plan Pro.
Si deseas acceder a los nuevos endpoints de X API v2, deberás usar las claves y los tokens de una App asociada a un Proyecto.
Si tienes Apps creadas antes del lanzamiento de Proyectos, aparecerán en la sección titulada “Apps Autónomas”. Las Apps Autónomas son Apps fuera de la estructura de Proyecto. Si asocias una App Autónoma a un Proyecto, entonces podrá realizar solicitudes a los endpoints v2.
Panel del Portal de desarrolladores
- Ver tus Apps Autónomo existentes y su App ID asociado.
- Crear un nuevo Project, App o App Autónomo.
- Eliminar un Project o App que no se utilice.
- Revisar o actualizar la configuración de una App específica, incluidos el nombre, la descripción, el sitio web, la URL de callback y los permisos.
- Regenerar credenciales específicas de la App como API Key & Secret, App Access Token y los Access Tokens de usuario del propietario de la App.
Cómo registrarte para obtener acceso
Etiqueta de cuenta automatizada para bots
- Ve a la configuración de tu cuenta
- Selecciona “Tu cuenta”
- Selecciona “Automatización”
- Selecciona “Administrar cuenta”
- A continuación, selecciona la cuenta de X que ejecuta tu bot
- Introduce tu contraseña para iniciar sesión
- Finalmente, deberías ver una confirmación de que la etiqueta se ha aplicado a tu cuenta.
El panel de App de X permite a los desarrolladores realizar de forma rápida y sencilla las siguientes tareas:
- Ver tus Apps y Projects existentes y su App ID asociado.
- Crear un nuevo Project o una App autónoma.
- Eliminar un Project, una App o una App autónoma.
- Abrir la configuración de una App específica haciendo clic en la configuración de la App. Dentro de la configuración, puedes ver los detalles de la App, las claves y tokens, y los permisos.
- Actualizar la configuración de Autenticación de usuario de tu App para usar OAuth 1.0a u OAuth 2.0.
Nota:Todas las claves y tokens de la App ya no se pueden ver dentro del Portal de desarrolladores y deben guardarse de forma segura una vez generadas. Recomendamos usar un gestor de contraseñas para almacenar tus claves y tokens.Puedes mostrar una pista de la clave de API para ayudarte a asociar tu credencial con su App correspondiente.
Configuración de autenticación de usuario
Permisos de aplicación-usuario de OAuth 1.0a
Tipo de App para OAuth 2.0
Permisos de App para OAuth 1.0a
- Solo lectura
- Lectura y escritura
- Lectura, escritura y acceso a Mensajes Directos
Existe un permiso adicional para solicitar la visibilidad de la dirección de correo electrónico de un usuario; se puede combinar con cualquiera de los tres niveles indicados anteriormente.
Si se cambia un nivel de permisos, cualquier token de usuario ya emitido para esa X App debe descartarse y los usuarios deben volver a autorizar la App para que el token herede los permisos actualizados.
Es una buena práctica solicitar solo el nivel mínimo de acceso a los datos de la cuenta de un usuario que una aplicación o servicio requiera.
Este nivel de permiso permite acceso de lectura a los recursos de X, incluidos (por ejemplo) los Tweets de un usuario, su cronología de inicio y la información de perfil. No permite leer los Mensajes Directos de un usuario ni actualizar ningún elemento u objeto.
Este nivel de permiso permite acceso de lectura y escritura a los recursos de X. Además de permitir el acceso de lectura, también permite publicar Tweets, seguir a usuarios o actualizar elementos de la información del perfil de un usuario. También permite ocultar respuestas en nombre del usuario autenticado. Este nivel de permiso no permite ningún acceso a los Mensajes Directos (incluidos lectura, escritura o eliminación).
Leer, escribir y acceder a Mensajes Directos
Determinación de permisos
x-access-level en la respuesta HTTP. El valor de este encabezado indica el nivel de permiso actualmente en uso. Los valores posibles son read, read-write y read-write-directmessages.
Los métodos de Autenticación Contexto de usuario de OAuth 1.0a y Código de autorización de OAuth 2.0 con PKCE permiten a los desarrolladores realizar solicitudes en nombre de distintos usuarios de X que han completado un flujo específico de inicio de sesión. Actualmente, hay dos flujos que puedes usar para permitir que los usuarios autoricen tu aplicación:
A medida que los usuarios avanzan por estos flujos, necesitan una página web o una ubicación a la que ser redirigidos después de iniciar sesión correctamente y otorgar autorización a la App del desarrollador. Esta página web o ubicación posterior se denomina URL de callback.
Al configurar estos flujos para que sus posibles usuarios los completen, los desarrolladores deben incluir una URL de callback en sus solicitudes a los endpoints de autenticación que conforman los flujos mencionados anteriormente. Por ejemplo, los desarrolladores que usan el Contexto de usuario de OAuth 1.0a deben pasar el parámetro callback_url al realizar una solicitud al endpoint GET oauth/request_token. Del mismo modo, los desarrolladores que usan el Código de autorización de OAuth 2.0 con PKCE deben pasar el parámetro redirect_uri con su solicitud al endpoint GET oauth2/authorize.
Además de usar estos parámetros, el desarrollador también debe asegurarse de que la URL de callback se haya agregado a la lista de permitidos de URL de callback de su App, que se encuentra en la página de configuración de la App en el Portal de desarrolladores.
Si se configura correctamente, los desarrolladores serán redirigidos a la URL de callback después de iniciar sesión correctamente en X como parte de estos flujos.
Aspectos a tener en cuenta
callback_url o redirect_uri, asegúrate de codificar la URL en HTTP.
Límites de la URL de callback
Existe un límite estricto de 10 URL de callback en el panel de X Apps. Tu URL de callback siempre debe coincidir exactamente entre la URL de callback permitida que agregas en el panel de Apps y el parámetro que incluyes en el flujo de autorización.
Si deseas incluir datos específicos de la solicitud en la URL de callback, puedes usar el parámetro state para almacenar datos que se incluirán después de que el usuario sea redirigido. Puedes codificar los datos en el propio parámetro state o usar el parámetro como un id de sesión para almacenar el estado en el servidor.
No uses localhost como URL de callback
En lugar de usar localhost, utiliza un host personalizado localmente o http(s)://127.0.0.1
URL con protocolo personalizado
Si deseas aprovechar el deep linking móvil, puedes utilizar URL con protocolo personalizado con una parte de ruta y dominio, como twitter://callback/path. Sin embargo, tenemos una lista de protocolos no permitidos que deberás evitar. Puedes revisar la lista de protocolos no permitidos a continuación.
Protocolos no permitidos
| |
|---|
vbscript | ldap |
javascript | mailto |
vbs | mmst |
data | mmsu |
mocha | msbd |
keyword | rtsp |
livescript | mso-offdap |
ftp | snews |
file | news |
gopher | nntp |
acrobat | outlook |
callto | stssync |
daap | rlogin |
itpc | telnet |
itms | tn3270 |
firefoxurl | shell |
hcp | sip |
{
"errors": [
{
"code":415,"message":"La URL de callback no está aprobada para esta App de cliente. Puedes ajustar las URL de callback aprobadas en la configuración de tu App."
}
]
}
<?xml version="1.0" encoding="UTF-8"?>
<hash>
<error>URL de devolución de llamada no aprobada para esta aplicación cliente. Las URL de devolución de llamada aprobadas se pueden ajustar en la configuración de tu aplicación</error>
<request>/oauth/request_token</request>
</hash>
{
"error": "invalid_request",
"error_description": "El valor proporcionado para el redirect uri no coincide con el uri del código de autorización."
}
