Conviértete en héroe: crea tu propia app con la API de Quire

Última actualización: 20 de julio de 2026

Crear una app que lee o modifica los datos de un usuario de Quire empieza con una decisión: ¿cómo autenticas sin ver nunca la contraseña del usuario? La API de Quire lo resuelve con OAuth 2.0. Este artículo recorre la configuración de la app OAuth, el flujo de autorización en cuatro pasos, el ciclo del token de acceso y de actualización, y los fallos más habituales en una primera integración.

La versión 1.0.0 de la OpenAPI de Quire se publicó en octubre de 2019 y se ha mantenido estable. Con OAuth, los usuarios autorizan a tu app a acceder a su contenido de Quire (tareas, proyectos, comentarios, asignaciones, etiquetas, fechas de vencimiento) y tú nunca tocas sus credenciales.

El usuario puede revocar ese acceso en cualquier momento sin cambiar su contraseña. Por eso guardar contraseñas era un antipatrón de seguridad antes de que OAuth lo hiciera innecesario.

¿Qué enfoque de integración de Quire se ajusta a tu caso?

Antes de montar la API OAuth, asegúrate de que la API es de verdad la herramienta adecuada. Quire tiene cuatro vías de integración compatibles en 2026, y cada una resuelve un problema distinto.

Si creas una integración típica (app móvil, panel de control web, servicio de sincronización), la API OAuth es lo que buscas. El resto del artículo da por hecho que vas por ese camino.

¿Cómo se configura una app OAuth para la API de Quire?

Para usar la API de Quire, necesitas crear una app OAuth.

Crea tu app OAuth de Quire

Debes haber iniciado sesión en tu cuenta de Quire para crear una app.

1. Ve a la consola de apps para desarrolladores de Quire y haz clic en el botón Crear nueva app.

2. Elige la Organización Quire a la que pertenece tu app; los Miembros de la organización pueden ver y editar todas las Apps de la organización seleccionada.

3. Dale un nombre a tu aplicación y una Redireccionar URL; más adelante veremos la función de la Redireccionar URL. Por ahora puedes usar esta URL:

   http://localhost:3000/callback

4. Haz clic en el botón Crear nueva app. Tu aplicación OAuth recién creada aparecerá en la página de la consola para desarrolladores, donde podrás seguir configurándola.

En resumen, deberías tener estos tres datos:

• Desarrollo de la ID del cliente: :wJoMEodI4fSSR54pfNwIuIzLnaJ
• Desarrollo del Cliente Anónimo: eb8faf4nyd1wbeconw060e9ejui8zg6w8p1hyoex
• URL de callback: http://localhost:3000/callback

¿Cómo se prepara el entorno de desarrollo para la API de Quire?

Paso 1. Configura tu app

Guarda en tu app la información de configuración de la aplicación.

const clientId = ':wJoMEodI4fSSR54pfNwIuIzLnaJ';
const clientSecret = 'eb8faf4nyd1wbeconw060e9ejui8zg6w8p1hyoex';
const redirectURI = 'http://localhost:3000/callback';
  
const authorizationUrl = 'https://quire.io/oauth';
const tokenUrl = 'https://quire.io/oauth/token';
const apiUrl = 'https://quire.io/api';

Paso 2. Redirige al usuario para autorizar la app en Quire

Genera una URL de autorización a la que redirigirás a tus usuarios, apuntando al endpoint OAuth de Quire. Se mostrará una página web donde los usuarios de Quire con sesión iniciada pueden autorizar a tu aplicación a acceder a su contenido.

URL de ejemplo:

https://quire.io/oauth?client_id=your-client-ID&redirect_uri=your-redirect-uri

Un ejemplo de vista con el enlace de autorización podría ser:

var http = require('http');
var url = require('url');
var server = http.createServer(function (req, res) { 
    var uri = url.parse(req.url, true);
    if (uri.pathname == '/') {        
        //..    
    } else if (uri.pathname == "/install") {
        var authUrl = authorizationUrl 
            + '?client_id=' + clientId 
            + '&redirect_uri=' + encodeURIComponent(redirectURI);
        res.writeHead(200, { 'Content-Type': 'text/html' });
        res.write(
             '<html><body>' 
            + '<a href="' + authUrl + '">Connect Quire</a>' 
         + '</body></html>');
        res.end();

    } else if (uri.pathname == "/callback") {
        //...
    }
});
server.listen(3000);

