Input & Output
The shared config-key pattern across every operation, and how results are shaped
Shared Input Pattern
Every operation takes the same top-level config keys, plus its own operation-specific fields listed on that resource's page:
| Key | Required | Description |
|---|---|---|
resource | ✓ Yes | One of secrets, token, lease, system. |
operation | ✓ Yes | The operation within that resource, e.g. read. |
vaultAddress | ✓ Yes | The tenant's Vault server base URL. No default exists. |
authMethod | ✓ Yes* | "token" or "appRole". *Omitted for system/health and system/sealStatus. |
credentialID | ✓ Yes* | BizFirst credential record ID. *Same exemption as above. |
appRolePath | No | Vault auth mount path, default "approle". |
namespace | No | Vault Enterprise namespace. |
mount | ✓ Yes** | KV engine mount path. **secrets operations only. |
engineVersion | No | "1" or "2", default "2". secrets operations only. |
Output Ports
Like every other ExecutionNode in this platform, the node exposes standard success
and error output ports (initialized via OutputMapping.GetOrCreatePortSuccessAndError()
on ValidateExecutorSettings). A successful call routes to the success port with the
operation's result fields (documented on each resource's page) plus status,
resource, and operation echoed back. List-shaped results (e.g.
secrets/list) additionally populate the standard items array so downstream
nodes can iterate them the same way they iterate any other node's list output.
How Errors Surface
| Situation | What happens |
|---|---|
Missing/invalid config key (e.g. no vaultAddress, bad authMethod, missing mount on a Secrets op) |
Fails validation before any HTTP call — HASHICORP_INVALID_CONFIGURATION. |
| Credential doesn't resolve to a usable token/AppRole pair | HASHICORP_CREDENTIAL_NOT_FOUND (token method) or HASHICORP_AUTH_FAILED (AppRole method). |
| Vault itself rejects the call (permission, not found, sealed, CAS mismatch, etc.) | Mapped to the matching HASHICORP_* code — see Error Codes. |
| Vault is completely unreachable (timeout, DNS failure, connection refused, TLS failure) | HASHICORP_VAULT_UNREACHABLE — this is HashiCorpApiException's status-code-0 sentinel, not a real Vault response. |
| An unexpected exception (not a Vault API error) during the call | HASHICORP_UPSTREAM_ERROR, logged with the underlying exception attached. |
read/list/
lookup*/health/sealStatus operation is safe to retry. Writes
(secrets/write, secrets/delete, secrets/destroy,
token/revokeByAccessor, lease/revoke) are not automatically retried by this
node and, for the destructive ones, are not reversible — use cas on
secrets/write if concurrent writers are a possibility.