It is worth separating two things that get discussed as one. There is the consumer product, which is a search interface that answers your question in prose with links to sources. And there is the API, which lets you build that behaviour into your own applications. The first barely needs documentation and the second is where the substance is, so I will spend most of my time there.
On the product side, the design decision that matters is citations. A general purpose chatbot answers from its weights and you have no idea what it is drawing on. This answers from retrieved pages and shows you which ones, which changes the verification cost enormously. Instead of trusting or independently researching, you click a link and check.
That single affordance makes it substantially more suitable for anything you are going to act on, and it is the reason it has earned a place in a lot of people's research process, mine included. The honest use case is triage. When you are entering an unfamiliar area and need to know the shape of it, the vocabulary, the main positions and where the arguments are, this is faster than reading five articles. It is a map, not the territory, and treating it as a map is the correct usage.
The API documentation is the more interesting artefact. What you get is a request that looks like a standard chat completion and a response that has been grounded in a live web search, with the sources returned. Building that yourself means a search integration, a fetching layer, content extraction, ranking, chunking and prompt construction, and keeping all of it working. Being able to skip that for a per-request fee is a genuine offer, and for a lot of applications where freshness matters, it is the pragmatic choice.
The documentation is short, the interface is familiar, and the search filter parameters, domain restriction, recency windows, and controlling how much context is retrieved, are documented practically and are the parameters that actually change your output quality. Now what is missing, and it is the same omission on both sides. Citations are reliably present and they are not reliably correct. The failure mode is specific and important.
A claim appears in the answer with a link beside it. The linked page is real, it is on topic, and it does not actually support that particular claim. Sometimes it supports something adjacent. Sometimes the claim is a synthesis across two sources that neither one makes.
The presence of a link creates a very strong impression of verification that has not actually occurred, and this failure is much harder to notice than an uncited fabrication, because the visual grammar of citation makes you relax. I have watched people trust cited output more than uncited output from the same underlying model, which is exactly backwards unless you are actually clicking through. Neither the product help nor the API documentation raises this. That is a serious gap for a product whose entire differentiation is grounding.
There is also nothing on when a summarised answer is the wrong format. Sometimes you need the actual source, in full, with its context and caveats and the parts the summary dropped. Legal text, medical guidance, technical specifications, anything where precise wording matters. A confident paragraph is worse than a link in those cases, and this product will happily give you the paragraph.
Knowing when to refuse the summary and read the document is a skill, and no documentation here helps you develop it. On the API side, pricing deserves more care than the documentation gives it. There are per-request costs alongside token costs, and the search itself has a cost independent of the tokens generated. An application that makes many small grounded requests can cost considerably more than a token-based estimate suggests.
The information is available and the shape of the trade is not made vivid, and people will be surprised by bills. Evaluation is the other API gap. If you build on this, the question you will face is whether the answers are good enough, and that means an evaluation set, a rubric, and a way of checking whether the citations actually support the claims. There is essentially nothing on this.
Given that the failure mode described above is the main risk of the product, guidance on detecting it programmatically would be the single most valuable thing the documentation could add. My three point four is for a genuinely useful research tool, a citation-first design that makes verification cheap, and an API that removes real engineering work for applications that need current information. Marked down for never confronting the gap between citations existing and citations being correct, for no discussion of when summarised answers are inappropriate, for pricing that is easy to misjudge, and for no evaluation guidance. Use it, and click the links.