What do “Scraper” and “API Response” mean?
Scraper: collecting the web experience
A scraper collects results from an AI product’s web interface. Depending on the service, it can return rendered HTML, extracted answer text, citations, business listings, and other structured fields.
For example, DataForSEO offers both structured results and an HTML version of ChatGPT Search results. Its advanced scraper documentation also includes a fan_out_queries field. See the scraper overview and advanced response fields.
This makes a scraper useful for checking the experience captured under a particular location, language, and session configuration. It is still a sample: a different account, conversation history, location, or run may produce something different.
API Response: collecting an API-generated answer
An API response comes from a programmatic request to an AI model or search service, either directly or through a third-party provider. The request can expose controls such as the model, prompt, and supported search settings.
DataForSEO’s LLM Responses endpoint documents its own request and response fields. These need to be read as the contract for that service, rather than assumed to match every field in an AI provider’s direct API. See the LLM Responses documentation.
One naming detail matters: “API Response” here describes the collection method. It does not automatically mean OpenAI’s specifically named Responses API, or establish which upstream endpoint a third-party service uses.
Scraper vs API Response at a glance
| Research question | Scraper | API Response |
|---|---|---|
| What am I observing? | A captured web-product experience. | An answer generated under an API configuration. |
| Can I choose the model? | Depends on the product and scraper controls. A missing model value does not identify the underlying model. | Often supports explicit model selection from the endpoint’s available models. |
| Can I collect citations? | Yes, where captured and exposed by the scraper. | Yes, where the model, search tool, and endpoint return citation data. |
| Can I inspect query fan-out? | Yes, on supported endpoints. Check the actual returned query fields. | Yes, when search is used and the endpoint exposes the search queries. |
| What about maps and local cards? | Can capture web-interface features and listing fields supported by the service. | May return location or grounding data, but should not be assumed to reproduce the consumer interface. |
| What usage information is available? | A provider may report task charges; underlying model token usage may be unavailable. | May include input, output, and reasoning token usage, alongside provider billing information. |
| What is it most useful for? | Web-experience audits, local listing visibility, and monitoring a defined interface. | Model comparisons, configurable experiments, and structured analysis. |
My ChatGPT comparison: the same prompt, different results
I used “best banh mi in Da Nang Vietnam” for both methods through DataForSEO. The following figures come from my test notes; they describe these particular outputs, not a benchmark of every run or a current pricing promise.
| Field | API Response result | Scraper result |
|---|---|---|
| Restaurants in the answer text | 6 named restaurants. | 5 named restaurants. |
| Local business pack | Absent from this result. | 10 listing entries, with ratings, review counts, and contact or website fields where available. |
| Text citations | 6 annotations: bestbanhmivietnam.com five times; joytime.vn once. | 4 citations: vietnamairlines.com once; joytime.vn once; gtrip.vn twice. |
| Model identity | Not independently established by the pricing information in my notes. | The reported model field was null. |
| Reported usage | 457 output tokens and 79 reasoning tokens. | No underlying model token counts recorded in the test notes. |
| Recorded charge and timing | Approximately US$0.013; 5.6 seconds. | No comparable charge or timing recorded here. |
| Citation URL parameter observed | utm_source=openai | utm_source=chatgpt.com |
The scraper listings in my notes showed ratings from 4.0 to 5.0 and review counts from 11 to 3,021. Those are observed listing values from that run, not verified assessments of the businesses. Reasoning tokens may already be included within output-token totals; the two counts should not automatically be added.
What overlapped?
My notes recorded two shared restaurant entities. However, counting text mentions alongside local-pack entries requires deduplication: a restaurant appearing in both should not automatically count as two distinct businesses. I would not turn the approximate entity totals into an overlap percentage without the complete, normalised lists.
The citation-domain comparison is clearer. The text citations listed above contain four distinct domains in total, with joytime.vn shared between the two outputs. This count excludes website links inside the local business pack.
The useful observation is that the two collected outputs differed substantially. A single paired test cannot isolate how much of that difference came from the collection method, model, search configuration, session context, or ordinary variation between runs.
Why the local business pack matters
The scraper captured a separate local discovery surface: ten business listings alongside the answer text. For hospitality research, that distinction matters. A business may appear in a listing without being named in the narrative answer, or it may be mentioned in the text without receiving a prominent listing.
The listing website fields also pointed to different kinds of destinations: business-owned domains, Facebook pages, Tripadvisor listings, or no website. That creates a practical question for a restaurant or hotel team: when someone discovers the business in this interface, where can they go next?
I would record text mentions, citations, and local listing appearances separately. Combining them into one “visibility” total hides how the business actually appeared.
This does not mean APIs can never return local information. For example, Google documents Google Maps grounding in the Gemini API. The distinction is between the exact interface captured and the fields supplied by the particular API—not a universal rule that all map information is scraper-only.
Query fan-out is available through both methods
Query fan-out describes the additional searches used to explore a prompt. A question about restaurants might lead to searches about neighbourhoods, reviews, opening hours, or particular businesses.
Scrapers can provide fan-out queries. DataForSEO’s ChatGPT advanced scraper exposes them in its documented output. API methods can expose search activity too: OpenAI’s API reference includes search actions with query fields, while Google documents search-query information in its grounding responses. OpenAI search-action fields; Gemini search grounding.
In my API test notes, one visible search was site:reddit.com Da Nang best banh mi. That is useful evidence of an exposed search step. It does not prove every Reddit result was read, or that an unlisted source was deliberately ignored.
For either method, I would keep three things separate:
- Search queries: the searches exposed by the collection tool.
- Retrieved sources: the pages or search results reported as available to the answer process.
- Final citations: the links attached to the answer.
A searched-for topic is not automatically a citation. An absent query field is not proof that no search occurred.
Where API-based testing is useful
For a controlled comparison, I want to record the requested model, returned model identifier where available, search settings, prompt, and usage fields. An API can make these easier to capture and vary systematically.
Explicit model selection helps define an experiment, but it does not guarantee identical answers across runs. Models and search results can change, and responses can vary even when the visible settings stay the same.
Cost is also a separate measurement. A third-party task charge can reflect its own billing rules, search calls, token usage, and other factors. Matching a price to a rate card does not prove which model generated an answer. For model verification, start with the saved request, response metadata, and provider documentation.
What the UTM difference can—and cannot—tell you
My two outputs used different URL parameters: utm_source=openai and utm_source=chatgpt.com. Preserve those original URLs when collecting evidence, but do not treat the parameter as a reliable fingerprint of the collection method.
Tracking parameters can be added, changed, or removed by the service producing the link, the application displaying it, or the person sharing it. The parameter alone cannot establish that a visit came from the consumer web interface or a particular API application.
For citation analysis, I keep the original link and a separate normalised URL or domain for comparison. For traffic analysis, I examine campaign parameters alongside referrer data and landing-page activity. A citation in a collected answer is not itself a website visit or booking.
How I would choose a method for GEO research
| Objective | Starting point | What to check |
|---|---|---|
| Audit the consumer web experience | Scraper. | Captured interface, location, language, search mode, and session conditions. |
| Measure local listing visibility | Scraper with listing support. | Business identity, listing position, contact fields, and destination links. |
| Compare specified models | API Response with model selection. | Requested and returned model identifiers, settings, and repeated runs. |
| Study citations or query fan-out | Either, depending on the research surface. | Actual returned fields, completeness, and separation of searches from citations. |
| Run a large prompt set | Assess both. | Coverage, task cost, latency, rate limits, retries, and data quality. |
| Compare web and API behaviour | Both, recorded as separate datasets. | Matched prompts and conditions, repeated observations, and explicit counting rules. |
The same discipline applies when comparing different AI products. Check each product and endpoint individually. Do not assume ChatGPT, Gemini, Perplexity, and Copilot offer equivalent API access, model controls, or extraction fields.
A repeatable way to run the comparison
- Define the surface. State whether the study measures a web-product experience, API output, or both.
- Save the configuration. Record the exact prompt, endpoint, timestamp, language, location, model fields, search settings, and available session details.
- Repeat the prompts. Keep individual runs so variation remains visible rather than treating one answer as a fixed result.
- Preserve the evidence. Save raw responses and, where available, HTML or screenshots.
- Separate the units. Count unique businesses, repeated mentions, local listings, citation URLs, and citation domains independently.
- Report the limits. Explain missing fields, deduplication rules, sample size, and what the data cannot establish.
For my hospitality work, the lesson is practical: before interpreting a visibility score, ask how the answers were collected. The method determines what the score can meaningfully describe.
Frequently asked questions
Does a scraper provide query fan-out?
It can. Supported scraper endpoints expose the searches associated with an answer. Check the provider’s documentation and actual response fields; fan-out visibility is not exclusive to API Response methods.
Does an API response reproduce what a ChatGPT user sees?
Not necessarily. An API request measures its own configuration. The consumer product may use different settings, context, search behaviour, and presentation features.
Can I choose a model when using a scraper?
That depends on the scraper and the product controls it supports. In this test, the scraper’s model field was null. That tells me the model identity was not reported; it does not establish what all scrapers can or cannot control.
Does a lower task price prove a cheaper model was used?
No. Price is not sufficient evidence of model identity. Keep the request and returned metadata, then check how the provider defines model selection and billing.
Which method is better for hospitality research?
Use a scraper when the question concerns the captured web experience, especially local listings. Use an API when you need the controls available through that endpoint. Use both when the difference between those surfaces is itself part of the research.