Sé un héroe: crea tu propia app con la API de Quire

Última actualización: 28 de mayo de 2026

TL;DR: La API OAuth 2.0 de Quire permite que tu app actúe sobre la cuenta de Quire de un usuario sin almacenar su contraseña. Necesitarás una app OAuth registrada (client ID, secret, URL de redirección), un flujo de autorización de cuatro pasos (configurar, redirigir, gestionar la respuesta, intercambiar el código por un token) y un ciclo de refresh-token, porque los tokens de acceso expiran al cabo de una hora.

Crear una app que lea o modifique los datos de Quire de un usuario empieza con una decisión: ¿cómo autenticas sin ver nunca su contraseña? La API de Quire responde a eso con OAuth 2.0. Este artículo recorre la configuración de la app OAuth, el flujo de autorización de cuatro pasos, el bucle de token de acceso y refresh, y los errores habituales que se cometen en la primera implementació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, razón por la cual las integraciones que almacenaban contraseñas eran un antipatrón de seguridad antes de que OAuth las hiciera innecesarias.

¿Qué enfoque de integración con Quire encaja con tu caso de uso?

Antes de montar la API OAuth, asegúrate de que la API es realmente la herramienta adecuada. Quire tiene cuatro superficies de integración soportadas en 2026, y resuelven problemas distintos.

Si estás creando una integración típica de app (app móvil, panel web, servicio de sincronización), la API OAuth es lo que quieres. El resto del artículo asume que vas por ese camino.

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

Para usar la API de Quire necesitarás crear una app OAuth.

Crea tu app OAuth de Quire

Tendrás que 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 podrán ver y editar todas las apps que pertenezcan a la organización seleccionada.

3. Asigna un nombre a tu aplicación y una URL de redirección; comentaremos más adelante el papel de la URL de redirección. Por ahora puedes usar la siguiente 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 de desarrolladores, donde podrás seguir configurándola.

En resumen, deberías tener estos tres datos:

• ID de Cliente de Desarrollo: :wJoMEodI4fSSR54pfNwIuIzLnaJ
• Secreto de Cliente de Desarrollo: eb8faf4nyd1wbeconw060e9ejui8zg6w8p1hyoex
• URL de callback: http://localhost:3000/callback

¿Cómo preparas tu entorno de desarrollo para la API de Quire?

Paso 1. Configura tu app

Aloja la información de configuración de tu aplicación dentro de tu app.

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 con la que redirigirás a tus usuarios al endpoint URI de OAuth de Quire. Esto mostrará una página web en la que los usuarios de Quire que hayan iniciado sesión podrán 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 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 + '">Conectar Quire</a>' 
         + '</body></html>');
        res.end();

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

El parámetro state es una cadena aleatoria que se usa para prevenir ataques Cross-Site Request Forgery (CSRF). Debes generar aleatoriamente una cadena de caracteres. Se devolverá a tu app, sin cambios, en el Paso 3. Tu aplicación debería 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 especificada en redirect_uri.

Si el usuario aprueba la solicitud de acceso, la respuesta contiene un código de autorización. Si el usuario no aprueba la solicitud, la respuesta contiene un mensaje de error. El código de autorización o el mensaje de error que se devuelve al servidor web aparece en la cadena de consulta, tal 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 es redirigido de vuelta al redirect_uri de tu aplicación, también estarán presentes en los parámetros de la cadena de consulta un parámetro code y otro state. El state es tu token anti-falsificación CSRF para validar la petición.

Extrae el code 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. Intercambia el código de autorización por un token de acceso

Tu aplicación necesita hacer una llamada POST al endpoint de token con el código de autorización extraído y los parámetros de la petición que figuran a continuación.

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

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 recibirás como respuesta vendrá en formato JSON.

Ejemplo de respuesta:

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

El token debe guardarse de forma cuidadosa y permanente, ya que lo necesitarás para acceder a toda la API de Quire.

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

Tu app ya tiene un token de acceso que se puede usar 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 bearer token en la cabecera de la petición.

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))
          });
    });
}

Ejemplo de respuesta:

