Gemini API Key richtig testen, bevor ein WordPress Plugin umgebaut wird
Bei technischen Entscheidungen geht es oft nicht nur um Code. Es geht um Annahmen. Eine kleine Annahme kann harmlos wirken. Wenn sie aber falsch ist, kann daraus schnell ein grosser Umbau entstehen.
Genau das ist bei der Einrichtung der KI Funktionen im Car Market Hub WordPress Plugin passiert. Es ging nicht darum, ob der KI Assistent gute Fahrzeugtexte schreiben kann. Es ging auch nicht zuerst um Prompts, Modelle oder Textqualität. Das eigentliche Problem lag viel tiefer. Es lag in der Frage, welcher Gemini API Key genutzt wird, welchem Rechnungskonto dieser Key zugeordnet ist und ob der direkte Weg über Google AI Studio wirklich sauber funktioniert.
Am Ende zeigte sich, dass kein grosser Umbau nötig war. Der bestehende Weg konnte weiter genutzt werden. Trotzdem standen vorher mehrere Stunden Tests, Fehlermeldungen, neue Architekturideen und Unsicherheit im Raum. Der Fall zeigt sehr gut, warum man bei API Problemen immer den kleinsten technischen Baustein zuerst prüfen muss.
Ausgangspunkt war ein Problem mit der Abrechnung
Die Gemini API Keys waren bereits in Google AI Studio angelegt. Sie waren im System hinterlegt und grundsätzlich funktionsfähig. Das Problem war also nicht, dass noch kein Zugriff auf Gemini vorhanden war.
Das eigentliche Problem lag bei der Zuordnung der Rechnungskonten. Google hatte die API Keys offenbar einem falschen Rechnungskonto zugeordnet. Damit lag die Abrechnung plötzlich nicht dort, wo sie liegen sollte. Für ein Produkt wie das Car Market Hub WordPress Plugin ist das ein kritischer Punkt. Wenn Kunden später KI Funktionen nutzen, muss klar sein, über welches Konto die Kosten laufen und wie diese Kosten intern kontrolliert werden.
Aus dieser Situation entstand der Gedanke, die Verwaltung stärker über die Google Cloud Console zu zentralisieren. Dort sollte ein Projekt sauber eingerichtet werden. Auch ein Dienstkonto spielte dabei eine Rolle. Die Überlegung war nachvollziehbar. Wenn Google AI Studio bei der Abrechnung unklar ist, wirkt die Google Cloud Console wie der professionellere Weg.
Für ein kommerzielles Plugin klingt das zunächst richtig. Zentrale Kontrolle, saubere Abrechnung, klare Rechte und eine technische Plattform, die nicht davon abhängt, dass jeder Kunde selbst einen Google Zugang einrichtet.
Die Idee einer zentralen KI Plattform
Der geplante Ansatz war ein Proxy Modell. Das Plugin sollte nicht mehr direkt mit Google sprechen. Stattdessen sollte das Plugin nur noch die eigene ADP API Plattform aufrufen.
Der Ablauf wäre so gewesen. Das Plugin sendet den Prompt an die ADP API Plattform. Die Plattform prüft die Lizenz. Danach prüft sie, ob KI für diesen Kunden erlaubt ist. Anschliessend ruft die Plattform Google über ein Dienstkonto auf. Die Antwort wird an das Plugin zurückgegeben. Die Nutzung wird pro Kunde gespeichert.
Das klingt nach einer sehr sauberen Lösung. Für viele SaaS Produkte ist das auch genau der richtige Weg. Kunden sehen keinen Google Key. Die Plattform kann Limits setzen. Die Plattform kann Token Verbrauch speichern. Die Plattform kann später unterschiedliche Modelle steuern. Auch die Abrechnung pro Kunde lässt sich so besser vorbereiten.
Trotzdem hat diese Lösung einen Preis. Sie ist deutlich komplexer. Sie braucht einen neuen Endpunkt. Sie braucht Token Verwaltung. Sie braucht Caching. Sie braucht Logging. Sie braucht Fehlerbehandlung. Sie verändert den Live Pfad des Plugins. Und sie erhöht das Risiko, dass neue Fehler entstehen.
Deshalb muss vor so einem Umbau die wichtigste Frage geklärt sein. Ist der Umbau wirklich nötig?
Der entscheidende Unterschied zwischen Google AI Studio und Vertex AI
Ein grosser Teil der Verwirrung entstand, weil zwei verschiedene Wege vermischt wurden.
Der erste Weg ist der direkte Weg über Google AI Studio und den Gemini API Key. Dieser Weg nutzt den klassischen Gemini API Endpoint. Das ist der Weg, den das Plugin bereits verwenden konnte.
Der zweite Weg ist der Weg über Google Cloud, Dienstkonto, OAuth und Vertex AI. Dieser Weg nutzt eine andere Schnittstelle. Er arbeitet mit anderen URLs, anderen Regionen und einem anderen Sicherheitsmodell.
Diese beiden Wege darf man nicht vermischen. Ein Fehler auf dem einen Weg beweist nicht automatisch, dass der andere Weg nicht funktioniert. Genau hier wurde es schwierig.
Ein Test mit Vertex AI sagt nicht automatisch aus, ob ein Gemini API Key über Google AI Studio funktioniert. Umgekehrt sagt ein funktionierender Gemini API Key nicht automatisch aus, ob der Vertex Weg mit Dienstkonto und OAuth korrekt eingerichtet ist.
Dazu kommt, dass Vertex AI mit Regionen arbeitet. Es gibt globale Endpunkte und regionale Standorte. Je nach Projekt und Modell können andere Pfade relevant sein. Wenn hier nur teilweise getestet wird, entsteht schnell ein falsches Bild.
Der kleine Fehler, der einen grossen Rattenschwanz ausgelöst hat
Im Rückblick war einer der wichtigsten Punkte ein sehr kleiner Fehler. Bei einem Test war offenbar ein Leerzeichen im Spiel. Dadurch entstand eine Fehlermeldung. Diese Fehlermeldung passte zu dem Bild, das sich im Verlauf der Tests immer stärker aufgebaut hatte.
Der Eindruck war, dass der gewünschte Weg nicht funktioniert. Und wenn man mehrere Stunden in einem Chat testet, Fehlermeldungen sieht, wartet, wieder testet und erneut widersprüchliche Ergebnisse bekommt, wird diese Annahme immer stärker.
Genau das ist gefährlich. Ein kleiner Testfehler wirkt dann nicht mehr wie ein kleiner Testfehler. Er wird Teil einer grösseren Geschichte. Diese Geschichte lautete irgendwann, dass der direkte Weg nicht möglich sei und ein kompletter Umbau notwendig werde.
Dabei war der Auslöser sehr wahrscheinlich viel kleiner. Ein falscher Test, ein Leerzeichen, eine unklare Key Zuordnung, eine mögliche Wartezeit bei Google und verschiedene Schnittstellen wurden zu einem einzigen Problem vermischt.
Warum funktionierende Tests trotzdem in die Irre führen können
Besonders schwierig war, dass einige Tests tatsächlich funktionierten. Das macht die Analyse nicht einfacher, sondern schwerer.
Wenn gar nichts funktioniert, ist die Lage klar. Dann sucht man den einen Fehler. Wenn aber manche Tests lokal funktionieren und andere auf Server Ebene nicht, entsteht ein Ping Pong Effekt. Man glaubt, kurz vor der Lösung zu stehen. Dann kommt wieder eine Fehlermeldung. Danach wartet man wegen möglicher Google Propagation. Dann funktioniert ein anderer Test. Dann wird wieder eine andere URL geprüft.
Genau in solchen Situationen muss man extrem streng trennen.
Welche Schnittstelle wurde getestet? Welcher Key wurde verwendet? Welches Rechnungskonto war aktiv? Wurde Google AI Studio getestet oder Vertex AI? War der Test lokal oder auf dem Server? Wurde exakt derselbe Request verwendet? Wurde der Key gerade erst erstellt, wiederhergestellt oder verändert?
Wenn diese Fragen nicht sauber getrennt werden, entsteht kein technisches Ergebnis. Es entsteht nur ein Gefühl. Und dieses Gefühl kann falsch sein.
Die KI Beratung hatte sich festgefahren
Ein weiterer wichtiger Punkt ist die Rolle der KI Beratung selbst. KI kann sehr gut helfen, technische Wege zu strukturieren. Sie kann API Modelle erklären, Fehler einordnen und Architekturvorschläge machen. Aber sie kann sich auch festfahren.
In diesem Fall wurde aus mehreren Fehlermeldungen immer stärker die Aussage abgeleitet, dass der direkte Weg nicht funktionieren werde. Diese Einschätzung wurde dann immer wieder bestätigt, statt neu geprüft zu werden.
Das Problem dabei ist nicht, dass ein KI Assistent einmal falsch liegt. Das passiert. Das eigentliche Problem entsteht, wenn eine frühe Annahme den weiteren Verlauf bestimmt. Dann werden spätere Tests nur noch durch diese Annahme interpretiert.
Wenn der Nutzer sagt, dass ein Weg vielleicht doch funktionieren müsste, sollte diese Möglichkeit ernsthaft geprüft werden. Gerade bei API Themen ist das entscheidend. Ein anderer Endpoint, ein anderer Header, ein aktiver Key oder ein falsches Leerzeichen können das Ergebnis komplett verändern.
Am Ende war es richtig, die laufende Session zu beenden und eine zweite Einschätzung einzuholen. Nicht, weil die erste KI grundsätzlich nutzlos war. Sondern weil die Diskussion festgefahren war. Bei kritischen Architekturentscheidungen ist ein Reset oft sinnvoller als noch eine weitere Stunde im gleichen Denkpfad.
Warum der grosse Umbau geschäftlich riskant gewesen wäre
Ein Umbau auf eine zentrale Proxy Architektur hätte viele neue Teile erzeugt. Diese Teile hätten gebaut, getestet und gewartet werden müssen. Ausserdem hätte sich der Live Pfad des Plugins verändert.
Für ein kommerzielles WordPress Plugin ist das kein kleiner Eingriff. Der KI Assistent ist Teil eines grösseren Produktes. Wenn der Aufruf der KI Funktion nicht mehr direkt funktioniert, betrifft das Fahrzeugbeschreibungen, SEO Metadaten, Bild Alt Texte und Highlights. Damit betrifft es Funktionen, die für Händler direkt sichtbar sind.
Noch wichtiger ist die geschäftliche Seite. Ein unnötiger Umbau kostet Zeit. Er kostet Fokus. Er erzeugt neue Fehlerquellen. Er verzögert andere Produktbereiche. Und er kann dazu führen, dass ein System komplizierter wird, obwohl die einfache Lösung bereits funktioniert.
Besonders kritisch ist, dass ein solcher Umbau später möglicherweise wieder als falsche Lösung bewertet worden wäre. Es ist gut vorstellbar, dass eine spätere Code Prüfung ergeben hätte, dass der direkte Gemini API Key Weg einfacher und besser gewesen wäre. Dann hätte man zuerst aufwendig umgebaut und danach wieder zurückgedacht.
Das wäre für ein Geschäft gravierend. Nicht wegen eines einzelnen API Tests. Sondern weil falsche Architekturentscheidungen fast immer Folgekosten erzeugen.
Was am Ende wirklich funktionierte
Am Ende musste nichts Grosses umgebaut werden. Der direkte Weg über den Gemini API Key funktionierte. Entscheidend war, den echten Pfad des Plugins sauber zu prüfen.
Der erfolgreiche Test lief nicht über das Dienstkonto JSON. Er lief nicht über den neuen Vertex Testpfad. Er lief über den bestehenden Plugin Weg mit dem Gemini API Key.
Damit wurde klar, dass der Live Pfad des Plugins grundsätzlich tragfähig ist. Die JSON Datei war für diesen Erfolg nicht beteiligt. Sie gehört zu einem anderen Testpfad. Dieser Testpfad kann weiterhin relevant sein, wenn später eine zentrale Enterprise Architektur gebraucht wird. Für das konkrete Problem war er aber nicht der Grund, warum der KI Assistent funktionierte.
Der wichtigste Unterschied lag also nicht im Plugin Code. Er lag in der korrekten Prüfung des richtigen Weges.
Wann ein Proxy trotzdem sinnvoll ist
Das bedeutet nicht, dass ein Proxy Modell grundsätzlich falsch ist. Im Gegenteil. Es gibt sehr gute Gründe für einen Proxy.
Ein Proxy ist sinnvoll, wenn alle Kunden über eine zentrale Plattform abgerechnet werden sollen. Er ist sinnvoll, wenn Kunden keinen eigenen Gemini API Key hinterlegen dürfen. Er ist sinnvoll, wenn Nutzungslimits serverseitig kontrolliert werden müssen. Er ist sinnvoll, wenn ein Anbieter verschiedene Modelle zentral verwalten will. Er ist auch sinnvoll, wenn Compliance Anforderungen oder Datenresidenz eine bestimmte Google Cloud Architektur verlangen.
Für den Car Market Hub kann so ein Modell später durchaus interessant sein. Es wäre dann aber eine bewusste Produktentscheidung. Es wäre kein Notumbau, der aus einer Fehlermeldung entsteht.
Genau das ist der Unterschied. Ein Proxy als strategische Plattformentscheidung ist etwas anderes als ein Proxy, weil ein falsch getesteter Gemini API Key angeblich nicht funktioniert.
Die wichtigste Lehre aus diesem Fall
Die wichtigste Lehre ist einfach, aber entscheidend.
Teste zuerst die kleinste Annahme.
Nicht die ganze Architektur. Nicht sofort den kompletten Umbau. Nicht direkt das neue Dienstkonto Modell. Sondern den kleinsten Baustein, auf dem die Entscheidung basiert.
In diesem Fall hätte die zentrale Frage lauten müssen, ob ein aktiver Gemini API Key am echten Gemini API Endpoint mit dem bestehenden Plugin Pfad funktioniert. Erst wenn diese Frage sauber beantwortet ist, kann man entscheiden, ob ein Umbau nötig ist.
Dazu gehört auch, Fehler sehr genau zu lesen. Ein Fehler wegen eines Leerzeichens ist kein Architekturproblem. Eine falsche Rechnungskonto Zuordnung ist kein Beweis dafür, dass ein API Key technisch nicht funktioniert. Ein Vertex Fehler ist kein Beweis dafür, dass Google AI Studio nicht funktioniert. Ein lokaler Erfolg ist kein Beweis dafür, dass der Serverpfad korrekt ist.
Gute technische Arbeit bedeutet, diese Dinge zu trennen.
Fazit
Der Fall zeigt, wie schnell aus einem kleinen technischen Problem eine grosse Architekturentscheidung werden kann. Die Gemini API Keys waren vorhanden. Das eigentliche Problem lag bei Rechnungskonten, Testpfaden, Schnittstellen und einer falschen Grundannahme.
Aus dieser Mischung entstand fast ein grosser Umbau des WordPress Plugins. Am Ende war dieser Umbau nicht nötig. Der direkte Weg über den Gemini API Key funktionierte, sobald der richtige Pfad sauber geprüft wurde.
Das ist die eigentliche Lehre. Bei API Problemen darf man sich nicht zu früh auf eine Erklärung festlegen. Man muss den kleinsten Test isolieren, den echten Endpoint nutzen, lokale und serverseitige Tests trennen und Fehlermeldungen nicht zu schnell verallgemeinern.
Ein Gemini API Key, der falsch getestet wurde, ist kein Beweis für eine falsche Architektur. Und eine KI Beratung, die sich in einer Annahme festfährt, sollte nicht die alleinige Grundlage für geschäftskritische Entscheidungen sein.
Für Entwickler, Agenturen und SaaS Betreiber ist dieser Fall deshalb wertvoll. Er zeigt, dass technisches Urteilsvermögen nicht nur bedeutet, eine Lösung bauen zu können. Es bedeutet auch, rechtzeitig zu erkennen, wann man etwas gar nicht bauen muss.
