Teams · beta

One owner key. Many capped agent keys. One audit trail.

The owner key is the key a top-up returns (xytara_spend_...). It is the Bearer for every team route. With it you mint agent keys that can only spend what you allow: per call, per day, in total, until an expiry, on the tools you list, and optionally only with a fresh signature from a key the agent holds. Caps are enforced on every spend; an agent key cannot mint keys or see other agents. Included with credits for now: no extra charge. Business plans later. This is a beta: the routes are live, the shapes may still gain fields.

Free: discovery + 20 tool calls per UTC day, no key needed Then: from $0.01 USDC per call (Base mainnet; $0.02 for a verified answer with a signed attestation) via x402, or from 3 credits per call with a spend key Pricing Buy credits ($1.00 = 400) Set up your client
Your owner key · optional

Paste your owner key and every snippet below fills itself in

The owner key is the key a top-up returns (xytara_spend_<hex>); it is the Bearer for every team route. It stays in this page (nothing is sent anywhere); the snippets replace YOUR_OWNER_KEY as you type. No key yet? Buy 400 credits for $1.00; the key you get back is your owner key.

How a team shares one balance safely

The model: owner key, agent keys

A top-up funds one account and returns one key. Today that key is the owner key. Instead of pasting it into every agent, the owner mints one agent key per agent, each with its own caps, expiry and tool list. Agents spend from the shared balance within their caps; the owner sees every spend in the activity trail and can revoke any key at once. Agent keys are presented to the MCP server and the runtime exactly like a spend key.

  • Owner key: the key a top-up returns (xytara_spend_...). Bearer for the four team routes below. Keep it with the people who fund the account.
  • Agent key: minted by the owner, shown once, spends within its caps. Cannot mint keys, cannot list or see other agents, cannot read the activity trail.
  • Caps: max_units_per_call, max_units_per_day, max_units_total (credits), expires_at_iso, allowed_tools. Enforced on every spend; a spend over any cap is refused before anything runs and nothing is charged.
  • Key-bound (optional): pass agent_public_key at mint time and every spend must also carry a fresh ed25519 signature bound to that exact request.
  • Units are credits: a standard tool call is 3 units, an attesting tool call (x402.verify-receipt, tx.status) is 6.

How a key is used in a client (identical for agent keys) · Buy credits (returns the owner key) · Pricing

POST https://xytara.onrender.com/v1/credits/agents

1. Mint a capped agent key

Every field except label is a cap or a restriction; omit a cap you do not want. The agent key is in the response once; hand it to the agent and never store it in this page or a URL.

mint
curl -s -X POST https://xytara.onrender.com/v1/credits/agents \
  -H "content-type: application/json" \
  -H "Authorization: Bearer YOUR_OWNER_KEY" \
  -d '{
    "label": "research-agent-1",
    "max_units_per_call": 6,
    "max_units_per_day": 120,
    "max_units_total": 1200,
    "expires_at_iso": "2026-12-31T00:00:00Z",
    "allowed_tools": ["summarize", "json.validate", "x402.verify-receipt"],
    "agent_public_key": "<optional: ed25519 public key, SPKI PEM or base64 SPKI DER>"
  }'
# -> 200: the agent key (xytara_spend_..., shown once) plus the agent record (id, label, caps, expiry, allowed tools, key-bound or not)
  • max_units_per_call: most credits one call may spend (3 covers any standard tool, 6 also covers the attesting tools).
  • max_units_per_day and max_units_total: rolling UTC-day and lifetime ceilings for this key.
  • expires_at_iso: after this instant the key stops spending. allowed_tools: only these tool names may be invoked; anything else is refused unpaid.
  • agent_public_key (optional): an ed25519 public key as SPKI PEM or base64 SPKI DER; makes the key key-bound (see below).
GET https://xytara.onrender.com/v1/credits/agents

2. List agent keys

Returns the agent records for the account: ids, labels, caps, usage so far, status and expiry. The tokens themselves are never returned; a lost agent key is replaced by revoking it and minting a new one.

list
curl -s https://xytara.onrender.com/v1/credits/agents \
  -H "Authorization: Bearer YOUR_OWNER_KEY"
# -> the agent records for this account: id, label, caps, usage, status, expiry. Never the tokens.
POST https://xytara.onrender.com/v1/credits/agents/:id/revoke

3. Revoke an agent key

Immediate and final: the key stops spending on the next request. The record stays in the list and in the activity trail so the history is intact.

