Getting Started

What is Ambr

Ambr is Ricardian legal infrastructure for AI agents. It lets autonomous software create, negotiate, sign, and verify legally-binding contracts through a single API -- no human bottleneck, no PDF workflows.

Get a Free Developer Key

Go to getamber.dev/activate, enter your email, and receive an API key instantly. The free developer tier includes 25 contracts per account per month with no payment required.

Your First Contract

Create a delegation contract with a single POST request:

curl -X POST https://getamber.dev/api/v1/contracts \
  -H "Content-Type: application/json" \
  -H "X-API-Key: YOUR_KEY" \
  -d '{
    "template_slug": "delegation-d1",
    "parameters": {
      "principal_name": "Acme Corp",
      "agent_name": "ProcureBot AI",
      "scope": "procurement up to $10,000",
      "duration": "90 days"
    }
  }'

The response includes the contract object with a SHA-256 content hash, a reader URL for the counterparty, and a sign URL for wallet-based execution.

Contract Lifecycle

Create

POST /api/v1/contracts creates a new Ricardian contract from a template. The response includes the contract body, a SHA-256 content hash, a reader URL (with embedded share token), and a sign URL.

{
  "id": "ctr_abc123",
  "hash": "sha256:9f86d08...",
  "status": "draft",
  "reader_url": "https://getamber.dev/reader/ctr_abc123?token=...",
  "sign_url": "https://getamber.dev/reader/ctr_abc123?token=...&sign=true"
}

Share

Send the reader_url to the counterparty. The URL contains a share token that grants read access to the contract without requiring an API key. The counterparty can review the full contract terms before proceeding to handshake or signature.

Handshake

POST /api/v1/contracts/:id/handshake lets the counterparty accept, reject, or request changes to a contract. The handshake also records a visibility preference (public or private).

{
  "action": "accept",        // "accept" | "reject" | "request_changes"
  "visibility": "public",    // "public" | "private"
  "wallet_address": "0x..."
}

Sign

POST /api/v1/contracts/:id/sign submits an ECDSA wallet signature. Contracts require two signatures: the first moves the contract to pending status, the second activates it and triggers on-chain minting.

Verify

GET /api/v1/contracts/:id returns the full contract including its SHA-256 hash. Compare this hash against the on-chain record to verify the contract has not been tampered with since signing.

Agent Integration

A2A Discovery

AI agents discover Ambr through the standard A2A well-known endpoint:

GET https://getamber.dev/.well-known/agent.json

The agent card describes available capabilities, authentication methods, and supported interaction protocols.

MCP Server

Add Ambr as an MCP server in your agent configuration:

{
  "mcpServers": {
    "ambr": {
      "url": "https://getamber.dev/api/v1/mcp",
      "headers": { "X-API-Key": "YOUR_KEY" }
    }
  }
}

The MCP server exposes tools for contract creation, retrieval, handshake, and signing -- enabling any MCP-compatible agent to manage contracts natively.

REST API

All endpoints accept and return JSON. Authenticate with the X-API-Key header or a share token where noted. Base URL: https://getamber.dev/api/v1

x402 Pay-per-contract

Instead of an API key, agents can pay per contract using the x402 protocol. Include a payment header with each request. The server validates the payment proof on-chain before processing the contract creation. This enables fully autonomous agent-to-agent commerce without pre-registration.

API Reference

Endpoints

Wallet & Identity

Connect Wallet

The Ambr dashboard supports dual login: authenticate with your API key or connect a wallet directly. Wallet connection links your on-chain identity to your Ambr account, enabling signature-based contract execution and cNFT management.

Wallet Auth

The Reader Portal uses ECDSA signature verification for counterparty authentication. When a counterparty visits the reader URL, they sign a challenge message with their wallet to prove identity before viewing or signing the contract.

Contract NFTs

Each fully-signed contract is minted as an ERC-721 cNFT on Base L2. The token stores the SHA-256 content hash on-chain, creating an immutable record that the contract existed in its exact form at the time of signing. The NFT metadata links back to the Ambr reader for the full contract text.

Transfers

Contract NFTs use counterparty-gated transfers. Both signing parties must approve a transfer before the NFT can move to a new wallet. This prevents unilateral reassignment of contractual obligations.

Payment Methods

Pricing

x402 Pay-per-Contract (Agent-Native)

No account needed. Agents pay per contract directly with crypto on Base L2. Include the transaction hash in the X-Payment header.

API Key Tiers (Predictable Billing)

For teams that prefer monthly billing with included contract limits. Visit getamber.dev/activate to get started.

Crypto

Pay for contracts with 7 tokens on Base L2:

Card Payments

Stripe checkout for card payments is available for Startup, Scale, and Enterprise tiers. Use the developer tier or x402 crypto payments to get started without a card.

Trust Layer

ZK Identity

Demos Network

Ambr uses zero-knowledge proof identity verification via Groth16/BN128 zk-SNARKs powered by the DemosSDK. Counterparties prove attributes about themselves — jurisdiction, accreditation, age, or KYC status — without revealing the underlying data. The verifier receives a cryptographic proof, not raw personal information.

Proofs are verified server-side using the identity_with_merkle circuit. Each proof generates a unique nullifier that prevents replay attacks. Identity attestations are stored alongside the contract signature in the immutable record.

Enable ZK identity verification on any contract by setting require_zk_identity: true in the contract creation parameters. When enabled, signers must complete identity verification before their signature is accepted.

POST /api/v1/contracts
{
  "template": "ai-delegation",
  "require_zk_identity": true,
  "parameters": { ... },
  "principal_declaration": { ... }
}