Skip to main content
The Directory API exposes the public listing of businesses that have opted into the Ready directory. List and detail reads are public (no authentication required). Opting in or out requires a session-authenticated request from the business owner. Each listing includes a 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 mcpServerUrl of the listing’s server, to relevanceScore (driven by analytics events), and the initial unverified verification 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.
Successful (2xx) 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

Returns a paginated list of active Ready-powered business listings. No authentication required. Query parameters: Response 200:
Response fields:

Get directory listing

Returns the full detail for a single active listing, including MCP server URL and industry metadata. No authentication required. Path parameters: Response 200:
Response fields: Errors:

Update directory visibility

Opts a business in or out of the public directory. The authenticated user must own the business associated with the listing. Setting 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:
Errors:

MCP server metadata

Returns structured metadata for a Ready MCP server identified by its subdomain. This endpoint is used by AI agents during server discovery. No authentication required. Query parameters: Response 200:
Top-level fields: 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.