Das Problem mit API-Schlüsseln, die nie ablaufen
Ein Schlüssel, der vor Jahren ausgestellt, nie rotiert wurde und heute noch gültig ist, ist keine Bequemlichkeit. Er ist ein Risiko, das sich seit Jahren niemand mehr angesehen hat.
Warum Sandbox-Umgebungen kostenlos sein sollten
Manche APIs bieten eine Sandbox-Umgebung, die funktional von der Produktion getrennt ist: andere Schlüssel, manchmal andere Endpunkte, gelegentlich eine eigene Preisstruktur oder eigene, strengere Limits. Die Absicht ist vernünftig: Entwicklern einen sicheren Raum zum Testen zu geben, ohne echte Nutzung oder echte Abrechnung zu berühren. In der Praxis bringt eine Sandbox, die einen eigenen Registrierungsschritt, einen eigenen Schlüssel oder ein eigenes kostenpflichtiges Upgrade erfordert, Reibung genau in den Moment, in dem ein Entwickler zu entscheiden versucht, ob Ihre API die Reibung überhaupt wert ist.
Wir betreiben keine separate Sandbox. Tests und Produktion nutzen dasselbe kostenlose Tageskontingent: 2.500 Anfragen pro Tag von jeder Adresse ohne Schlüssel und weitere 2.500 pro Tag, sobald Sie einen Schlüssel hinzufügen, gezählt pro Netzwerk. Es gibt keinen separaten Testmodus mit eigenen Limits, die man lernen müsste, und keine kostenpflichtige Stufe, die ernsthafte Tests hinter einem Kauf versteckt. Wogegen Sie während der Evaluierung bauen, ist genau dasselbe System, auf dem Sie auch produktiv gehen, mit genau demselben kostenlosen Kontingent, bevor Sie jemals einen Euro ausgeben.
Das ist wichtig, weil eine Sandbox, die sich auch nur geringfügig anders verhält als die Produktion, die Sandbox testet und nicht Ihre Integration. Wenn eine separate Sandbox vereinfachte oder gefälschte Antwortdaten statt des echten Datensatzes verwendet, erfahren Sie von den Eigenheiten realer Daten erst nach dem Livegang, was einen großen Teil dessen zunichtemacht, was Tests eigentlich aufdecken sollen. Gegen das echte System zu testen, mit echten Daten und dem echten kostenlosen Kontingent, bedeutet, dass das, was Sie während der Evaluierung lernen, auch tatsächlich für das gilt, was Sie in der Produktion betreiben werden.
Es kostet uns etwas, den Sandbox-Zugang nicht hinter einen separaten kostenpflichtigen Schritt zu stellen: Ein Teil dieses kostenlosen Test-Traffics wird nie zu einem zahlenden Konto, derselbe Kompromiss wie bei jeder großzügigen kostenlosen Stufe. Wir halten diese Kosten für gerechtfertigt, denn die Alternative setzt genau den falschen Anreiz für einen Entwickler, der entscheidet, ob er überhaupt gegen Ihre API bauen soll. Ein kostenpflichtiger oder stark eingeschränkter Testmodus verlangt von jemandem eine finanzielle Verpflichtung, bevor er weiß, ob das Produkt zu seinem Anwendungsfall passt. Ein kostenloser, voll funktionsfähiger Testweg lässt diese Entscheidung nach sachlichen Kriterien fallen, nachdem man es tatsächlich ausprobiert hat.
Das bedeutet nicht, dass Tests überhaupt keine Grenzen haben. Dieselben 2.500 Anfragen pro Tag, die eine leichte Produktionsnutzung abdecken, decken auch Tests ab, und ein großer Lasttest gegen dieses Kontingent stößt an dieselbe Obergrenze wie eine kleine Produktionsintegration. Das ist beabsichtigt. Die kostenlose Stufe ist großzügig genug für eine echte Evaluierung, aber nicht unendlich, und sie als dauerhafte Testumgebung für ein Produkt mit hohem Volumen zu nutzen, ist etwas anderes, als mit ihr zu bestätigen, dass eine Integration funktioniert, bevor man zur bezahlten Nutzung wechselt.
Eine Sandbox sollte eine Frage ehrlich beantworten: Funktioniert das so, wie ich es erwarte, mit dem echten System? Für diese Antwort Geld zu verlangen oder sie mit etwas anderem als dem echten System zu beantworten, verfehlt in beiden Fällen den Zweck.