Sei ein Held: 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 Auftrag eines Nutzers 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) sowie eine Refresh-Token-Schleife, da Zugriffstoken nach einer Stunde ablaufen.

Wer eine App baut, die Quire-Daten eines Nutzers liest oder verändert, steht vor einer grundlegenden Entscheidung: Wie authentifiziert man sich, ohne das Passwort des Nutzers jemals 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.

Die Version 1.0.0 von Quires OpenAPI wurde im Oktober 2019 veröffentlicht und ist seitdem stabil geblieben. Mit OAuth autorisieren Nutzer deine App für den Zugriff auf ihre Quire-Inhalte (Aufgaben, Projekte, Kommentare, Zuweisungen, Tags, Fälligkeitsdaten), ohne dass du ihre Zugangsdaten jemals zu sehen bekommst. Der Nutzer kann diesen Zugriff jederzeit widerrufen, ohne sein Passwort zu ändern – genau das macht das Speichern von Passwörtern in Integrationen zu einem Sicherheits-Antipattern, das OAuth überflüssig gemacht hat.

Welcher Quire-Integrationsansatz passt zu deinem Anwendungsfall?

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

Wer eine typische App-Integration baut (Mobile App, Web-Dashboard, Sync-Dienst), ist mit der OAuth API am besten bedient. Der Rest dieses Beitrags geht davon aus, dass du diesen Weg einschlägst.

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

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

Deine Quire OAuth-App erstellen

Du musst in deinem Quire-Konto eingeloggt 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 gehören.

3. Gib deiner Anwendung einen Namen und eine Weiterleitungs-URL. Die Rolle der Weiterleitungs-URL werden wir später besprechen. Fürs Erste kannst du folgende URL verwenden:

   http://localhost:3000/callback

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

Zusammengefasst benötigst du diese drei Informationen:

• 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 Konfigurationsdaten 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. Nutzer zur App-Autorisierung auf Quire weiterleiten

Generiere eine Autorisierungs-URL, zu der du deine Nutzer weiterleitest – an Quires OAuth-Endpunkt-URI. Dort sehen eingeloggte Quire-Nutzer eine Webseite, auf der sie deiner Anwendung den Zugriff auf ihre Inhalte Freigeben 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 zum Schutz vor Cross-Site Request Forgery (CSRF)-Angriffen. 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. 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 Nutzer die Zugriffsanfrage Freigibt, enthält die Antwort einen Autorisierungscode. Lehnt der Nutzer die Anfrage ab, enthält die Antwort eine Fehlermeldung. Der Autorisierungscode oder die Fehlermeldung, der bzw. die an den Webserver zurückgegeben wird, erscheint im Query-String, 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 Nutzer zurück zur redirect_uri deiner Anwendung weitergeleitet wird, sind auch ein code- und ein state-Parameter in den Query-String-Parametern vorhanden. Der state ist dein CSRF-Anti-Forgery-Token zur Validierung der Anfrage.

Extrahiere code und state aus den Query-String-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 folgenden Anfrageparametern durchführen.

Ein Beispiel für die Anforderung eines Zugriffstokens 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 macht man API-Aufrufe mit dem Quire-Zugriffstoken?

Deine App verfügt jetzt über ein Zugriffstoken, mit dem sie API-Aufrufe im Auftrag des Nutzers durchführen kann.

Die API aufrufen

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

Ein Beispiel für einen 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 erneuert man ein abgelaufenes Quire API-Zugriffstoken?

Ein Zugriffstoken ist bewusst 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.' 
}

Deine Anwendung muss das Zugriffstoken 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 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 im clientseitigen Code speichern. Das Client-Secret ist genau das: ein Geheimnis. Landet es in einem Mobile-App-Binary oder einem Browser-Bundle, kann jeder es extrahieren und deine App imitieren. Das Secret sollte ausschließlich auf einem Server liegen, den du kontrollierst. Falls deine App rein clientseitig ist (Single-Page-App, Mobile App), verwende stattdessen den OAuth 2.0 PKCE-Flow, anstatt das Secret einzubetten.

