Apps de desarrollador

​

Descripción general

Si ya tienes Apps, puedes verlas, editarlas o eliminarlas a través de la página de App del portal de desarrolladores.

Acceder a la X API y a la X Ads API requiere un conjunto de credenciales de autenticación, también conocidas como keys and tokens, que debes incluir en cada solicitud. Estas credenciales pueden presentarse en diferentes formas según el tipo de autenticación que requiera 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: Esencialmente, el nombre de usuario y la contraseña de tu App. Las usarás para autenticar solicitudes que requieren OAuth 1.0a User Context 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 OAuth 1.0a User Context. Si deseas realizar solicitudes en nombre de otro usuario, deberás usar el flujo de OAuth de 3 fases para que te autorice.

• Client ID and Client Secret: Estas credenciales se utilizan para obtener un user Access Token con autenticación OAuth 2.0. Al igual que con OAuth 1.0a, los user Access Tokens se utilizan para autenticar solicitudes que proporcionan información privada de la cuenta de usuario o realizan acciones en nombre de otra cuenta, pero con un alcance de permisos 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 and tokens necesarias 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 App desde el panel de administración.

​

Apps y Projects

Puedes usar Apps y Projects para organizar tu trabajo con la X Developer Platform por caso de uso. Cada Project puede incluir una App con el plan Free de X API, hasta dos Apps con el plan Basic y hasta tres Apps con el plan Pro.

Si deseas acceder a los endpoints nuevos de X API v2, deberás usar keys and tokens de una App asociada a un Project.

Si tienes Apps creadas antes de que lanzáramos Projects, serán visibles en la sección titulada “Standalone Apps”. Las Standalone Apps son Apps fuera de la estructura de Project. Si adjuntas una Standalone App a un Project, entonces podrá realizar solicitudes a los endpoints de v2.

​

Panel del portal de desarrolladores

Puedes visitar el panel para gestionar las Apps asociadas a tu cuenta. Para obtener más información, visita nuestra página de documentación sobre el portal de desarrolladores. El panel permite a los desarrolladores realizar de forma rápida y sencilla las siguientes tareas:

• Ver tus Apps independientes existentes y su App ID asociado.
• Crear un nuevo Project, App o App independiente.
• DELETE un Project o una App que no estés usando.
• Revisar o actualizar la configuración de una App específica, incluida la actualización del nombre, la descripción, el sitio web, la URL de callback y los permisos.
• Regenerar credenciales específicas de la App, como el API Key y Secret, el App Access Token y los Access Tokens de usuario del propietario de la App.

​

Registro para obtener acceso

Si ya tienes X Apps, puedes ver y editar tus Apps desde el panel de Apps de X si has iniciado sesión en tu cuenta de X en developer.x.com. Ten en cuenta que no necesitarás crear una cuenta nueva para administrar todas las Apps que se hayan creado previamente en developer.x.com.

Si necesitas crear una nueva X App, deberás haber creado una cuenta de desarrollador. Si eres miembro de una cuenta de equipo, debes tener asignado el rol de administrador para crear una nueva App.

​

Etiqueta de cuenta automatizada para bots

Puedes añadir una etiqueta de cuenta automatizada a tus cuentas de bot para informar a los usuarios de X que tu bot es una cuenta automatizada. Estos bots realizan acciones programadas a través de la X API. Al añadir una etiqueta de cuenta automatizada a tu bot, generas confianza con tu audiencia, legitimas tu cuenta y te diferencias de los bots de spam. Esto ayuda a que las personas en X comprendan mejor el propósito de tu cuenta al interactuar con tu bot.

Para añadir una etiqueta a tu cuenta de bot, sigue estos pasos:

1. Ve a la configuración de tu cuenta
2. Selecciona “Tu cuenta”
3. Selecciona “Automatización”
4. Selecciona “Administración de cuenta”
5. A continuación, selecciona la cuenta de X que ejecuta tu cuenta de bot
6. Ingresa tu contraseña para iniciar sesión
7. Por último, deberías ver la confirmación de que la etiqueta se ha aplicado a tu cuenta.

---

​

Administración de Apps

​

Introducción

El panel de X App 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 independiente.
• Eliminar un Project, una App o una App independiente.
• 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, keys and tokens y 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 keys and tokens de la App ya no son visibles en el portal de desarrolladores y deben guardarse de forma segura en cuanto se generen. Recomendamos usar un gestor de contraseñas para almacenar tus keys and tokens.

Puedes mostrar una pista de la API Key para ayudarte a vincular tu credencial con su App correspondiente.

