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.