verificationLevel field indicating the business’s current
verification tier. See Business Verification for the full tier system.
Rate limits:
Requests with a valid Hub API key are limited per key (and per account) at 300 req/min instead of per IP. Requests whose client IP cannot be determined share a strict 30 req/min bucket.
Non-429
GET responses carry X-RateLimit-Limit, X-RateLimit-Remaining and X-RateLimit-Reset (ISO-8601 timestamp) for the bucket with the least headroom; a 429 adds Retry-After. A 503 carries no rate-limit headers.
Caching and freshness:
GET /v1/directory and GET /v1/directory/:id are served through a short-lived server-side read cache (30 seconds). Responses are always JSON in the same shape; the cache only affects how quickly a change becomes visible.
- Rate limits still apply. The rate-limit check runs before the cache, so a cache hit consumes quota exactly like a database read.
- Listing changes show up immediately. The cache is invalidated when a listing’s visibility changes (
PATCH /v1/directory/:id), when a business profile or listing categories change (profile edits, Google Business Profile sync, JSON imports, profile-version reverts, onboarding), and when a verification tier is upgraded. - Some fields can lag by up to 30 seconds. Changes to the
mcpServerUrlof the listing’s server, torelevanceScore(driven by analytics events), and the initialunverifiedverification row are not invalidated and appear once the 30-second window expires. - Multi-instance deployments. If the shared cache backend is not configured, invalidation reaches only the instance that performed the write. If the shared backend is unavailable when a write is made, invalidation may not take effect on any instance, including the writer. In either case stale data can be served for up to 30 seconds.
- Cache failures are invisible to callers. If the cache backend errors, the request is answered from the database; it never produces a 5xx on its own.
GET responses also carry Cache-Control: private, max-age=30 and Vary: Authorization, Accept-Encoding, so a client may reuse a response for up to 30 seconds (including its X-RateLimit-* values). Non-2xx GET responses carry Cache-Control: no-store. A listing hidden via PATCH can therefore remain visible in a client-side cache for up to 30 seconds.
List directory
Response
200:
Get directory listing
Response
200:
Errors:
Update directory visibility
visible: true activates the listing and records publishedAt on first
publication (subsequent activations preserve the original publishedAt).
Setting visible: false returns the listing to pending status and hides it from
public reads.
Authentication: Session cookie (dashboard login). API key auth is not supported for
this endpoint.
Path parameters:
Request body:
Response
200:
MCP server metadata
Response
200:
agentDiscovery fields:
Trust signals (EP-R17):
Errors:
VerificationLevel type
The VerificationLevel string type is used across all directory responses to represent a
business’s verification status.
See Business Verification for the full tier progression and how to earn each level.