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

Dernière mise à jour : 20 juillet 2026

Développer une application qui lit ou modifie les données Quire d'un utilisateur commence par une question : comment l'authentifier sans jamais voir son mot de passe ? L'API Quire y répond avec OAuth 2.0. Cet article détaille la configuration de l'application OAuth, le flux d'autorisation en quatre étapes, la boucle jeton d'accès et rafraîchissement, ainsi que les erreurs que font le plus souvent les développeurs au premier essai.

La version 1.0.0 de l'OpenAPI de Quire est sortie en octobre 2019 et reste stable. 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 touchiez jamais à leurs identifiants.

L'utilisateur peut révoquer cet accès à tout moment sans changer de mot de passe. C'est pourquoi stocker les mots de passe était une mauvaise pratique de sécurité, devenue inutile avec OAuth.

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

Avant de brancher l'API OAuth, vérifiez qu'elle est bien l'outil adapté. Quire propose en 2026 quatre surfaces d'intégration prises en charge, qui répondent à des besoins différents.

Si vous créez une intégration d'application classique (application mobile, tableau de bord web, service de synchronisation), c'est l'API OAuth qu'il vous faut. La suite de cet article part de ce principe.

Comment configurer une application OAuth pour l'API Quire ?

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

Créer votre application OAuth Quire

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

1. Rendez-vous dans 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 peuvent consulter et modifier toutes les applications rattachées à l'organisation sélectionnée.

3. Donnez un nom à votre application et indiquez une URL de redirection. Nous verrons plus loin le rôle de l'URL de redirection. Pour l'instant, vous pouvez saisir l'URL suivante :

   http://localhost:3000/callback

4. Cliquez sur le bouton Créer une nouvelle application : votre application OAuth apparaît alors sur la page de la console développeur, où vous pouvez la configurer plus en détail.

En résumé, vous devez 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

Placez 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, c'est-à-dire l'URI du point de terminaison OAuth de Quire. Elle affiche une page web où les utilisateurs Quire connectés peuvent autoriser votre application à accéder à leur contenu.

URL d'exemple :

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

Voici à quoi peut ressembler une vue avec 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 qui sert à prévenir les attaques par falsification de requête intersite (CSRF). Générez une chaîne de caractères aléatoire. Elle sera renvoyée à votre application, inchangée, à l'étape 3, et votre application doit valider cette valeur. Ce paramètre est facultatif, mais nous vous recommandons vivement de l'inclure.

URL d'exemple :

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

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

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

Si l'utilisateur approuve la demande d'accès, la réponse contient un code d'autorisation. S'il la refuse, 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 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

Un exemple de rappel (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);
        });
   }
}

Quand l'utilisateur est redirigé vers le redirect_uri de votre application, un code et un paramètre state figurent aussi dans les paramètres de la chaîne de requête. Le state est votre jeton anti-falsification CSRF pour 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.

Un 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 vers le point de terminaison du jeton, avec le code d'autorisation extrait et les paramètres de requête ci-dessous.

Un exemple de requête 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 est au format JSON.

Exemple de réponse :

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

Conservez le jeton avec soin et durablement, car il vous sert à accéder à toutes les API Quire.

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

Votre application dispose désormais d'un jeton d'accès utilisable pour effectuer des appels d'API au nom de l'utilisateur.

Appeler l'API

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

Un exemple d'appel d'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 expiré de l'API Quire ?

Un jeton d'accès est volontairement conçu pour un usage de courte durée. C'est un mécanisme de sécurité important 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.

Quand 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 aussi rediriger l'utilisateur vers le flux d'authentification.

Quelles sont les erreurs les plus courantes avec l'API Quire ?

À force d'observer des équipes développer avec l'API Quire, les cinq mêmes problèmes reviennent. Aucun n'est subtil, et tous sont évitables.

1. Stocker le secret client dans du code côté client. Le secret client est bien un secret. S'il se retrouve dans le binaire d'une application mobile ou dans un bundle de navigateur, n'importe qui peut l'extraire et se faire passer pour votre application.

Le secret ne doit se trouver que 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'y intégrer le secret.