​

Configuración de la App

​

Detalles de la App

Aquí puedes editar el ícono de la App, el nombre de la App, la descripción de la App, la URL de tu sitio web, callback URLs/redirect URIs, la URL de los términos del servicio, la URL de la política de privacidad, el nombre de la organización, la URL de la organización y el propósito o caso de uso de la App.

OAuth 2.0 y OAuth 1.0a son métodos de autenticación que permiten a los usuarios iniciar sesión en tu App con X. También permiten que tu App realice solicitudes específicas en nombre de los usuarios autenticados. Puedes activar uno o ambos métodos para tu App.

Es importante mantener esta información actualizada. El nombre de tu App y la URL de tu sitio web se mostrarán como el origen dentro de los metadatos de cualquier Tweet creado de forma programática por tu aplicación. Si cambias el caso de uso de una X App, asegúrate de actualizarlo en estas configuraciones para garantizar el cumplimiento de los Developer Terms.

Si tu aplicación tiene una etiqueta que muestra “suspended”, se debe a que tu App infringe uno o más de los developer terms de X, como nuestras automation rules. El equipo de políticas de la plataforma para desarrolladores se comunicará con los desarrolladores a través de la dirección de correo electrónico configurada en la cuenta de X del propietario de la App; para revisar esta dirección, consulta la configuración de tu cuenta de X. Los correos electrónicos de notificación sobre suspensiones se enviarán a esta dirección con un título similar a “Application suspension notice” e incluirán información específica sobre qué hacer a continuación. Para trabajar con el equipo de X y resolver las suspensiones, revisa tu correo electrónico para obtener instrucciones específicas o usa nuestro platform help form.

​

Keys and tokens

Dentro de una App en un Project o mediante una App independiente, puedes ver, regenerar o revocar los siguientes tokens:

• API Key (Consumer Key) and API Secret (Consumer Secret)
• App Access Token
• User Access Token and Access Token Secret - El Access Token y el Secret disponibles en el portal de desarrolladores corresponden al usuario propietario de la App.

Ten en cuenta: si deseas realizar solicitudes en nombre de un usuario diferente (es decir, que no sea el propietario de la App), deberás usar el OAuth 1.0a 3-legged OAuth flow o el flujo de OAuth 2.0 Authorization Code with PKCE flow para generar un conjunto de Access Tokens de usuario. Luego utilizarás estos tokens específicos del usuario en tu solicitud a la API.

​

Configuración de autenticación de usuario

Puedes configurar la autenticación de tu App como OAuth 1.0a u OAuth 2.0. OAuth 2.0 solo puede usarse con la X API v2. OAuth 2.0 te permite seleccionar permisos detallados (scopes) que otorgan autorizaciones específicas en nombre de un usuario. OAuth 1.0a puede usarse con la X API v1.1 y v2 y emplea una autorización más amplia con scopes generales.

​

Permisos de aplicación-usuario de OAuth 1.0a

Si es el propietario de la App, puede ajustar los permisos de la App (solo lectura; lectura y escritura; o lectura, escritura y Mensajes Directos). Esto determina a qué recursos y eventos tiene acceso a través de la X API (nota: algunos recursos requieren permisos adicionales directamente de X).

También puede activar o desactivar en esta página la capacidad de sus Apps para solicitar direcciones de correo electrónico de los usuarios (esto requiere que en la página “App details” haya una URL de Términos del servicio y una URL de la Política de privacidad).

​

Tipo de App para OAuth 2.0

Si selecciona OAuth 2.0 como método de autenticación de usuario, deberá elegir el tipo de App que está creando. Sus opciones son Native App, Single page App, Web App, Automated App o bot. Las Native App y Single page App son clientes públicos, y las Web App y Automated App o los bots son clientes confidenciales.

Los clientes confidenciales se autentican de forma segura con el servidor de autorización y mantienen a salvo su client secret. Los clientes públicos son aplicaciones que normalmente se ejecutan en un navegador o en un dispositivo móvil y no pueden usar sus client secrets. Si selecciona un tipo de App que sea un cliente confidencial, se le proporcionará un client secret.

---

​

Permisos de la App

​

Permisos de App de OAuth 1.0a

Los permisos de App describen el nivel de acceso para la autenticación aplicación‑usuario de OAuth 1.0a. Los permisos de App se configuran por aplicación dentro de la configuración de tu X App.

Hay tres niveles de permiso disponibles:

