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

Dernière mise à jour : 28 mai 2026

En bref : 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 (identifiant client, secret, URL de redirection), d'un flux d'autorisation en quatre étapes (configuration, redirection, gestion de la réponse, échange du code contre un jeton) et d'une boucle de rafraîchissement, car les jetons d'accès expirent après une heure.

Développer 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 à cette question 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, ainsi que les erreurs courantes que commettent les développeurs lors de leur premier déploiement.

La version 1.0.0 de l'OpenAPI de Quire a été publiée 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, assignations, é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 — c'est pourquoi les intégrations stockant les mots de passe étaient un antipatterne de sécurité avant qu'OAuth ne les rende inutiles.

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

Avant de mettre en place l'API OAuth, assurez-vous que l'API est bien le bon outil. En 2026, Quire propose quatre surfaces d'intégration, chacune répondant à des besoins différents.

Si vous développez une intégration d'application classique (application mobile, tableau de bord web, service de synchronisation), l'API OAuth est ce qu'il vous faut. La suite de cet article part du principe que vous suivez cette voie.

Comment configurer une application OAuth pour l'API Quire ?

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

Créez votre application OAuth Quire

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

1. Accédez à la console développeur 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 voir et modifier toutes les applications associées à cette organisation.

3. Donnez un nom à votre application et renseignez l'URL de redirection — nous expliquerons son rôle plus loin. Pour l'instant, vous pouvez indiquer l'URL suivante :

   http://localhost:3000/callback

4. Cliquez sur le bouton Créer une nouvelle application ; votre nouvelle application OAuth apparaîtra dans la console développeur, où vous pourrez 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 rappel : http://localhost:3000/callback

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

Étape 1. Configurer votre application

Hébergez les informations de configuration de votre application dans celle-ci.

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. Rediriger l'utilisateur pour autoriser l'application sur Quire

Générez une URL d'autorisation vers laquelle vous redirigerez vos utilisateurs, pointant vers le point de terminaison OAuth de Quire. Une page web s'affichera, permettant aux utilisateurs Quire connectés d'autoriser votre application à accéder à leur contenu.

Exemple d'URL :

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

Voici un exemple de lien d'autorisation :

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 CSRF (Cross-Site Request Forgery). Vous devez générer une chaîne de caractères aléatoire. Elle sera renvoyée à votre application, inchangée, à l'étape 3. Votre application doit valider cette valeur. Bien qu'optionnel, nous recommandons vivement d'inclure ce paramètre.

Exemple d'URL :

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

Étape 3. Gérer 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 refuse 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 avec code d'autorisation :

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

Exemple de callback :

//...
} 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 l'redirect_uri de votre application, un paramètre code et un paramètre state seront également présents dans les paramètres de la chaîne de requête. Le paramètre state est votre jeton anti-CSRF permettant de valider la requête.

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

Exemple de validation :

} 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. Échanger le code d'autorisation contre un jeton d'accès

Votre application doit effectuer un appel POST au point de terminaison du jeton avec le code d'autorisation extrait et les paramètres de requête indiqués ci-dessous.

Exemple de demande de jeton d'accès :

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

Ce jeton doit être conservé soigneusement et de façon permanente, car il est nécessaire pour accéder à toutes les fonctions de l'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 qu'elle peut utiliser pour effectuer des appels API au nom de l'utilisateur.

Appeler l'API

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

Exemple d'appel API :

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 Quire expiré ?

Un jeton d'accès est intentionnellement conçu pour une utilisation à court terme — c'est un mécanisme de sécurité essentiel d'OAuth 2.0. Avec le 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.' 
}

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

Votre application peut également rediriger l'utilisateur vers le flux d'authentification.

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

Après avoir observé de nombreuses équipes développer sur l'API Quire, les mêmes cinq problèmes reviennent systématiquement. 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 se retrouve dans un binaire d'application mobile ou un bundle navigateur, n'importe qui peut l'extraire et usurper l'identité de votre application. Le secret ne doit résider que sur un serveur que vous contrôlez. Si votre application est purement côté client (application monopage, mobile), utilisez le flux OAuth 2.0 PKCE plutôt que d'intégrer le secret.

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

