Devenez un héros : créez votre propre application avec l'API Quire

Dernière mise à jour : 28 mai 2026

TL;DR : L'API OAuth 2.0 de Quire permet à votre application d'agir sur le compte Quire d'un utilisateur sans stocker son mot de passe. Vous aurez besoin d'une application OAuth enregistrée (client ID, secret, URL de redirection), d'un flux d'autorisation en quatre étapes (configurer, rediriger, traiter la réponse, échanger le code contre un jeton), et d'une boucle de rafraîchissement, car les jetons d'accès expirent après une heure.

Construire une application qui lit ou modifie les données Quire d'un utilisateur commence par une décision : comment s'authentifier sans jamais voir le mot de passe de l'utilisateur ? L'API Quire répond à cela avec OAuth 2.0. Cet article présente la configuration de l'application OAuth, le flux d'autorisation en quatre étapes, la boucle jeton d'accès / rafraîchissement, et les erreurs courantes que les développeurs commettent lors du premier build.

La version 1.0.0 de l'OpenAPI de Quire est sortie en octobre 2019 et est restée stable depuis. Avec OAuth, les utilisateurs autorisent votre application à accéder à leur contenu Quire (tâches, projets, commentaires, attributions, étiquettes, dates d'échéance) sans que vous ne touchiez jamais à leurs identifiants. L'utilisateur peut révoquer cet accès à tout moment sans changer son mot de passe, raison pour laquelle les intégrations stockant des mots de passe étaient un anti-modèle de sécurité avant qu'OAuth ne les rende inutiles.

Quelle approche d'intégration Quire correspond à votre cas d'usage ?

Avant de vous lancer dans l'API OAuth, assurez-vous que l'API est bien l'outil adapté. Quire propose quatre surfaces d'intégration prises en charge en 2026, qui résolvent des problèmes différents.

Si vous construisez une intégration applicative classique (application mobile, tableau de bord web, service de synchronisation), l'API OAuth est ce qu'il vous faut. La suite de cet article suppose que vous êtes sur cette voie.

Comment configurer une application OAuth pour l'API Quire ?

Pour utiliser l'API Quire, vous devrez créer une application OAuth.

Créez votre application OAuth Quire

Vous devrez être connecté à votre compte Quire pour créer une application.

1. Rendez-vous sur la console des applications développeur de Quire et cliquez sur le bouton Créer une nouvelle application.

2. Choisissez l'Organisation Quire à laquelle appartient votre application ; les membres de l'organisation pourront consulter et modifier toutes les applications appartenant à l'organisation sélectionnée.

3. Donnez un nom à votre application ainsi qu'une URL de redirection ; nous discuterons du rôle de l'URL de redirection plus tard. Pour l'instant, vous pouvez fournir l'URL suivante :

   http://localhost:3000/callback

4. Cliquez sur le bouton Créer une nouvelle application ; votre application OAuth nouvellement créée sera affichée sur la page de la console développeur, vous permettant de la configurer davantage.

En résumé, vous devriez disposer de ces trois informations :

• ID client de développement : :wJoMEodI4fSSR54pfNwIuIzLnaJ
• Secret client de développement : eb8faf4nyd1wbeconw060e9ejui8zg6w8p1hyoex
• URL de callback : http://localhost:3000/callback

Comment configurer votre environnement de développement pour l'API Quire ?

Étape 1. Configurez votre application

Hébergez les informations de configuration de votre application dans votre 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';

Étape 2. Redirigez l'utilisateur pour autoriser l'application sur Quire

Générez une URL d'autorisation vers laquelle vous redirigerez vos utilisateurs, pointant vers l'URI du point de terminaison OAuth de Quire. Cela affichera une page web où les utilisateurs Quire connectés pourront autoriser votre application à accéder à leur contenu.

Exemple d'URL :

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

Un exemple de vue de lien d'autorisation pourrait ressembler à :

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

Le paramètre state est une chaîne aléatoire utilisée pour prévenir les attaques de type Cross-Site Request Forgery (CSRF). Vous devez générer aléatoirement une chaîne de caractères. Elle sera renvoyée à votre application, inchangée, à l'étape 3. Votre application doit valider cette valeur. Bien que ce paramètre soit facultatif, nous recommandons vivement de l'inclure.

Exemple d'URL :

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

Étape 3. Traitez la réponse du serveur OAuth 2.0

Le serveur OAuth 2.0 répond à la demande d'accès de votre application en utilisant l'URL spécifiée dans redirect_uri.

