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

# Google Analytics Hub API

Analytics Hub is Google Cloud's data exchange built on top of BigQuery. The API manages data exchanges, listings (the published shareable assets), and subscriptions (the consumer side that surfaces a listing in a destination project's BigQuery dataset). It supports listing, creating, subscribing, refreshing, and revoking these resources, plus IAM-style policy management on each. It is intended for organisations that publish or consume data products across project, team, or organisation boundaries.

## For AI agents

Publish, subscribe to, and manage shared BigQuery data products via Analytics Hub data exchanges, listings, and subscriptions.

## Scope

Does not run BigQuery queries, copy datasets, or manage compute reservations - use for Analytics Hub data exchanges, listings, and subscriptions only.

## Capabilities

- List data exchanges available within an organisation or under a project parent
- Create a new listing in an exchange that publishes a BigQuery dataset for sharing
- Subscribe a destination project to a published listing so it appears as a linked dataset
- Refresh a subscription to pull the latest version of a published dataset
- Revoke a subscription to stop a consumer from accessing a shared listing
- Read and update the IAM policy on an exchange or listing for fine-grained access control
- List subscriptions on a listing to audit which consumer projects have access

## Use cases

### Cross-Team Data Product Publishing

A central data platform team curates BigQuery datasets and wants other teams across the organisation to subscribe to them rather than duplicating or copying tables. The Analytics Hub API creates a data exchange, registers a listing pointing at the source dataset, and exposes the listing for consumers to subscribe to. The consumer's BigQuery sees a linked dataset with no copy or storage cost.

Example prompt: POST /v1/{+parent}/dataExchanges to create the exchange, then POST /v1/{+parent}/listings with a bigqueryDataset source pointing at projects/{p}/datasets/{ds}.

### Consumer Subscription Workflow

A consumer team wants to subscribe to a published listing so the dataset appears in their own BigQuery project. Calling :subscribe on the listing creates a linked dataset in the destination project. :refresh keeps the subscription current after the publisher updates the source, and :revoke ends access. This replaces ad-hoc table copies and email requests for access.

Example prompt: POST /v1/{+name}:subscribe on the listing with destinationDataset set to the consumer's project, then schedule periodic POST /v1/{+name}:refresh on the resulting subscription.

### Access Audit on Shared Listings

Compliance teams need to know which consumer projects subscribe to a sensitive listing and revoke any that should no longer have access. List subscriptions on the listing returns each consumer subscription, and per-subscription IAM gives the binding details. A periodic audit job iterates these and emits a report.

Example prompt: List subscriptions under the listing, GET /v1/{+name} for each to capture state and consumer project, and surface anything that no longer matches the access policy.

### Agent-Led Data Sharing

An agent integrating Analytics Hub through Jentic can interpret 'share this dataset with the analytics team' as a chain of create-listing and subscribe operations. Jentic isolates the Google Cloud service account and exposes the operation schemas, so the agent does not need bespoke OAuth or BigQuery dataset wiring code - the data exchange, listing, and subscription steps are direct tool calls.

Example prompt: Use the Jentic search query 'create an Analytics Hub listing' to discover /v1/{+parent}/listings, create the listing, then call :subscribe to attach the consumer project.

## Key endpoints

| Method | Path | Description |
| --- | --- | --- |
| GET | /v1/{+organization}/dataExchanges | List data exchanges visible to an organisation |
| GET | /v1/{+parent}/dataExchanges | List data exchanges under a project parent |
| GET | /v1/{+parent}/listings | List listings under a data exchange |
| GET | /v1/{+parent}/subscriptions | List subscriptions under a parent |
| POST | /v1/{+name}:subscribe | Subscribe a consumer project to a listing |
| POST | /v1/{+name}:refresh | Refresh an existing subscription |
| POST | /v1/{+name}:revoke | Revoke a subscription |

## Key resources

- **Data Exchanges** — Top-level container for shared listings within an organisation or project
- **Listings** — Published BigQuery datasets attached to an exchange
- **Subscriptions** — Consumer-side binding that surfaces a listing in a destination BigQuery project
- **IAM Policies** — Per-resource access policies on exchanges, listings, and subscriptions

## Why Jentic

- **Setup:** Wiring the Analytics Hub API by hand means configuring Google OAuth 2.0 from a service account, rotating short-lived access tokens yourself, and pointing calls at the analyticshub.googleapis.com host. Through Jentic you install once, import the Analytics Hub API from the API Directory, store the OAuth credential once, and your agent calls it.
- **Permission scoping:** Analytics Hub puts the parent and resource names in the URL path (/v1/{+parent}/dataExchanges, /v1/{+name}:subscribe), so a rule can pin your agent to one project's exchanges and listings: it can read them and nothing else. You choose the operations it may call, so actions like subscribe, refresh, or revoke are not included unless you add them.
- **Credential handling:** Your Google service account credential is stored once, encrypted, by your own Jentic One instance and rotated into short-lived access tokens at execution time. The key never enters the agent's prompt, logs, or context.
- **Discovery method:** Agents search Jentic by intent such as 'create an Analytics Hub listing' or 'subscribe to a data exchange', and Jentic returns the matching Analytics Hub operation with its input schema so the agent calls the right endpoint without browsing the reference docs.

## Related APIs

- **BigQuery API** — BigQuery is the underlying warehouse; Analytics Hub is the sharing layer on top of BigQuery datasets.
- **BigQuery Data Transfer API** — Data Transfer copies external data into BigQuery; Analytics Hub shares existing BigQuery data without copying.
- **Data Catalog API** — Data Catalog tags and discovers datasets; Analytics Hub publishes them for cross-project subscription.

## FAQ

### What authentication does the Analytics Hub API use?

OAuth 2.0 with the cloud-platform or bigquery scopes, typically via a Google Cloud service account that holds Analytics Hub roles on the relevant resources. Jentic stores the service account JSON in your Jentic One instance and only short-lived access tokens reach the agent.

### Can I subscribe a consumer project to a listing through the API?

Yes. Call POST /v1/{+name}:subscribe on the listing with the consumer's destinationDataset, and a linked BigQuery dataset is created in that consumer project. Use :refresh to update and :revoke to remove access.

### What are the rate limits for the Analytics Hub API?

Analytics Hub is governed by per-project Google Cloud quotas listed under the Analytics Hub service. Subscriptions are also subject to BigQuery dataset and project limits in the destination project.

### How do I publish a BigQuery dataset as a listing through Jentic?

Search Jentic for 'create an Analytics Hub listing', load the schema for /v1/{+parent}/listings, and execute it with a bigqueryDataset source pointing at projects/{p}/datasets/{ds}. Run pip install jentic and use the async search, load, execute pattern.

### Does Analytics Hub copy the source dataset?

No. Listings are linked datasets - consumers query the publisher's data in place via BigQuery. The publisher pays storage and the consumer pays query compute, so there is no duplicate storage cost from sharing through Analytics Hub.

### Can I limit what my agent is allowed to do with the Analytics Hub API?

Yes. Because you run Jentic One yourself, your own rules decide which Analytics Hub operations and credentials the agent may use. Since the API puts the parent and resource names in the URL path (such as /v1/{+parent}/dataExchanges and /v1/{+name}:subscribe), you can pin the agent to one project's exchanges and listings so it only reads them. You also choose the exact operations it can call, so write actions like subscribe, refresh, or revoke are excluded unless you add them.