3. Traiter le jeton d'accès comme permanent. Les jetons d'accès expirent après une heure. Les applications qui stockent le jeton sans jamais le rafraîchir fonctionnent parfaitement le premier jour et échouent silencieusement le lendemain. Construisez la boucle de rafraîchissement avant de livrer quoi que ce soit — ne la repoussez pas à « quand les utilisateurs se plaindront ».

4. Interroger l'API pour détecter les changements. L'interrogation répétée consomme inutilement le quota de débit, augmente la latence et vide les batteries. Si vous avez besoin de réagir aux changements dans Quire, utilisez plutôt les Webhooks. Le webhook vous livre l'événement instantanément ; l'appel API que vous auriez effectué pour détecter cet événement n'a plus lieu d'être.

5. Négliger la liste blanche des URL de redirection. Toute inscription d'application OAuth accepte une liste d'URL de redirection. Si vous utilisez un caractère générique ou oubliez 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 sur 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 la façon dont il gère l'authentification, le rafraîchissement et les états d'erreur.

Quand l'API Quire n'est-elle pas adaptée ?

Trois situations où il vaut mieux vous tourner vers une autre surface d'intégration.

• Vous avez uniquement besoin de réagir à des événements, pas d'interroger un état. Les Webhooks sont plus simples, basés sur le push, et ne nécessitent pas d'autorisation utilisateur pour les souscriptions d'événements en lecture seule. Si votre application a pour rôle de « vous alerter quand quelque chose se produit », utilisez les Webhooks plutôt que l'API.
• Vous développez une intégration Claude ou agent LLM. Le serveur MCP Quire est la solution appropriée. Il gère l'authentification, fournit un schéma standard et vous dispense d'écrire du code OAuth. MCP est conçu spécifiquement pour cela ; le recréer soi-même avec l'API OAuth représente davantage de travail pour le même résultat.
• Vous effectuez une exportation de données ponctuelle. Si vous avez seulement besoin d'extraire les données d'un projet une fois pour une analyse ou une sauvegarde, l'intégration à n8n ou un export CSV manuel vous fera gagner une semaine de développement.

Si aucune de ces situations ne s'applique, l'API OAuth est votre outil.

Questions fréquentes

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

Non. L'API Quire est disponible sur tous les abonnements, y compris le niveau gratuit. Des limites de débit s'appliquent sur tous les abonnements ; 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 est basée sur HTTP avec des corps de requête et de réponse en JSON, ce qui signifie que tout langage disposant d'un client HTTP et d'un analyseur JSON fonctionne. Les exemples de cet article sont en JavaScript, mais le même flux fonctionne de manière identique en Python, Go, Ruby, PHP et tout autre langage. Il n'existe pas de bibliothèque cliente officielle ; la surface de l'API est suffisamment réduite pour qu'un simple wrapper autour du client HTTP de votre langage soit la pratique courante.

Quelle est la durée de validité des jetons d'accès Quire ?

Les jetons d'accès expirent après 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 redemander l'autorisation à l'utilisateur. 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 portées OAuth vous permettent de ne demander que les autorisations dont votre application a besoin. Si votre application ne fait que lire des tâches, demandez des portées de lecture. Les utilisateurs de Quire verront les autorisations demandées sur la page d'autorisation et pourront refuser si la demande leur semble excessive — en demander trop nuit à la conversion.

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

L'API est une surface REST à usage général 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 autres agents LLM : il gère l'authentification, expose un schéma d'outils standard et vous dispense d'écrire du code OAuth vous-même. Utilisez l'API pour les intégrations d'applications traditionnelles ; utilisez le serveur MCP pour les intégrations d'agents LLM.

Quelle est la prochaine étape ?

Voilà l'intégralité du flux OAuth 2.0 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 principale pour laquelle les développeurs livrent une intégration fonctionnelle qui cesse de fonctionner deux jours plus tard est de traiter la boucle de rafraîchissement comme une correction ultérieure plutôt que de l'intégrer dès le premier jour.

Commencez avec la console 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 à votre place et est le bon choix pour les intégrations d'agents LLM. Pour les intégrations pilotées par les événements, les Webhooks sont généralement plus adaptés que le pattern d'interrogation avec lequel la plupart des premières intégrations API finissent.