Skip to main content
The vault is a zero-knowledge encrypted credential store for your organization. Store API keys, login credentials, SSH keys, and other secrets: Inkbox never sees the plaintext. All encryption and decryption happens client-side in the SDK or console using your vault key.

How it works

Every secret stored in the vault is encrypted with your organization’s encryption key before it leaves the SDK. The server only ever sees ciphertext. To read secrets, you unlock the vault with your vault key, and the SDK or console decrypts everything locally. Two keys are involved: Each key resolves from the SDK/CLI argument, then its environment variable, then a ~/.inkbox/config file (api_key = ... / vault_key = ...) — handy for background or agent processes that don’t inherit your shell’s env.

Secret types

Each secret has a type that determines its payload structure:

Open the SDK client

The SDK examples below share one client. Keep it open while you work through them. Choose your own vault key in place of the example value, or use your existing vault key. For this manual setup, leave INKBOX_VAULT_KEY and the vault_key entry in ~/.inkbox/config unset. A configured vault key makes the SDK attempt to unlock during construction, before a new vault exists.

Initializing the vault

Initialize a vault once per organization. Your API key determines the organization. Initialization creates the vault, sets the primary vault key, and generates four recovery codes. Store the recovery codes securely when they are returned. If the vault already exists, continue to unlocking it with its current key.

Unlocking the vault

Before you can read or write secrets, unlock the initialized vault with the same key. The SDK validates the key, fetches all encrypted secrets, and decrypts them locally.

Creating secrets

Once unlocked, create secrets by specifying a name and a payload. Python uses payload dataclasses. TypeScript infers the secret type from the payload’s fields. The SDK encrypts the payload before sending it to the server.

Reading secrets

Access all decrypted secrets via the secrets property, or fetch a specific one by ID.

Updating and deleting secrets

Update a secret’s name, description, or payload. Delete secrets when they’re no longer needed.

Storing logins with TOTP

Login secrets can include a TOTP configuration for two-factor authentication. Use parse_totp_uri to parse a standard otpauth:// URI into a TOTP config, then attach it to the login payload.
You can also build a TOTP config manually instead of parsing a URI:

Generating TOTP codes

Once a login secret has a TOTP config, generate the current one-time code with get_totp_code. The code, expiry window, and seconds remaining are returned.
The returned TOTPCode includes: You can also generate codes directly from a TOTP config without storing it in the vault:

Identity access control

Grant specific agent identities access to individual secrets. This lets you control which agents can use which credentials.

Vault metadata

Check the vault’s ID and counts without unlocking it. info() returns None in Python or null in TypeScript if your organization has not initialized a vault.

Managing vault keys

Rotate the primary vault key or revoke an existing key by auth hash. Rotating the primary key keeps the same organization encryption key and re-wraps it under the new primary vault key.

Deleting the vault

Delete the vault and all its keys and secrets from the Inkbox Console. This is destructive and permanently removes access to all stored secrets. After deletion, the organization can initialize a new vault. Vault deletion is not available through the SDK or CLI. Use the Inkbox Console instead. After deletion, you can initialize a new vault.

Close the Python client

After you finish using the vault, close the Python client to release its connections:
Python