Werde zum Helden: Erstelle deine eigene App mit der Quire API

Zuletzt aktualisiert: 20. Juli 2026

Eine App, die Quire Daten eines Nutzers liest oder ändert, beginnt mit einer Entscheidung: Wie authentifizierst du, ohne je das Passwort des Nutzers zu sehen? Die Quire API beantwortet das mit OAuth 2.0. Dieser Beitrag führt durch die Einrichtung der OAuth-App, den vierstufigen Autorisierungsablauf, die Schleife aus Access Token und Refresh und die typischen Fehler beim ersten Build.

Die Version 1.0.0 der Quire OpenAPI erschien im Oktober 2019 und ist seitdem stabil. Mit OAuth autorisieren Nutzer deine App für den Zugriff auf ihre Quire Inhalte (Aufgaben, Projekte, Kommentare, Zuweisungen, Tags, Fälligkeitsdaten), und du kommst nie mit ihren Zugangsdaten in Berührung.

Der Nutzer kann den Zugriff jederzeit widerrufen, ohne sein Passwort zu ändern. Deshalb waren Integrationen, die Passwörter speichern, ein Sicherheits-Antipattern, bevor OAuth sie überflüssig machte.

Welcher Quire Integrationsweg passt zu deinem Anwendungsfall?

Bevor du die OAuth-API einrichtest, prüfe, ob sie das richtige Werkzeug ist. Quire bietet 2026 vier unterstützte Integrationsschnittstellen, und sie lösen unterschiedliche Probleme.

Baust du eine typische App-Integration (Mobile App, Web-Dashboard, Sync-Dienst), ist die OAuth-API genau richtig. Der Rest dieses Beitrags geht von diesem Weg aus.

Wie richtest du eine OAuth-App für die Quire API ein?

Um die Quire API zu nutzen, musst du eine OAuth-App erstellen.

Deine Quire OAuth-App erstellen

Zum Erstellen einer App musst du in deinem Quire Konto angemeldet sein.

1. Öffne die Quire Entwickler-App-Konsole und klicke auf Neue App erstellen.

2. Wähle die Quire Organisation, zu der deine App gehört. Die Mitglieder der Organisation können alle Apps der gewählten Organisation ansehen und bearbeiten.

3. Gib deiner Anwendung einen Namen und eine Weiterleitungs-URL. Die Rolle der Weiterleitungs-URL besprechen wir später. Vorerst kannst du diese URL eintragen:

   http://localhost:3000/callback

4. Klicke auf Neue App erstellen. Deine neue OAuth-Anwendung erscheint auf der Seite der Entwicklerkonsole und lässt sich dort weiter konfigurieren.

Zusammengefasst solltest du jetzt diese drei Angaben haben:

• Development Client ID: :wJoMEodI4fSSR54pfNwIuIzLnaJ
• Development Client Secret: eb8faf4nyd1wbeconw060e9ejui8zg6w8p1hyoex
• Callback-URL: http://localhost:3000/callback

Wie richtest du deine Entwicklungsumgebung für die Quire API ein?

Schritt 1. Konfiguriere deine App

Lege die Konfigurationsdaten deiner Anwendung in deiner App ab.

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

Schritt 2. Nutzer zur Autorisierung der App bei Quire weiterleiten

Erzeuge eine Autorisierungs-URL, über die du deine Nutzer zum OAuth-Endpunkt von Quire weiterleitest. Sie zeigt eine Webseite, auf der angemeldete Quire Nutzer deine Anwendung für den Zugriff auf ihre Inhalte autorisieren können.

Beispiel-URL:

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

Eine Ansicht mit Autorisierungslink könnte so aussehen:

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

Der Parameter state ist eine Zufallszeichenfolge, die vor Cross-Site-Request-Forgery-Angriffen (CSRF) schützt. Du solltest die Zeichenfolge zufällig erzeugen. Sie wird in Schritt 3 unverändert an deine App zurückgegeben, und deine Anwendung sollte den Wert prüfen. Der Parameter ist optional, wir empfehlen ihn aber ausdrücklich.

Beispiel-URL:

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

Schritt 3. Die Antwort des OAuth-2.0-Servers verarbeiten

Der OAuth-2.0-Server antwortet auf die Zugriffsanfrage deiner Anwendung über die in redirect_uri angegebene URL.

Gibt der Nutzer die Zugriffsanfrage frei, enthält die Antwort einen Autorisierungscode. Gibt er sie nicht frei, enthält die Antwort eine Fehlermeldung. Der Autorisierungscode oder die Fehlermeldung steht im Query-String an den Webserver, wie unten gezeigt:

