Skip to main content

SDK Configuration

createVaultkitClient accepts a VaultkitConfig object. Use it to control authentication, timeouts, retries, logging, and the way dynamic vaults are generated.

Required properties

Always provide these three values when creating a client:
About static vs. dynamic vaults:
  • Use vaultId if you have a pre-configured vault in the Vaultkit dashboard.
  • Use featureMappingId to generate vaults on demand. Vaultkit will create a per-user vault the first time connect() is called.

Optional properties

Fine-tune behavior with these optional settings: This is the typical flow for apps with user-facing UIs. Users select features and authenticate providers through the SDK UI components, then you create a client with the resulting vault.

Example: Programmatic flow (advanced)

Use this only when you need to dynamically provision vaults server-side without user interaction.

Example: Backend/Internal agent (no UI)

For internal services and scheduled jobs, use pre-configured vaults without any UI components:
For more details on backend integration patterns, see Backend Integration.

Inspecting the client

createVaultkitClient returns a small API:
  • vaultkit.tools – Getter that exposes the array of Vaultkit tools after connect() succeeds.
  • await vaultkit.connect() – Resolves the correct vault and fetches tools. It also handles dynamic provisioning when featureMappingId is present.
  • await vaultkit.disconnect() – Clears in-memory tool state. Call this in finally blocks to avoid leaking resources.
If you need to share discovery results across multiple requests (for example in a long-lived worker), keep the client in a module-level cache and call connect() once during startup.