Zocdoc built a door for AI agents: what site-run agent access changes for web data buyers

Written by Nathan Kessler
Last updated: 6 min read
On October 28, 2026, Zocdoc announced it is opening its platform to AI agents. Agents that register and identify themselves can find providers, check insurance and book appointments through an MCP server, a REST API, llms.txt guidance or deep links. It is a narrow launch in healthcare scheduling, but it poses a question web data buyers will meet more often: when a site offers its own agent interface, do you still scrape it?
The short answer
If a site publishes an agent interface and you need to act on its data (book, buy, cancel), use the interface. If you only need to read public pages in bulk, scraping or a licensed feed may still fit better. The interface usually brings accepted terms with it: registration, identity and limits on what you can do with the data. That is the cost of the better data.
What Zocdoc shipped
Zocdoc's press release lists four ways in: an MCP server, a REST API, agent guidance via llms.txt, and deep links. Instinct, a text- and call-based agent, gets direct MCP access under a new partnership. Zocdoc's network already includes Google Gemini and Amazon Health AI, per Healthcare Dive's report. Other agents can apply, and the application can be filled out by a human or by an agent.
The company gave its own numbers for why it is doing this. Agent traffic on Zocdoc has grown nearly 30x since July and has doubled roughly every 10 days since early September. These are Zocdoc's figures, not ours, and the release does not say what base they start from. A 30x increase on a small base is still a small number. What matters is the direction: a site operator watched agents show up anyway and built a lane for them.
Zocdoc also describes what sits behind the lane: 175+ scheduling integrations, 10,000+ insurance plans, 200,000+ verified providers and 250,000 appointments bookable in the next 24 hours. Its pitch to agents is that the open web is full of outdated directories and wrong insurance information, so a scraped answer may be a doctor who does not take the patient's plan.
For builders, that pitch is the point. The site is not selling access to pages. It is selling answers it can vouch for, plus a write action (a confirmed booking on a provider's calendar) that no scraper can perform.
The terms come attached
Access is not free of conditions. The release says Zocdoc commits to welcoming agents that register and identify themselves. In return, agents are expected to get explicit patient consent before booking and to protect patient and provider data.
Healthcare Dive adds a stricter reading: agents are not allowed to train on the data, resell it or republish it. It also notes that Zocdoc did not specify how it plans to ensure agents comply. So the restrictions exist on paper, and enforcement is unstated. If you build on this, assume the paper version is what your lawyers will read.
This is the part that changes a build-versus-buy calculation. A scraper owes a site nothing except the risk of being blocked. An integration owes the site a registration, an identity and a list of uses you agreed not to make. For a product that caches results, fine-tunes on them or resells a derived dataset, a no-training and no-resale clause can rule the source out, however good the data is.
Identity is the price of admission
Zocdoc's welcome is conditional on agents that "register and identify themselves." That fits a pattern we covered in Web Bot Auth: sites are moving from "block what looks like a bot" to "admit what proves who it is." Zocdoc's version is registration rather than cryptographic signing, so the two are different mechanisms. But they point the same way. An anonymous agent with a rotating user agent gets the worst treatment on the open web and, here, no access at all.
The other lane we have written about is payment. Pay-per-crawl lets a site charge agents for content. Zocdoc's approach charges nothing visible in the announcement, and instead asks for good behavior and identity. Whether it earns money from the agent traffic is not in the release, and we have not seen terms that say.
So a site now has at least three postures toward agents: block, charge, or invite on conditions. A buyer building a data pipeline across many sources will meet all three.
Scrape, license, or integrate
Here is how the options compare for a team that needs web data from a site that offers an agent interface.
| Scrape the public pages | License or buy the data | Use the site's agent interface | |
|---|---|---|---|
| Freshness | As fresh as your crawl | Set by the vendor's refresh cycle | Live, from the source |
| Write actions (book, buy) | No | No | Yes, where the site allows |
| Terms exposure | Site terms and blocking risk | Contract with the licensor | Registration plus use limits |
| Coverage | Whatever renders on the page | Whatever the licensor holds | Whatever the site exposes |
| Lock-in | Low | Medium | High: your product depends on one site's schema and approval |
| Setup cost | Parsing and anti-bot work | Procurement | Application and integration |
None of these wins everywhere. The interface is strongest where you need accurate, current, transactional data from one source. Scraping is still the practical choice for broad reads across many sites that have no interface. The build versus buy guide covers the cost side of that choice. The new factor here is a third column that did not exist at most sites a year ago.
What to do with this
One healthcare scheduler is no reason to rebuild anything, but it is a reason to run a quick audit.
- List your ten most important data sources. For each, check for an llms.txt file, an MCP server, a public API or an agent partner program. It takes an hour.
- Read the use terms before the docs. Look for training, caching, resale and republishing clauses. If your product does any of those, find out now.
- Decide per source, not per company. A source that offers transactions deserves an integration. A source you only read in bulk may not.
- Keep a fallback. If your product depends on one site's approval, a revoked key should degrade your product, not stop it.
- Check your own identity. If your agents are anonymous, expect to be treated worse by every site that is building a lane for registered ones.
What we did not test
We did not test Zocdoc's MCP server, REST API or registration flow, and we have no data on approval times, rate limits or pricing. The release does not give them. The 30x and 10-day figures are Zocdoc's own. We read the press release and one news report, and we have not seen the full agent terms. If Zocdoc or an agent partner publishes them, we will update this piece.
One company is not a trend. Zocdoc's CEO called the approach "a bit of a contrarian move" to Healthcare Dive, and much of the industry remains wary. The narrower takeaway: a site that opens a door sets the conditions on it, and those conditions belong in your sourcing decision from the start.
FAQ
Should I scrape a site that offers an AI agent interface? Use the interface if you need to take actions or want data the site vouches for. Scrape only if you need broad, read-only coverage the interface does not expose, and check the site's terms first.
What does an AI agent have to agree to for Zocdoc access? Per Zocdoc's announcement, agents register and identify themselves, get explicit patient consent before booking, and protect patient and provider data. Healthcare Dive reports agents also may not train on, resell or republish the data.
- #agent-access
- #mcp
- #market-analysis
- #build-vs-buy
More from the blog
- Indirect prompt injection: the web page your agent reads is now an attack surface
Jul 17, 2026 · 6 min read
- The web is closing as the agents arrive: what bot-majority traffic means for web data access
Jun 19, 2026 · 6 min read
- Web-data MCP servers grew up in mid-2026, and so did the risk
Jun 9, 2026 · 6 min read