canonical: https://jentic.com/apis/googleapis.com/versionhistory

# Google Chrome Version History API

The Chrome Version History API exposes the same release data that powers the Chrome version dashboard, enabling automation that reads channels, platforms, releases, and individual versions. Tooling can identify the current Stable, Beta, Dev, and Canary versions per platform, see when each version was promoted, and pin compatibility tests to known release builds. The API is read-only and unauthenticated for public release data.

## For AI agents

Look up Chrome release channels, platforms, releases, and versions so an agent can pin tests, alert on new builds, or generate compatibility reports.

## Scope

Does not handle Chrome browser deployment, policy enforcement, or device management - use for read-only Chrome release metadata only.

## Capabilities

- List the available Chrome release channels including Stable, Beta, Dev, and Canary
- Enumerate the platforms Chrome ships on, from Windows and Mac to Android and iOS
- Look up every release event for a channel and platform with promotion dates
- Retrieve specific Chrome versions with version strings and build identifiers
- Detect when a new Chrome Stable version has been promoted on a target platform

## Use cases

### Browser Compatibility Test Pinning

QA and release teams pin browser automation jobs to specific Chrome versions to keep test results reproducible across CI runs. The Version History API returns the canonical version strings per channel and platform, which the test harness uses to download the matching ChromeDriver and Chrome binary. This eliminates drift caused by silent Chrome auto-updates and gives test failures a stable version coordinate.

Example prompt: Get the current Stable Chrome version on Linux and emit it to the CI environment for ChromeDriver matching

### Release Monitoring and Alerting

Web platform teams subscribe to a polling job that calls the Version History API hourly and alerts when a new Stable or Beta release has been promoted on production-relevant platforms. The releases endpoint returns promotion timestamps so the alert payload can include both the version number and the rollout date. This replaces the need to scrape the Chrome status dashboard.

Example prompt: List the latest Stable releases on Windows and notify Slack if the most recent timestamp is within the last 24 hours

### Compatibility Documentation and Reporting

Developer relations and documentation teams generate compatibility tables that show when a Chrome feature shipped to Stable on each platform. The Version History API supplies the historical release timeline, letting docs render charts that stay in sync with the actual Chrome release cadence. The data is fully read-only and unauthenticated, so docs can call it from public CI pipelines.

Example prompt: List every Stable release on Mac for the past year and produce a markdown table of versions and dates

### AI Agent Browser Tooling Helper

An AI agent integrated through Jentic answers prompts like 'what version of Chrome should I test against?' by discovering the Version History API by intent search, calling the releases endpoint for the requested channel and platform, and returning the most recent version with its promotion date. Because the API requires only a Google API key, Jentic stores the key in your Jentic One instance and exposes a scoped reference at execution time.

Example prompt: Search Jentic for chrome stable version and call the releases endpoint for win64 Stable

## Key endpoints

| Method | Path | Description |
| --- | --- | --- |
| GET | /v1/{+parent}/channels | List Chrome release channels |
| GET | /v1/{+parent}/platforms | List supported platforms |
| GET | /v1/{+parent}/versions | List Chrome versions for a parent channel and platform |
| GET | /v1/{+parent}/releases | List release events with promotion timestamps |

## Key resources

- **Channels** — Enumerate Chrome release channels (Stable, Beta, Dev, Canary, ExtendedStable)
- **Platforms** — Enumerate the platforms Chrome ships on (Windows, Mac, Linux, Android, iOS, ChromeOS)
- **Versions** — Look up every Chrome version that has shipped on a given platform and channel
- **Releases** — List release events with promotion timestamps for a given channel and platform

## Why Jentic

- **Setup:** Wiring the Chrome Version History API by hand means provisioning a Google API key, attaching it to each request for quota, and building the platform and channel parent path templates yourself. Through Jentic you install once, import the Chrome Version History API from the API Directory, store the API key once, and your agent calls it.
- **Permission scoping:** Chrome Version History carries the platform and channel parent in the URL path (/v1/{parent}/versions), and every operation is read-only, so the agent only reads release metadata and never mutates anything. You choose the operations it may call, so it is limited to the channel, platform, version, and release lookups you allow.
- **Credential handling:** Your Chrome Version History API key is stored once, encrypted, by your own Jentic One instance and injected at execution time. It never enters the agent's prompt, logs, or context.
- **Discovery method:** Agents search Jentic by intent such as 'find the current chrome stable version', and Jentic returns the releases operation with its input schema, including the parent path format, so the agent calls the right endpoint without browsing the reference docs.

## Related APIs

- **Chrome Management API** — Manage the Chrome browser fleet whose versions Version History reports
- **Chrome Policy API** — Set Chrome update and channel policies for managed devices
- **Cloud Monitoring API** — Emit alerts when Version History reports a new Stable promotion

## FAQ

### What authentication does the Chrome Version History API use?

The Chrome Version History API accepts an unauthenticated read for public data and supports an optional Google API key passed as the api_key query parameter to attribute usage to a Cloud project. Through Jentic, the API key is stored encrypted in your Jentic One instance and only a scoped reference is exposed to the agent.

### Can I get the current Chrome Stable version with the Chrome Version History API?

Yes. Call GET /v1/chrome/platforms/{platform}/channels/stable/versions to list current Stable versions for a platform such as win64, mac, or linux. The first entry is the most recently shipped Stable build with its full version string.

### What are the rate limits for the Chrome Version History API?

Google enforces standard Cloud per-project quotas on Version History with a default of about 600 requests per minute per project. Anonymous unauthenticated callers are subject to per-IP throttling that is lower but unspecified; high-volume callers should attach a Cloud project API key.

### How do I monitor new Chrome releases through Jentic with the Version History API?

Install Jentic with pip install jentic, search for chrome stable version, load the schema for the releases endpoint, and run it on a schedule against the channel and platform you care about. Compare the most recent serving timestamp to your last seen value and trigger an alert when it advances.

### Does the Chrome Version History API include ChromeOS and mobile versions?

Yes. The platforms endpoint returns ChromeOS, Android, iOS, Windows, Mac, and Linux entries. You can request versions and releases under any platform, though the channel availability differs (for example, ChromeOS exposes the LongTermSupport channel that desktop platforms do not).

### Why does my Version History query return an empty versions list?

Empty results usually indicate an unsupported channel-platform combination or a malformed parent path. Use GET /v1/chrome/platforms/{platform}/channels to list valid channels for that platform before requesting versions or releases.

### Can I limit what my agent is allowed to do with the Chrome Version History API?

Yes. Because Jentic One is self-hosted, your own rules decide which of the Chrome Version History operations the agent may call, so you can allow only the channels, platforms, versions, and releases lookups it actually needs. Every operation is read-only and scoped by the platform and channel parent in the URL path (/v1/{parent}/versions), so the agent only reads release metadata and never mutates anything. Your Google API key is stored encrypted by your own instance and injected at execution time, so it stays out of the agent's prompt and context.