Bazaarvoice's Authentic Discovery API, read by someone who isn't selling it.

On April 2, 2026, Bazaarvoice issued a press release announcing the Authentic Discovery API. The release ran 740 words. It used the phrase "AI agents" eleven times. It used the phrase "user-generated content" thirteen times. It used the phrase "your product page" zero times.

That asymmetry is the essay.

The API, on its public spec, is a REST endpoint at `api.bazaarvoice.com/discovery/v1/` that returns structured JSON of a brand's review content. The endpoint accepts an authentication token, a brand identifier, and product or category filters. It returns reviews, ratings, Q&A entries, and aggregate metrics in a clean JSON envelope. AI clients with the credentials can query it. The marketing claim is that this is how Bazaarvoice's customers will reach AI buyers.

It is not. The API solves a distribution problem the platform owns. It does not solve the citation problem the brand owns. The brand's product page, on the brand's own domain, remains an empty widget shell when GPTBot fetches it. The API is downstream of that emptiness, not a fix for it.

This essay reads the API the way an operator should read it: closely, slowly, and with the brand's URL bar open in the next tab.

The endpoint is well-designed and the JSON is clean. A request to `/discovery/v1/products/{sku}/reviews` returns an array of review objects. Each object includes the review text, a verified-buyer flag, a rating, a posting date, a reviewer pseudonym, and a media manifest of attached photos or videos. Aggregate endpoints return a star average, a review count, and a "Triple-A Advantage" score (Bazaarvoice's authentication signal).

The schema is documented, the rate limits are reasonable, and the authentication uses standard OAuth 2.0. As a developer surface, it is professional.

The question this essay is asking is not whether the API works. The API works. The question is what the API is for.

Three categories of client could, in principle, hit the endpoint.

The brand's own systems. A brand can pull its own review data via the API, into its own database, for analytics or syndication. This use case exists but is not the marketed one. It is a sales-engineering capability, not an AI-discovery story.

Third-party retailers running syndication. Bazaarvoice's existing business is syndicating UGC across retailers. The API simplifies that pipeline. This is a real value flow and the press release is correct that it benefits Bazaarvoice's enterprise customers. It does not benefit AI discovery directly.

AI agents. This is the claim that carries the press release. The premise is that an LLM-powered shopping agent (the OpenAI shopping plugin, Anthropic's agent surface, Perplexity's commerce features, whatever else ships in 2026) will be authenticated against the API and will retrieve real review content rather than the empty HTML of a widget-rendered product page.

The first two clients exist. The third client mostly does not.

GPTBot is the OpenAI crawler, and it fetches HTML. It does not, in current public behaviour, hold authenticated API credentials against third-party UGC platforms. ChatGPT's "shopping" surface, where it answers product queries, is built on the corpus GPTBot has already collected. That corpus is HTML, and the API is not in it.

ClaudeBot is similar: Anthropic's agents fetch URLs and render text. They do not, by default, query third-party APIs for product data unless explicitly instructed.

PerplexityBot is the closest to the press release's pitch. Perplexity has built explicit integrations with several retailer APIs (Walmart, Best Buy, Amazon) for product data. But the integrations are direct retailer deals with Perplexity, not generic credentialed pulls against Bazaarvoice. Whether Perplexity will agree to authenticate against Bazaarvoice on behalf of every brand that has a Bazaarvoice account is, in May 2026, an open question. The press release implies it. The press release does not say it has happened.

OpenAI's shopping plugin, in its current form, retrieves product data via a small set of partner integrations and through retailer-supplied feeds. It does not, in any documentation that has been published, query Bazaarvoice's API as a general path.

Google's Shopping Graph ingests feeds, not third-party UGC APIs.

The current state, in other words: the API exists, the AI agents have not, in any public way, agreed to call it at scale. That gap may close, or it may not. The press release describes a future. The brand's product page is in the present.

This is the asymmetry the press release elides. A brand using Bazaarvoice's widget on its product page ships HTML that contains, at the slot where reviews should be, a small div with a Bazaarvoice container ID and a script tag that loads bv.com. The browser executes the script. The script fetches the reviews via the same API (or its internal cousin), renders them client-side, and inserts them into the DOM.

GPTBot, ClaudeBot, and PerplexityBot do not execute scripts. The agreed industry position, repeatedly confirmed across May 2026 testing (and discussed in the end of the review widget), is that these crawlers fetch the raw HTML and do not render JavaScript at scale. The container div is therefore empty in the HTML. The reviews are not in the page the crawler sees.

The Authentic Discovery API does not change this. The API exists on Bazaarvoice's domain. The brand's product page still does not contain the review content in its HTML. The HTML the crawler sees is, content-wise, the same as it was on April 1, 2026. The crawler saw nothing then. It sees nothing now.

The press release does not address this. The phrase "your product page" appears zero times. The phrase "API" appears thirty-two times. The geography of the words matches the geography of the content. The content is on Bazaarvoice's edge. The brand's edge is still empty.

Citation, in answer-engine output, is a two-layer artifact. The first layer is the URL the engine names as the source. The second layer is the sentence the engine quotes inside its answer.

The URL is the link the buyer can follow. For a brand, this is almost always the brand's own product page. It is the URL the buyer lands on, the URL where conversion happens, the URL Google has been ranking. The brand wants the engine to cite this URL.

The sentence is the text the engine quotes. It can be quoted from any URL the engine has indexed. If the brand's product page contains the sentence in its HTML, the engine can cite the brand's URL and quote the sentence from the same fetch. If the sentence lives only on Bazaarvoice's domain (via the API or via Bazaarvoice's own pages), the engine has to either quote from Bazaarvoice's URL or quote a sentence the brand's URL does have. In the first case, the brand's URL is not cited. In the second case, the brand's URL is cited but with a marketing sentence the engine actually wanted to avoid quoting.

