Authentification et routes disponibles
Les routes de récupération utilisent GET sur https://api.redditapihub.com. Transmettez X-API-Key: <clé> ou Authorization: Bearer <clé> ; les deux en-têtes sont acceptés. Conservez le secret sur votre serveur. Le panneau du compte utilise une session avec cookie Secure HttpOnly, distincte de l’authentification nécessaire aux requêtes de récupération de votre application.
/v1/search recherche publications et commentaires ; /v1/posts se limite aux publications et /v1/comments aux commentaires. Ces routes n’acceptent pas id comme filtre. Pour un identifiant connu, /v1/item?id=... recherche un enregistrement individuel. Cette opération ne parcourt pas automatiquement ses réponses, ses descendants ou ses ancêtres et ne promet pas de retrouver le message demandé.
/v1/subreddits accepte prefix et limit pour découvrir des communautés. prefix n’est pas un filtre des routes de contenu. Les comptages de communautés ne constituent pas un recensement global garanti. /v1/status est public et non facturé : il décrit statiquement le service et confirme que l’application HTTP répond, sans sonder le moteur de recherche ni vérifier la disponibilité des données archivées.
Filtres et structure des réponses
Les paramètres de search, posts et comments sont q, subreddit, author, kind, from, to, min_score, limit et page. kind accepte les valeurs littérales post et comment. q effectue une recherche textuelle, sans langage arbitraire de requêtes ni classification des sentiments. Choisissez les filtres en tenant compte des messages qu’ils peuvent exclure alors que votre analyse en aurait besoin pour comprendre une réponse.
from et to utilisent YYYY-MM-DD en UTC et s’appliquent à created_utc. Le jour indiqué par to est inclus entièrement. Ces paramètres n’acceptent ni heures ni secondes et ne désignent pas le moment d’entrée dans l’archive. min_score définit un seuil numérique de score, sans trier les résultats et sans sélectionner automatiquement les résultats les plus utiles pour votre application.
Les réponses de contenu sont des enregistrements plats. Les champs parent_id et link_id peuvent être présents ; ils permettent un regroupement local, sans garantie de discussion complète et sans filtres de requête pour ces identifiants. La réponse comprend data, pagination et credits. Dans le catalogue, les entrées comportent subreddit et count ; ce nombre ne garantit pas un recensement global exact. Le total de pagination du catalogue vaut null avec relation=unknown, sans total fiable à en déduire.
Pagination, erreurs et coût des tentatives
Sur /v1/search, /v1/posts et /v1/comments, limit et page acceptent des valeurs de 1 à 100. L’ordre interne _doc ne garantit aucun tri chronologique, par pertinence ou par score. Le catalogue /v1/subreddits n’accepte pas page. Trier les données reçues ou diviser les dates ne démontre ni exhaustivité, ni unicité, ni stabilité entre plusieurs requêtes.
Lisez pagination.total avec relation : eq indique un total exact pour la requête, gte une borne inférieure et unknown l’absence d’un total fiable, éventuellement null. Ne remplacez pas inconnu par zéro. Même un total exact ne prouve pas que tous les résultats ont été téléchargés ni que l’archive contient toute l’histoire. Conservez aussi les indicateurs de pagination renvoyés pour décrire les limites rencontrées.
HTTP 400 indique des paramètres invalides, 401 une clé absente ou invalide, 402 un solde insuffisant et 429 une limite de fréquence. Une récupération réussie, même vide, coûte un crédit. Les requêtes invalides ne débitent pas le compte ; les échecs du service source restituent la réservation. Une perte de réponse côté client peut suivre une réussite facturée. Une nouvelle tentative réussie coûte un autre crédit ; enregistrez les réponses avant de mettre à jour votre progression.
