Get Secret Version
const url = 'https://example.com/vault/v1/workspaces/example/engines/example/secrets/example/versions/example';const options = {method: 'GET'};
try { const response = await fetch(url, options); const data = await response.json(); console.log(data);} catch (error) { console.error(error);}curl --request GET \ --url https://example.com/vault/v1/workspaces/example/engines/example/secrets/example/versions/exampleReturns a version’s metadata and payload bytes. Clients that only need
metadata can filter on state via ListSecretVersions instead.
Parameters
Section titled “ Parameters ”Path Parameters
Section titled “Path Parameters ”The workspace the secret belongs to.
The parent secret.
The version id (UUID) to retrieve.
Responses
Section titled “ Responses ”OK
Response payload from Get Secret Version
Carries the output produced by getting a secret version.
object
The version metadata.
object
The unique identifier of this version (UUID)
The parent secret that owns this version (UUID)
The workspace that owns this version (UUID, denormalised from the parent secret).
Current lifecycle state of this version.
Vault-specific content checksum (etag) of the payload.
Timestamp when this version was created (server-managed).
Timestamp when this version’s state last changed (server-managed).
The provider holding this version. Always its parent secret’s — a version cannot be held by a different provider than the secret it belongs to, and the database enforces that rather than trusting the application to maintain it.
How the holding provider identifies this version. See VaultVersionIdentity:
address a version by id, and use this to correlate it with what the provider
reports.
object
The provider’s own handle for this version, verbatim and unparsed: “3” for a monotonic provider, a UUID or an opaque string for the others. Compare it for equality; do not parse it, and do not assume it sorts meaningfully.
The version’s position in the sequence, when the provider genuinely orders its versions. ABSENT means this provider does not — not that the version is first or unknown. Never compare an absent ordinal against a present one.
The version’s payload bytes (server-returned).
Example
{ "version": { "state": "SECRET_VERSION_STATE_UNSPECIFIED", "engine": "VAULT_ENGINE_UNSPECIFIED" }}default
Section titled “default ”Default error response
The Status type defines a logical error model that is suitable for different programming environments, including REST APIs and RPC APIs. It is used by gRPC. Each Status message contains three pieces of data: error code, error message, and error details. You can find out more about this error model and how to work with it in the API Design Guide.
object
The status code, which should be an enum value of [google.rpc.Code][google.rpc.Code].
A developer-facing error message, which should be in English. Any user-facing error message should be localized and sent in the [google.rpc.Status.details][google.rpc.Status.details] field, or localized by the client.
A list of messages that carry the error details. There is a common set of message types for APIs to use.
Contains an arbitrary serialized message along with a @type that describes the type of the serialized message.
object
The type of the serialized message.
Example generated
{ "code": 1, "message": "example", "details": [ { "@type": "example" } ]}