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 builtt3n 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:
agent-auth-update scoping the agent to your contract, its functions, and the hosts it may reach:
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.