Si l'utilisateur approuve la demande d'accès, la réponse contient un code d'autorisation. Si l'utilisateur n'approuve pas la demande, la réponse contient un message d'erreur. Le code d'autorisation ou le message d'erreur renvoyé au serveur web apparaît dans la chaîne de requête, comme illustré ci-dessous :

Une réponse d'erreur :

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

Une réponse contenant un code d'autorisation :

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

Un exemple de callback pourrait ressembler à :

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

Lorsque l'utilisateur est redirigé vers le redirect_uri de votre application, un paramètre code et state seront également présents dans la chaîne de requête. Le state est votre jeton anti-CSRF servant à valider la requête.

Extrayez les paramètres code et state de la chaîne de requête. Le state peut être validé à ce stade.

Un exemple de validation pourrait ressembler à :

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

Étape 4. Échangez le code d'autorisation contre un jeton d'accès

Votre application doit effectuer un appel POST vers le point de terminaison de jetons avec le code d'autorisation extrait et les paramètres de requête ci-dessous.

Un exemple de demande de jeton d'accès pourrait ressembler à ceci :

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

Le jeton d'accès que vous recevrez en réponse sera au format JSON.

Exemple de réponse :

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

Le jeton doit être conservé soigneusement et de manière permanente, car vous en avez besoin pour accéder à chaque API Quire.

Comment effectuer des appels API avec le jeton d'accès Quire ?

Votre application dispose désormais d'un jeton d'accès qui peut être utilisé pour effectuer des appels API au nom de l'utilisateur.

Appelez l'API

Effectuez l'appel API en transmettant le jeton d'accès sous forme de bearer token dans l'en-tête de la requête.

Un exemple d'appel API pourrait ressembler à :

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

Exemple de réponse :

{
  "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"
}

Comment rafraîchir un jeton d'accès API Quire expiré ?

Un jeton d'accès est volontairement destiné à un usage de courte durée. Il s'agit d'un mécanisme de sécurité important d'OAuth 2.0. Lors de l'utilisation du flux Authorization Code Grant, les jetons d'accès ont une durée de vie d'une heure par défaut.

Lorsqu'un jeton d'accès expire, une erreur HTTP 401 est renvoyée :

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

Votre application devra rafraîchir le jeton d'accès.
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))
          });
    });
}

Vous pouvez également rediriger l'utilisateur vers le flux d'authentification.

Quelles sont les erreurs les plus courantes que les développeurs commettent avec l'API Quire ?

Après avoir observé des équipes développer avec l'API Quire, les cinq mêmes problèmes reviennent. Aucun n'est subtil ; tous sont évitables.

1. Stocker le secret client dans du code côté client. Le secret client est, comme son nom l'indique, un secret. S'il finit dans le binaire d'une application mobile ou dans un bundle de navigateur, n'importe qui peut l'extraire et usurper l'identité de votre application. Le secret doit résider uniquement sur un serveur que vous contrôlez. Si votre application est purement côté client (application monopage, mobile), utilisez plutôt le flux OAuth 2.0 PKCE au lieu d'embarquer le secret.

2. Oublier de valider le paramètre state. Le paramètre state existe pour prévenir les attaques CSRF. Si vous ne validez pas ce paramètre lors du callback, vous laissez une faille qu'un site malveillant peut exploiter pour associer silencieusement un compte Quire à la session d'application d'un attaquant. Générez state par requête, stockez-le dans la session, et rejetez tout callback dont le state renvoyé ne correspond pas.

3. Considérer le jeton d'accès comme permanent. Les jetons d'accès expirent au bout d'une heure. Les applications qui stockent le jeton sans jamais le rafraîchir fonctionnent parfaitement le premier jour et tombent silencieusement en panne le deuxième. Construisez la boucle de rafraîchissement avant de livrer quoi que ce soit, pas comme un patch « on corrigera quand les utilisateurs se plaindront ».

4. Effectuer du polling sur l'API pour détecter les changements. Le polling consomme de la limite de débit, de la latence et de la batterie. Si vous devez réagir à des changements dans Quire, utilisez les webhooks à la place. Le webhook vous transmet l'événement instantanément ; l'appel API que vous auriez effectué pour détecter cet événement n'a jamais à se produire.

5. Négliger l'allowlist des URL de redirection. Chaque enregistrement d'application OAuth accepte une liste d'URL de redirection. Si vous utilisez un wildcard ou si vous négligez de la configurer précisément, un attaquant peut enregistrer son callback comme cible de redirection et intercepter les codes d'autorisation. N'ajoutez que les URL exactes que votre application utilise réellement.

