Registrierungs- und Freischaltungsablauf im Developer Portal

musiccloud, Analyse zum Stand des Codes
29. August 2026
PAP-014

Der übliche Ablauf in einem Developer Portal führt in fünf Schritten vom Konto über die App zur Subscription, zur Client-Registrierung und zum ersten Aufruf. Unser Backend kann diese fünf Schritte bereits, unser Portal zeigt sie nicht: die Oberfläche fährt noch den alten Antragsweg, während die Projekt- und Registrierungs-Endpunkte fertig danebenliegen und von keiner Komponente aufgerufen werden. Der wichtigste Befund ist kein fehlendes Feature, sondern eine offene Tür: über die Projekt-Endpunkte kommt ein Entwickler heute ohne jede Prüfung an einen gültigen API-Token, weil neue Registrierungen sofort auf active stehen. Dazu kommen fehlende Kontaktdaten jenseits der E-Mail-Adresse, eine Tier-Einstellung ohne Schreibpfad für das Creem-Produkt-Mapping und zwei konkurrierende Subscription-Tabellen.

1. Was in Developer Portalen üblich ist

1.1 Die fünf Schritte

Über alle recherchierten Portale hinweg ist der Ablauf derselbe, und er hat fünf Schritte. Der Entwickler legt ein Konto an und bestätigt seine E-Mail-Adresse. Er registriert eine Anwendung. Er bekommt oder wählt einen Plan. Er erzeugt Zugangsdaten für diese Anwendung. Er schickt den ersten authentifizierten Aufruf, meist aus einer Schnellstart-Anleitung heraus¹.

Die Empfehlung, die in jeder Quelle auftaucht, betrifft die Reibung an dieser Kette. Je schneller der erste erfolgreiche Aufruf erreicht ist, desto höher die Übernahme, und die Selbstregistrierung soll deshalb so wenige Schritte wie möglich verlangen¹. Zweitens sollen Zugangsdaten an genau eine Anwendung gebunden sein, damit ein Entzug eine einzelne Anwendung trifft und nicht den Entwickler als Ganzes¹.

1.2 Was beim Anlegen der App abgefragt wird

Die Felder sind erstaunlich einheitlich. Ein Name, eine kurze Beschreibung, eine Adresse der Anwendung, und bei OAuth eine Rücksprungadresse. Die Kontaktdaten kommen in aller Regel nicht aus dem App-Formular, sondern aus dem Konto, das der Entwickler vorher angelegt hat.

Bemerkenswert an dieser Reihe ist MusicBrainz. Lesende Aufrufe brauchen dort gar keinen Schlüssel, dafür einen sprechenden User-Agent mit einer Kontaktmöglichkeit, und ein Aufruf ohne diesen Kopf wird geblockt². Der Kontakt ist also nicht weniger wichtig geworden, er ist nur an eine andere Stelle gewandert.

1.3 Zwei Modelle der Freischaltung

Es gibt genau zwei Muster, und die Wahl zwischen ihnen ist die eigentliche Produktentscheidung.

Das erste ist die sofortige Ausgabe. Wer sich registriert, bekommt seinen Schlüssel in derselben Sitzung, ohne dass ein Mensch etwas ansieht. Das machen Last.fm, Discogs und MusicBrainz so. Der Missbrauch wird über Kontingente und über den Entzug einzelner Schlüssel begrenzt, nicht über eine Vorabprüfung.

Das zweite ist der gestufte Zugang. Jede neue Anwendung startet in einem Entwicklungsmodus mit engen Grenzen, und der Weg in den vollen Zugang führt über eine Prüfung. Spotify ist dafür das ausführlichste Beispiel: neue Anwendungen stehen im Development Mode, dürfen höchstens fünf freigeschaltete Nutzer bedienen, und der Extended Quota Mode wird über einen Fragebogen im Dashboard beantragt, mit einer Prüfdauer von bis zu sechs Wochen³. Discord unterscheidet ebenso: unverifizierte Anwendungen laufen bis 100 Server, darüber verlangt die Verifizierung ein Entwickler-Team und eine Identitätsprüfung des Team-Eigentümers über Stripe⁴.

1.4 Die Registrierung als Standard

