Réponse rapide
Comment vérifier que LLMWebSearch fonctionne ?
Appelez GET https://llmwebsearch.com/api/v1/credits avec votre clé. C'est gratuit, cela ne touche aucun site web, et une réponse JSON normale prouve que l'API LLMWebSearch, votre clé et votre compte fonctionnent. Lancez ensuite une requête, qui coûte 1 crédit d'un pack à partir de 1,20 $US/1K requêtes. Les erreurs de notre côté ne sont jamais facturées, et les incidents sont datés sur le changelog.
Quel est le health check le plus rapide ?
L'endpoint des crédits. Il répond uniquement de notre côté : authentification, API et votre compte. S'il renvoie vos crédits restants, le service est opérationnel pour vous. S'il renvoie 401, la clé est erronée ou révoquée ; créez-en une nouvelle dans le dashboard.
curl -s https://llmwebsearch.com/api/v1/credits \
-H "Authorization: Bearer $LLMWEBSEARCH_API_KEY"
import os
import sys
import requests
resp = requests.get(
"https://llmwebsearch.com/api/v1/credits",
headers={"Authorization": f"Bearer {os.environ['LLMWEBSEARCH_API_KEY']}"},
timeout=10,
)
if resp.status_code != 200:
print("API check failed:", resp.status_code, resp.text[:200])
sys.exit(1)
print("API up, credits left:", resp.json()["credits_remaining"])
Comment distinguer notre erreur d'un refus de site web ?
Regardez où le problème apparaît dans la réponse.
- Une erreur HTTP sur l'appel entier (
502 search_failed,504 search_timeout) vient de notre côté ou en amont. Elle ne coûte rien ; attendez un peu et réessayez avec un délai croissant. - Un appel réussi dont certains résultats n'ont pas de contenu concerne ces pages. Chaque résultat porte un
content_status:blocked_by_robots,blocked_by_site_policy,target_refused,fetch_failedoufetch_timeout. La requête elle-même a fonctionné.
Le second cas est normal sur le web ouvert et n'est pas un incident. La page des erreurs liste tous les codes.
Où les incidents sont-ils consignés ?
Sur le changelog. Un incident qui touche de nombreux comptes fait l'objet d'une entrée datée : ce qui a échoué, de quand à quand, et ce qui a changé ensuite. Les appels en échec pendant un incident n'ont pas été facturés, il n'y a donc rien à récupérer.
Nous ne publions ni pourcentage de disponibilité ni chiffre de latence. Nous préférons vous donner une vérification que vous pouvez lancer plutôt qu'un chiffre que vous ne pouvez pas vérifier.
Que doit faire mon agent quand un appel échoue ?
Ne réessayez que ce qui peut réussir plus tard. Un 429 rate_limited, 502 search_failed ou 504 search_timeout mérite un nouvel essai après une courte attente qui double à chaque fois. Un 401 ou 402 nécessite une personne : une nouvelle clé ou plus de crédits. Une page refusée par son site web ne doit pas être réessayée du tout ; utilisez plutôt les autres résultats de la même requête.
Questions sur le statut
L'appel des crédits consomme-t-il un crédit ?
Non. GET https://llmwebsearch.com/api/v1/credits est gratuit, donc une tâche de monitoring peut l'exécuter aussi souvent que votre limite par minute le permet.
Ma requête a fonctionné mais un résultat n'a pas de contenu. Est-ce une panne ?
Non. Cette page n'a pas pu être lue : son content_status en indique la raison. Notre lecteur respecte robots.txt : il s'annonce comme LLMWebSearch, suit les règles qu'un site écrit pour lui ou pour tous les robots, et laisse de côté le contenu de toute page qu'il n'est pas autorisé à lire.
À qui signaler un problème que le health check ne montre pas ?
Au support à [email protected], avec l'heure, l'endpoint et une réponse en échec complète. Une personne répond en moins de 12 heures.