revoke
curl -s -X POST https://xytara.onrender.com/v1/credits/agents/AGENT_ID/revoke \
  -H "Authorization: Bearer YOUR_OWNER_KEY"
# -> the agent record with status revoked; its key stops spending immediately
GET https://xytara.onrender.com/v1/credits/activity

4. Read the audit trail

Every spend on the account, attributed: which agent key spent how many credits on which tool, and when. Refused spends (over a cap, outside allowed_tools, expired, bad signature) are visible too, so a misbehaving agent is found before it costs anything.

activity
curl -s "https://xytara.onrender.com/v1/credits/activity" \
  -H "Authorization: Bearer YOUR_OWNER_KEY"
# -> the audit trail: which agent spent what (credits), on which tool, when
Identical to a spend key

Using an agent key

Put the agent key where a spend key goes: Authorization: Bearer <agent key> on https://xytara-mcp-executor.onrender.com/mcp (also X-Naxytra-Key or ?key= for clients that cannot set headers), or on the runtime with "payment_preference": "credits_first". Every client snippet on /setup works unchanged. The server reports the credits spent and remaining in each result's _meta["naxytra.com/allowance"].

Claude Code, for example
# an agent key is used exactly like a spend key (see /setup for every client)
claude mcp add --transport http naxytra https://xytara-mcp-executor.onrender.com/mcp --header "Authorization: Bearer <agent key>"

All client snippets

agent_public_key · X-Agent-Signature · X-Agent-Timestamp

Key-bound agents: what the agent signs

A key-bound agent key is useless on its own: every spend must carry a fresh ed25519 signature from the agent's private key, and the signature commits to the exact request (account, amount, task), so a leaked key or a captured signature cannot be replayed or stretched to a larger spend. The binding is a JSON array of fixed-order fields; its SHA-256 is appended to the message.

the binding (JSON array, exact order)
["naxytra-spend-binding/v1", "<account>", "3", "adapter.mcp.invoke"]
# the third element is the units of this spend as a string: "3" for a standard tool, "6" for an attesting tool
the message the agent signs (ed25519, signature sent base64)
naxytra-spend-auth:<credential_id>:<timestamp>:<sha256 hex of the binding JSON above>
sign one spend (Node)
// Node 20+: sign one spend with a key-bound agent key. The signature is single-use and bound
// to this account, this amount and this task; it travels in two headers next to the Bearer.
import { createHash, createPrivateKey, sign } from "node:crypto";

const credentialId = process.env.AGENT_CREDENTIAL_ID;   // the agent record's id
const account = process.env.NAXYTRA_ACCOUNT;            // the account the owner key funds
const units = "3";                                      // "3" standard tool, "6" attesting tool
const binding = JSON.stringify(["naxytra-spend-binding/v1", account, units, "adapter.mcp.invoke"]);
const digest = createHash("sha256").update(binding, "utf8").digest("hex");
const timestamp = String(Date.now());
const message = "naxytra-spend-auth:" + credentialId + ":" + timestamp + ":" + digest;
const privateKey = createPrivateKey(process.env.AGENT_PRIVATE_KEY_PEM);   // ed25519
const signature = sign(null, Buffer.from(message, "utf8"), privateKey).toString("base64");

const headers = {
  "content-type": "application/json",
  "Authorization": "Bearer " + process.env.AGENT_KEY,
  "X-Agent-Signature": signature,
  "X-Agent-Timestamp": timestamp
};
// then POST the tool call with these headers; a stale, reused or re-bound signature is refused
  • Freshness is bounded in both directions (about two minutes into the past, half a minute into the future); every signature is single-use.
  • <account> is the account the owner key funds (the account_id the balance endpoint returns); <credential_id> is the agent record's id from the mint response.
  • The units element is a string: "3" for a standard tool call, "6" for an attesting tool call; the task is adapter.mcp.invoke for MCP tools.
What is and is not here yet

Beta notes and limits

Included with credits for now: no extra charge. Business plans later.

  • Beta: the four routes are live; field names may gain optional entries. Breaking changes will be announced on /releases first.
  • One owner key per account for now. Rotating the owner key means a fresh top-up; ask support to revoke a leaked owner key.
  • Caps are counted in credits, not dollars; 1 credit = $0.0025.
  • A revoked or expired agent key never spends again; the activity trail keeps its history.

Support · Releases · Terms