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

Zuletzt aktualisiert: 28. Mai 2026

TL;DR: Die Quire OAuth 2.0 API ermöglicht es deiner App, im Namen eines Benutzers auf dessen Quire-Konto zuzugreifen, ohne sein Passwort zu speichern. Du benötigst eine registrierte OAuth-App (Client-ID, Secret, Weiterleitungs-URL), einen vierstufigen Autorisierungsablauf (konfigurieren, weiterleiten, Antwort verarbeiten, Code gegen Token tauschen) und eine Refresh-Token-Schleife, da Zugriffstoken nach einer Stunde ablaufen.

Wer eine App baut, die Quire-Daten eines Benutzers liest oder verändert, steht vor einer grundlegenden Entscheidung: Wie authentifiziert man sich, ohne jemals das Passwort des Benutzers zu sehen? Die Quire API löst das mit OAuth 2.0. Dieser Beitrag führt durch die OAuth-App-Einrichtung, den vierstufigen Autorisierungsablauf, die Zugriffstoken-und-Refresh-Schleife sowie die häufigsten Fehler, die Entwickler beim ersten Build machen.

Das 1.0.0-Release von Quires OpenAPI erschien im Oktober 2019 und ist seitdem stabil geblieben. Mit OAuth autorisieren Benutzer deine App, auf ihre Quire-Inhalte zuzugreifen (Aufgaben, Projekte, Kommentare, Zuweisungen, Tags, Fälligkeitsdaten) – ohne dass du ihre Zugangsdaten jemals siehst. Der Benutzer kann diesen Zugriff jederzeit widerrufen, ohne sein Passwort zu ändern. Genau deshalb war das Speichern von Passwörtern in Integrationen ein Sicherheits-Antipattern, bevor OAuth das überflüssig machte.

Welcher Quire-Integrationsansatz passt zu deinem Anwendungsfall?

Bevor du die OAuth-API einrichtest, solltest du sicherstellen, dass die API tatsächlich das richtige Werkzeug ist. Quire bietet 2026 vier unterstützte Integrationsoberflächen, die unterschiedliche Probleme lösen.

Wenn du eine typische App-Integration baust (mobile App, Web-Dashboard, Sync-Dienst), ist die OAuth-API das Richtige. Der Rest dieses Beitrags setzt voraus, dass du diesen Weg gehst.

Wie richtet man eine OAuth-App für die Quire API ein?

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

Erstelle deine Quire OAuth-App

Du musst in deinem Quire-Konto angemeldet sein, um eine App zu erstellen.

1. Gehe zur Quire Entwickler-App-Konsole und klicke auf die Schaltfläche Neue App erstellen.

2. Wähle die Quire Organisation, zu der deine App gehört – die Mitglieder der Organisation können alle Apps anzeigen und bearbeiten, die der ausgewählten Organisation angehören.

3. Gib deiner Anwendung einen Namen und eine Weiterleitungs-URL. Die Rolle der Weiterleitungs-URL besprechen wir später. Für den Moment kannst du die folgende URL angeben:

   http://localhost:3000/callback

4. Klicke auf die Schaltfläche Neue App erstellen – deine neu erstellte OAuth-Anwendung wird auf der Entwicklerkonsolenseite angezeigt, wo du sie weiter konfigurieren kannst.

Zusammenfassend solltest du diese drei Informationen zur Hand haben:

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

Wie richtet man die Entwicklungsumgebung für die Quire API ein?

Schritt 1. App konfigurieren

Speichere die Konfigurationsinformationen deiner Anwendung in der 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';

Schritt 2. Benutzer zur App-Autorisierung auf Quire weiterleiten

Generiere eine Autorisierungs-URL, an die du deine Benutzer zum OAuth-Endpunkt von Quire weiterleitest. Dort wird eine Webseite angezeigt, auf der angemeldete Quire-Benutzer deiner Anwendung den Zugriff auf ihre Inhalte gewähren können.

Beispiel-URL:

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

Ein Beispiel für einen 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 zufällige Zeichenkette, die Cross-Site-Request-Forgery-(CSRF)-Angriffe verhindert. Du solltest eine zufällige Zeichenkette generieren. Sie wird in Schritt 3 unverändert an deine App zurückgegeben. Deine Anwendung sollte diesen Wert validieren. Obwohl er optional ist, empfehlen wir dringend, diesen Parameter einzuschließen.

Beispiel-URL:

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

Schritt 3. Die OAuth 2.0-Serverantwort verarbeiten

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

