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

# Google Site Verification API

The Google Site Verification API lets owners prove control over a website or DNS domain so that Google services like Search Console, Analytics, AdSense, and Webmaster Tools recognise them as the verified owner. Agents request a verification token (HTML file, meta tag, DNS TXT, or DNS CNAME), place it on the property, and then call insert to verify ownership. Verified resources can be listed, retrieved, updated, and deleted, and ownership can be shared with other Google accounts.

## For AI agents

Prove ownership of websites and DNS domains to Google so they can be claimed in Search Console, Analytics, and other Google products.

## Scope

Does not handle search analytics, URL indexing, or DNS record creation - use for proving and managing site or domain ownership with Google only.

## Capabilities

- Request a verification token in any of four formats: HTML file, HTML meta tag, DNS TXT, or DNS CNAME
- Verify ownership of a website or domain by calling insert after placing the token
- List every webResource the authenticated user has verified
- Retrieve a single verified webResource to see owners and verification method
- Update or replace owner sets on a verified resource to share ownership
- Delete a verification record when a property is no longer owned

## Use cases

### Search Console Onboarding Automation

When platforms onboard customer websites to Google Search Console, they automate Site Verification first. The flow is: call getToken to obtain a DNS TXT or HTML meta token, instruct the customer to place it, then call insert to verify. Once verified, the platform can also call the Search Console API on behalf of the customer.

Example prompt: Call POST /token with verificationMethod='DNS_TXT' for site type=INET_DOMAIN, then once the customer places the record call POST /webResource with the matching identifier.

### Multi-Property Ownership Audit

Agencies and platforms managing many properties periodically list every verified webResource, cross-reference against the customer roster, and surface any properties that should be unclaimed. The API exposes list, get, and delete on webResources so this audit can run end to end without UI scraping.

Example prompt: Call GET /webResource to list every verified site, then for each one decide whether to call DELETE /webResource/{id} based on the current customer list.

### Co-Ownership Management

Add or remove co-owners on a verified property without re-verification. The update and patch operations on a webResource accept a new owners array, which is useful when team members change or when a managed-services provider hands ownership back to the end customer.

Example prompt: Call PATCH /webResource/{id} with owners=['old@example.com','new@example.com'] to add a co-owner without disturbing the verification token.

### AI Agent Property Manager

An AI agent acts as a property manager for an SEO or marketing platform - verifying customer sites, watching for failed verification (token removed), and re-running verification when DNS changes. Through Jentic the agent searches by intent and never holds the customer's Google OAuth refresh tokens directly.

Example prompt: On a webhook from a customer's DNS provider, call POST /webResource for the affected domain to re-run verification and notify the customer of the result.

## Key endpoints

| Method | Path | Description |
| --- | --- | --- |
| POST | /token | Request a verification token in a chosen format |
| POST | /webResource | Verify a site after placing the token |
| GET | /webResource | List every verified site for the user |
| GET | /webResource/{id} | Retrieve a specific verified resource |
| PATCH | /webResource/{id} | Update owners on a verified resource |
| DELETE | /webResource/{id} | Delete a verification record |

## Key resources

- **webResource** — List, get, insert, update, patch, and delete verified site or domain resources
- **token** — Request a verification token in HTML file, meta tag, DNS TXT, or DNS CNAME format

## Why Jentic

- **Setup:** Wiring the Google Site Verification API by hand means registering an OAuth client, walking users through the consent screen, and refreshing access tokens against the www.googleapis.com/siteVerification/v1 host yourself. Through Jentic you install once, import the Site Verification API from the API Directory, store the OAuth credential once, and your agent calls it.
- **Permission scoping:** Site Verification puts the web resource in the URL path (/webResource/{id}), so a rule can pin your agent to the resources you name: it can request tokens and read a resource and nothing else. You choose the operations it may call, so updating or deleting a web resource is not included unless you add it.
- **Credential handling:** Your Google OAuth credential for Site Verification 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 'verify a domain via DNS TXT with Google' or 'get a verification token', and Jentic returns the matching Site Verification operation with its input schema so the agent calls the right endpoint without browsing the reference docs.

## Related APIs

- **Google Search Console API** — Reads search analytics and inspects URLs once a property has been verified via Site Verification.
- **Google Indexing API** — Notifies Google about URL changes - also requires a verified site.
- **Google Cloud DNS API** — Adds the DNS TXT or CNAME records that Site Verification expects when using DNS-based methods.
- **Google Analytics API** — Often paired with verified sites for cross-property reporting.

## FAQ

### What authentication does the Google Site Verification API use?

The API uses OAuth 2.0 with the siteverification or siteverification.verify_only scope. Through Jentic the OAuth client and refresh tokens are stored encrypted in your Jentic One instance and a scoped token is provided at execution.

### Which verification methods does the API support?

Four methods: an HTML file uploaded to the site root, an HTML meta tag in the homepage head, a DNS TXT record on the domain, and a DNS CNAME record on the domain. Site type INET_DOMAIN supports DNS methods; SITE supports the HTML methods.

### What are the rate limits for the Google Site Verification API?

Google enforces a default per-project quota of around 100 queries per second and reasonable daily caps; verification calls are typically infrequent so most callers stay well under the limits. Quotas can be raised via the Cloud Console quota page.

### How do I verify a site through Jentic?

Run the Jentic search query 'verify ownership of a site with google', load POST /token to fetch the token, place it on the site or in DNS, then load POST /webResource to confirm verification. Jentic injects the OAuth token at execution.

### Can I add multiple owners to a verified site?

Yes. PATCH /webResource/{id} or PUT /webResource/{id} with an updated owners list lets you add or remove co-owners. The verification token itself does not need to be replaced.

### Does the API support sub-paths or only full origins?

Site verification covers a full HTTP origin (scheme + host) for SITE type and a full registrable domain for INET_DOMAIN. Sub-path verification is not supported; granular access is handled at the Search Console level instead.

### Can I limit what my agent is allowed to do with the Google Site Verification API?

Yes. Because you run Jentic One yourself, your own rules decide which Site Verification operations and which OAuth credential the agent may use. Since the web resource sits in the URL path (/webResource/{id}), you can pin the agent to the resources you name and let it only request tokens and read a resource. Updating or deleting a web resource is not included unless you explicitly add those operations.