Eine Fehlerantwort:

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

Eine Antwort mit Autorisierungscode:

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

Ein Callback-Beispiel könnte so aussehen:

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

Wird der Nutzer zur redirect_uri deiner Anwendung zurückgeleitet, stehen in den Query-String-Parametern auch ein code- und ein state-Parameter. Der state ist dein CSRF-Schutztoken zur Validierung der Anfrage.

Lies code und state aus den Query-String-Parametern aus. An dieser Stelle kann der state geprüft werden.

Ein Validierungsbeispiel könnte so aussehen:

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

Schritt 4. Autorisierungscode gegen Access Token tauschen

Deine Anwendung muss einen POST-Aufruf an den Token-Endpunkt senden, mit dem ausgelesenen Autorisierungscode und den folgenden Anfrageparametern.

Ein Beispiel für die Anforderung eines Access Tokens könnte so aussehen:

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

Das Access Token kommt als Antwort im JSON-Format.

Beispielantwort:

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

Bewahre das Token sorgfältig und dauerhaft auf, denn du brauchst es für jeden Zugriff auf die Quire API.

Wie führst du API-Aufrufe mit dem Quire Access Token aus?

Deine App hat jetzt ein Access Token, mit dem sie API-Aufrufe im Namen des Nutzers ausführen kann.

Die API aufrufen

Führe den API-Aufruf aus und übergib das Access Token als Bearer Token im Header der Anfrage.

Ein API-Aufruf könnte so aussehen:

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

Beispielantwort:

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

Wie erneuerst du ein abgelaufenes Quire API Access Token?

Ein Access Token ist bewusst nur für die kurzfristige Nutzung gedacht. Das ist ein wichtiger Sicherheitsmechanismus von OAuth 2.0. Beim Authorization Code Grant Flow gilt ein Access Token standardmäßig eine Stunde.

Ist ein Access Token abgelaufen, wird ein HTTP-401-Fehler zurückgegeben:

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

Deine Anwendung muss dann das Access Token erneuern.

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

Alternativ kann deine Anwendung den Nutzer erneut in den Authentifizierungsablauf schicken.

Welche Fehler machen Entwickler mit der Quire API am häufigsten?

Wer Teams beim Bauen mit der Quire API beobachtet, sieht immer dieselben fünf Probleme. Keines ist subtil, alle sind vermeidbar.

1. Das Client Secret im clientseitigen Code speichern. Das Client Secret ist genau das: geheim. Landet es in einer Mobile-App-Binärdatei oder einem Browser-Bundle, kann es jeder auslesen und sich als deine App ausgeben. Das Secret gehört nur auf einen Server, den du kontrollierst. Ist deine App rein clientseitig (Single-Page-App, Mobile), nutze stattdessen den OAuth-2.0-PKCE-Flow, statt das Secret einzubetten.

2. Den state-Parameter nicht validieren. Der Parameter state verhindert CSRF-Angriffe. Überspringst du die Prüfung im Callback, entsteht eine Lücke, über die eine bösartige Seite unbemerkt ein Quire Konto mit der App-Sitzung eines Angreifers verknüpfen kann. Erzeuge state pro Anfrage, speichere ihn in der Sitzung und weise jeden Callback ab, dessen zurückgegebener state nicht passt.

3. Das Access Token als dauerhaft behandeln. Access Tokens laufen nach einer Stunde ab. Apps, die das Token speichern und nie erneuern, laufen an Tag 1 problemlos und brechen an Tag 2 unbemerkt. Baue die Refresh-Token-Schleife ein, bevor du irgendetwas auslieferst, und nicht als Flicken nach dem Motto „reparieren, wenn sich Nutzer beschweren".

4. Die API auf Änderungen abfragen (Polling). Polling verbrennt Ratenlimit, Latenz und Akku. Willst du auf Änderungen in Quire reagieren, nutze stattdessen Webhooks. Der Webhook schickt dir das Ereignis sofort, der API-Aufruf, mit dem du es sonst erkannt hättest, entfällt.

5. Die Allowlist für Weiterleitungs-URLs auslassen. Jede OAuth-App-Registrierung akzeptiert eine Liste von Weiterleitungs-URLs. Setzt du dort einen Platzhalter oder konfigurierst sie nicht exakt, kann ein Angreifer seinen Callback als dein Weiterleitungsziel registrieren und Autorisierungscodes abfangen. Trage nur die genauen URLs ein, die deine App wirklich nutzt.