1. Solo lectura
2. Lectura y escritura
3. 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; este puede combinarse con cualquiera de los tres niveles indicados arriba.

Si se cambia un nivel de permiso, 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.

Una buena práctica es solicitar solo el nivel mínimo de acceso a los datos de la cuenta de un usuario que una aplicación o servicio requiera.

​

Solo lectura

Este nivel de permiso permite acceso de lectura a los recursos de X, incluidos (por ejemplo) los Tweets de un usuario, la cronología de inicio y la información del perfil. No permite leer los Mensajes Directos de un usuario ni actualizar ningún elemento u objeto.

​

Lectura y escritura

Este nivel de permisos permite el 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 permisos no permite ningún acceso a los Mensajes Directos (incluidos lectura, escritura o eliminación).

​

Lectura, escritura y acceso a los Mensajes Directos

Este nivel de permiso incluye todo lo anterior y además permite leer, escribir y eliminar Mensajes Directos en nombre de un usuario.

• POST /2/dm_conversations/:dm_conversation_id/messages
• POST /2/dm_conversations/
• POST /2/dm_conversations/with/:participant_id/messages
• GET /2/dm_conversations/with/:user_id/dm_events
• GET /2/dm_conversations/:dm_conversation_id/dm_events
• GET /2/dm_events

​

Determinación de permisos

Todas las solicitudes autenticadas a la API incluyen un encabezado x-access-level en la respuesta HTTP. El valor de ese encabezado indica el nivel de permisos actualmente en uso. Los posibles valores son read, read-write y read-write-directmessages.

---

​

URL de callback

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 que los desarrolladores realicen solicitudes en nombre de diferentes usuarios de X que hayan 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:

• Flujo de código de autorización de OAuth 2.0 con PKCE
• Flujo de OAuth de 3 fases de OAuth 1.0a (y, por separado, el flujo Iniciar sesión con X)

A medida que los usuarios avanzan por estos flujos, necesitan una página web o una ubicación a la que se les redirija después de iniciar sesión correctamente y otorgar autorización a la App del desarrollador. Esta página web o ubicación de seguimiento 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 componen los flujos mencionados. Por ejemplo, los desarrolladores que usan Contexto de usuario de OAuth 1.0a deben pasar el parámetro callback_url al realizar una solicitud al endpoint GET oauth/request_token. De forma similar, los desarrolladores que usan Código de autorización de OAuth 2.0 con PKCE deben pasar el parámetro redirect_uri en 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 allowlist de URL de callback de su App, que se encuentra en la página de configuración de la App del 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

Al configurar tus URLs de callback, hay algunos aspectos que debes considerar:

Codifica en HTTP los parámetros de query

Como estás pasando la URL de callback como parámetro de query mediante callback_url o redirect_uri, asegúrate de codificar la URL en HTTP.

Límites de la URL de callback

Existe un límite rígido de 10 URLs de callback en el panel de X Apps. Tu URL de callback siempre debe coincidir exactamente entre la URL de callback permitida que agregues en el panel de Apps y el parámetro que incluyas 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 de forma local o http(s)://127.0.0.1

URLs de protocolo personalizado Si deseas aprovechar el deep linking en dispositivos móviles, puedes utilizar URLs de protocolo personalizado con una ruta y una parte de dominio, como twitter://callback/path. Sin embargo, tenemos una lista de protocolos no permitidos que deberás evitar. Puedes consultar 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

​

Ejemplo de error

Si usas una URL de callback que no se haya agregado correctamente a la configuración de tu App en el portal de desarrolladores, recibirás el siguiente mensaje de error:

OAuth 1.0a

HTTP 403 - Forbidden

{
  "errors": [
    {
      "code":415,"message":"URL de callback no aprobada para esta aplicación cliente. Las URL de callback aprobadas se pueden ajustar en la configuración de su aplicación."
    }
  ]
}

O

<?xml version="1.0" encoding="UTF-8"?>
<hash>
<error>URL de callback no aprobada para esta aplicación cliente. Las URL de callback aprobadas pueden ajustarse en la configuración de su aplicación</error>
<request>/oauth/request_token</request>
</hash>

OAuth 2.0

HTTP 400

{
  "error": "invalid_request",
  "error_description": "El valor proporcionado para el redirect uri no coincide con el uri del código de autorización."
}

Solución de problemas

Si recibe un error, asegúrese de que la URL de callback que está usando en sus solicitudes de autenticación esté codificada para HTTP y que coincida con una URL de callback que se haya agregado a la allowlist de la App cuyas keys and tokens está usando en su solicitud.

---