2. Oublier de valider le paramètre state. Le paramètre state sert à prévenir les attaques CSRF. Si vous ne le validez pas lors du rappel, vous laissez une faille qu'un site malveillant peut exploiter pour associer discrètement un compte Quire à la session d'une application contrôlée par un attaquant. Générez state à chaque requête, stockez-le dans la session et rejetez tout rappel dont le state renvoyé 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 très bien le premier jour et cessent de fonctionner sans bruit le deuxième. Construisez la boucle de rafraîchissement avant de livrer quoi que ce soit, et non comme un correctif à appliquer quand les utilisateurs se plaignent.

4. Interroger l'API en boucle pour détecter les changements. Le polling consomme de la limite de débit, ajoute de la latence et vide la batterie. Si vous devez réagir aux changements dans Quire, utilisez plutôt les webhooks. Le webhook vous envoie l'événement instantanément ; l'appel d'API que vous auriez fait pour détecter cet événement n'a plus lieu d'être.

5. Négliger la liste d'autorisation des URL de redirection. Chaque enregistrement d'application OAuth accepte une liste d'URL de redirection. Si vous utilisez un joker ou ne la configurez pas précisément, un attaquant peut enregistrer son rappel 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 pour la première fois avec l'API, le moyen le plus rapide d'apprendre les bonnes pratiques est de forker une intégration existante, comme le connecteur n8n, et d'étudier sa gestion de l'authentification, du rafraîchissement et des erreurs.

Quand l'API Quire n'est-elle pas la meilleure option ?

Dans trois cas, mieux vaut se tourner vers une autre surface d'intégration.

• Vous devez seulement réagir à des événements, sans interroger l'état. Les webhooks sont plus simples, fonctionnent en mode push et n'exigent pas d'autorisation utilisateur pour des abonnements en lecture seule aux événements. Si le rôle de votre application est « prévenez-moi quand quelque chose se passe », utilisez les webhooks plutôt que l'API.
• Vous créez une intégration avec Claude ou un agent LLM. Le serveur MCP de Quire est la bonne surface. Il gère l'authentification, fournit un schéma standard et vous évite d'écrire du code OAuth. MCP est conçu pour cet usage ; recréer le tout avec l'API OAuth demande plus de travail pour le même résultat.
• Vous faites un export de données ponctuel. Si vous devez simplement extraire une fois les données d'un projet pour une analyse ou une sauvegarde, l'intégration à n8n ou un export CSV manuel vous fera gagner 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 une formule Quire payante ?

Non. L'API Quire est disponible avec toutes les formules, y compris l'offre gratuite. Des limites de débit s'appliquent à toutes les formules ; consultez la documentation de l'API pour connaître les limites actuelles par application.

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

L'API repose sur HTTP, avec des requêtes et des réponses au format JSON : tout langage doté d'un client HTTP et d'un analyseur JSON convient. 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 cliente officielle ; la surface de l'API est assez réduite pour qu'une fine couche autour du client HTTP de votre langage soit le schéma habituel.

Combien de temps les jetons d'accès Quire restent-ils valides ?

Les jetons d'accès expirent après une heure par défaut. Les jetons de rafraîchissement durent plus longtemps et permettent d'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 en lecture seule ?

Oui. Les scopes OAuth vous permettent de ne demander que les autorisations dont votre application a besoin. Si elle se contente de lire les tâches, demandez des scopes de lecture. Les utilisateurs de Quire voient les scopes demandés sur la page d'autorisation et peuvent refuser si la demande leur paraît excessive : demander trop nuit donc à la conversion.

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

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

Et maintenant, par où continuer ?

Voilà le flux OAuth 2.0 complet de 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 courante pour laquelle une intégration qui marche tombe en panne deux jours plus tard : la boucle de rafraîchissement a été traitée comme un correctif ultérieur au lieu d'être prévue dès le premier jour.

Pour démarrer, rendez-vous dans la console des applications développeur de Quire ou lisez la référence de l'API complète. Si vous préférez ne pas écrire de code OAuth, le serveur MCP de Quire gère l'authentification pour vous et convient parfaitement aux intégrations d'agents LLM.

Pour les intégrations pilotées par les événements, les webhooks sont généralement mieux adaptés que le polling auquel aboutissent la plupart des premières intégrations d'API. Et si vous voulez simplement scripter quelques modifications sans créer d'application OAuth, la CLI de Quire exécute des commandes de gestion de projet directement depuis votre terminal.