Give your agents a payment proposal API.
REST. OpenAPI-described. HMAC-signed. Idempotent. Designed so an agent can express intent without ever holding the keys to a wallet.
Agent API
Four verbs. One spend surface.
The agent-facing API is intentionally small. Most workflows are some sequence of these four calls.
Create proposal
Submit a signed payment proposal with amount, currency, merchant, and purpose.
Get spend capacity
Query the current spendable headroom for this agent in any supported currency.
Get proposal status
Poll for the lifecycle state — created, approved, executed, failed.
Receive webhooks
Subscribe to signed lifecycle events instead of polling — same auth model in reverse.
- POST
/v1/proposalsCreate a signed payment proposal on behalf of an agent. - GET
/v1/spend-capacityGet current spend headroom — owner balance bounded by agent cap and policy. - GET
/v1/proposals/{id}Fetch the current state of a single proposal. - GET
/v1/proposalsList proposals scoped to the calling agent.
Security
Five headers. Replay-proof by construction.
Each request carries its own integrity proof. The platform recomputes everything before accepting.
X-API-KeyIdentifies the calling agent and resolves the signing key.
agt_live_4f2c8a9c…
X-TimestampUnix seconds, current. Requests outside a 5-minute window are rejected.
1747920000
X-NonceSingle-use random value. Replay protection — reusing a nonce within the window fails.
0a8f3c1e7b…
X-SignatureHex HMAC-SHA256 over `<ts>.<nonce>.<method>.<path>.<sha256(body)>`.
a91c4f…b9e2
Idempotency-KeyClient-chosen UUID. Re-sending the same key returns the original result.
0193b7c0-…-d4f1
Signature contract
One canonical base string per request.
The signature input is fully deterministic — no field is optional, no whitespace is allowed. Mismatches fail closed.
// signature base string (newline-free, concatenated with '.')
<timestamp>.<nonce>.<method>.<path>.<sha256(body)>
// signature
hex(HMAC-SHA256(base_string, agent_signing_key))Example
A complete proposal request.
Headers on one side, payload on the other. Drop these into your client; the rest is auth handling.
POST /v1/proposals
Host: api.0x1e.ai
X-API-Key: agt_live_4f2c8a9c…
X-Timestamp: 1747920000
X-Nonce: 0a8f3c1e7b…
X-Signature: a91c4f…b9e2
Idempotency-Key: 0193b7c0-…-d4f1
Content-Type: application/json{
"amount": "249.00",
"currency": "USD",
"merchant_name": "API Provider",
"category": "compute",
"description": "Top up inference credits"
}Re-sending the same Idempotency-Key returns the original proposal — never creates a duplicate. Important for retry loops on flaky networks.
Webhooks
Subscribe instead of polling.
Five signed events cover the full proposal-to-settlement lifecycle. Same HMAC contract, applied in reverse.
proposal.approvedOwner confirmed the proposal. Funds have been reserved atomically.
proposal.deniedOwner rejected the proposal. No reservation took place.
payment.succeededPayment rail confirmed the transaction. Reserve has been committed.
payment.failedPayment rail rejected the transaction. Reserve has been released.
refund.succeededRefund completed against an original transaction. Owner balance restored.
SDKs · coming soon
Official client libraries are on the roadmap.
TypeScript and Python first. Until then, the REST contract plus a few lines of HMAC code in your language of choice gets you a production client — early-access partners get reference implementations.
- TypeScript
- Python
- Go (community)
- Ruby (community)
Ship the agent integration this quarter.
Early access partners get keys, OpenAPI spec, reference HMAC client, and direct support.