Vault API

Searchers type "vaultre api" when they want Empyre Vault's HTTP surface for autonomous agents. The agent API lives under `/vault/agent/*` on the platform API host. Each call carries a `vlt_live_…` bearer token; the server applies deny-by-default policies and meters secret reads and signatures against the org owner's Vault plan.

You integrate by minting an agent token in the Vault console, calling list and access routes from a trusted worker, issuing one-time `vlt_tmp_…` credentials when a narrower handoff fits, and using `sign` when the private key must never leave the vault.

The sections below map each endpoint, what `@empyre/vault-sdk` wraps, and how Vault billing differs from Relay OAuth or a generic secrets manager. For custody philosophy and architecture comparisons, use the articles linked at the end.

Two hosts, one product

Humans configure vaults, policies, and agent tokens on the Vault product host. Runtime traffic is JSON to the platform API.

Default API base is `https://api.empyre.dev`. Override with `baseUrl` in the SDK or `VAULT_BASE_URL` in the environment.

The product console is vault.empyre.dev (HTTP 200 on 2026-10-01). Pricing is at vault.empyre.dev/pricing (HTTP 200 on 2026-10-01).

Vault billing is card-only and separate from Empyre company-builder plans and Relay subscriptions. State lives in Vault tables, not `profiles.plan`.

Agent endpoints under `/vault/agent/*`

Authentication: agent bearer tokens only

Every agent endpoint expects `Authorization: Bearer vlt_live_…`. That token is minted in the Vault dashboard for one agent identity. It is not the human owner's session cookie.

401 means the token is missing, unknown, or expired. 403 means policy denied the action even though the token is valid. 429 often means monthly read or signature quota is exhausted for the org's plan.

Never paste a live token into a model prompt, a public repo, or client-side JavaScript. The worker that calls Vault should be as small and auditable as your threat model allows.

Secrets vs temporary credentials

Direct access and credentials solve different handoff shapes:

Signing without exporting private keys

Stored signing keys support Ed25519, ECDSA P-256, RSA-2048, and HMAC-SHA256. The private key never leaves the vault. The API returns a base64 signature and the public key material needed to verify.

`POST /vault/agent/sign` accepts `key_id`, `payload`, and `encoding` (`utf8` or `base64`). `POST /vault/agent/sign/batch` accepts an array of up to 20 items with the same fields.

This is the pattern when an agent must produce a JWT, webhook signature, or on-chain message without holding a PEM file in an environment variable the model can read.

What `@empyre/vault-sdk` wraps (1.0.0)

MCP on the same contract

Vault's MCP server lives at https://vault.empyre.dev/mcp. Tools expose the same agent API for hosts that connect through MCP rather than importing the SDK.

The npm package has zero runtime dependencies. It uses global `fetch` (Node 18+, Deno, Bun, browsers). Set `VAULT_AGENT_TOKEN` or pass `token` to `new VaultAgent()`.

For OAuth to third-party APIs as a user, use Relay instead of Vault. Vault answers "what may this agent read or sign?" not "log in as the owner to Gmail."

Reads and signatures vs downstream API traffic

Vault meters secret reads and signatures per organization plan, not every HTTP call your product makes afterward.

A secret read counts when policy allows `access` or a successful credential redemption. A signature counts on each `sign` or each item in `sign/batch`.

Self-serve tiers on vault.empyre.dev/pricing on 2026-10-01: Free includes 5,000 reads and 1,000 signatures per month; Developer is $39 per month for 100,000 reads and 50,000 signatures; Team is $149 per month for 1,000,000 reads and 500,000 signatures. Enterprise is invoiced separately.

Vault subscriptions are independent from Empyre company-builder plans and Relay. One Stripe customer can hold multiple products; metering stays separate.

Not Relay, and not a generic env-var store

Relay issues OAuth tokens so an agent can call third-party APIs with owner consent. Vault stores org secrets and signing keys under policy. Many production stacks use both.

For the Relay HTTP map, read Relay API. For why keys must not live in prompts and logs, read How AI agents leak API keys.

For custody patterns when servers must not hold private keys at all, read How to store private keys for an AI agent app and AI agent secret storage without server private keys.

Minimal agent wiring (SDK 1.0.0)

Run this in a worker the model cannot read. The agent receives only short-lived outputs:

import { VaultAgent } from "@empyre/vault-sdk";

const vault = new VaultAgent({
  token: process.env.VAULT_AGENT_TOKEN,
  // baseUrl: process.env.VAULT_BASE_URL ?? "https://api.empyre.dev",
});

const who = await vault.me();
const secrets = await vault.secrets();
const value = await secrets.access(secrets[0].id);

const issued = await vault.credentials.issue({
  secretId: secrets[0].id,
  ttlMinutes: 15,
  maxReads: 1,
});
// Hand vlt_tmp_… to a narrow consumer once:
const redeemed = await vault.credentials.redeem(issued.token);

const keys = await vault.signingKeys();
const sig = await vault.sign(keys[0].id, "payload-to-sign", "utf8");

Common questions

Related

Last updated 2026-10-01. Competitor descriptions reflect each product's publicly documented capabilities at that date; they change often, so check the source before relying on a detail.