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

Última actualización: 28 de mayo de 2026

En resumen: La API OAuth 2.0 de Quire permite que tu app actúe en la cuenta de Quire de un usuario sin almacenar su contraseña. Necesitarás una app OAuth registrada (ID de cliente, secreto y Redireccionar URL), un flujo de autorización en cuatro pasos (configurar, redirigir, gestionar la respuesta e intercambiar el código por un token) y un ciclo de token de actualización, ya que los tokens de acceso caducan después de una hora.

Desarrollar una app que lea o modifique datos de Quire de un usuario comienza con una decisión: ¿cómo autenticarte sin ver jamás su contraseña? La API de Quire responde a esa pregunta con OAuth 2.0. Este artículo explica la configuración de la app OAuth, el flujo de autorización en cuatro pasos, el ciclo de token de acceso y actualización, y los errores más comunes 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 en Quire (tareas, proyectos, comentarios, asignaciones, etiquetas, fechas de vencimiento) sin que tú toques sus credenciales en ningún momento. El usuario puede revocar ese acceso en cualquier momento sin cambiar su contraseña, lo que convierte las integraciones que almacenan contraseñas en un antipatrón de seguridad que OAuth hizo innecesario.

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

Antes de conectar la API OAuth, asegúrate de que la API es realmente la herramienta adecuada. En 2026, Quire cuenta con cuatro superficies de integración, cada una diseñada para resolver problemas distintos.

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

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

Para usar la API de Quire, primero debes 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 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 Redireccionar URL; más adelante hablaremos del papel de la Redireccionar URL. 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:

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

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

Paso 1. Configura tu app

Almacena la información de configuración de tu aplicación en la propia 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 que autorice la app en Quire

Genera una URL de autorización a la que redirigirás a tus usuarios hacia el endpoint URI de OAuth de Quire. Esto mostrará una página web donde 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 enlace de autorización podría tener este aspecto:

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 se usa 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 incluirlo.

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 incluye 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, como se muestra a continuación:

Respuesta de error:

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

Respuesta con código de autorización:

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

Un ejemplo de callback podría ser así:

//...
} 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 a la redirect_uri de tu aplicación, también estarán presentes los parámetros code y state en la cadena de consulta. El state es tu token anti-CSRF para validar la solicitud.

Extrae el código y el estado de los parámetros de la cadena de consulta. El estado puede validarse en este punto.

Un ejemplo de validación podría ser así:

} 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 debe realizar una llamada POST al endpoint del token con el código de autorización extraído y los parámetros de solicitud indicados a continuación.

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

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 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 de forma segura y permanente, ya que lo necesitarás para acceder a toda la 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 puede usarse para realizar llamadas a la API en nombre del usuario.

Llama a la API

Realiza 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 así:

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 de la API de Quire caducado?

Un token de acceso está diseñado intencionalmente para un uso de corta duración. Este es un mecanismo de seguridad fundamental de OAuth 2.0. Al usar el flujo de concesión de código de autorización, los tokens de acceso tienen una vida útil de una hora por defecto.

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

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

Your application will need to refresh the access token. 
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))
          });
    });
}

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

¿Cuáles son los errores más comunes de los desarrolladores con la API de Quire?

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

1. Guardar el secreto del cliente en código del lado del cliente. El secreto del cliente es exactamente eso: un secreto. Si acaba en el binario de una app móvil o en un bundle de navegador, cualquiera puede extraerlo e impersonar tu app. El secreto debe vivir únicamente en un servidor bajo tu control. Si tu app es puramente del lado del cliente (single-page app, móvil), usa el flujo PKCE de OAuth 2.0 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 una brecha que un sitio malicioso puede usar para asociar silenciosamente una cuenta de Quire con la sesión de la app de un atacante. Genera state por solicitud, guárdalo en la sesión y rechaza cualquier callback donde el estado devuelto no coincida.

3. Tratar el token de acceso como permanente. Los tokens de acceso caducan después de una hora. Las Apps que almacenan el token sin actualizarlo funcionan bien el primer día y fallan silenciosamente el segundo. Construye el ciclo del token de actualización antes de publicar nada, no como un parche para cuando los usuarios se quejen.

4. Hacer polling a la API para detectar cambios. El polling consume límite de velocidad, genera latencia y agota la 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 detectar ese evento nunca llega a producirse.

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

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 n8n y estudiar cómo gestiona la autenticación, la actualización de tokens y los estados de error.

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

Tres situaciones en las que deberías optar por una superficie de integración diferente.

• Solo necesitas reaccionar a eventos, no consultar el estado. Los Webhooks son más sencillos, basados 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 u otro agente LLM. El servidor MCP de Quire es la superficie adecuada aquí. Gestiona la autenticación, incluye un esquema estándar y evita que tengas que escribir código OAuth. El MCP está diseñado específicamente para esto; hacerlo tú mismo con la API OAuth supone más trabajo para el mismo resultado.
• Estás haciendo 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án 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 nivel gratuito. Se aplican límites de velocidad 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 solicitud y respuesta en JSON, por lo que funciona con cualquier lenguaje que tenga un cliente HTTP y un analizador 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 existe una biblioteca cliente oficial; la superficie de la API es lo suficientemente pequeña como para que un envoltorio ligero 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 caducan después de una hora por defecto. Los tokens de actualización duran más tiempo y pueden usarse para obtener nuevos tokens de acceso sin volver a solicitar permiso al usuario. Integra el ciclo del token de actualización en tu app desde el primer día.

¿Puedo usar la API de Quire solo para lectura?

Sí. Los scopes de OAuth 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 permisos solicitados en la página de autorización y pueden rechazarlos si la solicitud les parece excesiva, así que pedir más de lo necesario 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 elimina la necesidad de escribir código OAuth. Usa la API para integraciones de apps tradicionales; usa el 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 el ciclo de actualización. La razón más habitual por la que los desarrolladores publican una integración funcional que falla dos días después es tratar el ciclo de actualización como una corrección posterior en lugar de integrarlo desde el primer día.

Empieza en la consola de apps para desarrolladores de Quire o consulta la referencia completa de la API. Si prefieres no escribir código OAuth en absoluto, el servidor MCP de Quire gestiona 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 las primeras integraciones de API.