Für den Schritt, in dem eine Anwendung Zugangsdaten bekommt, gibt es eine Norm. RFC 7591 beschreibt die dynamische Client-Registrierung: der Client schickt seine Metadaten wie client_name, redirect_uris, grant_types und token_endpoint_auth_method, und der Server vergibt daraufhin die client_id, die der Client nie selbst bestimmen kann⁶. Das ist genau die Trennung, die unser Portal einem Entwickler erklären muss: die client_id ist eine Kennung und kein Geheimnis.

Der Anhang dazu ist eine Betriebswarnung, die auch für unsere Projekt-Endpunkte gilt. Ein offener Registrierungsweg erzeugt Datensätze, die nie zu einer Nutzung führen, und braucht deshalb eine Begrenzung pro Quelle und ein Aufräumen der Karteileichen⁶.

1.5 Wie Tiers üblicherweise modelliert werden

Das ausgereifteste öffentlich beschriebene Modell ist das der Oracle-API-Gateway-Nutzungspläne. Ein Plan trägt Berechtigungen, und jede Berechtigung besteht aus einem Ratenlimit, einem Kontingent und den Zielen, auf die beides wirkt⁷. Drei Eigenschaften daraus fehlen bei uns und sind es wert, benannt zu werden.

Erstens trägt ein Kontingent eine Angabe, was beim Überschreiten passieren soll, also ablehnen oder weiter zulassen, und eine Angabe, wann es sich zurücksetzt⁷. Zweitens dürfen mehrere Zeitfenster übereinanderliegen, und das engste gewinnt, sodass eine Sekundenspitze und ein Minutenkontingent nebeneinander bestehen⁷. Drittens gehört zu einem Plan die Aussage, auf welche Endpunkte er überhaupt Zugriff gibt, was in unserem Modell schlicht nicht vorkommt.

2. Unser Stand

2.1 Das Datenmodell kann bereits mehr als das Portal

Seit Pull Request 108 ist das Projekt die Wurzel des Zugriffsmodells. Die Tabelle developer_projects hält Anzeigename, Status und eigene Limits pro Minute und pro Tag. Daran hängen developer_project_subscriptions mit Tier, Creem-Kennungen, Status, Intervall und Laufzeitende, sowie die Registrierungen in api_clients, die seit derselben Migration eine public_client_id, einen registration_type aus development, confidential und public sowie eine capabilities-Liste tragen. Jeder Aufruf schreibt einen Datensatz nach api_usage_events, und jede Zustandsänderung einen nach api_access_audit_events.

Das ist das Modell, das der Branchenablauf verlangt, und es ist gebaut. Die Endpunkte dazu stehen in apps/backend/src/routes/dev-api-access.ts, von Zeile 142 bis Zeile 240.

2.2 Der Ablauf, den das Portal heute anbietet

Die Oberfläche kennt dieses Modell nicht. Die Seitenleiste des eingeloggten Bereichs hat vier Einträge, nämlich Overview, API access, API keys und Usage. Ein Projekt kommt darin nicht vor, ein Plan auch nicht.

Das Formular in ApiAccessPanel.tsx ruft ausschließlich submitAccessRequest auf, also den alten Antragsweg unter ENDPOINTS.dev.apiAccess.requestsCreate. Die Funktionen für Projekte und Registrierungen liegen in derselben Bibliothek, in apps/developer/src/lib/apiAccessClient.ts zwischen Zeile 277 und Zeile 329, und werden von keiner einzigen Komponente aufgerufen. Dasselbe gilt im Dashboard für fetchDeveloperProjects und updateDeveloperProjectSubscription.

2.3 Der Ablauf, den das Backend heute erlaubt

Neben dem Antragsweg steht ein zweiter Weg offen, der ohne Prüfung auskommt.

Nach diesen drei Aufrufen hält der Entwickler einen gültigen Token in der Hand. Es gibt nichts, was ihn aufhält: createApiClient setzt keinen Status, und die Spalte steht per Vorgabe auf active. Der einzige Riegel im Token-Endpunkt ist rejectInactiveCredentialOwner, und der prüft genau diesen Status, der frisch angelegt eben aktiv ist. Der Antragsweg mit seiner Prüfung ist damit eine Empfehlung der Oberfläche, keine Regel des Systems.