El parámetro state es una cadena aleatoria que sirve para prevenir ataques de falsificación de solicitudes entre sitios (CSRF). Debes generar una cadena de caracteres aleatoria. Se devolverá a tu app, sin cambios, en el Paso 3. Tu aplicación debe validar este valor. Aunque es opcional, recomendamos encarecidamente incluir este parámetro.

URL de ejemplo:

https://quire.io/oauth?client_id=your-client-ID&redirect_uri=your-redirect-uri&state=lpcl9v94z

Paso 3. Gestiona la respuesta del servidor OAuth 2.0

El servidor OAuth 2.0 responde a la solicitud de acceso de tu aplicación usando la URL indicada en redirect_uri.

Si el usuario aprueba la solicitud de acceso, la respuesta contiene un código de autorización. Si no la aprueba, la respuesta contiene un mensaje de error. El código de autorización o el mensaje de error que llega al servidor web aparece en la cadena de consulta, como se muestra a continuación:

Una respuesta de error:

http://localhost:3000/callback?error=access_denied

Una respuesta con código de autorización:

http://localhost:3000/callback?code=4/P7q7W91a-oMsCeLvIaQm6bTrgtp7

Un ejemplo de callback podría ser:

//...
} else if (uri.pathname == "/callback") {
   var result = uri.query;
   var message = 'Auth fail';
   if (result["error_description"] != null) {
       message = result["error_description"];
       if (result["error"] == 'access_denied') {
           //display reject message
       }
       messageView(res, message);
   } else if (result["code"] != null) {
       return exchangeAccessToken(result["code"])
       .then(function(data) {
            var token = data['access_token'];
            message = token != null ? 'Success': 'Fail';
            messageView(res, message);
        });
   }
}

Cuando el usuario vuelve a la redirect_uri de tu aplicación, en los parámetros de la cadena de consulta también estarán presentes un código y el parámetro state. El state es tu token anti-falsificación CSRF para validar la solicitud.

Extrae el código y el state de los parámetros de la cadena de consulta. En este punto puedes validar el state.

Un ejemplo de validación podría ser:

} else if (result["code"] != null) {
    if (result["state"] != stateFromSession(res))
        return messageView(res, 'invalid state');
            
    return exchangeAccessToken(result["code"])
    .then(function(data) {
         var token = data['access_token'];
         message = token != null ? 'Success': 'Fail';
         messageView(res, message);
     });
}

Paso 4. Canjea el código de autorización por un token de acceso

Tu aplicación debe hacer una llamada POST al endpoint del token con el código de autorización extraído y los parámetros de solicitud que se indican a continuación.

Un ejemplo de solicitud de un token de acceso podría ser este:

var request = require('request');
function exchangeAccessToken(code) {
    return new Promise(function(resolve, reject){
        request.post({
            url: tokenUrl,
            form: {
              grant_type: 'authorization_code',
              code: code,
              client_id: clientId,
              client_secret: clientSecret,
              redirect_uri: redirectURI
            }
          },
          function (error, httpResponse, body) {
            if (error) {
              return reject(error);
            }
            resolve(JSON.parse(body))
          });
    });
}

El token de acceso que recibas en la respuesta tendrá formato JSON.

Respuesta de ejemplo:

{ 
  "access_token":"ACCESS_TOKEN", 
  "token_type": "bearer", 
  "expires_in":2592000, 
  "refresh_token":"REFRESH_TOKEN"
}

Guarda el token con cuidado y de forma permanente, ya que lo necesitas para acceder a cualquier API de Quire.

¿Cómo se hacen llamadas a la API con el token de acceso de Quire?

Tu app ya tiene un token de acceso que sirve para hacer llamadas a la API en nombre del usuario.

Llama a la API

Haz la llamada a la API pasando el token de acceso como token bearer en la cabecera de la solicitud.