2. Die Validierung des State-Parameters vergessen. Der state-Parameter dient der Abwehr von CSRF-Angriffen. Wenn du die Validierung beim Callback überspringst, hast du eine Lücke hinterlassen, die eine bösartige Website nutzen kann, um ein Quire-Konto stillschweigend mit der App-Session eines Angreifers zu verknüpfen. Generiere state pro Anfrage, speichere ihn in der Session und weise 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 niemals erneuern, funktionieren am ersten Tag einwandfrei und brechen am zweiten Tag still zusammen. Baue die Refresh-Token-Schleife ein, bevor du etwas auslieferst – nicht als „Fix, wenn Nutzer sich beschweren"-Patch.

4. Die API nach Änderungen abfragen. Polling verschwendet Rate-Limit, erhöht die Latenz und leert den Akku. Wenn du auf Änderungen in Quire reagieren musst, verwende stattdessen Webhooks. Der Webhook liefert das Ereignis sofort; der API-Aufruf, den du zur Erkennung des Ereignisses gemacht hättest, entfällt vollständig.

5. Die Weiterleitungs-URL-Allowlist überspringen. Jede OAuth-App-Registrierung akzeptiert eine Liste von Weiterleitungs-URLs. Wenn du sie mit einem Wildcard versiehst oder nicht präzise konfigurierst, kann ein Angreifer seinen Callback als dein Weiterleitungsziel registrieren und Autorisierungscodes abfangen. Füge ausschließlich die exakten URLs hinzu, 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 sie Authentifizierung, Refresh und Fehlerzustände handhabt.

Wann ist die Quire API nicht die richtige Wahl?

Drei Muster, bei denen du stattdessen eine andere Integrationsoberfläche verwenden solltest.

• Du musst nur auf Ereignisse reagieren, nicht den Status abfragen. Webhooks sind einfacher, push-basiert und erfordern keine Nutzerautorisierung für reine Lese-Ereignisabonnements. Wenn deine App nur „benachrichtige mich, wenn etwas passiert" tun soll, 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 standardisiertes Schema und erspart dir das Schreiben von OAuth-Code. MCP ist genau dafür gebaut; eine eigene Lösung mit der OAuth API zu entwickeln, bedeutet mehr Aufwand für dasselbe Ergebnis.
• Du führst einen einmaligen Datenexport durch. Wenn du nur einmalig die Daten eines Projekts für eine Analyse oder ein Backup abrufen 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 steht auf jedem Plan zur Verfügung, einschließlich des kostenlosen Plans. Für alle Pläne gelten Rate-Limits; die aktuellen Limits pro App 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 schlanker 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-Tokens haben eine längere Gültigkeitsdauer und können verwendet werden, um neue Zugriffstoken zu erhalten, ohne den Nutzer erneut aufzufordern. Baue die Refresh-Token-Schleife von Anfang an in deine App ein.

Kann ich die Quire API für reinen Lesezugriff verwenden?

Ja. OAuth-Scopes erlauben es dir, nur die Berechtigungen anzufordern, die deine App benötigt. Wenn deine App nur Aufgaben liest, fordere Lese-Scopes an. Quire-Nutzer sehen die angeforderten Scopes auf der Autorisierungsseite und können ablehnen, wenn die Anfrage übertrieben wirkt – daher schadet das Anfordern zu vieler Berechtigungen der Conversion-Rate.

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 Auftrag eines Nutzers 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 erspart dir das Schreiben von OAuth-Code. Verwende die API für traditionelle App-Integrationen und MCP für LLM-Agenten-Integrationen.

Wie geht es 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 abbricht, ist, die Refresh-Schleife als späteren Fix zu behandeln, anstatt sie von Anfang an einzubauen.

Starte mit der Quire Entwickler-App-Konsole oder lies die vollständige API-Referenz. Wer lieber keinen OAuth-Code schreiben möchte, ist mit dem Quire MCP-Server besser beraten – er übernimmt die Authentifizierung 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.