The API answers the sentence question. It does not answer the URL question. A brand whose reviews are only queryable via api.bazaarvoice.com is a brand whose reviews can be cited, but cited at api.bazaarvoice.com, not at the brand's domain. The conversion never happens.

This is the same structural problem covered by the raw html your review widget never delivers. The widget is invisible. The API is a workaround for the platform, not for the brand. The brand wants the content rendered in the brand's HTML, on the brand's URL, fetchable by a default crawler with no credentials.

To be fair to Bazaarvoice, three counter-arguments are worth naming and weighing.

First, the API may, over time, be queried by AI agents through retailer or aggregator partnerships. If Perplexity, OpenAI, or Anthropic strike a deal with Bazaarvoice for credentialed access at scale, the API does become a real pipe. The brand might prefer the pipe to be Bazaarvoice's rather than build its own. This is a real argument. It is also speculative; no such deal has been publicly announced as of May 2026.

Second, the API simplifies the brand's own engineering, even if AI agents do not call it. A brand that wants to render reviews server-side on its own product page can use the API to do so. This is a real win, but it is a win that flatly contradicts the press release's framing. The win is not "expose your UGC to AI agents." The win is "render your UGC server-side via API instead of via widget." That is the workaround. Bazaarvoice is selling the workaround as the solution.

Third, the API improves the syndication network's economics. Bazaarvoice has thousands of retailer integrations. A cleaner API surface speeds up those integrations and may grow the network. This benefits Bazaarvoice and, indirectly, brands whose reviews are syndicated to retailers (Walmart product pages, Target product pages). That is real value, but it is not the same as AI-agent value.

Steel-manned, the API is a useful piece of infrastructure that solves the platform's distribution problem and gives the brand a server-side rendering workaround. That is a good product. It is not the product the press release describes.

Bazaarvoice's actual business, the one that earns most of its revenue, is the syndication network. A brand selling on its DTC site, on Walmart.com, on Target.com, and on a dozen specialty retailer sites can use Bazaarvoice to push the same review corpus to all of those product pages. The retailer accepts the syndicated content because Bazaarvoice has spent twenty years building moderation and authenticity workflows the retailers trust.

