Credential Recipe Research
A recipe is only as good as the documentation it came from. This is a
procedure, not guidance: execute every step with the research tool and keep
only findings you can point to on a fetched page. Guessed URLs are how users
end up on the wrong page with a key that can't be verified.
Inputs: the service name and the API host(s) the workflow's nodes call.
1. Auth scheme (template)
Fetch the provider's authentication docs — research(action="web-search")
with "<service> API authentication", then fetch-url the best docs hit.
Record the scheme EXACTLY as documented: header name, prefix word, casing
(Authorization: Key {{api_key}} vs Bearer {{api_key}} vs a custom header
like xi-api-key). If the documented auth is basic, digest, or OAuth, stop:
that is not expressible as a template — use the matching generic type instead
(see the workflow-builder skill's credential ladder).
2. Key page (docsUrl)
Find where a logged-in user CREATES or COPIES the key. The URL is not shown in the form — the n8n Assistant help thread presents it as THE place to get the value, so a wrong URL sends the user to a dead end with full confidence:
- Search
"<service> dashboard API keys", and scan the fetched auth docs for phrases like "get your key from", "Dashboard → API Keys", "console", "settings". - The answer normally lives on an app/console/dashboard host —
console.apify.com/settings/integrations,elevenlabs.io/app/settings/api-keys,replicate.com/account/api-tokens,app.tavily.com/home— not under/docs,/reference, or/documentation. - Accept a docs-domain URL only when the fetched page shows keys are actually issued there (some ReadMe-style logged-in portals do).
- NEVER construct a dashboard path by analogy (
/account/api-keys,/dashboard/keys, …). Dashboards are apps behind a login: a fetch answers 200 for any invented route, so the path cannot be verified by fetching. Emit a deep dashboard URL only when it appears VERBATIM on a page you fetched; when the docs only describe navigation ("Dashboard → API Keys") without a literal URL, use the dashboard/app root they reference — a shallower real page beats a deeper invented one. - Nothing conclusive after both steps → omit docsUrl. Never pass off the API reference as the key page.
3. Verification endpoint (testUrl)
Find a documented, side-effect-free GET that rejects a bad key with 401/403. Check the API reference in this order and stop at the first qualifying hit:
- Account/profile/me endpoints —
/v1/account,/v2/users/me,/v1/user. - Usage/quota endpoints — e.g. fal's
/v1/models/usage, Tavily's/usage. - List/discovery endpoints —
/v1/templates,/v1/models,/v1/voices.
Rules, all mandatory:
- The endpoint must appear on a page you fetched — never construct a path by analogy with other APIs.
- Never one of the workflow's own endpoints, never a resource or action URL, never anything that can trigger billable work. Setup rejects workflow-URL collisions, and the probe reports unexpected statuses as "could not be verified" — an invented URL only costs the user trust.
- Skip endpoints that answer 2xx regardless of the key: auth-optional
endpoints (Pexels search) or services that signal auth errors in the
response body (Apollo's
auth/health, TikTok) — a status probe cannot verify through them. - Nothing qualifies → omit testUrl. The credential saves fine and the card honestly reports it could not be verified, which beats a false green.
4. Compose
Fill credentialHints (field list and example in the post-build-flow skill)
from the findings above only. suggestedName names the service ("Apify API
Token"); never include a real secret.