canonical: https://jentic.com/apis/googleapis.com/cloudsearch # Google Cloud Search API Cloud Search provides cloud-based search across Google Workspace data and lets enterprises index third-party content alongside it. The API exposes datasource and schema management, item indexing, query execution, and search analytics so internal apps can deliver Google-quality search over Drive, Gmail, Calendar, and custom corpora. It is the backbone for enterprise search portals, intranet copilots, and federated retrieval across SaaS systems mapped into a single index. ## For AI agents Index third-party documents into Google Cloud Search, run authenticated queries across Workspace and custom datasources, and read query analytics. Lets agents retrieve grounded context from an enterprise's connected content. ## Scope Does not crawl public web content, replace Drive's full-text search UI, or store documents itself - use for indexing and querying enterprise content with permission-aware retrieval only. ## Capabilities - Index third-party items into a Cloud Search datasource with per-item ACLs - Run permission-filtered queries that scope results to the calling user's identity - Define and update structured schemas on a datasource - Inspect indexing status, errors, and item counts per datasource - Read query, session, and search application analytics for the tenant - Configure search applications with custom ranking and facets ## Use cases ### Federated Enterprise Search Index content from ticketing systems, wikis, and internal databases alongside Google Drive and Gmail so employees see one ranked result list. Cloud Search applies the user's access controls per item, so federation does not weaken existing permissions, and the indexing API supports incremental updates so the corpus stays fresh. Example prompt: Index a Confluence page as a Cloud Search item under datasource sources/123 with viewer ACLs derived from the page's space permissions ### RAG Grounding for Internal Copilots Use Cloud Search as the retrieval layer for an internal LLM assistant - call the query API with the user's identity and feed the top results as grounding context. Because Cloud Search filters results to documents the user can already see, the assistant cannot leak content the user is not entitled to read, which is critical for regulated workplaces. Example prompt: Call query.search with the end user's OAuth token for 'Q3 forecast deck' and return the top five items as grounding context ### Index Health Monitoring Pull per-datasource statistics and item indexing status to dashboard the health of your Cloud Search corpus. The API exposes search application stats, query stats, and itemized indexing errors so platform owners can spot stalled connectors and stale indexes before users report bad results. Example prompt: List items under datasource sources/abc with status=ERROR, group by error code, and post a daily summary to a Slack channel ### Agent-Driven Knowledge Lookup An AI agent can resolve user questions against the organisation's Google Workspace and connected systems by calling Cloud Search through Jentic. The agent searches Jentic for 'search workspace content', loads the query schema, and gets back permission-filtered results scoped to the calling user's identity. Example prompt: Use Jentic to call query.search with the prompt 'employee handbook PTO policy' and return the top result's URL and snippet ## Key endpoints | Method | Path | Description | | --- | --- | --- | | POST | /v1/indexing/{+name}/items:push | Push an item update into a datasource | | GET | /v1/indexing/{+name}/items | List indexed items in a datasource | | DELETE | /v1/indexing/{+name} | Delete an indexed item | | POST | /v1/debug/{+name}:checkAccess | Check whether a principal can access an item | | GET | /v1/debug/{+name}/items:searchByViewUrl | Locate an item by its view URL for debugging | ## Key resources - **Items** — Index, update, get, delete, and list items inside a datasource - **Datasources** — Create, configure, and manage third-party data sources - **Schemas** — Define the structured fields and operators available on a datasource - **Query** — Execute search queries against indexed content with permission filtering - **Search Applications** — Configure scoped search experiences with custom ranking and facets - **Stats** — Read query, session, item, and search application analytics ## Why Jentic - **Setup:** Wiring the Cloud Search API by hand means setting up Google OAuth 2.0 admin credentials, minting short-lived tokens against the relevant cloud-search scopes, and addressing each data source and item by resource name against cloudsearch.googleapis.com yourself. Through Jentic you install once, import the Cloud Search API from the API Directory, store the OAuth credential once, and your agent calls it. - **Permission scoping:** Cloud Search puts the item and data source resource names in the URL path (/v1/indexing/{+name}/items:push, /v1/indexing/{+name}/items), so a rule can pin your agent to one data source: it can push and list items there and nothing else. You choose the operations it may call, so item deletion is not included unless you add it. - **Credential handling:** Your Cloud Search OAuth credential 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 'search Workspace content' or 'index a document into Cloud Search', and Jentic returns the matching Cloud Search operation with its input schema so the agent calls the right endpoint without browsing the reference docs. ## Related APIs - **Admin SDK API** — Manages Workspace users, groups, and OUs that Cloud Search ACLs reference - **Compute Engine API** — Hosts the third-party connector workloads that push items into Cloud Search - **Cloud Tasks API** — Queues indexing jobs so connectors can rate-limit pushes into Cloud Search ## FAQ ### What authentication does the Cloud Search API use? It uses Google OAuth 2.0 with scopes such as https://www.googleapis.com/auth/cloud_search.indexing for indexing flows and https://www.googleapis.com/auth/cloud_search.query for end-user search. Through Jentic the OAuth credentials live in your Jentic One instance and only short-lived access tokens are passed to the agent. ### Can I index third-party content with the Cloud Search API? Yes. Create a datasource, push items via the indexing.datasources.items.index endpoint, and supply per-item ACLs so search results respect the original system's permissions. The API supports incremental updates and bulk deletes. ### What are the rate limits for the Cloud Search API? Indexing operations are limited per datasource and per project, and query QPS is governed by the connected Cloud Search license tier. Use the items.list endpoint with pagination rather than re-indexing when reconciling state, and stagger heavy reindexing operations. ### How do I run a permission-filtered query through Jentic? Search Jentic for 'search workspace content', load the query.search schema, and execute the call against /v1/query/search using the end user's OAuth token. Cloud Search filters the results so the user only sees items they are entitled to. ### Does Cloud Search require a paid Google Workspace plan? Yes, Cloud Search is available on specific Workspace editions and as a standalone offering. The API itself has no per-call price but you must have a license and an admin-configured Cloud Search tenant before calls succeed. ### Can I retrieve search analytics from the API? Yes. The stats resource exposes query, session, user, and item-level analytics under /v1/stats endpoints. Use these to dashboard search performance and spot underperforming datasources. ### Can I limit what my agent is allowed to do with the Cloud Search API? Yes. Because you run Jentic One yourself, your own rules decide which Cloud Search operations and credentials the agent may use. Cloud Search puts the data source and item resource names in the URL path, such as /v1/indexing/{+name}/items:push and /v1/indexing/{+name}/items, so you can pin the agent to a single data source and let it push and list items there and nothing else. You choose which operations it may call, so item deletion is excluded unless you add it, and the OAuth credential stays in your instance rather than the agent's context.