Si vous développez avec l'API pour la première fois, le moyen le plus rapide d'en apprendre les patterns est de forker une intégration existante comme le connecteur n8n et d'étudier comment il gère l'authentification, le rafraîchissement et les états d'erreur.

Quand l'API Quire n'est-elle pas le bon choix ?

Trois cas où vous devriez plutôt vous tourner vers une autre surface d'intégration.

• Vous avez seulement besoin de réagir à des événements, pas d'interroger un état. Les Webhooks sont plus simples, push-based, et ne nécessitent pas d'autorisation utilisateur pour les abonnements à des événements en lecture seule. Si le rôle de votre application est « préviens-moi quand quelque chose se passe », utilisez les webhooks, pas l'API.
• Vous construisez une intégration d'agent Claude ou LLM. Le serveur MCP Quire est la bonne surface ici. Il gère l'authentification, expose un schéma standard, et vous évite d'écrire vous-même du code OAuth. MCP est conçu spécifiquement pour cela ; développer le vôtre avec l'API OAuth représente plus de travail pour le même résultat.
• Vous faites un export de données ponctuel. Si vous avez seulement besoin de récupérer une fois les données d'un projet pour analyse ou sauvegarde, l'intégration à n8n ou un export CSV manuel vous fera économiser une semaine de développement.

Si aucun de ces cas ne s'applique, l'API OAuth est votre outil.

Foire aux questions

L'API Quire nécessite-t-elle un plan Quire payant ?

Non. L'API Quire est disponible sur tous les plans, y compris la formule gratuite. Des limites de débit s'appliquent sur tous les plans ; consultez la documentation de l'API pour les limites actuelles par application.

Quels langages de programmation l'API Quire prend-elle en charge ?

L'API repose sur HTTP avec des corps de requête et de réponse au format JSON, donc tout langage disposant d'un client HTTP et d'un parseur JSON fonctionne. Les exemples de cet article sont en JavaScript, mais le même flux fonctionne à l'identique en Python, Go, Ruby, PHP et dans tout autre langage. Il n'existe pas de bibliothèque client officielle ; la surface de l'API est suffisamment réduite pour qu'un simple wrapper autour du client HTTP de votre langage soit le pattern courant.

Combien de temps durent les jetons d'accès Quire ?

Les jetons d'accès expirent au bout d'une heure par défaut. Les jetons de rafraîchissement durent plus longtemps et peuvent être utilisés pour obtenir de nouveaux jetons d'accès sans demander à l'utilisateur de se reconnecter. Intégrez la boucle de rafraîchissement dans votre application dès le premier jour.

Puis-je utiliser l'API Quire pour un accès en lecture seule ?

Oui. Les scopes OAuth vous permettent de demander uniquement les autorisations dont votre application a besoin. Si votre application ne fait que lire des tâches, demandez des scopes de lecture. Les utilisateurs Quire verront les scopes demandés sur la page d'autorisation et pourront refuser si la demande semble excessive ; en demander trop nuit donc à la conversion.

Quelle est la différence entre l'API Quire et le serveur MCP Quire ?

L'API est une surface REST polyvalente pour toute application souhaitant lire ou modifier des données Quire au nom d'un utilisateur. Le serveur MCP est conçu spécifiquement pour Claude et d'autres agents LLM : il gère l'authentification, expose un schéma d'outils standard, et vous évite d'écrire vous-même du code OAuth. Utilisez l'API pour les intégrations d'applications traditionnelles ; utilisez MCP pour les intégrations d'agents LLM.

Et maintenant, quelle est la suite ?

Voilà le flux OAuth 2.0 complet pour l'API Quire : configuration de l'application OAuth, autorisation en quatre étapes, utilisation du jeton d'accès et boucle de rafraîchissement. La raison la plus fréquente pour laquelle les développeurs livrent une intégration qui fonctionne avant de tomber en panne deux jours plus tard, c'est de traiter la boucle de rafraîchissement comme un correctif ultérieur plutôt que de l'intégrer dès le premier jour.

Lancez-vous sur la console des applications développeur Quire ou consultez la référence complète de l'API. Si vous préférez ne pas écrire de code OAuth du tout, le serveur MCP Quire gère l'authentification pour vous et constitue le bon choix pour les intégrations d'agents LLM. Pour les intégrations événementielles, webhooks sont généralement plus adaptés que le pattern de polling vers lequel se tournent la plupart des premières intégrations API.