API & MCP
The whole catalogue is readable for free, by people and by machines. Acting on a listing is the part that is metered.
Nuntrix is built for a world where the buyer might be a person typing, a person asking their assistant, or an agent acting on someone's behalf. All three get the same corpus. Reading is open, unauthenticated and documented. Acting — getting a business's contact details, posting a listing, answering one — is done as an account: on the site by signing in, or by an agent holding an API key its owner issued for exactly that. The same rules and the same limits apply either way.
Public read API
/api/public/v1/catalogcategories and revenue tiers/api/public/v1/localitieslocalities with centroid and radius/api/public/v1/nuntiosopen nuntios, cursor-paginated; ?q= narrows by term/api/public/v1/nuntios/{slug}one nuntio with its structured brief/api/public/v1/providersproviders with rating, response time and verification tier/api/public/v1/providers/{slug}one provider profile/api/public/v1/coveragethe live category × locality matrix with counts/api/public/v1/openapi.jsonmachine-readable schemaMCP server
The MCP server is at /api/mcp — one endpoint, streamable HTTP, no installation. Six read tools cover the corpus: search and read nuntios, search and read businesses, list the categories and the places. They need no account, because an assistant reading the marketplace is the product working. Three tools act as the account a Nuntrix API key belongs to, each only if its owner allowed that key to: contact_provider releases a business's contact details and emails the business to say so; post_nuntio publishes a listing, and the account is emailed about it; answer_nuntio answers one. They go through the same rules as the site — contact details are removed from public text, one answer waits per listing, a suspended account cannot act — and count against the same daily limits. Issue keys, choose what each may do and revoke them under Your account. Reading over plain HTTP still works exactly as it did — the endpoints above are the same corpus, and the MCP tools return the same shapes.
What is public and what is gated
| Public, free, crawlable | Gated behind an authenticated call |
|---|---|
| Service type and description | Phone number |
| Coverage area and locality | Email address |
| Credentials, licences, insurance | The booking link, where the provider gave one |
| Verification tier and badges | — |
| Ratings and review counts | — |
| Price band and availability windows | — |
| Listing photos, at two sizes | — |
| Stable canonical listing URL | — |
An agent can fully evaluate and rank our providers without an account. To act — to contact a business, post a listing or answer one — it presents an API key, and the act is its owner's.
Do you rate-limit the read API?
Yes, by network address and generously: six hundred reads an hour, which is more than reading the whole marketplace takes. A refusal is a 429 with Retry-After, never a block — if you need more, tell us what you are building.
Can I cache the corpus?
Yes. Every response carries a corpus version header and a licence link. Canonical listing URLs are permanent and never recycled.
Do you block AI crawlers?
The opposite. GPTBot, ClaudeBot, PerplexityBot, Google-Extended, CCBot and the rest are explicitly allowed in robots.txt.
Is there an ACP or UCP integration?
Not yet. Both protocols are product-shaped today — feeds, carts, variants, inventory — and services have no SKU, no cart and no inventory. We are watching for a services extension.