Un ejemplo de llamada a la API podría ser:

function getCurrentUser(token) {
    return new Promise(function(resolve, reject){
        request.get({
            url: apiUrl + '/user/id/me', 
            headers: {
              "Authorization": "Bearer " + token
            }
          }, 
          function (error, httpResponse, body) {
            if (error) {
              return reject(error);
            }
            resolve(JSON.parse(body))
          });
    });
}

Respuesta de ejemplo:

{
  "email": "john@gmail.cc",
  "website": "https://coolwebsites.com",
  "id": "My_ID",
  "description": "This is *cool*!",
  "url": "https://quire.io/u/My_ID",
  "nameText": "My Name",
  "nameHtml": "My Name",
  "descriptionText": "This is cool!",
  "descriptionHtml": "This is <i>cool</i>!",
  "image": "https://quire.s3.amazonaws.com/oid/image.jpg",
  "iconColor": "37",
  "name": "My Name",
  "oid": "Dyh2YkFcu9uLgLFIeN1kB4Ld"
}

¿Cómo se actualiza un token de acceso caducado de la API de Quire?

Un token de acceso está pensado, a propósito, para un uso de corta duración. Es un mecanismo de seguridad importante de OAuth 2.0. Con el flujo Authorization Code Grant, los tokens de acceso duran una hora por defecto.

Cuando un token de acceso caduca, se devuelve un error HTTP 401:

{ 
  code: 401, 
  message: 'Invalid or expired token.'
}

Tu aplicación deberá actualizar el token de acceso.

function refreshToken(refreshToken) {
    return new Promise(function(resolve, reject){
        request.post({
            url: tokenUrl, 
            form: {
              grant_type: 'refresh_token',
              refresh_token: refreshToken,
              client_id: clientId,
              client_secret: clientSecret
            }
          }, 
          function (error, httpResponse, body) {
            if (error) {
              return reject(error);
            }
            resolve(JSON.parse(body))
          });
    });
}

Como alternativa, tu aplicación puede redirigir al usuario al flujo de autenticación.

¿Cuáles son los errores más comunes al usar la API de Quire?

Tras ver a varios equipos construir sobre la API de Quire, los mismos cinco problemas se repiten. Ninguno es sutil y todos se pueden evitar.

1. Guardar el secreto del cliente en código del lado del cliente. El secreto del cliente es justo eso, un secreto. Si acaba en el binario de una app móvil o en un paquete de navegador, cualquiera puede extraerlo y hacerse pasar por tu app. El secreto debe vivir solo en un servidor que controles.

Si tu app es puramente de cliente (aplicación de una sola página, móvil), usa el flujo OAuth 2.0 PKCE en lugar de incrustar el secreto.

2. Olvidar validar el parámetro state. El parámetro state existe para prevenir ataques CSRF. Si omites su validación en el callback, dejas un hueco que un sitio malicioso puede usar para asociar en silencio una cuenta de Quire con la sesión de la app de un atacante.

Genera state en cada solicitud, guárdalo en la sesión y rechaza cualquier callback cuyo state devuelto no coincida.

3. Tratar el token de acceso como permanente. Los tokens de acceso caducan tras una hora. Las Apps que guardan el token y nunca lo actualizan funcionan bien el primer día y se rompen en silencio el segundo. Construye el ciclo del token de actualización antes de lanzar nada, no como un parche de «lo arreglo cuando los usuarios se quejen».

4. Sondear la API para detectar cambios. El sondeo consume límite de uso, aumenta la latencia y gasta batería. Si necesitas reaccionar a cambios en Quire, usa Webhooks. El webhook te envía el evento al instante; la llamada a la API que habrías hecho para detectarlo nunca tiene que producirse.

5. Omitir la lista de Redireccionar URL permitidas. Cada registro de app OAuth acepta una lista de Redireccionar URL. Si usas comodines o no la configuras con precisión, un atacante puede registrar su callback como destino de redirección e interceptar códigos de autorización. Añade solo las URL exactas que tu app usa de verdad.

