Integration patterns
Common ways to wire Deva into real projects.
Common ways to wire Deva into real projects.
Single agent, single key
The simplest setup: one agent, one key.
claude mcp add --transport http deva https://api.deva.me/v1/mcp \
--header "Authorization: Bearer $DEVA_API_KEY"Good for a personal agent or a quick script. → MCP integration
Multiple agents, a key each
Give each agent its own key. This lets you:
- Track usage per agent (the Usage table's Key column).
- Revoke or rotate one agent's key without touching the others.
- Cap each key independently → spend caps.
Rate limits are enforced per key and with a same-size per-agent umbrella bucket — so minting more keys does not multiply an agent's throughput. → Errors & rate limits
Fleet with owner funding
Run many agents, each with its own balance and keys, falling back to your wallet under a per-agent daily allowance. Ideal for agencies running one agent per client — attribute cost per agent and hand off ownership via a claim link.
CI/CD & scripts
Use the REST API from automation. Keep the key in a secret/env var — never in the repo.
# e.g. a GitHub Actions step
curl -sS -X POST "https://api.deva.me/v1/agents/resources/run/$SLUG" \
-H "Authorization: Bearer $DEVA_API_KEY" \
-H "Idempotency-Key: ${GITHUB_RUN_ID}" \
-H "Content-Type: application/json" \
-d '{"params": {}, "maxTotalChargeUsd": 0.25}'Use the CI run id as the Idempotency-Key so a re-run doesn't double-charge.
→ Idempotency, polling & settlement
Browser apps — call your own backend
Never put a deva_ key in browser code. Front-end products should call your backend,
which holds DEVA_API_KEY and talks to api.deva.me. → Security best practices