This is a useful service. It is also, almost entirely, what the Authentic Discovery API is for.

A retailer running their own AI shopping agent (Walmart's Sparky, Target's stylist surface, Amazon's Rufus) wants to query a clean, structured source of reviews for products in their catalogue. Hitting the retailer's own product detail pages with their own crawler is expensive and brittle. Hitting Bazaarvoice's API is cheap and consistent. The API was, in the strongest steel-manning of the launch, built for the retailer-side agents, not the consumer-side ones.

This is a real value flow. It also matters less to the DTC brand than the press release suggests. The DTC brand, in this framing, is a contributor to the syndication network; the agent on the other end is the retailer's, not OpenAI's. The brand's product page on its own domain is, again, not the surface that benefits.

The press release does not say "this API is for retailer-side AI agents." It says "expose your UGC to AI agents." The vagueness is the move. The brand reads the press release and pictures GPT-5 quoting their reviews. The actual customer is more likely the retailer's procurement-side agent doing internal product analytics.

Even before the API, Bazaarvoice's primary distribution surface on the brand's own product page is an iframe or a script-injected widget. Both, by current crawler behaviour, render to nothing for GPTBot, ClaudeBot, and PerplexityBot. The brand's product page HTML, fetched by curl, contains the container div and not much else.

The Authentic Discovery API does not move this content into the brand's HTML. The API is at api.bazaarvoice.com. The iframe is at bazaarvoice's CDN. Neither sits inside the brand's domain.

A brand that wanted to put the reviews inside its own HTML, today, has to do one of three things. Use Bazaarvoice's server-side rendering option, which exists in their enterprise tier but is unevenly adopted (the engineering team has to do the integration). Pull the review data via the new API and template it server-side themselves. Or switch to a platform that ships server-side rendered HTML by default and avoid the iframe entirely.

The first option is the closest to what Bazaarvoice would want a brand to do. It uses Bazaarvoice's services and lands content on the brand's domain. It is also the most expensive engineering-wise; few mid-market customers will run that integration. The second option is the do-it-yourself version of the same path. The third option is the migration path covered in the elegy for the widget.

The point is that the API, by itself, changes none of this. The brand that does not do additional engineering after the API ships sees no change in what the crawler sees on the brand's URL. The press release frames the API as a complete solution. It is a component.

A brand running Bazaarvoice (or Yotpo, or Okendo, or Junip, or any review platform that ships a JavaScript widget) has the same question to answer regardless of the API.

The question is: does the brand's product page, at the brand's URL, contain the review text in its rendered HTML when a crawler with no credentials fetches it?

The answer is testable. `curl -A "GPTBot" [product URL]` will return the HTML the crawler sees. Search the response for a review sentence. If the sentence is there, the brand is rendering server-side and the crawler will read it. If the sentence is not there, no API on any third-party domain solves this problem.

If the answer is no, the operator's options are three. Server-side render the reviews from the platform's API into the brand's own HTML (technically possible, requires engineering work, defeats the platform's UI). Switch to a platform that ships server-side rendered review content by default (and there are a small number). Or accept that the brand's product page will not be a citation surface and let the reviews live on the platform's domain as the cited URL.

None of these is "wait for the API to attract AI agents." That is, at best, a hope. The product page is in the present.

A press release is not a fix. The Authentic Discovery API is a real piece of infrastructure that does real work for Bazaarvoice. It does almost no work, today, for the brand's own URL in the answer-engine economy. The product page is still empty. The citation, if it happens, lands on someone else's domain.

The work the brand has to do is upstream of any vendor's API. It is the work of putting the review text in the brand's own HTML, on the brand's own URL, in the format the crawler with no credentials can read on the first request. That is not an API problem. It is a content placement problem. The vendor whose product solves it ships HTML on the brand's domain. The vendor whose product is an API is solving the vendor's problem.