fix(banking-ai-mcp-bootcamp): validate vaulted apiKey secret via metadata

[avdev4j]

Problem

The "Set API Key" validation step in the Banking AI MCP bootcamp stopped passing even when learners had correctly configured their apiKey environment variable.

Postman now stores sensitive environment values in Postman Vault. As a result, the variable's value field is always returned empty by the API, with the real data referenced via source.{vault_provider}.secretId. The previous validator required a non-empty value, so a correctly configured secret could never validate.

Fix

Validate the apiKey variable's metadata instead of its value. The step now passes when the variable:

1. exists (key apiKey),
2. is enabled, and
3. is marked sensitive (type: "secret" or secret: true).

The value / vault-backed checks were removed since the value is intentionally empty for vaulted secrets.

Notes

• Because the check relies only on metadata, it works regardless of where the secret is stored — local vault (tested with a free Postman account) or cloud vault (Enterprise account).
• User-facing validation messages are preserved so the lesson guidance still reads correctly.

This is a first suggestion — happy to discuss the approach.

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
liftoff	Ready	Preview, Comment	Jul 6, 2026 3:45pm

[DannyDainton]

Tested the changes on the Preview branch and it's fine for me as I worked through the module. A slight copy change will be needed to cover when Free users are not able to share a sensitive value without upgrading first.

@quintonwall Could you give it a once over too? We also might need to add @avdev4j to the vercel team (subscription dependant) so that he can test on the Preview branches.

[avdev4j]

Regarding the free account, I can confirm that users will have an unsecured variable "apiKey" in the environment after calling the Generate API Key endpoint. Users can store the value in the local vault but cannot share it.

The API returns the variable entry with the following definition, which seems sufficient to validate the step:

{
  key: "apiKey",
  value: "",
  enabled: true,
  type: "default",
  secret: true,
}

I'm updating the PR to take this into account.

[avdev4j]

Here is a suggestion to align the wording with the current behavior. Please let me know if it works. We can make it less detailed, as you prefer. We just want to avoid any misunderstanding between sharing the variable and the features included in the plan.