Docs
⌕ ⌘K
Onboarding / Registering agents

Registering agents

Registration turns a principal's software into an accountable economic actor: it gets a permanent identifier, a signed identity document, a certificate other agents can verify, and — for a business agent that sells — an escrow wallet and settlement configuration.

Before you start

An agent must belong to a principal, so register the principal first. The principal’s verified tier is what allows Nustro to register an agent of a given type at all.

What registration produces

ArtifactWhat it is
DIDThe agent’s permanent identifier, did:aeap:{uuid4}. Opaque, case-sensitive, and stable for the life of the agent — it survives key rotation, environment promotion, and transfer to a new principal.
AIDThe Agent Identity Document: one signed record organised into five pillar objects (identity, performance, escrow, disputes, governance). Which pillars are populated depends on what the agent does.
CertificateAn ES256 JWT binding the agent’s public key to its stable claims. This is what counterparties verify — offline, without contacting Nustro.
Key pairEC P-256. The private key is delivered once and never stored.
Escrow walletBusiness agents that sell only. A segregated on-chain account, provisioned by Nustro, with the settlement split registered on-chain.

Choose the type and actions first

An agent’s agent_type says whom it acts for, and its authorized_actions say what it may do. Both are fixed at registration — no scope update changes them, and the only change of type is the in-place upgrade from personal to business. Getting either wrong usually means registering a new agent and losing the DID, the rating, and the transaction history attached to it. They are the fields worth confirming with your principal before you call the API.

PersonalBusiness
TypeBuysSellsEscrowRequired verification tier
PersonalYes — purchase is requiredNoNone — liability runs through spending limitsTier 1 — in practice a card authorization or address document; individual principals only
BusinessWith purchaseWith sellMUST maintain when it sells, sized on what it sellsTier 2 — KYC/KYB, business registration (a sole proprietor’s business license qualifies), beneficial ownership
One agent can buy and sell

A business agent may carry both purchase and sell — a seller that also buys the services it resells, for instance. It stays one agent with one Agent Rating, a blend of its seller and buyer records weighted by transaction value, so there is no reason to split such a business into two agents. Its escrow covers only what it sells; its spending limit governs only what it buys.

Nustro checks the tier; the verification is yours

The type ↔ verification-tier coupling is normative. Nustro checks the principal’s asserted tier at registration and again at activation, and rejects an agent whose type it does not meet with verification_tier_insufficient. The check is only as good as the assertion behind it — which is your platform’s. AEA/P §5.2.1. Read §5.2 ↗

The registration flow

Three calls. The agent is not usable until the third.

Register the agent. POST /v1/agents with the principal, agent type, authorized actions, and initial scope. Nustro returns the full AID in DRAFT — it exists, but it cannot transact.
Activate it. POST /v1/agents/{did}/activate. Nustro generates the key pair, issues the certificate, signs the AID, and moves it to ACTIVE. The private key is in this response and nowhere else.
Configure settlement. For a business agent that sells, POST /v1/agents/{did}/scope/authorized_markets sets its markets, provisions the escrow wallet and registers the split on-chain. Agents that only buy skip this.

Registering the agent

cURL
curl -X POST https://api.nustro.com/v1/agents \
  -H "Nustro-Api-Key: nustro_sandbox_••••" \
  -H "Idempotency-Key: 8f2c1a90-4d3e-4b77-9c11-2ad5e6b70f31" \
  -d '{
    "principal_id": "prn_7c4e21",
    "agent_type": "BUSINESS",
    "authorized_actions": ["sell"],
    "capabilities": ["fulfilment", "tracking"],
    "profile": {
      "display_name": "northwind-fulfilment",
      "description": "Order fulfilment and tracking"
    },
    "endpoint_url": "https://agents.northwind.example/fulfil"
  }'
Scope is a protocol object

Every dimension of scope — authorized actions, capabilities, transaction ceilings, counterparty floors — is enforced both down the delegation chain and over the life of the AID. The full schema and the mutability rules per dimension are in AEA/P §5.3. Read §5.3 ↗

Activation and the key pair

Activation is the only moment the private key exists outside the agent. Nustro stores the public key and the certificate; the private key is returned once and discarded.

{
  "did": "did:aeap:d2146ca7-fbbd-4167-b725-b5ca2ebbb6da",
  "status": "ACTIVE",
  "private_key": "-----BEGIN PRIVATE KEY-----…",
  "public_key": "-----BEGIN PUBLIC KEY-----…",
  "certificate": "eyJhbGciOiJFUzI1NiIsImtpZCI6…",
  "status_url": "https://api.nustro.com/v1/agents/…/status"
}
Nustro enforces

The private key appears in this response and never again. If your platform loses it, the only recovery is POST /v1/agents/{did}/rotate-key, which issues a new pair and re-signs the AID — the agent keeps its DID, rating, and history, but every deployment holding the old key stops working immediately. Send an Idempotency-Key on activation so a network timeout does not cost you the key.

Hand the private key to the principal, or write it into the agent’s runtime configuration, and do not persist it in your own systems. Your platform does not need it: it authenticates to Nustro with its own management key, and the agent authenticates with its certificate and proofs.

Provisioning settlement

A business agent that sells needs somewhere for money to land. This call sets the markets it sells in and its operational wallet on each network, provisions the escrow wallet, and writes the split configuration on-chain. The markets list replaces the current one on every call.

cURL
curl -X POST https://api.nustro.com/v1/agents/{did}/scope/authorized_markets \
  -H "Nustro-Api-Key: nustro_sandbox_••••" \
  -d '{
    "markets": ["GB-USDC"],
    "wallets": [{
      "network": "arc-testnet", "operational_wallet": "0x7f3a…"
    }]
  }'
Nustro enforces

The escrow wallet is provisioned under Nustro’s control, and the funding rate comes from Operator-held configuration. A seller that could set its own rate could carry no coverage, so neither the principal nor your platform can modify it. The operational wallet stays with the principal — Nustro cannot sign for it.

Upgrading a personal agent to business

A personal agent can become a business agent in place — the same DID, rating history and dispute record. Verify the principal to Tier 2 first, then upgrade with the action set the business agent should carry.

cURL
curl -X POST https://api.nustro.com/v1/agents/{did}/upgrade-type \
  -H "Nustro-Api-Key: nustro_sandbox_••••" \
  -d '{
    "authorized_actions": ["purchase", "sell"]
  }'

Nustro reissues the certificate and re-signs the AID. Adding sell here only declares it: the agent cannot sell until its markets and escrow are configured with POST /v1/agents/{did}/scope/authorized_markets. The reverse — business to personal — is not supported; register a new personal agent.

CodeStatusWhat it means
invalid_type_transition409The agent is not a personal agent, or not ACTIVE.
verification_tier_insufficient409The principal is not verified to Tier 2 yet.
tier_exceeds_accreditation403cert_tier: "business" was requested by a platform not accredited to issue it.

Agent states

Counterparties resolve state before transacting. The usual path is DRAFT → ACTIVE → REVOKED.

StateMeaningCan transact?
DRAFTRegistered but not yet activated — no keys, no certificateNo
ACTIVESigned and operationalYes
SUSPENDEDTemporarily halted — escrow entered CONSTRAINED, the verification attestation expired, or the principal suspended itNo new transactions
REVOKEDPermanently invalidated by the principal. Open disputes still resolve and the performance record is retainedNo
TRANSFERREDOwnership moved to a new principal; escrow and rating follow the agentYes, under the new principal
ABANDONEDA draft never activated within the timeoutNo — terminal
Certificate validity is not status

A certificate can be cryptographically valid while the agent behind it is suspended. That is why counterparties verify the certificate offline and then resolve live status separately. The status-resolution fields are normative in AEA/P §5.6.5. Read §5.6 ↗

Common errors

CodeStatusWhat it means
cert_tier_type_mismatch422The certification tier does not match the agent type. PERSONAL accepts provisional or personal; BUSINESS accepts provisional or business. Field-level, inside field_errors.
authorized_action_type_mismatch422The actions do not fit the type — a personal agent declaring sell, or a business agent with neither purchase nor sell. Field-level, inside field_errors.
verification_tier_insufficient422The principal’s tier is below the type’s requirement — Tier 1 for personal, Tier 2 for business. Assert it with PUT /v1/principals/{pid}/verification. Returned as 409 by activation, if the tier has since fallen short.
principal_type_mismatch422A personal agent was registered under a company principal.
tier_exceeds_accreditation403The requested certification tier exceeds what your platform’s own accreditation permits — not a statement about the principal.
validation_failed422A field or scope dimension is invalid. field_errors[] names each one; correctable in place.
invalid_status409Activation was called on an agent that is not in DRAFT. Re-read the agent; it may already be active.
invalid_market_format422The jurisdiction-currency format is invalid. Field-level, inside field_errors.

Next