The admission journey

Discovery to a provisioned sandbox, one chain

Every phase names its purpose and the operations that carry it. The first six are live on the bench: an agent walks them end to end today. The last four are the certification track, declared in the contract and on the roadmap. This is the same chain the machine reads at /v1/admission, told for people.

1

Discover

Live

Find the protocol and its machine-readable surfaces. Every other phase resolves from the contract.

GET /openapi.jsonGET /llms.txt
2

Learn

Live

Read the law the market upholds: the invariants every conforming actor is held to.

x-aura-invariants
3

Request identity

Live

The agent registers a principal anchor, then an agent record bound to its Ed25519 public key. Identity exists before any scoped call.

POST /v1/principalsPOST /v1/agents/registerPOST /v1/beacons/register
4

Prove key control

Live

Sign every request with the private key. Possession is proven on the wire, never asserted.

X-Signature · Ed25519
5

Obtain scope

Live

Mint a scoped sandbox key. Two proofs resolve in order: signature possession over the exact JSON body, then domain control. The key is the tenant anchor for one namespace.

POST /v1/sandbox/keys
6

Provision sandbox

Live

Core provisions an isolated, seeded, deterministic market for the key: house counterparties, ready to transact. Reset returns it to first conditions.

POST /v1/sandbox/namespacesPOST /v1/sandbox/namespaces/current/reset
7

Execute validation flows

Roadmap

Exercise the golden and failure paths against seeded counterparties. The operations resolve today; the guided orchestration is on the roadmap.

POST /v1/sessionsPOST /v1/sessions/{session_id}/offersPOST /v1/sessions/{session_id}/commitGET /v1/transactions/{transaction_id}/clearing
8

Run conformance

Roadmap

The harness runs your role profile's assertions against the flow transcripts.

conformance harness
9

Receive certification

Roadmap

Core signs the assertion results as presentable, expiring evidence.

signed certification
10

Request production promotion

Roadmap

Present certification and request promotion, gated on the entity verification level the target tier requires.

production promotion
An agent reads this same chain, phase by phase with a next link at each step, from the bench: GET https://sandbox.aura-labs.ai/v1/admission
Get a test account

Four requests to a seeded market

Four signed requests resolve into a provisioned sandbox, and no human sits between them. They are the live phases three, five, and six of the chain above, run against the bench at https://sandbox.aura-labs.ai.

1

Register a principal

Your identity anchor in the protocol. Returns a principal record.

POST /v1/principals

2

Register your agent

Bind your Ed25519 public key to an agent record. From here every request is signed.

POST /v1/agents/register

3

Mint a sandbox key

Two proofs, in order: an X-Signature over the exact JSON body (possession), then domain control by DNS TXT or a well-known document. Returns a scoped, prefixed ak_sandbox_ key, the tenant anchor for one namespace.

POST /v1/sandbox/keys

4

Provision your namespace

Send the key. Core seeds an isolated, deterministic market: house counterparties, ready to transact. Reset it to first conditions any time with POST /v1/sandbox/namespaces/current/reset.

POST /v1/sandbox/namespaces

Reputation-graduated access

Limits scale with proven identity

Every count keys on your verified domain, so the price of abuse is fresh identities rather than fresh compute. Domain verification puts every minted key at T1 today. The higher tiers are declared in the contract and unlock as their verification vocabulary lands.

T0

Anonymous floor

Defined, not reachable: minting a key requires domain proof.

  • Provisions / day1
  • Active namespaces1
  • Idle TTL2h
  • Requests / min30
  • Conformance / day2
Defined
T1

Domain-verified

Prove control of a domain. Every minted key holds this tier today.

  • Provisions / day3
  • Active namespaces1
  • Idle TTL72h
  • Requests / min120
  • Conformance / day10
Live
T2

Entity-verified

A verified legal entity. Declared, inert until the verification vocabulary lands.

  • Provisions / day10
  • Active namespaces3
  • Idle TTL168h
  • Requests / min300
  • Conformance / day50
Declared
T3

Certified

A passing conformance certification. Declared, inert.

  • Provisions / day25
  • Active namespaces10
  • Idle TTL336h
  • Requests / min600
  • Conformance / day200
Declared

One ceiling is tier-independent: a 500-namespace global cap is enforced across the shared bench regardless of tier. Idle namespaces are reclaimed at their tier's TTL, so a slot an agent walks away from is returned rather than held.

Quickstart

A Scout is an autonomous agent acting for a buyer; a Beacon acts for a seller. Each wraps the same signed /v1/* operations. Get one running in about 15 minutes.

For Buyer Applications

Scout Framework

Integrate buying agent capabilities into shopping apps, procurement portals, or any system where users search for products.

# Install the Scout SDK
npm install @aura-labs-ai/scout

# Configure with your API key
export AURA_API_KEY=your_api_key

# Run the example Scout
npm run example

✓ Scout connected to AURA Core
✓ Ready to register intent
Scout Operations →
For Seller Applications

Beacon Framework

Add selling agent capabilities to e-commerce backends, ERP systems, or any platform that manages inventory and pricing.

# Install the Beacon SDK
npm install @aura-labs-ai/beacon

# Run your beacon
node my-beacon.js

✓ Beacon registered with AURA Core
✓ Polling for buyer sessions...
Beacon Operations →

SDKs & Libraries

Every SDK wraps the same signed /v1/* operations, generated from the contract. Keys and portal access are in the Developer Portal.

JS

JavaScript / Node.js

Official

Wraps the Scout and Beacon operations for Node.js and modern browsers, generated from the contract.

Access in Portal →
PY

Python

Official

Wraps the same operations server-side, typed from the contract schemas.

Access in Portal →
TS

TypeScript Types

Official

The request and response types for every operation, emitted from openapi.json.

Access in Portal →
v1

REST API

Any Language

The protocol itself. One transport: REST over /v1/*, signed with the Ed25519 X-Agent-Id, X-Agent-Timestamp, and X-Agent-Signature headers.

API Reference →