Ein API-Schlüssel ist eine Vollmacht für Software. Wer ihn besitzt, kann im Namen des Kontos oder Nutzers handeln, für den er ausgestellt wurde. Ein zweites Passwort oder ein Login-Schritt ist dann nicht mehr nötig.
Die wichtigste Frage ist: in wessen Namen? Manche Schlüssel gelten für einen einzelnen Nutzer mit dessen Rechten, andere für das ganze Unternehmenskonto. Davon hängt ab, welchen du für eine Integration brauchst.
Viele Tools brauchen gar keinen Schlüssel. Zapier und Make verbinden sich bei vielen Anbietern per Anmeldung. Einen Schlüssel kopierst du erst, wenn du eine API direkt aufrufst.
Sicher ist ein Schlüssel nur mit Ablaufdatum und Widerruf. Speichere ihn als Secret, gib ihm eine Laufzeit und widerrufe ihn, sobald er nicht mehr gebraucht wird oder nach außen gelangt ist.
Ein API-Schlüssel ist eine Zeichenkette, mit der sich ein Programm gegenüber einer Schnittstelle ausweist. Die meisten Erklärungen hören bei dieser Definition auf. In der Praxis scheitern Integrationen aber selten daran, dass jemand den Begriff nicht kennt. Sie scheitern, weil ein Tool nach einem Schlüssel fragt und niemand weiß, welcher gemeint ist, wer damit handelt und was passiert, wenn der Kollege, der ihn erstellt hat, das Unternehmen verlässt. Dieser Leitfaden erklärt den Begriff deshalb an einem konkreten Ablauf: Eine neue Terminbuchung soll automatisch im CRM landen.
Was ist ein API-Schlüssel?
Ein API-Schlüssel (englisch API Key) ist ein geheimer Wert, den ein Dienst ausstellt, damit andere Programme seine Schnittstelle nutzen können. Das aufrufende Programm schickt den Schlüssel bei jeder Anfrage mit. Der Dienst prüft ihn, erkennt daran das Konto und entscheidet, ob die Anfrage erlaubt ist.
Meist steckt der Schlüssel im Authorization-Header der Anfrage:
Das Wort Bearer bedeutet Inhaber. Das Verfahren ist im Internet-Standard RFC 6750 beschrieben, und der Name sagt, worauf es ankommt: Wer den Wert hat, gilt als berechtigt. Google formuliert es in seinen Empfehlungen für den Umgang mit API-Schlüsseln ausdrücklich so, dass ein gestohlener Schlüssel dem Dieb denselben Zugriff gibt wie dem rechtmäßigen Besitzer. In einem Thread in r/googlecloud mit rund 20 Kommentaren läuft die Diskussion auf denselben Punkt hinaus: Ein geleakter Schlüssel braucht keine weitere Bestätigung, er funktioniert einfach.
Ein API steht dabei für Application Programming Interface, also die Schnittstelle, über die zwei Programme Daten austauschen. Der Schlüssel ist die Eintrittskarte zu dieser Schnittstelle, die Schnittstelle selbst legt fest, welche Daten es überhaupt gibt.
API-Schlüssel, Token, OAuth: wo liegt der Unterschied?
Die Begriffe werden im Alltag durcheinander verwendet, und viele Anbieter nennen dasselbe Ding unterschiedlich. Der Unterschied liegt darin, wie der Zugang entsteht und in wessen Namen er gilt.
| Zugangsart | Wie er entsteht | In wessen Namen | Typischer Einsatz |
|---|---|---|---|
Passwort | Du legst es selbst fest | Du als Person | Anmeldung im Browser |
ZugangsartPasswort Wie er entstehtDu legst es selbst fest In wessen NamenDu als Person Typischer EinsatzAnmeldung im Browser | |||
API-Schlüssel | Du erzeugst ihn im Konto und kopierst ihn | Konto oder Projekt | Server ruft Schnittstelle auf |
ZugangsartAPI-Schlüssel Wie er entstehtDu erzeugst ihn im Konto und kopierst ihn In wessen NamenKonto oder Projekt Typischer EinsatzServer ruft Schnittstelle auf | |||
Persönliches Zugriffstoken | Du erzeugst es im eigenen Profil | Du, mit deiner Rolle | Skripte, eigene Tools |
ZugangsartPersönliches Zugriffstoken Wie er entstehtDu erzeugst es im eigenen Profil In wessen NamenDu, mit deiner Rolle Typischer EinsatzSkripte, eigene Tools | |||
OAuth-Zugang | Du meldest dich an und bestätigst die Freigabe | Du, mit freigegebenem Umfang | Apps wie Zapier oder Make |
ZugangsartOAuth-Zugang Wie er entstehtDu meldest dich an und bestätigst die Freigabe In wessen NamenDu, mit freigegebenem Umfang Typischer EinsatzApps wie Zapier oder Make | |||
Technisch sind API-Schlüssel und persönliche Zugriffstoken oft gleich aufgebaut, beide werden als Bearer-Wert mitgeschickt. Der Unterschied ist organisatorisch: Ein persönliches Token hängt an einem Nutzer, ein Plattform- oder Projektschlüssel am Konto. Bei OAuth kopierst du gar nichts. Du meldest dich beim Dienst an, bestätigst, welche Daten die App sehen darf, und die App erhält im Hintergrund ein eigenes Token, das du jederzeit wieder entziehen kannst.
Wie sehr die Namen verschwimmen, zeigt HubSpot. Die klassischen HubSpot-API-Schlüssel wurden am 30. November 2022 abgeschaltet, seitdem laufen eigene Integrationen über Zugriffstoken privater Apps oder über OAuth. Ab Ende September 2026 ersetzt HubSpot auch das Anlegen neuer Legacy-Private-Apps durch sogenannte Service Keys (Stand: 22.09.2026). Wer eine alte Anleitung liest, sucht also nach einem Menüpunkt, den es nicht mehr gibt.
Welche Rechte hat ein API-Schlüssel?
Ein API-Schlüssel hat die Rechte, die der ausstellende Dienst ihm gibt, und das ist bei jedem Anbieter anders. Drei Muster kommen häufig vor.
Nutzerbezogen mit vollen Rechten. In Pipedrive findest du den persönlichen API-Schlüssel unter Einstellungen, Persönliche Einstellungen, API. Er ist an einen Nutzer und ein Unternehmen gebunden und gibt Zugriff auf alle Daten, die dieser Nutzer sieht. Pro Nutzer ist nur ein aktiver Schlüssel möglich, und ob du ihn überhaupt siehst, hängt davon ab, ob dein Admin den API-Zugang für deine Berechtigungsgruppe freigeschaltet hat (Stand: 22.09.2026).
Nutzerbezogen mit Rolle. Das persönliche Zugriffstoken in meetergo handelt genau wie du im Dashboard. Als normales Mitglied verwaltet es deine eigenen Terminseiten, Verfügbarkeiten und Buchungen. Als Admin kann es zusätzlich Daten im gesamten Workspace lesen, etwa die Termine anderer Nutzer. Nutzer anlegen oder löschen kann es nicht.
Kontoweit mit Scopes. Viele Plattformen lassen dich beim Erstellen einzelne Bereiche wählen, zum Beispiel nur Kontakte lesen, aber keine Rechnungen schreiben. Wenn diese Auswahl angeboten wird, nutze sie. Das Prinzip dahinter heißt Least Privilege: Ein Schlüssel bekommt nur die Rechte, die seine Aufgabe braucht.
Die Frage nach dem Besitzer ist dabei mehr als eine Formalie. Wird der Besitzer eines persönlichen Tokens aus dem Workspace entfernt, funktioniert das Token nicht mehr. Für eine Integration, die das ganze Team nutzt, lohnt sich deshalb ein gemeinsames Integrationskonto statt des persönlichen Profils eines Mitarbeiters.
Beispiel: Terminbuchung mit dem CRM verbinden
Angenommen, du willst jede neue Buchung als Kontakt oder Deal in deinem CRM anlegen. So gehst du vor, und bei jedem Schritt zeigt sich, wo ein API-Schlüssel gebraucht wird und wo nicht.
Schritt 1: Klären, in welche Richtung die Daten fließen
Bevor du irgendeinen Schlüssel erzeugst, klär die Richtung. Soll die Buchungssoftware das CRM benachrichtigen, sobald etwas passiert, oder soll ein Skript regelmäßig Buchungen abholen? Für den ersten Fall gibt es Webhooks: Das Buchungssystem schickt bei jedem Ereignis eine Nachricht an eine Adresse, die du angibst. In meetergo sind das die Ereignisse neue Buchung, Absage und Verschiebung, eingerichtet über die Webhook-Integration. Für Webhooks brauchst du auf der Buchungsseite keinen API-Schlüssel, nur die Ziel-URL.
Schritt 2: Den richtigen Zugang wählen
Jetzt geht es um die Seite, die schreibt. Drei Wege sind üblich:
- Fertige Integration: Für verbreitete CRMs wie Pipedrive oder HubSpot bringen Buchungstools oft eigene Anbindungen mit. Dann richtest du die Verbindung im Tool ein und kümmerst dich nicht um Header.
- Automatisierungsplattform: Über Zapier, Make oder n8n nimmst du den Webhook entgegen und schreibst ins CRM. Die offizielle meetergo-App in Zapier und Make nimmt keinen Schlüssel an, du meldest dich dort mit deinem meetergo-Konto an.
- Eigener Code: Ein kleines Skript oder eine Serverfunktion empfängt den Webhook und ruft die CRM-API direkt auf. Hier brauchst du den API-Schlüssel des CRM.
Für die meisten Teams ist der zweite Weg der pragmatische Mittelweg. Den API-Schlüssel des CRM brauchst du nur, wenn es in der Plattform kein fertiges Modul gibt und du einen HTTP-Schritt selbst baust.
Schritt 3: Den Schlüssel erstellen und einmal sichern
Erstelle den Schlüssel im Konto, das die Integration dauerhaft tragen soll. Gib ihm einen sprechenden Namen wie Buchungen-an-CRM-Make, damit du ihn später wiedererkennst. Setz ein Ablaufdatum, wenn der Dienst es anbietet. Viele Anbieter zeigen den Wert genau einmal an: meetergo speichert persönliche Zugriffstoken nach der Ausstellung nicht auf seinen Servern und kann sie deshalb später nicht erneut anzeigen. Kopiere ihn direkt in den Passwortmanager oder den Secret-Speicher der Plattform, nicht in eine Notiz oder einen Chat.
Schritt 4: Den Schlüssel als Secret hinterlegen
In Make, n8n oder deinem Code gehört der Schlüssel in ein dafür vorgesehenes Feld: Verbindungen, Credentials oder Umgebungsvariablen. Er gehört nicht fest in eine Code-Datei und nicht in ein Git-Repository. Ein Einsteiger schreibt in einem Thread in r/learnprogramming mit rund 20 Kommentaren, dass sein Framework keine eingebaute Funktion für Schlüssel mitbringt. Genau diese Lücke füllen die Secret-Speicher der Integrationsplattformen, ohne dass du selbst etwas bauen musst.
Beim eigentlichen Aufruf setzt du den Header so, wie es die Dokumentation des CRM verlangt. Manche Dienste wollen Authorization: Bearer, andere einen eigenen Header oder einen Parameter in der URL. Parameter in der URL landen leichter in Logdateien, deshalb ist der Header die sicherere Variante, wenn der Dienst beide erlaubt.
Schritt 5: Testen, beobachten, dokumentieren
Buche einen Testtermin und prüf, ob der Kontakt im CRM mit den richtigen Feldern ankommt. Sieh dir auch die Fehlerfälle an: Was passiert bei einer Absage, was bei einer Verschiebung? Notiere zum Schluss an einer Stelle, die das Team findet, welcher Schlüssel wofür genutzt wird, wer ihn besitzt und wann er abläuft. Diese Notiz spart später die Suche, wenn eine Integration plötzlich mit einem Fehler 401 stehen bleibt.
API-Schlüssel sicher speichern, rotieren und widerrufen
Ein API-Schlüssel braucht dieselbe Sorgfalt wie ein Passwort, nur fehlt ihm meistens die zweite Sicherung. Die OWASP-Liste der häufigsten API-Risiken führt fehlerhafte Authentifizierung als eigenes Risiko, und schwach geschützte Zugangsdaten sind ein typischer Einstieg. Fünf Regeln decken die meisten Fälle ab:
- Nie im Frontend. Ein Schlüssel im Browser-Code oder in einer App ist öffentlich, auch wenn er versteckt aussieht. Aufrufe mit geheimen Schlüsseln gehören auf einen Server.
- Nie im Repository. Umgebungsvariablen oder ein Secret-Manager statt fester Werte im Code. Dienste wie GitHub Secret Scanning erkennen bekannte Schlüsselformate in Commits, verlassen solltest du dich darauf nicht.
- Ein Schlüssel pro Zweck. Getrennte Schlüssel für Make, für das Telefonsystem und für das Reporting-Skript. Wird einer kompromittiert, widerrufst du nur diesen.
- Laufzeit setzen und rotieren. Google empfiehlt, Schlüssel regelmäßig zu ersetzen. meetergo rät in seinen Sicherheitsempfehlungen zu Laufzeiten zwischen 30 und 90 Tagen.
- Sofort widerrufen, wenn nötig. Bei einem Verdacht zuerst widerrufen, dann suchen. In meetergo erledigt das die Schaltfläche Widerrufen neben dem Token, danach ist es für die API wertlos.
Wie man die Abwägung zwischen Schlüssel und Secret-Paar gestaltet, diskutieren Entwickler in einem Thread in r/Supabase mit acht Kommentaren. Für Teams, die nur Tools verbinden, ist die Antwort einfacher: Nutze die Verfahren, die der Anbieter vorgibt, und bau keine eigenen.
Datenschutz ist dabei eine eigene Frage. Ein API-Schlüssel sagt nichts darüber, wo die Daten verarbeitet werden, die durch die Verbindung fließen. Wenn Buchungsdaten über eine Automatisierungsplattform ins CRM laufen, ist jede Station ein Auftragsverarbeiter. Was das für Zapier bedeutet, zeigt der Beitrag zu Zapier und DSGVO, den Zusammenhang mit IT-Sicherheit allgemein der Artikel über DSGVO und Cybersecurity.
Wo meetergo in diesem Ablauf hilft und wo nicht
meetergo ist eine Plattform für Terminbuchung aus Deutschland, die Buchungsseiten, Videocalls und ein eigenes CRM zusammenbringt. Im Beispiel oben sitzt meetergo auf der Buchungsseite, und die Zugänge sind klar getrennt:
- Persönliches Zugriffstoken: in jedem Tarif verfügbar, auch im kostenlosen. Es verbindet eigene Skripte, meetergo Log oder einen KI-Telefonassistenten mit deinem Konto, mit deiner Rolle und optionalem Ablaufdatum.
- Webhooks: ab dem Light-Tarif, also in jedem bezahlten Tarif. Ein Admin richtet sie für den ganzen Account ein, pro Account sind bis zu sechs Webhooks möglich.
- Zapier und Make: ebenfalls ab dem Light-Tarif, Verbindung per Anmeldung statt per Schlüssel.
- Platform API: Wer ein eigenes Produkt baut, das Konten anderer Nutzer anlegt und verwaltet, nutzt die meetergo API mit einem kontoweiten Plattformschlüssel. Er wird unter Einstellungen, Entwickler, API-Schlüssel mit einer Laufzeit von 1 bis 90 Tagen erstellt und gilt für das ganze Unternehmen.
Die Grenzen gehören dazu. Das persönliche Token kann keine Nutzer anlegen, ändern oder löschen, dafür brauchst du die Platform API, und die ist nicht im normalen Tarif enthalten, sondern wird separat freigeschaltet. Die Zapier-Anmeldung fragt nach E-Mail und Passwort. Wer sein meetergo-Konto über Google oder Microsoft angelegt hat, hat dort kein Passwort und wendet sich derzeit an den Support (Stand: 22.09.2026). Und meetergo erzeugt keine Webhook-URL, die Adresse muss von deinem Zielsystem oder deiner Automatisierungsplattform kommen.
Der Free-Tarif bleibt dauerhaft kostenlos, die bezahlten Tarife lassen sich sieben Tage testen. Welche Funktionen in welchem Tarif stecken, steht auf der Preisseite. Wie meetergo Daten schützt, beschreibt die Seite zur Sicherheit.
Buchungen ohne Abtippen ins CRM
Häufige Fehler mit API-Schlüsseln
Den Schlüssel im persönlichen Konto eines Mitarbeiters erstellen. Verlässt die Person das Unternehmen, wird ihr Zugang entfernt, und die Integration bricht ohne Vorwarnung ab. Ein gemeinsames Integrationskonto verhindert das.
Einen Schlüssel für alles verwenden. Wenn Make, das Telefonsystem und ein altes Skript denselben Wert nutzen, musst du bei einem Leck alle drei gleichzeitig umstellen. Mit getrennten Schlüsseln betrifft ein Widerruf nur eine Verbindung.
Die falsche Art von Zugang wählen. Ein kontoweiter Plattformschlüssel für ein simples Skript gibt mehr Rechte als nötig, ein persönliches Token für ein Produkt mit vielen Nutzern reicht nicht aus. Lies in der Hilfe des Anbieters nach, welchen Zugang er für deinen Fall vorsieht.
Alte Anleitungen blind befolgen. Menüpunkte und Verfahren ändern sich, wie das Ende der klassischen HubSpot-Schlüssel zeigt. Wenn der beschriebene Menüpunkt fehlt, ist die Anleitung wahrscheinlich veraltet.
FAQ
Wo finde ich meinen API-Schlüssel?
Fast immer in den Einstellungen des Kontos, unter Bereichen wie API, Entwickler oder Integrationen. In meetergo liegen persönliche Zugriffstoken unter Integrationen & Apps. Fehlt der Bereich, hat dein Admin den API-Zugang für deine Rolle oft nicht freigeschaltet.
Kann ich einen API-Schlüssel später noch einmal anzeigen?
Bei vielen Diensten nicht. Der Wert wird nur beim Erstellen angezeigt, danach speichert der Anbieter ihn nicht mehr lesbar. Wenn du ihn verloren hast, erstellst du einen neuen und widerrufst den alten.
Ist ein API-Schlüssel dasselbe wie ein Passwort?
Nein. Ein Passwort meldet eine Person an, meist mit zweitem Faktor. Ein API-Schlüssel meldet ein Programm an und wirkt sofort, ohne weitere Bestätigung. Deshalb braucht er eine Laufzeit und getrennte Werte pro Zweck.
Was mache ich, wenn mein API-Schlüssel öffentlich geworden ist?
Widerruf ihn sofort und erstelle einen neuen. Danach prüfst du die Protokolle des Dienstes auf ungewöhnliche Zugriffe und ersetzt den Wert in allen Integrationen. Einen veröffentlichten Schlüssel nur aus dem Code zu löschen reicht nicht, weil er in der Versionsgeschichte bleibt.
Brauche ich einen API-Schlüssel für Zapier oder Make?
Für die offiziellen App-Module meist nicht, dort meldest du dich beim jeweiligen Dienst an. Einen Schlüssel brauchst du, wenn du in Zapier oder Make einen eigenen HTTP-Schritt baust, der eine API direkt aufruft.
Wie lange sollte ein API-Schlüssel gültig sein?
So kurz, wie es der Aufwand für den Austausch zulässt. Für Integrationen, die dauerhaft laufen, sind 30 bis 90 Tage ein üblicher Rahmen. Ein Schlüssel ohne Ablaufdatum sollte die Ausnahme sein und in deiner Dokumentation stehen.
