Skip to main content
Agents call your contract via the same execute transport as any other T3N contract. The only difference is the contract_id starts with z:<tid>:.
Agents authenticate as themselves, not as tenants. Like every T3N session, an agent reads its own DID back from the authenticated session — there’s nothing tenant-specific to set.

1. Set up the agent’s identity

An agent is a separate authenticated session with its own key — it is not the tenant and not the user. Build it the same way you built t3n in Quickstart, but with its own credential:
Where AGENT_KEY comes from. An agent’s key is not derived from your tenant key — get it the same way you got your own, from the claim page. It needs its own test credits too: an agent DID’s balance is separate from its tenant’s and starts at zero, so a key generated any other way (or your tenant’s key, reused) will fail metered calls with InsufficientCreditError. See Register a Public Agent for the full flow.

2. Authorize the contract’s egress (as the user)

Before any function that makes an outbound HTTP call can run, the user (data owner) must authorize it. A tenant contract’s allowed hosts are resolved per-call from the user’s authorization grant — not from the contract. In this walkthrough you’re standing in for the user yourself, so build a third session — userClient — with its own credential, exactly like t3n and agentClient above:
Now the user signs an agent-auth-update scoping the agent to your contract, its functions, and the hosts it may reach:
For a direct (self) call — where the user invokes the contract themselves rather than through a separate agent — set agentDid to the user’s own DID (a self-grant) instead of building a separate agentClient. Without a matching grant the contract still runs, but any outbound call is denied with host/http.egress_denied. See Outbound HTTP is authorized by the user, not the contract.

3. Invoke your contract (as the agent)

With the grant in place, the agent can call the contract’s functions: