Neuer x402-Listings-Feed

Feed der x402/L402-Dienste, die kürzlich auf 402index.io gelistet wurden – innerhalb eines vom Aufrufer angegebenen Rezenzzeitfensters. NEXUS-Kandidat #8 -- manueller Build, nicht FORGE-generiert, gleiches manuelles Cloud-Run-Asset-Muster wie die Kandidaten #3 (agent-verification-api), #4 (url-metadata-api) und #6 (document-conversion-api).

• POST /new-x402-listings {"window_hours": 24, "protocol": null, "category": null, "payment_network": null} -- Dienste, die innerhalb des Fensters (1-168 h, Standard 24) auf 4022index.io registriert wurden. $0,01/Aufruf.

• MCP-Tool get_new_x402_listings unter /mcp, gleiche Parameter -- derzeit kostenlos, siehe „Bekannte Einschränkungen".

• GET /health, GET /.well-known/agent-card.json, GET /openapi.json (enthält x-payment-info), GET /.well-known/402index-verify.txt (402index-Anspruchs-Verifizierungsdatei).

Was dies ist (und was nicht)

Dies sind keine exklusiven Daten. Die diesem Asset zugrunde liegenden Registrierungsdaten stammen aus dem eigenen kostenlosen, öffentlichen Verzeichnis von 402index.io (https://402index.io/api-docs, ohne Authentifizierung, 100 req/min im kostenlosen Tarif). Jeder kann sie direkt und kostenlos abfragen. Der Wert dieses Assets liegt vollständig in der Verpackung: Abfragen und Paginieren des Katalogs mit ~96.000+ Einträgen, sodass ein Käufer dies nicht selbst tun muss, Einbinden von 402index' eigenem Rezenz-Feed für Aktualität, Deduplikation und Filterung nach Fenster/Protokoll/Kategorie/Zahlungsnetzwerk des Aufrufers. Dieser Hinweis steht nicht nur in dieser README – er ist im Produkt selbst verankert: Jede Antwort enthält ein note-Feld, das dies klar angibt, und das protocol_note der Agent-Card wiederholt es, sodass ein Käufer nie danach suchen muss.

Related MCP server: x402-discovery

Machbarkeitsuntersuchung (2026-08-23, vor dem Schreiben von Code)

Die Prämisse des Aufgabenauftrags bezog sich auf eine frühere Sitzungszahl von „~7.595 Diensten insgesamt" auf 402index.io. Ein echtes curl https://402index.io/api/v1/services?limit=5 zu Beginn dieser Sitzung zeigte total: 96093 – der Katalog ist seit dieser Prüfung um etwa das 12-fache gewachsen. registered_at ist real und bei jedem untersuchten Eintrag vorhanden. Zwei upstream-Mechanismen wurden live verifiziert, jeweils mit einer echten Einschränkung, die weder der Aufgabenauftrag noch 402index's eigene Doku vollständig aufzeigten:

1. GET /api/v1/services (paginiert, limit/offset, max. 200/Seite) hat KEINEN Sortier-vor-Datum- oder Datumsbereichfilter – sort akzeptiert nur name/price/latency/uptime/reliability (direkt in /api-docs geprüft). Eine Fensterabfrage kann nur durch Durchlaufen des gesamten Katalogs und clientseitigem Filtern beantwortet werden – es gibt keinen günstigeren serverseitigen Pfad. Bei der tatsächlich aktuellen Größe sind das ~481/482 Sekunden, nicht die ~40 Sekunden, die die ~7.595-Zahl impliziert hätte.

2. GET /feed.xml?type=new ist echt, RSS 2.0 und bereits nach Aktualität sortiert (pubDate) – und steht auf 402index Scheibe eigener dokumentierter, vom Rat-Limit ausgenommener Liste. Aber es ist auf eine feste Element-Anzahl begrenzt: Ein Live-Abruf während dieser Sitzung lieferte genau 90 Elemente, die nur ~3 s abdeckten, obwohl die Doku type=new als „Dienste, die in den letzten 7 Tagen hinzugefügt wurden" beschreibt. Bei der aktuellen Registrierungsgeschwindigkeit deckt es allein kein 7-Tage-Fenster (oder selbst bei einem 24-h-Fenster bei Spitzengeschwindigkeit) ab.

Keine der beiden Quellen erfüllt allein ehrlich das beworbene Fensterspektrum des Produkts. Entscheidung: beide verwenden. Siehe das Modul-Docstring von main.py und „Architektur" (Mt weiter unten), wie sie kombiniert werden. Diese Art von realer, aktueller Datenabweichung soll CLAUDE.md SS3 an die Oberfläche bringen, anstatt stillschweigend daran vorbeizubauen – sie wird daher hier festgehalten und nicht nur in einem Chat-Transkript.

Architektur

• Eine Hintergrund-asyncio-Task (gestartet in FastAPIs lifespan, blockiert den Start nicht) durchläuft den vollständigen /api/v1/services-Katalog alle NEXUS_CATALOG_REFRESH_SECONDS (Standard 600 s/10 min), mit 0,65 s/Anfrage getaktet (~92 req/min dauerhaft, Sicherheitsmarge unter dem 100-req/min-Free-Tier-Limit von 402index). Die Ergebnisse werden im Arbeitsspeicher zwischengespeichert (_catalog_cache), je Dienst-ID keyed. Ein vollständiger Durchlauf der aktuellen Kataloggroße ist ~481/482 Seiten / ~5,2 Minuten – vollständig eine Kosten des Hintergrundtasks, niemals inline in einer Käuferanfrage.

• Jede Käuferanfrage ruft zusätzlich live /feed.xml?type=new ab (vom Rate-limit ausgenommen, ~1 Anforderung, günstig) und führt es in das zwischengespeicherte Ergebnis der Hintergrund-Ausführung zusammen, wodurch alles erfasst wird, was nach dem letzten abgeschossenen Lauf registriert wurde. Cache-Einträge gewinnen bei ID-Konflikt (reichhaltigere Felder); Feed-Einträge schließen nur Lücken.

• Die Antwort wird aus diesem Merge gefiltert/dedupliziert/sortiert (neueste zuerst), auf 500 Ergebnisse begrenzt.

Warum kein wörtlicher TTL-Cache (Abweichung von der im Aufgabenauftrag vorgeschlagenen Form)

Der Auftrag schlug „einen kurzen In-Memory-Cache (5-10 min TTL)" vor. Stattdessen implementiert: eine kontinuierlich laufende Hintergrundschleife, die über alle 10 Minuten neu läuft und den Cache ersetzt, wobei Käuferanfragen immer das lesen, was derzeit zwischengespeichert ist (niemals einen Lauf selbst auslösen). Ein wörtlicher On-Demand-Be-refresh-TTL würde bedeuten, dass diejenige Käuferanfrage, die zufällig nach dem Ablauf eintrifft, $0,01 bezahlt und dann bis zu den Wartbaren ~5 Minuten blockiert, während ein neuerer 481-Seiten-Lauf mit dem vollständigen Katalog ausgeführt wird – ein in der Designphase-- gefundener, nicht retroaktiv entdeckter – untragbarer Käufer-Erlebnis. Die Hintergrundschleifen-Form erreicht dasselbe „402index.io nicht überlasten"-Ziel, ohne dass ein zahlender Aufrufer jemals auf den Lauf warten müsste.

KalstStart (Cloud-Run-Scale-to-zero)

min-instances=0 bedeutet, dass ein neuer Container mit einem leeren Cache startet. Die erste(n) Anfrage(n) nach jeder Inaktivitätsphase erhält einen catalog_walk.status: "cold_fallback_feed_only" – die Ergebnisse sind auf das begrenzt, was /feed.xml?type=new derzeit enthält (zuletzt beobachtet, dass dies nur wenige Stunden abdeckt), nicht das vollständige angefragte Fenster. Dies wird im eigenen note-Feld der Antwort offengelegt, nicht versteckt. Sobald der erste Lauf der Hintergrundauftrag abgeschlossen ist (~5 Minuten nach Serverstart), erhalten nachfolgende Anfragen den Status "warm" mit vollständiger Katalogabdeckung. Echtiermitigiert, nicht gelöst – siehe „Bekannte Einschränkungen".

Preisgestaltung: $0,01/Aufruf (niedrige Stufe)

Spekulativenspezifisches Nische laut Produktbesitzer (explizite Vorgabe, keine datengetriebene Schlussfolgerung) – gleiches niedriges Niveau wie url-metadata-api/document-conversion-api mit $0,01-$0,02, nicht die $0,35-Signalstufe von agent-verification-api. Keine kostenpflichtigen Drittanbieter-API-Kosten, reine CPU/Arbeitsspeicher plus wird ein kostenloser Upstream-Abruf pro Aufruf.

Qualitäts-Gate vor Bereitstellung (2026-08-23, aus dem Design stammend, nicht retroaktiv)

Vor der ersten Bereitstellung anhand von 4 Püfbereichen bewertet und bei jedem Schritt gegen die echte Live-402index.io-Schnittstelle (nicht simuliert) getestet. Echte Ergebnisse und Korrekturen:

• Security: Die Aufrufereingaben (window_hours/protocol/category/payment_network) werden nie in die Upstream-Anforderung von 402index.io hineininterpoliert – der Kataloglauf und der Feed-Abruf verwenden nur feste, hartkodierte Abfrageparameter (limit/offset/sort/order bzw. type=new); Aufruferfilter wirken ausschließlich auf das bereits abgerufene, normalisierte In-Memory-Ergebnis. Verifiziert, dass Upstream-JSON/XML niemals blind vertraut wird: Jedes Feld wird über .get() mit Typ-Prüfungen gelesen (_normalize_catalog_item gibt bei einem fehlerhaften Eintrag None zurück, statt einen Fehler zu werfen), fehlerhaftes XML von /feed.xml wird abgefangen (ET.ParseError), statt die Anfrage zum Absturz zu bringen, und ein einzelnes fehlerhaftes <item> im Feed lässt den Rest nicht untergehen. All das wurde während Sitzung mit realen Fehlertests bestätigt (None, fehlende id, falsche Typen, Garble-Zeitstempel, abgeschnittendes XML), nicht nur als korrekt gelesen.

• Funktionale Korrektheit (reale Lücke, behoben): Das anfängliche Design hat complete: bool intern zwischengespeichert, es aber nie in der Antwort nach außen gezeigt – ein Aufrufer hatte keine Möglichkeit, einen Hintergrundlauf, der die _WALK_MAX_WALL_SECONDS-Wanduhrgrenze überschritt (mit Teilergebnis abgebrochen), von einem sauber abgeschlossenen zu unterscheiden, obwohl beide status: "warm" als positiven. Behoben: catalog_walk.walk_complete zur Antwort hinzugefügt. Die Pagination selbst (Offset-Weiterrücken, Stopp-gesamt, Wanduhr-Abbruch) wurde live gegen die reale API mit einem eingegrenzten Testlauf verifiziert (8 echte Seiten, Offset korrekt , sauberer Abbruch protokolliert) – keine stille Abschneidung, keine Endlosschleifen.

• Codequalität: Kein toter Code und keine unbenutzten Importe in der Überprüfung gefunden; entspricht der Struktur der Schwester-Assets (Supabase-Telemetrie-Helfer, x402-Verdahaltung, Discovery-Routen) von Hand portiert wird, konsistent mit dem Aufbau von document-conversion-api/url-metadata-api.

• Käufer-Erfahrung (die „Rohdaten sind andervärts kostenlos"-Offenlegungsbrille): Die Tatsache, dass die Daten von 402index selbst kostenlos sind, wurde an 3 Stellen verifiziert, nicht nur in der README: in protocol_note der Agent-Card und – direkter, damit kein Käufer die Agent-Kern überhaupt abrufen muss – im note-Feld jeder einzelnen API-Antwort. Der Zustand mit eingeschränkter Abdeckung bei kaltem Cache (cold_fallback_feed_only) wird ebenfalls im selben note-Feld in klaren Worten offengelegt, was dies für das angeforderte Fenster bedeutet – und nicht nur als Statuten-Enum, das ein Aufrufer bereits interpretieren können muss.

Bekannte Einschränkungen (als dokumentierte Trade-offs belassen, nicht stillschweigend)

• MCP-Tool-Aufrufe werden nicht berechnet. Gleiches In-Process-Aufrufmuster wie die manuellen Schwester-Assets.

• Keine Ratenbegrenzung pro Aufrufer. Für ein 7-Tage-Wegwerf-Messfenster in Ordnung.

• ** Unterdeckung des Fensters bei kaltem Cache ist abgemildert, nicht gelöst.** Eine Anfrage in den ersten ~5 Minuten nach einem Cloud-Run-Kaltstart erhält oltre die Feed-allein-Abdeckung (zuletzt beobachtet ~3h-Spanne für einen 90-Element-Feed bei der aktuellen 402index-Geschwindigkeit), nicht das volle angeforderte Fenster, obwohl dieselben $0,01 berechnet werden. Dies wird live in der Antwort offengelegt, aber ein Käufer, der nur einmal gleich nach einem Cold-Start aufruft und catalog_walk.status/note nicht liest Lesen, könnte eine kurze Ergebnisliste zu verstehen als „nichts Neues" statt „Cache wärmt gerade auf". Eine zukünftige Lösung könnte min-instances=1 halten, um Cold-Starts vollständig zu eliminieren, zu einem echten immer aktiven Cloud-Run-Preis – für einen 7-Tage-Bewährungskandidaten nicht umgesetzt.

• registered_at wird als UTC angenommen. /api/v1/services von 402 geht naive Zeitstempel zurück ("2026-08-22 22:13:15", ohne Offset) – wird als UTC behandelt, basierend auf Konsistenz mit last_checked-Werten, die während der Sitzung live beobachtet wurden, nicht auf dokumentierten Garantie von 402index.io.

• Die Gehgeschwindigkeit des vollständigen Katalographik-Durchgangs setzt die heutige Kataloggröße voraus. Mit ~96k+ Einträgen erfordert ein vollständiger Lauf ~5-5,5 Minuten und liegt liegt sicher innerhalb des 10-Minuten-Refresh-Intervalls. Wenn der Katalog von 402 weiter wächst – in der in dieser Sitzung beobachteten Größen (seit der letzten Prüfung) – könnte ein zukünftiger Lauf das 10-Minuten-Aktualisierungsintervall erreichen oder überschreiten (dann dauert es nur länger zwischen den sichtbaren „last_full_walk_at"-Aktualisierungen, es bricht nicht – _WALK_MAX_WALL_SECONDS bricht einen einzelnen Zyklus bei 900 s ab und walk_complete gibt die auf ehrlich an) – wird nicht präventiv neu entworfen gemäß CLAUDE.md leer (kein Gate ohne Beweis, dass es sie braucht).

NEXUS_X402_FREE_MODE

Standardwert false (Berechnung ab Tag 1, ohne Freemium-Fenster ist Standardwert false – gleiche Konvention wie document-conversion-api). Für lokale Tests auf true setzen, ohne echte Fikator-Roundtrip.

Bereitstellungsziel: Cloud Run, nicht Railway

Gleiche Pipeline wie Kandidaten #3/#4/#6 – siehe skills/infra-deploy-ops. Keine PDF-/Office-Parsierung hier, daher wird der Standard-512Mi des gemeinsamen Skripts verwendet (nicht auf 1Gi erhöht wie bei document-conversion-api).

# 1. First deploy -- PUBLIC_DOMAIN not known yet, every real request 421s until step 2.
./scripts/deploy_cloud_run.sh new-x402-listings-feed manual_assets/new-x402-listings-feed \
    manual_assets/new-x402-listings-feed/env-vars.deploy.yaml

# 2. Grab the printed *.run.app URL, then:
gcloud run services update new-x402-listings-feed --region us-central1 --project nexus-505016 \
    --update-env-vars PUBLIC_DOMAIN=<the-real-domain>

Messung (Kandidat #8, 7-Tage-Fenster)

7-Tage-Fenster ab der ersten tatsächlichen Bereitstellung (2026-08-23 -> Entscheidungspunkt 2026-08-30). Quelle der Fakten: Tabellen traffic_events/revenue_events/mcp_call_events (asset_name = 'new-x402-listings-feed'), nicht Cloud-Run-Protokolle. Tag 7: Wenn null echter Datenverkehr (Crawler herausgefiltert), Cloud-Run-Dienst pausieren/löschen, gleiche Entscheidungsregel wie Kandidaten #3/#4/#6. Dies ist ausdrücklich der spekulativendste der 4 manuellen Kandidaten (eigene Formulierung des Produktbesitzers) – ein Nischenvorfindungs-Feed für ein noch junge x402-Ökosystem, kein bewährtes Muster mit wiederkehrender Nachfrage wie Dokumentenkonvertierung oder Linkvorschauen.