/credential-recipe-research
Lookup procedure for Simplified Custom Auth recipe fields — sources the auth template, the key-issuing docsUrl and an auth-rejecting testUrl from the provider's real documentation instead of memory. Load before composing credentialHints for a service without a dedicated
$ npx -y skills add n8n-io/n8n --skill credential-recipe-research --agent claude-codeHow it fires
How this skill gets triggered: by you, by Claude, or both.
- Fires itselfAuto-invocation. Claude auto-loads it when your prompt matches the work.Auto-invocation is when the right skill fires by itself at the right moment, driven by a FLOW.md router and a hook, instead of you invoking it by name. It is the difference between a skill being installed and a skill actually getting used.Read the full definition →
- You can call itInvoke it directly when you want it.
- Slash command
/credential-recipe-research
Context preview
The summary Claude sees to decide when to auto-load this skill.
Lookup procedure for Simplified Custom Auth recipe fields — sources the auth template, the key-issuing docsUrl and an auth-rejecting testUrl from the provider's real documentation instead of memory. Load before composing credentialHints for a service without a dedicated
SKILL.md
credential-recipe-research.SKILL.mdname: credential-recipe-research
description: >-
Lookup procedure for Simplified Custom Auth recipe fields — sources the auth
template, the key-issuing docsUrl and an auth-rejecting testUrl from the
provider's real documentation instead of memory. Load before composing
credentialHints for a service without a dedicated credential type (the
post-build-flow setup step), or when asked to fix a recipe whose template,
key page or test endpoint is wrong.
recommended_tools:
- research
- workflows
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 AI 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:
1. Account/profile/me endpoints — `/v1/account`, `/v2/users/me`, `/v1/user`. 2. Usage/quota endpoints — e.g. fal's `/v1/models/usage`, Tavily's `/usage`. 3. 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.
Read more
name: credential-recipe-research description: >- Lookup procedure for Simplified Custom Auth recipe fields — sources the auth template, the key-issuing docsUrl and an auth-rejecting testUrl from the provider's real documentation instead of memory. Load before composing credentialHints for a service without a dedicated credential type (the post-build-flow setup step), or when asked to fix a recipe whose template, key page or test endpoint is wrong. recommended_tools: - research - workflows
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 AI 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:
1. Account/profile/me endpoints — `/v1/account`, `/v2/users/me`, `/v1/user`. 2. Usage/quota endpoints — e.g. fal's `/v1/models/usage`, Tavily's `/usage`. 3. 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.
Fair-code platform to build and deploy AI agents and workflows. Combine a visual canvas with custom code, run it self-hosted or in the cloud, and connect to 1500+ integrations. AI automation you can trust with real work, from prototype to production.
Repo: n8n-io/n8n
Other skills on n8n.
- /setup-mcps
Configure MCP servers for n8n development. Use when the user says /setup-mcps or asks to set up MCP servers for n8n.
Open skill - /n8n-cli
Use the n8n CLI to manage workflows, credentials, executions, and more on an n8n instance. Use when the user asks to interact with n8n, automate workflows, manage credentials, or operate their instance from the command line.
Open skill - /agent-builder
Load before calling build-agent for a new or existing n8n Agent. Governs prerequisite creation, faithful handoff of the user's request, agent targeting across turns, builder questions, testing, and publishing. Use directly for routine follow-ups when the conversation already
Open skill - /config-evals
Builds and maintains configuration-based evaluations on a workflow with the eval-config tool. Use when the user asks to set up, add, view, change, or remove an evaluation, score, grade, or judge a workflow's output, or measure answer quality against a test dataset. This is the
Open skill - /credential-setup-with-computer-use
Guides n8n credential setup through Computer Use browser tools. Use when a user needs OAuth apps, API keys, client IDs, client secrets, or other credential values from an external service console.
Open skill - /data-table-manager
Load before calling data-tables or parse-file. Use for natural standalone requests like "what data tables do I have?", "show/list my tables", or "what columns are in this table?", and whenever the user asks to list, show, create, inspect, import, seed, query, update, clean up,
Open skill

