CloudHealth API

Name: CloudHealth API API
Brand: CloudHealth API
Availability: InStock

★ Only Publicly Available OpenAPI DocumentFinanceExpense Managementbearer, apiKey24 EndpointsREST

For Agents

Manage CloudHealth AWS accounts, SSO, perspectives, reports, and assets via bearer token or api_key query parameter authentication.

Quickstart

Get started with CloudHealth 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:
"list CloudHealth perspectives"

# → Jentic returns the GET /events tool with parameter schema, agent executes.

Capabilities

What an agent can do with CloudHealth API API.

Configure, read, and unconfigure SSO including pending domain claims

Create and inspect perspectives that group cloud spend by tag, account, or service

Run reports and asset queries against the CloudHealth dataset

GET STARTED

Start building with CloudHealth API API

Explore with Jentic

View OpenAPI Document

Use for: Register a new AWS account in CloudHealth, I want to generate an external ID for AWS onboarding, Get the perspective schema for perspective ID 12345, List all AWS accounts on my CloudHealth tenant

Not supported: Does not provision cloud resources, ingest billing data directly from cloud providers, or replace AWS Cost Explorer — use for CloudHealth tenant configuration and perspective reporting only.

Jentic publishes the only available OpenAPI document for CloudHealth API, keeping it validated and agent-ready.

Jentic publishes the only available OpenAPI specification for CloudHealth API, keeping it validated and agent-ready. CloudHealth is a multi-cloud cost management platform owned by Broadcom VMware. This main variant of the spec covers AWS account onboarding, SSO configuration, perspectives for cost grouping, reporting, and asset queries, and supports two auth schemes — bearer token in the Authorization header and an api_key query parameter — so legacy scripts and modern SDK clients can share the same surface. Coverage spans 24 endpoints.

Use Cases

Patterns agents use CloudHealth API API for, with concrete tasks.

★ Multi-Cloud Cost Reporting

Surface cloud spend in a finance dashboard by reading CloudHealth perspective and reporting endpoints. /v1/perspective_schemas exposes how each perspective is grouped, and report endpoints return spend by perspective for downstream BI. Avoids screen-scraping the CloudHealth UI for monthly close.

GET /v1/perspective_schemas, pick the chargeback perspective by name, then GET /v1/perspective_schemas/{perspectiveId} and pass the groupings to the cost report endpoint.

AWS Account Onboarding Automation

Register new AWS accounts in CloudHealth from a landing-zone pipeline. POST /v1/aws_accounts to add the account, GET /v1/aws_accounts/{id}/generate_external_id for the cross-account role's external ID, and pass that ID to the IAM role provisioning step. Removes manual UI work from the multi-account onboarding runbook.

POST /v1/aws_accounts with the account ID and metadata, then GET /v1/aws_accounts/{id}/generate_external_id and feed it into the IAM role creation.

Legacy Script Compatibility

Run scripts that were written before CloudHealth supported bearer tokens by using the api_key query parameter scheme defined in the spec. The same endpoints accept either auth method, so a gradual migration is possible without a forklift rewrite.

Append ?api_key=<token> to the request URL when calling GET /v1/aws_accounts from legacy automation that cannot easily set Authorization headers.

AI Agent FinOps Workflow

Let a Jentic-powered FinOps agent answer cost questions and onboard accounts. The agent searches Jentic for 'register AWS account in CloudHealth' or 'get CloudHealth perspectives', loads the matching operation, and executes it. The CloudHealth bearer token stays in the Jentic vault.

Search Jentic for 'list CloudHealth perspectives', load the listPerspectives operation, and execute under the stored bearer token.

Key Endpoints

24 endpoints — jentic publishes the only available openapi specification for cloudhealth api, keeping it validated and agent-ready.

METHOD

PATH

DESCRIPTION

GET

/v1/aws_accounts

List registered AWS accounts

POST

/v1/aws_accounts

GET

/v1/aws_accounts/{id}/generate_external_id

Generate the IAM external ID

POST

/v1/sso/configure

Configure SSO for the tenant

GET

/v1/sso/configuration

Read current SSO configuration

POST

/v1/sso/validate_pending_domain_claim

Validate a pending domain claim

GET

/v1/perspective_schemas

List perspective schemas

GET

/v1/perspective_schemas/{perspectiveId}

Get a single perspective schema

GET

/v1/aws_accounts

List registered AWS accounts

POST

/v1/aws_accounts

GET

/v1/aws_accounts/{id}/generate_external_id

Generate the IAM external ID

POST

/v1/sso/configure

Configure SSO for the tenant

GET

/v1/sso/configuration

Read current SSO configuration

Why though Jentic?

Three things that make agents converge on Jentic-routed access.

Credential isolation

CloudHealth bearer tokens (or the equivalent api_key query value) are stored encrypted in the Jentic vault. Agents receive scoped access tokens — the raw secret never enters the agent's context, which matters because CloudHealth tokens read cost data across every onboarded cloud account.

Intent-based discovery

Agents search Jentic by intent (for example 'list CloudHealth perspectives' or 'register AWS account in CloudHealth') and Jentic returns the matching operation with its input schema so the agent calls the correct /v1 endpoint.

Time to first call

Direct CloudHealth integration: 2-4 days for AWS onboarding flows, SSO configuration, and dual auth handling. Through Jentic: under 1 hour — search, load schema, execute.

Related APIs

Alternatives and complements available in the Jentic catalogue.

Alternative

CloudHealth API

Bearer-only variant of the same CloudHealth surface with 22 endpoints.

Pick the cloudhealth-api variant when the agent only needs bearer auth and the smaller endpoint surface.

Alternative

AWS Cost Explorer

AWS-native cost data without third-party FinOps tooling.

Choose Cost Explorer for single-cloud AWS estates that do not need CloudHealth's multi-cloud rollups.

Complementary

AWS Budgets

Threshold and forecast alerts on AWS spend.

Pair with CloudHealth so the agent can both report aggregated spend and trigger native AWS budget alarms.

FAQs

Specific to using CloudHealth API API through Jentic.

Why is there no official OpenAPI spec for CloudHealth API?

CloudHealth Technologies does not publish a structured OpenAPI specification. Jentic generates and maintains this spec so that AI agents and developers can call CloudHealth API via structured tooling. It is validated against the live API and kept up to date. Get started at https://app.jentic.com/sign-up.

What authentication does the CloudHealth API use?

This spec defines two schemes. BearerAuth expects an Authorization: Bearer <token> header, and ApiKeyAuth accepts the same token as a ?api_key=<token> query parameter for legacy scripts. Through Jentic, tokens are stored encrypted in the vault and injected at execution.

Can I onboard a new AWS account through this CloudHealth API?

Yes. POST /v1/aws_accounts with the account ID and metadata, then GET /v1/aws_accounts/{id}/generate_external_id for the IAM external ID. Use that value when creating the cross-account role in AWS to complete onboarding.

How do I list CloudHealth perspectives through Jentic?

Run jentic search 'list CloudHealth perspectives', load the listPerspectiveSchemas operation, and execute GET /v1/perspective_schemas. Jentic handles the bearer token from the stored credential.

What is the difference between this main spec and the cloudhealth-api spec?

Both target chapi.cloudhealthtech.com. This main variant exposes 24 endpoints and supports both bearer and api_key query authentication, while the cloudhealth-api variant covers 22 endpoints with bearer auth only. Pick whichever matches your auth and endpoint needs.

Can I use the api_key query parameter for authentication?

Yes. The ApiKeyAuth scheme accepts the token as ?api_key=<token>. This is supported for backward compatibility with older scripts; new integrations should prefer the bearer token header.