Fragen zur API

Registrieren Sie sich und bestätigen Sie Ihre E-Mail-Adresse. Die erste Seite nach der Anmeldung, «Über die API verbinden», erstellt Ihren Schlüssel clk_live_….

Der Schlüssel wird einmal angezeigt, direkt nach dem Erstellen. Kopieren Sie ihn dann: Wir speichern nur seinen Hash. Ein Konto kann bis zu 10 aktive Schlüssel haben. Einen Schlüssel, den Sie nicht mehr brauchen, widerrufen Sie auf derselben Seite; er funktioniert sofort nicht mehr.

Die API liegt unter https://api.consent.link/v3 und spricht JSON. Senden Sie den Schlüssel bei jeder Anfrage im Header Authorization: Bearer clk_live_… (der Header X-AUTH-TOKEN unserer alten API v2 funktioniert auch). Eine Anfrage ohne gültigen Schlüssel bekommt 401 unauthenticated.

Rufen Sie die API nur von Ihrem Server aus auf. Wer den Schlüssel hat, kann Links erstellen und Ihr Protokoll mit vollständigen Besucherdaten lesen.

Alle auf einen Blick. Jeder Pfad folgt auf https://api.consent.link; die öffentlichen Schlüssel zum Prüfen von Entscheidungstoken liegen unter https://app.consent.link/.well-known/jwks.json.

Senden Sie POST /v3/links mit dem Ziel. Die Antwort ist 201 mit dem Link: short ist die Adresse für Ihre Anzeigen, Posts und E-Mails, id ihr Code. Nur destination ist Pflicht.

Links entstehen nur über die API, nie im Kundenbereich: Jedes Ziel wird beim Erstellen eines Links geprüft, das hält Phishing fern.

• destination: wohin der Besucher nach der Entscheidung geht. Pflicht.
• type: die Kennzeichnung auf der Einwilligungsseite, eines von ad, sponsored, affiliate, none. Ohne Angabe gilt die Kennzeichnung aus «Gestaltung».
• template: der Text der Seite, eine Vorlagen-ID aus unserer Bibliothek (Tabelle unten). Ohne Angabe gilt die Vorlage aus «Gestaltung».
• name: Ihr eigener Name für den Link, bis zu 255 Zeichen, im Kundenbereich sichtbar.
• external_id: Ihre eigene ID, etwa eines Posts oder einer Kampagne, bis zu 255 Zeichen. Sie können Links danach filtern; später ändern lässt sie sich nicht.
• metadata: ein eigenes JSON-Objekt, das unverändert gespeichert und zurückgegeben wird.

Die Antwort enthält außerdem resolved_destination (für einen Tracker oder Kurzlink, siehe unten), status (active, disabled oder blocked), mode (live oder test) und created_at, dazu warnings, wenn es etwas zu warnen gibt.

Auf eine absolute http- oder https-Adresse mit öffentlichem Domainnamen, bis zu 2.048 Zeichen: keine IP-Adressen, kein Benutzername oder Passwort, keine Leerzeichen oder Backslashes. Wir speichern sie Byte für Byte.

Jede neue Adresse wird mit unserer Sperrliste und Google Web Risk abgeglichen, eine gefährliche wird mit 422 destination_blocked abgelehnt. Stellt sich eine Adresse später als gefährlich heraus, wird der Link gesperrt: Er öffnet sich nicht mehr, lässt sich nicht mehr ändern, und Ihr Webhook bekommt link.blocked.

Ist der Host des Ziels die Klickadresse eines Affiliate-Netzwerks oder eines Linkkürzers, etwa awin1.com, sjv.io, prf.hn, admitad.com, amzn.to, bit.ly (auch Subdomains), folgen wir seinen Weiterleitungen selbst: beim Erstellen des Links, auch im Stapel, und wenn PATCH sein destination ändert. Das sind bis zu 5 Weiterleitungen in wenigen Sekunden. Die Adresse, an der die Kette die Tracker zu einer anderen Website verlässt, speichern wir Byte für Byte als resolved_destination. Andere Ziele rufen wir nie ab, ihr resolved_destination bleibt null.

destination bleibt genau so, wie Sie es geschickt haben. Mit Einwilligung kommt der Besucher dorthin, über den Tracker. Ohne Einwilligung geht er direkt zu resolved_destination, am Tracker vorbei und ohne die Klick-IDs von Anzeigen.

Lässt sich die Kette nicht verfolgen (der Tracker leitet nicht weiter, antwortet zu langsam, leitet zu oft weiter, führt zu einer internen oder gesperrten Adresse oder verlässt die Tracker nie), wird der Link trotzdem erstellt, aber eine Ablehnung führt vorerst über den Tracker. Jede Antwort mit dem Link enthält dann warnings mit dem Code tracker_unresolved, und die Seite des Links im Kundenbereich sagt es ebenfalls. Wir versuchen es im Hintergrund erneut und warten zwischen den Versuchen 5 Minuten, 1 Stunde; sobald es klappt, wird resolved_destination gefüllt und die Warnung verschwindet. Nach dem letzten Versuch prüfen Sie die Adresse und senden sie mit PATCH erneut. Gibt es nichts zu warnen, fehlt warnings in der Antwort.

Unsere Anfragen an Tracker tragen den User-Agent Consent.link-Resolver/1 (+https://consent.link/faq/api).

Senden Sie bei POST /v3/links und POST /v3/links/bulk einen Header Idempotency-Key: 1 bis 255 druckbare ASCII-Zeichen, zum Beispiel eine UUID oder Ihre eigene ID des Posts. Eine Wiederholung mit demselben Schlüssel und demselben Body innerhalb von 24 Stunden gibt die bereits erstellten Links zurück, mit dem Header Idempotent-Replayed: true, und erstellt nichts.

Derselbe Schlüssel mit anderem Body wird mit 422 idempotency_key_reused abgelehnt. Läuft die erste Anfrage noch, bekommt die Wiederholung 409 idempotency_in_progress: Warten Sie kurz und senden Sie sie erneut.

Ja: POST /v3/links/bulk mit {"links": [ … ]}, bis zu 500 Links pro Anfrage, jeder mit denselben Feldern wie ein einzelner Link. Die Antwort ist 201 mit data, die Links in der Reihenfolge, in der Sie sie gesendet haben.

Alles oder nichts: Ist ein Eintrag ungültig, wird nichts erstellt, und der Fehler nennt ihn, zum Beispiel links.3.destination.

PATCH /v3/links/{id} nur mit den Feldern, die sich ändern: destination, type, template, name, metadata. null leert ein optionales Feld, metadata wird als Ganzes ersetzt, und external_id bleibt, wie sie beim Erstellen war. Die Einwilligungsseite zeigt die Änderung sofort. Ein neues Ziel wird wie das eines neuen Links geprüft, und liegt es auf einer anderen Domain, lassen frühere Einwilligungen mit «Nicht erneut fragen» für die alte Domain Besucher nicht mehr durch.

DELETE /v3/links/{id} schaltet den Link ab: Er öffnet sich nicht mehr und lässt sich weder ändern noch wieder einschalten, seine Datensätze bleiben im Protokoll. Brauchen Sie ihn wieder, erstellen Sie einen neuen Link.

GET /v3/links listet Ihre Links auf, die neuesten zuerst, 50 pro Seite (bis zu 100 mit limit). Filter: status, mode, type, template, external_id, domain sowie from und to für den Erstellungszeitpunkt (2026-10-31 oder 2026-10-31T14:00:00Z). Für die nächste Seite übergeben Sie next_cursor aus der Antwort als cursor; null heißt, es gibt keine weiteren Seiten.

GET /v3/links/{id} gibt einen Link mit stats seit seiner Erstellung zurück: shown, granted, denied, left (Seite ohne Entscheidung verlassen), reused und withdrawn. Die Zahlen hängen dem Protokoll ein paar Minuten hinterher.

Die Seite, die Sie im Kundenbereich unter «Gestaltung» eingerichtet haben: die Textvorlage aus unserer Bibliothek, die Datenempfänger, die Kennzeichnung, den Link zu Ihrer Datenschutzerklärung und bei Business Ihr Logo und Ihre Farbe. type und template des Links haben Vorrang vor der Gestaltung. Wenn Sie eine neue Version veröffentlichen, ändern sich die Seiten Ihrer Links innerhalb einer Minute.

Die Sprache wird nach dem Browser des Besuchers gewählt: Englisch, Spanisch, Deutsch, Französisch, Italienisch, Portugiesisch oder Russisch. Sie wählen eine Vorlage, keine Worte: Die Texte stammen aus unserer Bibliothek, eigene Texte gibt es nicht.

Solange in «Gestaltung» nichts veröffentlicht ist, zeigt die Seite keinen Link zu Ihrer Datenschutzerklärung und keine Datenempfänger. Links werden trotzdem erstellt, und die Antworten auf POST /v3/links, POST /v3/links/bulk und PATCH /v3/links/{id} tragen den Header Consent-Link-Warning: design_unpublished, solange die Konfiguration des Links keine veröffentlichte Version hat.

Speichern Sie unter «Gestaltung» oder über die API mehrere Profile der Seite, jedes mit eigener ID wie black-friday, und nennen Sie beim Erstellen eines Links eines davon: "profile": "black-friday" in POST /v3/links oder in einem Eintrag der Massenerstellung. Ohne profile bekommt der Link Ihr Standardprofil.

Ein Link behält sein Profil: Wird später ein anderes Profil zum Standard, bleiben alte Links unverändert. PATCH /v3/links/{id} mit profile verschiebt einen Link, "profile": null verschiebt ihn auf den Standard dieses Moments. Eine unbekannte ID ergibt 422 beim Feld profile. Das Link-Objekt zeigt sein profile, und GET /v3/links?profile=black-friday listet die Links eines Profils. Wie viele Profile Sie haben können, hängt vom Tarif ab: 1 bei Free, 5 bei Pro, 50 bei Business, das Standardprofil mitgezählt.

GET /v3/profiles listet sie auf, das Standardprofil zuerst. POST /v3/profiles erstellt eines mit id und policy_url (Pflicht) und nach Wunsch name, template, vendors, type, remember, brand_name und default. Es wird sofort veröffentlicht. PATCH /v3/profiles/{id} ändert es: Die Felder der Seite veröffentlichen sofort eine neue Version, name und "default": true allein veröffentlichen nichts.

DELETE /v3/profiles/{id} löscht ein Profil, das nicht der Standard ist (409 profile_is_default) und keine aktiven Links hat (409 profile_in_use). Ein Profil über dem Tariflimit zu erstellen oder eines zu verwenden, das nach einem Downgrade über dem Limit liegt, ergibt 402 profiles_limit_reached. Änderungen brauchen einen Live-Schlüssel.

Mit Einwilligung kommt der Besucher genau auf die Adresse, die Sie angegeben haben. Ohne Einwilligung bleiben utm_* und Ihre anderen Parameter ebenfalls erhalten, entfernt werden nur die Klick-IDs von Anzeigen: gclid, gbraid, wbraid, fbclid, msclkid, ttclid, twclid, li_fat_id. In beiden Fällen hängen wir einen Parameter an, cl_ct, das Entscheidungstoken.

Es zählen nur die Parameter des Ziels selbst: Was an den Kurzlink angehängt wird (https://consent.link/nk7Qa?utm_source=…), wird nicht weitergegeben. Legen Sie alles, was Ihre Website braucht, in destination oder erstellen Sie einen Link pro Kampagne.

Jede Weiterleitung von der Einwilligungsseite trägt cl_ct, ein signiertes Token (JWT, ES256), das 10 Minuten gilt. Prüfen Sie es von Ihrem Server aus mit POST /v3/consents/verify: Die Antwort enthält die Entscheidung, und jedes Token lässt sich nur einmal prüfen, eine kopierte Adresse ist also wertlos. Lesen Sie das Token und entfernen Sie es dann aus der Adresse.

Was es enthält: decision (granted oder denied), purposes (was der Besucher erlaubt hat), cid (der Datensatz im Protokoll), sid (das Pseudonym des Besuchers in Ihrem Konto, auf all Ihren Links gleich), cexp (bis wann die Einwilligung gilt, Unix-Zeit), link, mode, iat und exp. Keine IP, kein Browser, keine anderen personenbezogenen Daten. Ein Besucher, der früher eingewilligt und «Nicht erneut fragen» gelassen hat, geht direkt durch, mit granted.

Die Signatur können Sie auch selbst prüfen, mit den Schlüsseln unter https://app.consent.link/.well-known/jwks.json und einer beliebigen JWT-Bibliothek: Prüfen Sie exp und dass link einer Ihrer Links ist. Ihre eigene Prüfung erkennt nicht, ob ein Token schon verwendet wurde; die API-Methode schon. Fehler: 422 token_invalid, 422 token_expired, 409 token_used.

Erstellen Sie einen Webhook: POST /v3/webhooks mit url und den gewünschten events (Tabelle unten). Die Adresse muss https mit öffentlichem Hostnamen sein. Die Antwort enthält secret (whsec_…) zum Prüfen der Signaturen: Es wird einmal angezeigt, speichern Sie es. Ein Konto kann bis zu 10 aktive Webhooks haben.

Das Zustellungsprotokoll, die Schaltfläche «Wiederholen» und das Ab- und Einschalten eines Webhooks finden Sie im Kundenbereich unter «Konto» → «Webhooks».

Jedes Ereignis ist ein POST mit JSON-Body: id (evt_…), type, created_at, mode und data. Ein Einwilligungsdatensatz in data.consent hat id, link, decision, purposes, scope (domain, wenn der Besucher «Nicht erneut fragen» gelassen hat, sonst link), sid, dest_domain, country, notice_version, created_at und expires_at. Nie eine IP, einen Browser oder ein Cookie.

Jede Anfrage trägt die Header Consent-Event, Consent-Delivery und Consent-Signature: t=1793712000,v1=5f3a…. v1 ist der HMAC-SHA256 in Hex aus t, einem Punkt und dem unveränderten Body der Anfrage, mit dem Secret Ihres Webhooks als Schlüssel.

Berechnen Sie ihn aus dem Body genau so, wie er angekommen ist (vor jedem JSON-Parsing), vergleichen Sie in konstanter Zeit und lehnen Sie ein t ab, das mehr als fünf Minuten von Ihrer Uhr abweicht, damit eine mitgeschnittene Anfrage nicht wiederholt werden kann.

Eine Zustellung zählt, wenn Ihr Server innerhalb von 10 Sekunden mit 2xx antwortet; Weiterleitungen werden nicht verfolgt. Sonst versuchen wir es erneut und warten zwischen den Versuchen 1 Minute, 5 Minuten, 30 Minuten, 2 Stunden, 12 Stunden, insgesamt 6 Versuche. Nach dem letzten gilt die Zustellung als fehlgeschlagen und bleibt im Protokoll, wo «Wiederholen» sie bis zu 3 Tage nach dem Ereignis erneut sendet.

Antworten Sie also schnell und erledigen Sie die Arbeit danach. Dasselbe Ereignis kann mehr als einmal ankommen, etwa nach einer Zeitüberschreitung: Überspringen Sie bereits verarbeitete id. Ereignisse kommen nicht immer in der Reihenfolge an, in der sie geschahen.

Besucher sehen und widerrufen ihre Einwilligungen unter «Meine Einwilligungen». Wendet sich ein Besucher stattdessen an Sie, widerrufen Sie für ihn: POST /v3/consents/{id}/withdraw ohne Body, mit der ID seines Datensatzes granted oder reused. Das geht für jede noch gültige Einwilligung, egal wie weit Ihr Tarif das Protokoll zurück zeigt. Die Antwort ist 201 mit dem neuen Datensatz withdrawn, dessen first_consent_id die widerrufene Einwilligung ist. Ein Datensatz, der keine gültige Einwilligung ist (abgelehnt, schon widerrufen oder abgelaufen), bekommt 409 consent_not_in_force; einer, den Sie nicht lesen dürfen, 404 wie bei GET /v3/consents/{id}.

Beide Wege enden gleich: ein Datensatz withdrawn im Protokoll, consent.withdrawn an Ihren Webhook mit data.withdraws, der ID der widerrufenen Einwilligung, und ab dann fragen Ihre Links diesen Besucher wieder. Ein Widerruf schließt alle Einwilligungen, die der Besucher vorher für diese Domain gegeben hat, und zählt nicht zu Ihrem Limit.

Verwenden Sie seine Daten auf Ihrer Seite nicht mehr: Ordnen Sie über sid oder die Datensatz-ID zu.

Eine Einwilligung gilt 6 Monate ab ihrer Erteilung: expires_at im Datensatz, cexp im Entscheidungstoken. Ein Datensatz reused trägt das expires_at der Einwilligung, die er wiederverwendet. Danach fragen Ihre Links den Besucher wieder.

Läuft eine Einwilligung granted ab, ohne widerrufen worden zu sein, bekommt Ihr Webhook consent.expired mit data.consent, dem Datensatz, und data.expired_at. Wir prüfen einmal pro Stunde, das Ereignis kommt also innerhalb der Stunde nach expires_at, einmal pro Einwilligung. Datensätze reused bekommen kein eigenes Ereignis: Das der wiederverwendeten Einwilligung deckt sie ab. Das Ereignis geht nur an Webhooks mit consent.expired in events. Ein Ablauf wird einmal gemeldet, auch wenn damals kein Webhook darauf wartete: Später kommt er nicht noch einmal.

Binden Sie unser Skript im <head> vor GTM und gtag ein: https://consent.link/js/consent.js. Es setzt den Standard von Consent Mode v2 (alles abgelehnt außer functionality_storage und security_storage, mit wait_for_update 500 ms), liest cl_ct aus der Adresse, prüft die Signatur mit den Schlüsseln unter https://app.consent.link/.well-known/jwks.json direkt im Browser und aktualisiert die Einwilligung.

Die Entscheidung wird im Cookie cl_consent auf Ihrer Domain gespeichert: bei Einwilligung bis cexp, bei Ablehnung 180 Tage, sodass die nächsten Seiten kein Banner brauchen. Nach der Prüfung verschwindet cl_ct aus der Adressleiste, Ihre anderen Parameter bleiben. Das Skript sendet uns nichts.

Wenn Sie die Entscheidung bei sich speichern, prüfen Sie das Token zusätzlich von Ihrem Server mit POST /v3/consents/verify: Das Skript weiß nicht, ob ein Token schon benutzt wurde.

Laden Sie die Vorlage consent-link.tpl herunter, öffnen Sie in GTM Vorlagen → Neu → ⋮ → Importieren und speichern Sie. Legen Sie damit ein Tag mit dem Trigger «Consent Initialization – All Pages» («Einwilligungsinitialisierung – Alle Seiten») an.

Das Tag setzt die Standardwerte, wendet die im Cookie cl_consent gespeicherte Entscheidung an und lädt das Skript, das ein frisches cl_ct prüft. Das Skript im <head> brauchen Sie dann nicht zusätzlich.

Die purposes des Tokens geben diese Signale frei. Was nicht freigegeben ist, bleibt abgelehnt; eine Ablehnung (denied) lehnt alles ab außer den zwei, die immer erlaubt sind.

Zeigen Sie kein zweites Banner, wenn jemand schon auf unserer Seite entschieden hat. Das Skript liefert die Entscheidung in window.consentLink.decision (granted, denied oder null) und window.consentLink.has('stats'); window.consentLink.ready erfüllt sich, sobald ein Token in der Adresse geprüft ist. Dazu kommen das Ereignis consentlink:update auf document und consent_link_update im dataLayer. Laden Sie unser Skript vor dem des Banners.

Cookiebot: Geben Sie die Entscheidung mit Cookiebot.submitCustomConsent weiter, dann erscheint sein Banner nicht. OneTrust hat keine öffentliche Funktion, um eine Einwilligung von der Website aus zu speichern; laden Sie sein Skript deshalb nur, wenn keine Entscheidung vorliegt. Andere Banner ebenso: Zwecke über deren API weitergeben oder das Banner nicht laden.

GET /v3/consents listet die Datensätze auf, die neuesten zuerst, mit den Filtern decision (granted, denied, reused, withdrawn), link, country (DE), from, to und denselben Seiten wie bei Links. GET /v3/consents/{id} gibt einen Datensatz mit seinen Nachweisen zurück (IP-Adresse, Browser, Sprache, Hash des Seitentexts, wann die Seite gezeigt wurde und wie lange der Besucher brauchte) und seinen Platz in der Hash-Kette, chain.

Eine Ablehnung speichert nur die Entscheidung, die Zeit, den Link und das Land, ihr evidence ist daher null. Die API liefert die Daten vollständig; der Kundenbereich verbirgt einen Teil davon, bis Sie die Anmeldung mit einem Code aus einer App einschalten. Wie weit zurück Sie sehen, hängt vom Tarif ab (Tabelle unter «Tarife und Limits»).

GET /v3/consents/{id}/proof liefert den Datensatz als PDF: die Entscheidung, wer, was gezeigt wurde, die Hashes und wie man sie prüft. Es ist in der Sprache Ihres Kundenbereichs. Verfügbar bei Pro und Business (bei Free 402 plan_required), bis zu 20 pro Minute. Lässt sich das PDF gerade nicht erstellen, lautet die Antwort 503 unavailable mit Retry-After.

Jeder Datensatz granted trägt evidence.snapshot_hash: den SHA-256 der Einwilligungsseite, wie der Besucher sie gesehen hat, als HTML. Ein Snapshot gilt für alle Besucher derselben Seite, also derselben Gestaltungs- und Textversion, Sprache und Linkart. GET /v3/consents/{id}/snapshot liefert dieses HTML mit dem Hash im Header X-Snapshot-Hash, GET /v3/consents/{id}/snapshot.png einen Screenshot davon. Für beide gelten die Regeln von GET /v3/consents/{id}, einschließlich der Protokolltiefe.

Zum Prüfen bilden Sie den SHA-256 des HTML genau so, wie es ankam: Er ist gleich snapshot_hash, und der eigene Hash des Datensatzes in der Kette deckt snapshot_hash ab, sodass die Seite nachträglich nicht ausgetauscht werden kann. Was sich von Aufruf zu Aufruf ändert, ist im Snapshot festgelegt: Der Host des Ziels lautet example.com, die Signatur des Formulars ist leer und seine action #. Die echte Adresse steht in dest_domain und evidence.destination.

Datensätze reused, Ablehnungen und Datensätze aus der Zeit vor den Snapshots haben snapshot_hash null, und ihr Snapshot antwortet mit 404 not_found («This record has no page snapshot.»). Direkt nach einer Entscheidung werden die Dateien eventuell noch geschrieben: 404 not_found mit «The page snapshot is not ready yet.» heißt, es gleich noch einmal zu versuchen. Das HTML ist nach Sekunden da, der Screenshot etwas später. Die Seite des Datensatzes im Kundenbereich und der PDF-Nachweis zeigen Screenshot und Hash ebenfalls.

POST /v3/exports mit den Filtern von GET /v3/consents (decision, link, country, from, to) antwortet sofort mit 202 und der id des Exports. Die Datei entsteht im Hintergrund: Sie bekommen den Webhook export.ready, oder Sie fragen GET /v3/exports/{id} ab, bis status gleich ready ist, und laden dann GET /v3/exports/{id}/file herunter. Der Export enthält außerdem rows und den sha256 der Datei.

Dateien werden 7 Tage aufbewahrt (danach 410 export_expired). Bis zu 3 Exporte können gleichzeitig in Arbeit sein (429 too_many_exports). Pro und Business.

GET /v3/stats/summary liefert shown, granted, denied, left, reused und withdrawn für UTC-Tage von from bis to (2026-10-31, beide eingeschlossen; standardmäßig die letzten 30 Tage, höchstens 366 Tage, so weit zurück, wie Ihr Tarif das Protokoll zeigt). Mit link für einen Link. GET /v3/stats/daily liefert dieselben Zahlen pro Tag und bei Pro und Business mit by=country nach Ländern. Bots werden nie gezählt.

GET /v3/usage zeigt die Einwilligungen dieses Zeitraums, Ihr limit, was davon remaining ist, sowie Beginn und Ende des Zeitraums.

Die API, Webhooks und die Einwilligungsseite in sieben Sprachen gibt es in jedem Tarif. Die Tarife unterscheiden sich in Einwilligungen pro Monat, wie weit zurück das Protokoll gezeigt wird, der Anfragerate und zusätzlichen Funktionen. Preise in Euro, ohne MwSt.

Es zählen nur neue Einwilligungen: Ablehnungen, wiederholte Besuche mit «Nicht erneut fragen», und Bots nicht. Bei 80 % und 100 % des Limits bekommen Sie eine E-Mail und den Webhook usage.warning.

Ist das Limit aufgebraucht, werden neue Live-Links mit 402 limit_reached abgelehnt. Alles andere läuft weiter: Bestehende Links fragen und protokollieren wie bisher, Webhooks und Token kommen wie gewohnt, nichts wird verborgen. Links lassen sich wieder erstellen, sobald der nächste Zeitraum beginnt (bei Free am 1. des Monats, bei bezahlten Tarifen am Tag der Zahlung) oder direkt nach einem Upgrade.

Pro Konto, alle Schlüssel zusammen: 60 pro Minute bei Free, 300 bei Pro, 1.000 bei Business. Darüber lautet die Antwort 429 rate_limited mit einem Header Retry-After; die Header X-RateLimit-Limit und X-RateLimit-Remaining zeigen, wo Sie stehen. Manche Methoden haben zusätzlich ein eigenes Limit: PDF-Nachweise 20 pro Minute, neue Exporte 10, Export-Downloads 30.

Immer gleich: der HTTP-Status und ein JSON-Body mit einem festen code und einer englischen message. Richten Sie sich nach dem code, die Meldung kann umformuliert werden. Ungültige Felder ergeben 422 validation_failed mit fields: jedes Feld mit seinen Problemen.

Erstellen Sie unter «Über die API verbinden» einen neuen Schlüssel, stellen Sie Ihren Server darauf um und widerrufen Sie dann den alten: Er funktioniert sofort nicht mehr. Der Widerruf eines Schlüssels berührt weder Ihre Links noch das Protokoll oder die Webhooks.

Bewahren Sie Schlüssel in den Umgebungsvariablen Ihres Servers auf, nie im Browser, in einer mobilen App oder einem öffentlichen Repository. Könnte ein Webhook-Secret nach außen gelangt sein, schalten Sie diesen Webhook im Kundenbereich ab und erstellen Sie einen neuen.