Wenn der Benutzer die Zugriffsanfrage freigibt, enthält die Antwort einen Autorisierungscode. Wenn der Benutzer die Anfrage nicht freigibt, enthält die Antwort eine Fehlermeldung. Der Autorisierungscode oder die Fehlermeldung, der bzw. die an den Webserver zurückgegeben wird, erscheint in der Abfragezeichenkette, wie unten gezeigt:

Eine Fehlerantwort:

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

Eine Autorisierungscode-Antwort:

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

Wenn der Benutzer zurück zu deiner Anwendungs-redirect_uri weitergeleitet wird, sind in den Querystring-Parametern auch ein Code und ein State-Parameter enthalten. Der State ist dein CSRF-Anti-Forgery-Token zur Validierung der Anfrage.

Extrahiere den Code und den State aus den Querystring-Parametern. Der State kann an diesem Punkt validiert 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 Zugriffstoken tauschen

Deine Anwendung muss einen POST-Aufruf an den Token-Endpunkt mit dem extrahierten Autorisierungscode und den unten aufgeführten Anfrageparametern durchführen.

Ein Beispiel für eine Zugriffstoken-Anfrage 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 Zugriffstoken, das du als Antwort erhältst, liegt im JSON-Format vor.

Beispielantwort:

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

Das Token sollte sorgfältig und dauerhaft gespeichert werden, da du es für den Zugriff auf jede Quire API benötigst.

Wie führt man API-Aufrufe mit dem Quire-Zugriffstoken durch?

Deine App verfügt nun über ein Zugriffstoken, mit dem sie API-Aufrufe im Namen des Benutzers durchführen kann.

Die API aufrufen

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

Ein API-Aufruf-Beispiel 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 erneuert man ein abgelaufenes Quire API-Zugriffstoken?

Ein Zugriffstoken ist absichtlich nur für den kurzfristigen Gebrauch gedacht. Das ist ein wichtiger Sicherheitsmechanismus von OAuth 2.0. Bei Verwendung des Authorization Code Grant Flow haben Zugriffstoken standardmäßig eine Lebensdauer von einer Stunde.

Wenn ein Zugriffstoken abläuft, wird ein HTTP-401-Fehler zurückgegeben:

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

Alternativ könnte deine Anwendung den Benutzer zum Authentifizierungsablauf weiterleiten.

Was sind die häufigsten Fehler, die Entwickler mit der Quire API machen?

Nach der Beobachtung vieler Teams beim Entwickeln gegen die Quire API tauchen immer wieder dieselben fünf Probleme auf. Keines davon ist subtil – alle sind vermeidbar.

1. Das Client-Secret in clientseitigem Code speichern. Das Client-Secret ist genau das: ein Geheimnis. Landet es in einem mobilen App-Binary oder einem Browser-Bundle, kann es jeder extrahieren und deine App imitieren. Das Secret gehört ausschließlich auf einen Server, den du kontrollierst. Wenn deine App rein clientseitig ist (Single-Page-App, mobile App), verwende stattdessen den OAuth 2.0 PKCE-Flow anstatt das Secret einzubetten.

2. Den State-Parameter nicht validieren. Der state-Parameter existiert, um CSRF-Angriffe zu verhindern. Wenn du ihn beim Callback nicht validierst, hast du eine Lücke hinterlassen, die eine bösartige Website nutzen kann, um ein Quire-Konto stillschweigend mit der App-Sitzung eines Angreifers zu verknüpfen. Generiere state pro Anfrage, speichere ihn in der Sitzung und lehne jeden Callback ab, bei dem der zurückgegebene State nicht übereinstimmt.

3. Das Zugriffstoken als dauerhaft behandeln. Zugriffstoken laufen nach einer Stunde ab. Apps, die das Token speichern und nie erneuern, funktionieren an Tag 1 einwandfrei und scheitern still an Tag 2. Baue die Refresh-Token-Schleife ein, bevor du etwas auslieferst – nicht als „Fix es, wenn Nutzer sich beschweren"-Patch.

4. Die API auf Änderungen abfragen. Polling verbraucht Ratenlimit, erhöht die Latenz und belastet den Akku. Wenn du auf Änderungen in Quire reagieren musst, verwende stattdessen Webhooks. Der Webhook liefert das Ereignis sofort an dich; der API-Aufruf, den du gemacht hättest, um dieses Ereignis zu erkennen, muss gar nicht erst stattfinden.

5. Die Weiterleitungs-URL-Allowlist überspringen. Jede OAuth-App-Registrierung akzeptiert eine Liste von Weiterleitungs-URLs. Wenn du sie mit Wildcards versiehst oder nicht präzise konfigurierst, kann ein Angreifer seinen Callback als dein Weiterleitungsziel registrieren und Autorisierungscodes abfangen. Trage nur die genauen URLs ein, die deine App tatsächlich verwendet.

