Skip to main content
Cette API implémente le contrat standard de tâches asynchrones. Pour les endpoints qu’elle prend en charge, les schémas de requête et de réponse sont inchangés : un client qui fonctionne n’a généralement besoin d’aucune modification de code.

​
La migration

Faites pointer votre constante de clé d’API vers une clé querying.ai. Votre URL de webhook, vos clés d’idempotence, vos types de tâche et votre analyse des réponses restent tels quels.

​
Ce qui est implémenté

Pris en charge

POST /v1/async/taskPOST /v1/async/task/batchGET /v1/async/task/{id}Callbacks webhook

Non implémenté

Endpoints synchrones /v1/monitor/*/v1/async/status
La famille synchrone /v1/monitor/* est absente à dessein. Chaque moteur fonctionne ici de manière asynchrone ; une requête qui bloque le temps d’une interrogation n’est pas une forme que propose ce service.

​
Où le comportement diffère

Il n’y a pas de limite de débit par clé. Pour de gros volumes, utilisez la soumission par lot afin de réduire les allers-retours.Consultez Régions et bonnes pratiques.
credits est présent dans chaque réponse, dans l’enveloppe. Les réponses de soumission et de polling indiquent { "creditsToCharge": 0, "creditsCharged": 0 } ; les webhooks indiquent le coût en crédits du moteur (1 à 3 crédits selon le moteur).Les tâches échouées ne sont pas facturées. Les soldes de crédits sont visibles dans le tableau de bord.
Une combinaison ne peut pas être servie du tout : CHATGPT/PERPLEXITY/GEMINI vers CN, où aucune sortie n’est disponible et où la requête n’atteint jamais la cible. Elle échoue immédiatement avec 422 REGION_UNSUPPORTED au lieu d’être acceptée. 422 REGION_UNAVAILABLE couvre la version transitoire du même cas.Un client qui suppose que toute soumission bien formée est acceptée a besoin d’une branche ici. Consultez Régions.
Les flags payload.include sont acceptés, mais la plupart des moteurs renvoient une réponse de forme fixe et les ignorent. Seul ChatGPT respecte l’ensemble complet ; GEMINI ne respecte que markdown et rawResponse.Demander html à Gemini, par exemple, est ignoré silencieusement : ni erreur, ni champ. Consultez le tableau de prise en charge des flags.
La gestion des erreurs est par ailleurs classique : les échecs de validation renvoient 400, 401 signale MISSING_API_KEY, 404 signale RESOURCE_NOT_FOUND, et details nomme le champ fautif.Le seul ajout est la paire 422 (REGION_UNSUPPORTED, REGION_UNAVAILABLE) décrite plus haut. Nous vous prévenons d’emblée quand une région ne peut pas être servie : un client qui n’a jamais eu à gérer de 422 commencera à en voir.
GET /v1/async/task/{id} sur une tâche FAILED renvoie un champ error de premier niveau que le schéma du statut de tâche ne définit pas par ailleurs, et c’est une simple chaîne, pas l’objet {code, message, timestamp} des erreurs de requête.
Un client qui traite un body.error non vide comme une requête échouée interprétera mal une tâche échouée récupérée avec succès. Branchez plutôt sur task.status.
Ces comportements ont été établis en appelant cette API, pas en lisant un schéma. Si une spécification publiée et une réponse réelle divergent, ces pages documentent la réponse réelle.

​
Choisir le bon taskType

Si votre intégration actuelle appelle un endpoint par moteur, le nom du moteur correspond à un taskType :
Que GOOGLE désigne « AI Overview » est une convention de nommage, pas un nom de produit Google. La réponse est une enveloppe SERP dont aioverview est un membre nullable : consultez la forme GOOGLE.

​
Vérifier la bascule

Faites tourner en parallèle votre intégration actuelle et celle-ci pendant un temps, et comparez les champs que vous consommez réellement, en pratique response.text, response.sources[] et response.markdown. Une comparaison en miroir détecte les écarts de forme qu’une vérification de schéma ne voit pas, comme une liste de sources remplie mais ordonnée différemment.