- Trouvez le ticket ou la pull request dans lequel un bug a été signalé et corrigé
- Lisez les passages d’un README ou d’une page de documentation qui répondent à une question précise
- Remontez d’un contrat d’API à la pull request qui l’a modifié
- Retrouvez la discussion à l’origine d’un message d’erreur
Nous vous recommandons vivement d’utiliser notre CLI ou MCP, associés à notre skill Developer dédiée, que vous pouvez installer avec :
Points de terminaison
Rechercher dans l’Index Developer
POST est également disponible sur le même point de terminaison et constitue la solution la plus simple pour transmettre des filtres de tableaux au format JSON :
cURL
id stable tel que issue:owner/repo#123, un type parmi doc, issue, pull_request ou readme, une url et ses passages correspondants au format Markdown, afin de préserver les tableaux et les blocs de code. Le champ title est souvent absent des résultats doc lorsque la page source ne comporte aucun titre exploitable. Utilisez donc url comme solution de repli plutôt que de supposer que ce champ est présent.
En plus des résultats, coverage indique l’état de chaque type de résultat et reranked indique si la liste classée est passée par l’étape de reranking. Vérifiez coverage lorsqu’un type de résultat attendu est absent : skipped signifie que votre valeur types ne demandait pas ce type, tandis que degraded ou unavailable signifie que l’absence provient de l’index ou d’un filtre, et non de la requête.
Les filtres facultatifs permettent d’affiner la recherche :
kdéfinit le nombre de résultats renvoyés, 10 par défaut, etpassagesle nombre de passages correspondants inclus dans chacuntypessélectionne les types à rechercher parmidoc,issue,pull_requestetreadmereposdéfinit le périmètre de la partie GitHub de l’index, etsourcescelui de la partie documentationskillsdéfini suronlylimite la recherche aux fichiers de skills d’agent indexéslanguage,topic,license,min_stars,max_stars,archivedetforkfiltrent selon les attributs du dépôt, tels quelanguage=Rust,topic=asyncoulicense=MIT
sources ne renvoie donc aucun résultat doc et indique doc comme unavailable dans coverage. Consultez comment les filtres de dépôt définissent le périmètre d’une recherche avant d’en envoyer un.
Consultez la référence de la recherche développeur pour connaître le type et les limites de chaque filtre, la manière dont repos et sources définissent le périmètre d’une recherche, ainsi que le schéma de réponse complet.
Ajouter des résultats pour développeur à une recherche web
developer dans le tableau categories de /search lorsque vous appelez déjà /search et souhaitez que les résultats pour développeur soient pondérés avec les résultats web ordinaires dans un seul appel. L’API renvoie les résultats pour développeur dans un groupe developer, à côté de web, et les deux SDK exposent ce groupe via .developer.
Aucune clé API n’est nécessaire pour commencer : /search accepte les requêtes sans clé, y compris la catégorie developer, dans la limite du quota sans clé. Utilisez une clé pour bénéficier de limites de débit plus élevées.
url, title, description et position. Ils ont la même structure qu’un résultat web, avec en plus category: "developer". Les résultats web de la même réponse n’ont pas de champ category : utilisez donc ce champ si vous fusionnez les deux groupes. Les résultats sont regroupés séparément plutôt que dans web : les utilisateurs du SDK y accèdent donc avec result.developer.
Cette interface renvoie la structure des résultats web, et non celle des résultats pour développeur classés. Pour les passages correspondants et les filtres d’index, utilisez le point de terminaison de recherche pour développeurs.
Le serveur MCP hébergé expose les deux interfaces, et aucune n’écrit quoi que ce soit. Consultez les outils MCP pour
firecrawl_developer_search, pour les résultats pour développeur via firecrawl_search, et pour savoir laquelle des deux est disponible via l’ensemble d’outils sans clé.
