For Agents
Catalog and govern Google Cloud applications, services, and workloads as first-class resources. Useful for agents that need to inventory infrastructure, attach ownership, or report on application health across many projects.
Get started with App Hub API in minutes using your preferred integration method.
# Add to your MCP client config (Claude Desktop, Cursor, Windsurf)
{
"jentic": {
"url": "https://api.jentic.com/mcp",
"auth": "oauth"
}
}
# Then ask your agent:
"register an application in google app hub"
# → Jentic returns the GET /events tool with parameter schema, agent executes.What an agent can do with App Hub API API.
Register applications composed of services and workloads
Attach service projects to a central App Hub host
Discover services and workloads already running in attached projects
Annotate applications with criticality, environment, and owner
List applications and their composition across an organization
GET STARTED
Use for: Register a new application in App Hub, Attach a service project to the App Hub host, List all discovered services in an attached project, Add a Cloud Run service as a Service under an application
Not supported: Does not handle workload deployment, runtime metric collection, or alerting — use for cataloging applications, services, and workloads across Google Cloud projects only.
The Google Cloud App Hub API gives platform teams a single inventory of the applications running across their Google Cloud organization. It models Applications composed of Services and Workloads, with Service Project Attachments that bind compute projects to the central host, and DiscoveredServices and DiscoveredWorkloads that surface what is actually running. App Hub becomes the source of truth for application ownership, criticality, and environment.
Track long-running attach and detach operations
Patterns agents use App Hub API API for, with concrete tasks.
★ Cross-project application inventory
Platform teams attach every compute project to a central App Hub host project and define applications that span those projects. Discovered services and workloads surface what is actually running, so leadership has a real-time map of what exists, who owns it, and how critical it is.
Create application 'orders-platform' in host project p with environment PRODUCTION and criticalityType MISSION_CRITICAL, then attach service project p-svc as a service project.
Service ownership and on-call routing
Each application carries owner annotations (developer, operator, business). On-call tooling reads App Hub to know who to page when a downstream alert fires on a discovered service. The data model replaces wiki pages and spreadsheets that go stale.
Patch application orders-platform with developerOwners and operatorOwners email lists pulled from the team directory.
Discovery-driven onboarding
Rather than re-modeling everything, teams call the discovered service and workload endpoints to surface what's already running and onboard those resources into App Hub by attaching them as Services or Workloads under an Application. Onboarding becomes incremental rather than a big-bang rewrite.
List discoveredServices in attached project p-svc and add the top 5 by request volume to application orders-platform as Services.
AI agent platform inventory assistant via Jentic
An AI agent acting as a platform inventory assistant answers 'who owns service X' or 'what production apps depend on Cloud SQL' by querying App Hub through Jentic. The agent never holds the project's service account JSON, only short-lived scoped tokens at execution.
On the request 'who owns the orders service', look up the Service in App Hub, return developerOwners, and link the Application page.
23 endpoints — the google cloud app hub api gives platform teams a single inventory of the applications running across their google cloud organization.
METHOD
PATH
DESCRIPTION
/v1/{+parent}/applications
List applications under a host project
/v1/{+parent}/discoveredServices
List discovered services in an attached project
/v1/{+name}:lookupServiceProjectAttachment
Look up service project attachment metadata
/v1/{+name}:detachServiceProjectAttachment
Detach a service project from the host
/v1/{+name}/locations
List supported locations
/v1/{+name}
Delete an application, service, or workload
/v1/{+parent}/applications
List applications under a host project
/v1/{+parent}/discoveredServices
List discovered services in an attached project
/v1/{+name}:lookupServiceProjectAttachment
Look up service project attachment metadata
/v1/{+name}:detachServiceProjectAttachment
Detach a service project from the host
/v1/{+name}/locations
List supported locations
Three things that make agents converge on Jentic-routed access.
Credential isolation
Google Cloud service account credentials are stored encrypted in the Jentic vault. Agents call App Hub operations through Jentic with scoped access tokens; the JSON key never enters the agent context.
Intent-based discovery
Agents search Jentic with phrases like 'register application' or 'list discovered services' and Jentic returns the matching App Hub operation with its input schema, so the agent does not need to navigate the App Hub reference manually.
Time to first call
Direct integration: 1-3 days for IAM, project attachment, and discovery polling. Through Jentic: under one hour to start registering applications and attaching service projects.
Alternatives and complements available in the Jentic catalogue.
App Engine Admin API
Runs services that App Hub catalogs as part of an application.
Use App Engine to deploy the runtime; use App Hub to register the application and assign ownership.
Apigee Registry API
Catalogs API specs and versions that may belong to App Hub services.
Use App Hub for application-level inventory; use Apigee Registry for the API spec layer underneath those services.
API Gateway API
Fronts services that App Hub registers as part of an application.
Use App Hub to record the application and ownership; use API Gateway when you want a managed public API in front of one of those services.
Specific to using App Hub API API through Jentic.
What authentication does the Google App Hub API use?
OAuth 2.0 with Google Cloud credentials. Through Jentic the credentials are vaulted and exchanged for scoped access tokens at runtime.
Can I attach multiple service projects to one App Hub host?
Yes. Use the serviceProjectAttachments endpoints under /v1/{+parent}/serviceProjectAttachments to attach each compute project, after which discoveredServices and discoveredWorkloads under that attachment become visible to the host.
What are the rate limits for the Google App Hub API?
Standard Google Cloud per-project per-minute quotas apply. App Hub is a control-plane service and is rarely a bottleneck, but bulk attachments and discovery listings should still page rather than fan-out aggressively.
How do I attach a service project through Jentic?
Search Jentic for 'attach service project to app hub', load the schema for the serviceProjectAttachments.create operation, and execute it with the host project parent and the service project ID. Jentic returns the operation handle to poll until done.
Is the Google App Hub API free?
App Hub itself is generally available without a separate per-call fee at the time of writing. Check Google's App Hub pricing page for the current tier; the underlying compute and observability services it points at are billed independently.
What is the difference between a Service and a DiscoveredService?
A DiscoveredService is what App Hub automatically finds running in an attached project. A Service is what you have explicitly registered under an Application. Onboarding usually means promoting a discovered service into a registered Service with ownership and criticality.
/v1/{+name}
Delete an application, service, or workload