2.4 Was der Administrator heute einstellen kann

Der Tier-Editor im Dashboard deckt alle fünfzehn inhaltlichen Spalten der Tabelle tiers ab, also Name, Aufrufe pro Minute, Aufrufe pro Tag, Attributionspflicht, Monats- und Jahrespreis als Text, Farbe, Symbol, Beschriftung des Buttons, Beschreibung, Aktiv-Schalter, Abschaltgrund, Empfehlungsmarkierung, Sortierung und die Merkmalsliste. Für das reine Tier-Objekt ist die Anforderung damit erfüllt.

Was fehlt, steht in einer anderen Tabelle. tier_creem_products verbindet ein Tier und ein Intervall mit einer Creem-Produkt-Kennung, und weil Creem-Produkte selbst kein Metadatenfeld tragen, muss diese Zuordnung bei uns liegen. Die Repository-Schnittstelle in apps/backend/src/db/tiers-repository.ts bietet dafür genau eine Methode, nämlich listCreemProductMappings. Es gibt keinen Schreibpfad, keine Route und keine Oberfläche. Ein neues bezahltes Tier ist heute nicht bis zum Bezahlvorgang einstellbar, ohne dass jemand von Hand in die Datenbank schreibt.

3. Abgleich gegen die vier Anforderungen

4. Befunde im Einzelnen

4.1 Der Prüfschritt ist umgehbar

Das ist der einzige Befund mit Sicherheitscharakter, und er trifft die dritte Anforderung ins Mark. Wer einen bestätigten Account hat, legt sich in drei Aufrufen selbst einen Token an, und der Antrag, den die Oberfläche verlangt, wird dabei nie geschrieben. Die Ursache ist die Vorgabe active auf api_clients.status in Verbindung damit, dass der Token-Endpunkt nur diesen Status prüft.

Die Reparatur ist klein und muss vor allem anderen kommen, weil jede Oberfläche, die auf diesen Endpunkten aufsetzt, sonst auf einem offenen Fundament steht. Eine Registrierung, die über den Selbstbedienungsweg entsteht, startet in einem Zustand, aus dem noch kein Token fällt. Welcher Zustand das ist, hängt an der Antwort auf die nächste Frage.

4.2 Prüfen oder nicht prüfen, und wenn ja, wie lange

Die Anforderung sagt, dass auch der Free Tier einen beantragten Token braucht. Das ist das gestufte Modell, und aus Abschnitt 1.3 folgt daraus eine Verpflichtung: jeder Antrag wartet auf einen Menschen. Spotify zeigt, was passiert, wenn dieser Mensch nicht zuverlässig antwortet.

Es gibt eine Zwischenform, die beide Seiten bedient, und sie ist bei Spotify und Discord genau die gebaute. Der Development Client entsteht sofort und ohne Prüfung, mit engen Grenzen und der klaren Aussage, dass er nicht für den Betrieb gedacht ist. Geprüft wird erst der Schritt heraus aus dieser Stufe, also der erste Confidential oder Public Client, oder das erste bezahlte Tier. Dann steht der erste erfolgreiche Aufruf innerhalb von Minuten, die Kontaktdaten liegen trotzdem vor, und die Prüfung fällt nur dort an, wo sie etwas entscheidet.

Diese Frage ist eine Produktfrage und keine technische, deshalb steht sie hier als Frage und nicht als Entscheidung.

4.3 Portal und Backend beschreiben zwei verschiedene Produkte

Die Endpunkte für Projekte, Registrierungen und Projekt-Subscriptions sind gebaut, getestet und in der Client-Bibliothek gekapselt, und beide Oberflächen ignorieren sie. Für den Entwickler heißt das, dass er eine App beschreibt statt sie anzulegen. Für den Administrator heißt es, dass er kein Projekt sehen und keinem Projekt eine Subscription zuweisen kann, obwohl die Route PUT /api/admin/developer/api-access/projects/:id/subscription und die passende Funktion im Dashboard-Code vorhanden sind.