{
  "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 renuevas un token de acceso expirado de la API de Quire?

Un token de acceso está pensado intencionadamente para un uso a corto plazo. Es un mecanismo de seguridad importante de OAuth 2.0. Al usar el Authorization Code Grant Flow, los tokens de acceso tienen una vida útil de una hora por defecto.

Cuando un token de acceso expira, se devolverá un error HTTP 401:

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

Tu aplicación tendrá que renovar 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 habituales que cometen los desarrolladores con la API de Quire?

Tras observar cómo los equipos desarrollan sobre la API de Quire, se repiten los mismos cinco problemas. Ninguno es sutil; todos son evitables.

1. Guardar el client secret en código del lado del cliente. El client secret es exactamente eso, un secreto. Si acaba en el binario de una app móvil o en un bundle de navegador, cualquiera puede extraerlo y suplantar tu app. El secret debe vivir solo en un servidor bajo tu control. Si tu app es puramente del lado del cliente (single-page app, móvil), usa el flujo OAuth 2.0 PKCE en lugar de incrustar el secret.

2. Olvidar validar el parámetro state. El parámetro state existe para prevenir ataques CSRF. Si te saltas la validación en el callback, dejas un agujero que un sitio malicioso puede aprovechar para asociar silenciosamente una cuenta de Quire con la sesión de la app de un atacante. Genera state por petición, guárdalo en la sesión y rechaza cualquier callback en el que el state devuelto no coincida.

3. Tratar el token de acceso como permanente. Los tokens de acceso expiran al cabo de una hora. Las apps que guardan el token y nunca lo renuevan funcionan bien el Día 1 y dejan de funcionar silenciosamente el Día 2. Implementa el ciclo de refresh-token antes de publicar nada, no como un parche del tipo «ya lo arreglaré cuando los usuarios se quejen».

4. Hacer polling a la API para detectar cambios. El polling consume rate limit, latencia y batería. Si necesitas reaccionar a cambios en Quire, usa webhooks en su lugar. El webhook te envía el evento al instante; la llamada a la API que habrías hecho para detectarlo no tiene que ocurrir nunca.

5. Saltarte la allowlist de URL de redirección. Cada registro de app OAuth acepta una lista de URL de redirección. Si la dejas con comodín o no la configuras con precisión, un atacante puede registrar su callback como tu destino de redirección e interceptar códigos de autorización. Añade solo las URL exactas que tu app realmente usa.

Si estás desarrollando contra la API por primera vez, la forma más rápida de aprender los patrones es hacer un fork de una integración existente como el conector de n8n y estudiar cómo gestiona auth, refresh y los estados de error.

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

Hay tres patrones en los que deberías recurrir a otra superficie de integración.

• Solo necesitas reaccionar a eventos, no consultar estado. Los webhooks son más simples, basados en push y no requieren autorización del usuario para suscripciones a eventos de solo lectura. Si la función de tu app es «avísame cuando ocurra 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 superficie adecuada. Gestiona la autenticación, expone un esquema estándar y evita que tengas que escribir código OAuth tú mismo. MCP está diseñado específicamente para esto; hacerlo tú mismo con la API OAuth es más trabajo para el mismo resultado.
• Vas a hacer una exportación puntual de datos. Si solo necesitas extraer los datos de un proyecto una vez para análisis o backup, la integración con n8n o una exportación manual a CSV te ahorrarán una semana de desarrollo.

Si nada de esto se 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 nivel gratuito. Hay límites de uso en todos los planes; consulta la documentación de la API para conocer los límites actuales por app.

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

La API está basada en HTTP con cuerpos de petición y respuesta en JSON, así que funciona con cualquier lenguaje que tenga un cliente HTTP y un parser de JSON. Los ejemplos de este artículo están en JavaScript, pero el mismo flujo funciona de forma idéntica 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 un envoltorio fino alrededor del cliente HTTP de tu lenguaje sea el patrón habitual.

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

Los tokens de acceso expiran al cabo de una hora por defecto. Los refresh tokens duran más y permiten obtener nuevos tokens de acceso sin volver a pedir permiso al usuario. Integra el ciclo de refresh-token en tu app desde el primer día.

¿Puedo usar la API de Quire solo para lectura?

Sí. Los scopes de OAuth te permiten solicitar únicamente los permisos que tu app necesita. Si tu app solo lee tareas, solicita scopes de lectura. Los usuarios de Quire verán los scopes solicitados en la página de autorización y pueden rechazarlos si la petición les 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á diseñado específicamente para Claude y otros agentes LLM: gestiona la autenticación, expone un esquema de herramientas estándar y evita que tengas que escribir código OAuth tú mismo. Usa la API para integraciones de apps tradicionales; usa MCP para integraciones con agentes LLM.

¿Cuál es el siguiente paso?

Ese es el flujo completo de OAuth 2.0 para la API de Quire: configuración de la app OAuth, autorización en cuatro pasos, uso del token de acceso y ciclo de refresh. La razón más habitual por la que los desarrolladores publican una integración que funciona y se rompe dos días después es tratar el ciclo de refresh 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 en absoluto, el servidor MCP de Quire se encarga de la autenticación por ti y es la opción adecuada para integraciones con agentes LLM. Para integraciones basadas en eventos, los webhooks suelen ser una mejor opción que el patrón de polling con el que acaban la mayoría de integraciones que usan la API por primera vez.