Grundlagen der Archivabfrage und Datenstruktur
Die API bietet einen direkten Zugriff auf historische Reddit-Archive, die als unabhängige Sammlung ohne Verbindung zu Reddit als Live-Dienst fungieren. Sie ist speziell für Community-Intelligenzanalysten konzipiert, die quantitative Daten für Vergleiche auswerten möchten. Die Struktur der Antwort besteht aus flachen Datensätzen, was bedeutet, dass hierarchische Thread-Navigationen nicht serverseitig zusammengefügt werden.
Jede Anfrage an das System liefert eine Liste von Elementen zurück, die als flache Objekte vorliegen. Clients können diese Daten zwar lokal gruppieren, wenn Felder wie parent_id oder link_id vorhanden sind, dies gewährleistet jedoch nicht die Vollständigkeit einer gesamten Konversation oder Vorfahrenkette. Es gibt auch keine serverseitigen Filter, die explizit nach parent_id oder link_id suchen lassen, was die Interpretation der Datenstruktur beeinflusst.
Die Abfrage liefert Ergebnisse in der internen Dokumentreihenfolge _doc. Das ist weder eine chronologische Sortierung noch eine Rangfolge nach Relevanz oder Punktestand. Eine früh angezeigte Fundstelle ist daher nicht automatisch aktuell oder besonders wichtig. min_score setzt nur eine numerische Untergrenze und verändert diese Reihenfolge nicht. Auch eine spätere Abfrage mit denselben Bedingungen muss nicht dieselben Datensätze liefern.
Filter, Paginierung und Datentypen
Die Inhaltsrouten unterstützen q, subreddit, author, kind, from, to, min_score, limit und page. kind akzeptiert post oder comment. from und to verwenden YYYY-MM-DD für created_utc in UTC; der angegebene Endtag to wird vollständig eingeschlossen. min_score ist ausschließlich ein Filter und keine Sortierung nach Punktestand. Pro Anfrage sind höchstens 100 Datensätze und pro Abfrage höchstens 100 Seiten möglich. Diese Grenzen müssen auch bei einer Aufteilung nach Zeiträumen berücksichtigt werden.
Die Parameter-ID ist ein spezielles Feld, das nur für die Ermittlung spezifischer Elemente über die Route /v1/item erforderlich ist. Die Endpunkte /v1/posts und /v1/comments benötigen hingegen keine ID, was die Abfrage von Sammlungen oder Listen von Inhalten erheblich erleichtert. Die Gesamtanzahl der Ergebnisse variiert: Sie kann genau sein, eine untere Schranke darstellen oder unbekannt, was eine vorsichtige Interpretation der Paginierung erfordert.
Die Paginierung garantiert nicht, dass alle übereinstimmenden Datensätze durch Iteration über die Seiten erfasst werden. Die Bounded-Page-Iteration schließt keine vollständige Erfassung der Datenbasis aus. Nutzer müssen bedenken, dass eine untere Schranke nicht als exakte Zählung zu verstehen ist. Die Architektur ist darauf ausgelegt, große Datenmengen effizient zu durchsuchen, ohne eine vollständige Exportgarantie zu bieten, da nicht alle Datensätze garantiert vollständig sind.
Fehlercodes, Status und Abrechnungslogik
Die API verwendet HTTP 400 für ungültige Parameter, 401 für fehlende oder ungültige Schlüssel, 402 für unzureichendes Guthaben und 429 für eine überschrittene Anfragerate. Ungültige Anfragen buchen keinen Credit ab. Ein Fehler der vorgelagerten Quelle gibt den reservierten Credit zurück. Davon zu unterscheiden ist eine verlorene Clientantwort nach einem erfolgreichen, bereits berechneten Abruf: Eine erfolgreiche Wiederholung kostet einen weiteren Credit. Der öffentliche Status-Endpunkt wird nicht berechnet.
Jeder erfolgreiche Abruf kostet einen Credit, auch wenn das Ergebnis leer ist. Das zählt Anfragen, nicht gelieferte Datensätze, und belegt keinen exakten Gesamtumfang. Bei den Ergebnistotalen bedeutet eq einen exakten Wert für die Antwort, gte eine Untergrenze und unknown einen unbekannten Wert, der null sein kann. /v1/status liefert nur eine statische Dienstbeschreibung und bestätigt die HTTP-Antwort. Der Endpunkt prüft weder die Suchquelle noch die Verfügbarkeit bestimmter Datensätze.
Der Preis beträgt $1 für 1000 erfolgreiche Abrufe. Die Mindestaufladung von $50 ergibt 50000 bezahlte Credits, die nicht verfallen; ein Abonnement ist nicht erforderlich. Mögliche 100 Testcredits hängen von der netzwerkweiten Missbrauchskontrolle ab und sind nicht für jedes Konto garantiert. Für USDT auf TRON TRC20 oder USDC auf Ethereum mainnet ERC20 sind der Empfänger und der genaue Betrag der aktuellen, nach Anmeldung erstellten Serverrechnung maßgeblich.