Si vas a trabajar con la API por primera vez, la forma más rápida de aprender los patrones es bifurcar una integración existente, como el conector de n8n, y estudiar cómo gestiona la autenticación, la actualización y los estados de error.

¿Cuándo no es la API de Quire la opción más adecuada?

Hay tres casos en los que conviene recurrir a otra vía de integración.

• Solo necesitas reaccionar a eventos, no consultar el estado. Los Webhooks son más sencillos, se basan en push y no requieren autorización del usuario para suscripciones de eventos de solo lectura. Si el trabajo de tu app es «avísame cuando pase algo», usa Webhooks, no la API.
• Estás creando una integración con Claude o un agente LLM. El servidor MCP de Quire es la vía adecuada. Gestiona la autenticación, incluye un esquema estándar y evita que escribas código OAuth. MCP está pensado para esto; montarlo por tu cuenta con la API OAuth supone más trabajo para el mismo resultado.
• Vas a hacer una exportación de datos puntual. Si solo necesitas extraer los datos de un proyecto una vez, para análisis o copia de seguridad, la Integración n8n o una exportación manual en CSV te ahorrará una semana de desarrollo.

Si ninguno de estos casos aplica, la API OAuth es tu herramienta.

Preguntas frecuentes

¿La API de Quire requiere un plan de pago de Quire?

No. La API de Quire está disponible en todos los planes, incluido el gratuito. Se aplican límites de uso en todos los planes; consulta la documentación de la API para ver los límites actuales por app.

¿Qué lenguajes de programación admite la API de Quire?

La API funciona sobre HTTP con cuerpos de solicitud y respuesta en JSON, así que sirve cualquier lenguaje con un cliente HTTP y un analizador JSON. Los ejemplos de este artículo están en JavaScript, pero el mismo flujo funciona igual en Python, Go, Ruby, PHP y cualquier otro lenguaje.

No hay biblioteca cliente oficial; la superficie de la API es lo bastante pequeña como para que lo habitual sea un envoltorio sencillo alrededor del cliente HTTP de tu lenguaje.

¿Cuánto duran los tokens de acceso de Quire?

Los tokens de acceso caducan tras una hora por defecto. Los tokens de actualización duran más y sirven para obtener nuevos tokens de acceso sin volver a pedir permiso al usuario. Incorpora el ciclo del token de actualización a tu app desde el primer día.

¿Puedo usar la API de Quire solo para lectura?

Sí. Los ámbitos (scopes) de OAuth te permiten solicitar solo los permisos que necesita tu app. Si tu app solo lee tareas, solicita ámbitos de lectura. Los usuarios de Quire verán los ámbitos solicitados en la página de autorización y podrán rechazarlos si la solicitud parece excesiva, así que pedir de más perjudica la conversión.

¿Cuál es la diferencia entre la API de Quire y el servidor MCP de Quire?

La API es una superficie REST de propósito general para cualquier app que quiera leer o modificar datos de Quire en nombre de un usuario. El servidor MCP está pensado para Claude y otros agentes LLM: gestiona la autenticación, expone un esquema de herramientas estándar y evita que escribas código OAuth.

Usa la API para integraciones de apps tradicionales; usa MCP para integraciones con agentes LLM.

¿Adónde ir a partir de aquí?

Este es el flujo OAuth 2.0 completo de la API de Quire: configuración de la app OAuth, autorización en cuatro pasos, uso del token de acceso y ciclo de actualización. El motivo más común por el que una integración que funciona se rompe dos días después es tratar el ciclo de actualización como un arreglo posterior en lugar de incorporarlo desde el primer día.

Empieza en la consola de apps para desarrolladores de Quire o lee la referencia completa de la API. Si prefieres no escribir código OAuth, el servidor MCP de Quire se encarga de la autenticación y es la mejor opción para integraciones con agentes LLM.

Para integraciones basadas en eventos, los Webhooks suelen encajar mejor que el patrón de sondeo en el que acaban muchas primeras integraciones con la API. Y si solo quieres automatizar cambios rápidos sin crear una app OAuth, la CLI de Quire ejecuta comandos de gestión de proyectos directamente desde tu terminal.