Skip to main content
Agent API Server provides application discovery, session management, agent execution, artifacts, and memory ingestion. This section documents the Google ADK HTTP service, including the corresponding endpoints exposed when veadk web loads VeADK agents This reference uses Google ADK 2.2.0 as its interface baseline. VeADK supports a broad dependency range, so the endpoints available in a deployment depend on its installed Google ADK version. Check GET /version before integrating

​
Choose a service

These endpoints are separate from AgentKit cloud resource management APIs and do not describe every custom HTTP route an application may expose after deployment to AgentKit

​
Start the server

Install the Google ADK version used by this reference in a dedicated Python environment:
For VeADK agents, follow VeADK installation and the quickstart, then confirm the Google ADK version in the same environment Prepare an agent application using the ADK directory layout, such as agents/travel_assistant/agent.py exporting root_agent. Configure the model credentials and application dependencies in the server environment From the project root containing agents, run:
For VeADK memory integration and the evaluation and debugging UI, use:
The base URL is http://localhost:8000. Verify the server version and available applications:
Evaluation requires additional dependencies. Install the extension matching the server version to avoid changing the API baseline:
Local session and artifact storage is enabled by default. Explicit storage URIs or disabling local storage change this behavior. Unless --auto_create_session is enabled, create a session before calling /run or /run_sse

​
Make the first call

Choose an application from /list-apps, create a session under that application and the intended user, and keep the returned id. Use these three identifiers to run an agent or stream its events. Then get the session to read its saved state and events Events can contain text, tool calls, or state and artifact updates; not every event is a final answer. With SSE, handle in-stream errors as well. HTTP 200 alone does not establish that the entire invocation succeeded

​
Addresses and fields

Use the field names shown on each endpoint page. Most models use camelCase fields such as appName, sessionId, and newMessage. Some models, including evaluation sets, retain snake_case fields such as eval_set_id and eval_cases; do not rename fields globally Google ADK 2.x moved evaluation and debugging into the development namespace. Older paths such as /apps/{app_name}/eval-sets or /debug/trace/... do not apply to this baseline. The compatibility group includes only paths that the current server still exposes

​
Authentication and interactive requests

Examples assume a local server without configured login authentication and do not require a universal API key. user_id identifies a session namespace; it does not authenticate the caller. If a deployment uses VeADK OAuth2, gateway authentication, or another access control mechanism, follow that deployment’s authentication requirements. Model API keys are not server access credentials
Sessions, artifacts, memory, and traces may contain user data. The examples bind only to the local machine. Configure authentication and access control before exposing the server, and restrict development endpoints to trusted callers
Endpoint pages display methods, paths, parameters, request bodies, response schemas, and language examples. Interactive requests are real requests: use the deployment’s server address and meet its authentication, connectivity, and cross-origin requirements. Delete and replace operations modify real data Use curl -N to inspect live streaming events; the interactive request panel may not render each event as it arrives. /run_live uses WebSocket, while A2A and optional triggers use separate protocols and are outside the default HTTP endpoint scope of this section
Last modified on September 19, 2026