Einen Schlüssel senden
Wie Ihr Backend den Frontend-Schlüssel sendet und was ein abgewiesener Schlüssel erhält.
Senden Sie den Schlüssel als Bearer-Token im Header Authorization jedes Aufrufs der Mitglieder-API:
POST <studio>/api/v1/members/eligibility Authorization: Bearer ofk_3f9a1c2b7d4e_… Content-Type: application/json
Ein Aufruf im Namen eines angemeldeten Frontend-Benutzers trägt zusätzlich dessen Zugriffstoken, in einem eigenen Header neben dem Schlüssel, nie an dessen Stelle (siehe Das angemeldete Mitglied).
Ein abgewiesener Schlüssel
Jede Abweisung erhält dieselbe Antwort, gleich aus welchem Grund:
HTTP/1.1 401 Unauthorized
WWW-Authenticate: Bearer
{"error": "unauthenticated"}
Das gilt für einen fehlenden Header, ein anderes Schema als Bearer, einen fehlerhaften, unbekannten oder widerrufenen Schlüssel und den Schlüssel eines getrennten Frontends. Das Studio sagt nicht, welcher Fall vorliegt: Vergleichen Sie den ausgerollten Schlüssel mit dem Präfix auf der Karte „Schlüssel“ und fragen Sie die Organisation, ob das Frontend getrennt ist.
Nichts wird zwischengespeichert: Ein widerrufener Schlüssel wird ab der nächsten Anfrage abgewiesen, und der Schlüssel eines wieder verbundenen Frontends funktioniert sofort wieder.
Wenn das Studio nicht antworten kann
503 {"error": "unavailable"} bedeutet, dass das Studio selbst ausgefallen ist. Der Schlüssel ist in Ordnung: Versuchen Sie es später erneut und wechseln Sie ihn nicht.