Das ist bekannt und geplant. Issue 88 beschreibt genau diese Oberfläche, mit Projektanlage, Projektumschalter, verpflichtender Plan-Auswahl und den drei Client-Profilen. Der Bericht bestätigt hier nur, dass zwischen dem, was das Backend kann, und dem, was ein Entwickler sieht, derzeit die volle Strecke liegt.

4.4 Zwei Subscription-Tabellen für dieselbe Frage

developer_subscriptions hängt an einem Konto und verlangt Creem-Kennungen als Pflichtfelder. developer_project_subscriptions hängt an einem Projekt und lässt sie zu. Beide tragen dieselben Statuswerte und dasselbe Intervall. Welche von beiden ein Tier für einen Aufruf bestimmt, ist damit zweimal beantwortet, und die Regel aus unseren eigenen Grundsätzen sagt, dass eine der beiden Antworten verschwinden muss.

Die Richtung ist durch Issue 88 vorgegeben: Abrechnung, Kontingent und Nutzung gehören zum Projekt. Die Kontotabelle ist damit die, die geht, sobald ihre Daten übertragen sind.

4.5 Kontaktdaten fehlen, und für Österreich fehlen sie zweimal

Heute liegt eine bestätigte E-Mail-Adresse vor und ein selbstgewählter Anzeigename. Das reicht, um jemanden zu benachrichtigen, und es reicht für nichts anderes.

Für eine Rechnung fehlt alles. Ein bezahltes Tier über Creem verlangt eine Rechnungsanschrift, ein Land und bei einem Unternehmen eine Umsatzsteuer-Identifikationsnummer, weil sich daran entscheidet, ob österreichische Umsatzsteuer anfällt oder die Steuerschuld übergeht. Ob wir diese Daten selbst halten oder ob Creem sie erhebt und uns nur das Ergebnis zurückmeldet, ist eine Entscheidung, die vor dem Bau des Bezahlwegs fällt.

Für die App fehlt die Website. Sie ist in vier von fünf verglichenen Portalen ein Feld und dient dem, was der Betreiber tun muss, wenn eine Anwendung auffällt: nachsehen, was sie ist. Ein zweiter technischer Kontakt gehört in dieselbe Kategorie, weil die Konto-Adresse eine Privatadresse sein kann und Betriebsmeldungen jemanden erreichen sollen, der reagiert.

4.6 Das Creem-Produkt-Mapping ist eine Tier-Einstellung ohne Oberfläche

Aus der vierten Anforderung folgt unmittelbar, dass diese Zuordnung ins Dashboard gehört. Sie ist die einzige Verbindung zwischen einem Tier bei uns und einem Produkt bei Creem, und sie hat heute nur einen Lesepfad. Ohne sie liefert der Katalog für ein neues Tier keinen Preis, und ein Bezahlvorgang kann nicht beginnen.

4.7 Das Tier-Modell trägt nur zwei Achsen

Aufrufe pro Minute und Aufrufe pro Tag beschreiben ein Ratenlimit, aber keinen Plan. Was üblicherweise dazugehört und bei uns fehlt: die Endpunkte oder Fähigkeiten, die ein Tier freischaltet, ein Monatskontingent als Abrechnungsgröße, eine Grenze für gleichzeitige Verbindungen, und eine Obergrenze für Projekte und Registrierungen je Konto. Die capabilities-Spalte an der Registrierung existiert bereits und wäre die Stelle, an der ein Tier bestimmt, welche Fähigkeiten überhaupt zur Wahl stehen.

Die Merkmalsliste am Tier ist davon zu trennen. Sie ist Text für die Preisseite und entscheidet nichts. Wer sie zur Durchsetzung heranzieht, hat eine Produktbeschreibung zu einer Zugriffsregel gemacht.

4.8 Der schlüssellose Endpunkt widerspricht der Token-Pflicht

GET /api/v1/resolve steht bewusst außerhalb der authentifizierten Gruppe, damit einfache Skripte ihn ohne Schlüssel erreichen. Solange er das tut, ist die Aussage, dass auch der Free Tier einen Token braucht, für den meistgenutzten Weg unserer API nicht wahr. Das ist keine Panne, sondern eine frühere Entscheidung, und sie gehört zusammen mit der Frage aus 4.2 noch einmal auf den Tisch.

4.9 Nutzungsdaten werden geschrieben und nicht gelesen

Jeder authentifizierte Aufruf legt eine Zeile in api_usage_events an. Die Nutzungsseite im Portal zeigt davon nichts. Sie zeigt das durchgesetzte Kontingent und wann ein Schlüssel zuletzt benutzt wurde, und sagt selbst, dass die Auswertung später kommt. Der Entwickler kann damit nicht sehen, wie nah er an seiner Grenze ist, was in jeder Empfehlung zur Kontingentgestaltung der erste genannte Punkt ist.

4.10 Projekte lassen sich unbegrenzt anlegen

Die Begrenzung von zwanzig Vorgängen pro Minute in dev-api-access.ts hängt an den Token-Endpunkten. Das Anlegen von Projekten und Registrierungen läuft ungebremst. Das ist genau die Karteileichen-Warnung aus RFC 7591, und sie wird ab dem Moment relevant, in dem die Oberfläche diese Endpunkte tatsächlich anbietet.

5. Der Zielablauf

Der Ablauf, der zu den vier Anforderungen passt und dem entspricht, was das Backend bereits kann, hat sieben Schritte. Er ist unten so aufgeschrieben, dass jeder Schritt sagt, was der Entwickler tut und was dabei entsteht.

Schritt 4 ist der, den unser heutiger Ablauf gar nicht hat, und Issue 88 hält ausdrücklich fest, dass er nicht stillschweigend übersprungen werden darf. Er ist auch die Stelle, an der die Anforderung nach einem beantragten Token für den Free Tier ihren natürlichen Platz findet: eine Plan-Wahl ist ein Antrag, sie ist nur einer, der sich sofort beantworten lässt, solange der gewählte Plan kostenlos ist.

6. Reihenfolge der Arbeit

Die Reihenfolge folgt Abhängigkeiten, nicht Wichtigkeit. Was weiter oben steht, blockiert das darunter.

7. Geprüfte Code-Belege

Quellennachweis

Sieben Quellen, in der Reihenfolge ihres Auftretens.

1. DigitalAPI, MuleSoft und API7 (2026): Zusammenfassende Empfehlungen zum Aufbau von Developer Portalen. Ausgewertet über eine Websuche, Kernaussagen zu Ablauf, Reibungsarmut und Bindung von Zugangsdaten an eine Anwendung. über Suchergebnis ausgewertet Quelle↩↩↩
2. MetaBrainz Foundation: MusicBrainz API. Lesender Zugriff ohne Schlüssel, verpflichtender User-Agent mit Kontakt, eine Anfrage pro Sekunde. über Suchergebnis ausgewertet Quelle↩
3. Spotify AB: Quota modes. Development Mode mit fünf freigeschalteten Nutzern, Extended Quota Mode über Fragebogen im Dashboard, Prüfdauer bis zu sechs Wochen, Kriterien seit dem 15. Mai 2025. Volltext gelesen Quelle↩↩
4. Discord Inc.: How Do I Get My App Verified. Verifizierung ab 100 Servern, Entwickler-Team als Voraussetzung, Identitätsprüfung des Team-Eigentümers über Stripe, Wiederholung der Prüfung mit Frist von sechzig Tagen. über Suchergebnis ausgewertet Quelle↩
5. Spotify Community: Extended quota application in review for 7+ weeks. Erfahrungsberichte zu Bearbeitungszeiten und zur zeitweise fehlenden Antragsmöglichkeit. über Suchergebnis ausgewertet Quelle↩
6. Richer, J. (Hrsg.), Jones, M., Bradley, J., Machulak, M. und Hunt, P. (2015): OAuth 2.0 Dynamic Client Registration Protocol. RFC 7591, IETF Standards Track. Client-Metadaten, serverseitig vergebene client_id, Betriebshinweise zu Begrenzung und Aufräumen offener Registrierungswege. über Suchergebnis ausgewertet Quelle↩↩
7. Oracle: API Gateway Usage Plan Entitlement. Modell aus Plan, Berechtigung, Ratenlimit und Kontingent, mit Verhalten bei Überschreitung, Rücksetzregel und übereinanderliegenden Zeitfenstern. über Suchergebnis ausgewertet Quelle↩↩↩