Baust du zum ersten Mal gegen die API, lernst du die Muster am schnellsten, indem du eine bestehende Integration wie den n8n Connector forkst und studierst, wie er Authentifizierung, Refresh und Fehlerzustände behandelt.

Wann ist die Quire API nicht die richtige Wahl?

Drei Muster, bei denen du lieber zu einer anderen Integrationsschnittstelle greifen solltest.

• Du musst nur auf Ereignisse reagieren, nicht den Zustand abfragen. Webhooks sind einfacher, push-basiert und brauchen für reine Lese-Ereignisabos keine Nutzerautorisierung. Lautet die Aufgabe deiner App „sag mir Bescheid, wenn etwas passiert", nutze Webhooks, nicht die API.
• Du baust eine Integration für Claude oder einen LLM-Agenten. Hier ist der Quire MCP-Server die richtige Schnittstelle. Er übernimmt die Authentifizierung, liefert ein Standardschema und erspart dir eigenen OAuth-Code. MCP ist genau dafür gebaut, mit der OAuth-API selbst zu bauen ist mehr Arbeit für dasselbe Ergebnis.
• Du machst einen einmaligen Datenexport. Musst du die Daten eines Projekts nur einmal für Analyse oder Backup ziehen, spart dir die n8n Integration oder ein manueller CSV-Export eine Woche Entwicklungszeit.

Trifft nichts davon zu, ist die OAuth-API dein Werkzeug.

Häufig gestellte Fragen

Braucht die Quire API einen kostenpflichtigen Quire Tarif?

Nein. Die Quire API ist in jedem Tarif verfügbar, auch im kostenlosen. In allen Tarifen gelten Ratenlimits, die aktuellen Limits pro App findest du in der API-Dokumentation.

Welche Programmiersprachen unterstützt die Quire API?

Die API basiert auf HTTP mit JSON-Anfrage- und Antwort-Bodys, daher funktioniert jede Sprache mit HTTP-Client und JSON-Parser. Die Beispiele in diesem Beitrag sind in JavaScript, aber derselbe Ablauf funktioniert identisch in Python, Go, Ruby, PHP und jeder anderen Sprache. Eine offizielle Client-Bibliothek gibt es nicht, die API ist so überschaubar, dass ein schlanker Wrapper um den HTTP-Client deiner Sprache das übliche Muster ist.

Wie lange sind Quire Access Tokens gültig?

Access Tokens laufen standardmäßig nach einer Stunde ab. Refresh Tokens gelten länger und liefern neue Access Tokens, ohne dass der Nutzer erneut gefragt werden muss. Baue die Refresh-Token-Schleife von Tag 1 an in deine App ein.

Kann ich die Quire API nur lesend nutzen?

Ja. Mit OAuth Scopes forderst du nur die Berechtigungen an, die deine App braucht. Liest deine App nur Aufgaben, fordere Lese-Scopes an. Quire Nutzer sehen die angeforderten Scopes auf der Autorisierungsseite und können ablehnen, wenn die Anfrage übertrieben wirkt. Zu viele Scopes kosten also Konversionen.

Was ist der Unterschied zwischen der Quire API und dem Quire MCP-Server?

Die API ist eine universelle REST-Schnittstelle für jede App, die Quire Daten im Auftrag eines Nutzers lesen oder ändern will. Der MCP-Server ist speziell für Claude und andere LLM-Agenten gebaut: Er übernimmt die Authentifizierung, bietet ein Standard-Tool-Schema und erspart dir eigenen OAuth-Code. Nutze die API für klassische App-Integrationen, MCP für LLM-Agenten-Integrationen.

Wie geht es von hier aus weiter?

Das ist der vollständige OAuth-2.0-Ablauf für die Quire API: OAuth-App-Einrichtung, vierstufige Autorisierung, Nutzung des Access Tokens und die Refresh-Schleife. Der häufigste Grund, warum eine funktionierende Integration zwei Tage später bricht: Die Refresh-Schleife wird als spätere Korrektur behandelt, statt sie von Tag 1 an einzubauen.

Starte in der Quire Entwickler-App-Konsole oder lies die vollständige API-Referenz. Willst du gar keinen OAuth-Code schreiben, übernimmt der Quire MCP-Server die Authentifizierung und ist die richtige Wahl für LLM-Agenten-Integrationen.

Für ereignisgesteuerte Integrationen passen Webhooks meist besser als das Polling-Muster, bei dem viele erste API-Integrationen landen. Und wenn du schnelle Änderungen per Skript erledigen willst, ganz ohne OAuth-App, führt die Quire CLI Projektmanagement-Befehle direkt in deinem Terminal aus.