Give each integration the credentials it needs
Each provider describes the credentials it needs without putting their values in the module. Runtime configuration supplies the actual material to the processes that use it.
The distinction matters when a vendor supports several services or a customer connects its own account: the right provider is not enough; the call must also use the right identity.
Example — Keep model access separate from sign-in
One vendor can need an API key for model requests and a different client secret for sign-in. Both requirements are named, so an operator can supply the appropriate material without confusing the two.
For engineers
The Google backend module names independent secrets for its model and sign-in protocols:
Selected from google.backend.module.ts; surrounding declarations and imports are omitted.
secretsContract: {
apiKey: {
envVarName: "GOOGLE_API_KEY",
required: true,
description: "Google API key for Gemini LLM calls."
},
oauth2ClientSecret: {
envVarName: "GOOGLE_OAUTH2_CLIENT_SECRET",
required: true,
description: "Google OAuth2 client secret for SSO token exchange."
}
},
The keys describe the requirement; envVarName connects it to deployment material, and the description explains its purpose. Protocol contracts refer to the appropriate secret. The module is registered on the backend side, and the application declares it in each runtime scope that should use it.
wildo config sync materializes scoped runtime environments from the provider declarations. Application runtimes receive provider material for their declared set; the platform tier has an explicit broader entitlement. An empty declared set differs from an omitted scope. This contract governs generated environments, not a claim that a process can never receive an extra variable from its operator.
Resolve the credential for the account the call names
The provider executor resolves access through an explicit connection target. Its owner scope determines which account supplies the credential:
| Connection owner | Credential source | If missing or unreadable |
|---|---|---|
| Application | The deployment’s provider credential | Refuse the call |
| Organization | That organization’s connected credential | Refuse; do not substitute the deployment account |
| User | That person’s connected credential | Refuse; do not substitute another account |
resolveProviderSecretForTarget implements these choices and is consumed by the shared HTTP API access resolver. Authorization of the target is a separate check: naming an owner does not grant permission to spend that owner’s credential. Let the sanctioned executor resolve access from the admitted target rather than looking up a secret in application code.
An encrypted credential that cannot be opened is an error, not evidence that another identity should be tried. This keeps the remote action attributable to the requested account. Some older framework consumers use a separate organization-first resolver with deployment fallback; that legacy behavior is not the target-aware executor’s contract.
Browser modules carry public configuration and receive no backend secret contract.
A required flag is information used by the relevant provider builder, not a universal startup validation guarantee. Optional credentials still need validation by the provider that consumes them. Never put a real secret value in the module, public contribution or example code.