Recherche de recette d'authentification

Une recette n'est aussi bonne que la documentation dont elle provient. Ceci est une procédure, non une guidance : exécutez chaque étape avec l'outil research et conservez uniquement les découvertes que vous pouvez pointer sur une page récupérée. Les URLs devinées, c'est comment les utilisateurs se retrouvent sur la mauvaise page avec une clé qui ne peut pas être vérifiée.

Entrées : le nom du service et le(s) host(s) API que les nœuds du workflow appellent.

1. Schéma d'authentification (template)

Récupérez la documentation d'authentification du fournisseur — research(action="web-search") avec "<service> API authentication", puis fetch-url le meilleur résultat de documentation. Enregistrez le schéma EXACTEMENT tel que documenté : nom du header, mot préfixe, casse (Authorization: Key {{api_key}} vs Bearer {{api_key}} vs un header personnalisé comme xi-api-key). Si l'authentification documentée est basic, digest ou OAuth, arrêtez : ce n'est pas exprimable en template — utilisez plutôt le type générique correspondant (voir l'échelle d'authentification de la skill workflow-builder).

2. Page de clé (docsUrl)

Trouvez où un utilisateur connecté CRÉE ou COPIE la clé. L'URL n'est pas affichée dans le formulaire — le fil de discussion de l'aide de l'Assistant IA la présente comme LE lieu pour obtenir la valeur, donc une mauvaise URL envoie l'utilisateur vers une impasse avec une confiance totale :

• Cherchez "<service> dashboard API keys" et scannez la documentation d'authentification récupérée pour des phrases comme « get your key from », « Dashboard → API Keys », « console », « settings ».
• La réponse se trouve normalement sur un host app/console/dashboard — console.apify.com/settings/integrations, elevenlabs.io/app/settings/api-keys, replicate.com/account/api-tokens, app.tavily.com/home — pas sous /docs, /reference ou /documentation.
• Acceptez une URL de domaine de docs uniquement quand la page récupérée montre que les clés sont réellement émises là (certains portails connectés de style ReadMe le font).
• NE CONSTRUISEZ JAMAIS un chemin de dashboard par analogie (/account/api-keys, /dashboard/keys, …). Les dashboards sont des apps derrière une connexion : une fetch répond 200 pour n'importe quelle route inventée, donc le chemin ne peut pas être vérifié en fetching. Émettez une URL de dashboard profonde uniquement quand elle apparaît LITTÉRALEMENT sur une page que vous avez récupérée ; quand les docs décrivent uniquement la navigation (« Dashboard → API Keys ») sans URL littérale, utilisez la racine du dashboard/app qu'ils référencent — une page réelle moins profonde vaut mieux qu'une profonde inventée.
• Rien de concluant après les deux étapes → omettez docsUrl. Ne présentez jamais la référence API comme la page de clé.

3. Point de terminaison de vérification (testUrl)

Trouvez un GET documenté et sans effet secondaire qui rejette une mauvaise clé avec 401/403. Vérifiez la référence API dans cet ordre et arrêtez au premier résultat qualifiant :

1. Points de terminaison account/profile/me — /v1/account, /v2/users/me, /v1/user.
2. Points de terminaison usage/quota — par ex. /v1/models/usage de fal, /usage de Tavily.
3. Points de terminaison list/discovery — /v1/templates, /v1/models, /v1/voices.

Règles, toutes obligatoires :

• Le point de terminaison doit apparaître sur une page que vous avez récupérée — ne construisez jamais un chemin par analogie avec d'autres APIs.
• Jamais l'un de vos propres points de terminaison du workflow, jamais une URL de ressource ou d'action, jamais rien qui peut déclencher du travail facturable. Setup rejette les collisions d'URL de workflow, et la sonde signale les statuts inattendus comme « could not be verified » — une URL inventée ne coûte que la confiance de l'utilisateur.
• Ignorez les points de terminaison qui répondent 2xx indépendamment de la clé : points de terminaison auth-optionnels (recherche Pexels) ou services qui signalent les erreurs d'auth dans le corps de la réponse (le auth/health d'Apollo, TikTok) — une sonde de statut ne peut pas vérifier via eux.
• Rien ne qualifie → omettez testUrl. L'authentification se sauvegarde bien et la card signale honnêtement qu'elle n'a pas pu être vérifiée, ce qui vaut mieux qu'un faux vert.

4. Composition

Remplissez credentialHints (liste des champs et exemple dans la skill post-build-flow) uniquement à partir des découvertes ci-dessus. suggestedName nomme le service (« Apify API Token ») ; n'incluez jamais un vrai secret.