Request External Resource
request_external_resourceRequest the USER'S OWN external credential for this project — their OpenAI or Anthropic API key, an external Postgres connection string (ALWAYS type POSTGRES — a Postgres credential requested as GENERIC is refused, because only POSTGRES gives the user a database: the Databases tab, helpers/db, the typed schema and query_database), or any other service's key (type GENERIC, e.g. Stripe/Resend — secret_env_vars is REQUIRED for GENERIC and the call is refused without it; a var the user can only produce LATER, like a webhook signing secret, goes in optional_env_vars so the dialog doesn't demand it up front). NOT for Floot-managed resources (database/auth/push/oauth/…) — use provision_resource for those; they need no user input. REUSE FIRST: if the project owner already has a matching credential on their account (list_resources section 2), this connects that saved credential to the project directly and returns the env var names — no link, no dialog, nothing to poll. Pass the name exactly as list_resources shows it to make that happen. Reusing a POSTGRES credential also seeds helpers/db, installs the query stack, and pulls the typed schema helper, so do NOT write those yourself afterwards. Otherwise it returns a secure connect link: SHOW it to the user (UI-capable hosts render a Connect button automatically; on terminal hosts with shell access open it in the user's default browser yourself and paste the URL as plain text) and ask them to open it. The call completes only when the user finishes the connect flow — it never expires. Do NOT block on it: request the credential EARLY, keep building everything that doesn't need the secret (the env var names are known now — reference process.env.X in code before the secret exists), and check the request between tasks; the user may never connect it, and the build must not stall. NEVER ask the user to paste a secret into the chat. On completion you get the env var names — never the secret values. Re-calling with the same type returns the same pending request. If the credential is already connected and holds every value you asked for, you get those env var names and their value SHAPES back immediately and the user is not interrupted — to reopen a dialog because a stored value is wrong, re-call with instructions saying what is wrong.
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | Display name for GENERIC requests, e.g. 'Stripe'. | |
| type | Yes | ||
| projectId | Yes | ||
| instructions | No | Why the key is needed / where the user can find it — shown to the user in the dialog. | |
| secret_env_vars | No | REQUIRED for GENERIC (the call is refused without it): the env var name(s) the secret(s) should be exposed as — e.g. ["STRIPE_SECRET_KEY"]. Name what you will actually reference as process.env.<NAME> in code; it is the identity of the request, what account-credential reuse matches on, and what the value is stored under, so there is no usable default. Every var listed here is a REQUIRED field in the connect dialog — the user cannot submit while one is blank, so only list vars the user can produce right now; anything they'd fill in later belongs in optional_env_vars instead. | |
| optional_env_vars | No | GENERIC only: env vars the user may leave blank at connect time and fill in later — e.g. a webhook signing secret that only exists after the webhook endpoint is created. Rendered as optional fields; names here need not repeat secret_env_vars (a name in both stays required). To collect a skipped value later, call request_external_resource again — the connected resource opens in an update dialog. |