Wer zum ersten Mal gegen die API entwickelt, lernt die Muster am schnellsten, indem er eine bestehende Integration wie den n8n-Connector forkt und studiert, wie dieser Authentifizierung, Refresh und Fehlerzustände behandelt.

Wann ist die Quire API nicht die richtige Wahl?

Drei Szenarien, in denen du besser zu einer anderen Integrationsoberfläche greifst.

• Du musst nur auf Ereignisse reagieren, nicht den Status abfragen. Webhooks sind einfacher, push-basiert und erfordern keine Benutzerautorisierung für schreibgeschützte Ereignis-Abos. Wenn die Aufgabe deiner App lautet „Benachrichtige mich, wenn etwas passiert", verwende Webhooks statt der API.
• Du baust eine Claude- oder LLM-Agenten-Integration. Der Quire MCP-Server ist hier die richtige Wahl. Er übernimmt die Authentifizierung, liefert ein Standardschema und bedeutet, dass du keinen OAuth-Code selbst schreiben musst. MCP ist genau dafür gebaut; das Eigene mit der OAuth-API zu entwickeln bedeutet mehr Aufwand für dasselbe Ergebnis.
• Du machst einen einmaligen Datenexport. Wenn du nur einmal die Daten eines Projekts für Analysen oder Backups herausziehen musst, sparen dir die n8n Integration oder ein manueller CSV-Export eine Woche Entwicklungszeit.

Wenn keines davon zutrifft, ist die OAuth-API dein Werkzeug.

Häufig gestellte Fragen

Erfordert die Quire API einen kostenpflichtigen Quire Plan?

Nein. Die Quire API ist auf jedem Plan verfügbar, einschließlich des kostenlosen Tiers. Ratenlimits gelten für alle Pläne; die aktuellen App-Limits findest du in der API-Dokumentation.

Welche Programmiersprachen unterstützt die Quire API?

Die API ist HTTP-basiert mit JSON-Anfrage- und Antwortkörpern, sodass jede Sprache mit einem HTTP-Client und JSON-Parser funktioniert. Die Beispiele in diesem Beitrag sind in JavaScript, aber derselbe Ablauf funktioniert identisch in Python, Go, Ruby, PHP und jeder anderen Sprache. Es gibt keine offizielle Client-Bibliothek; die API-Oberfläche ist klein genug, dass ein einfacher Wrapper um den HTTP-Client deiner Sprache das übliche Muster ist.

Wie lange sind Quire Zugriffstoken gültig?

Zugriffstoken laufen standardmäßig nach einer Stunde ab. Refresh-Token sind länger gültig und können verwendet werden, um neue Zugriffstoken zu erhalten, ohne den Benutzer erneut aufzufordern. Baue die Refresh-Token-Schleife vom ersten Tag an in deine App ein.

Kann ich die Quire API für schreibgeschützten Zugriff verwenden?

Ja. OAuth-Scopes ermöglichen es dir, nur die Berechtigungen anzufordern, die deine App benötigt. Wenn deine App nur Aufgaben liest, fordere Lese-Scopes an. Quire-Benutzer sehen die angeforderten Scopes auf der Autorisierungsseite und können ablehnen, wenn die Anfrage übertrieben wirkt – daher schadet eine übermäßige Anforderung der Konversionsrate.

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

Die API ist eine universelle REST-Oberfläche für jede App, die Quire-Daten im Namen eines Benutzers lesen oder ändern möchte. Der MCP-Server ist speziell für Claude und andere LLM-Agenten entwickelt: Er übernimmt die Authentifizierung, stellt ein standardisiertes Tool-Schema bereit und bedeutet, dass du keinen OAuth-Code selbst schreiben musst. Verwende die API für traditionelle App-Integrationen; verwende 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, Zugriffstoken-Nutzung und die Refresh-Schleife. Der häufigste Grund, warum Entwickler eine funktionierende Integration ausliefern, die zwei Tage später bricht, ist, die Refresh-Schleife als spätere Korrektur zu behandeln anstatt sie von Anfang an einzubauen.

Leg los an der Quire Entwickler-App-Konsole oder lies die vollständige API-Referenz. Wenn du gar keinen OAuth-Code schreiben möchtest, übernimmt der Quire MCP-Server die Authentifizierung für dich und ist die richtige Wahl für LLM-Agenten-Integrationen. Für ereignisgesteuerte Integrationen sind Webhooks in der Regel besser geeignet als das Polling-Muster, bei dem die meisten erstmaligen API-Integrationen enden.