Bright Data vs AnswerLine

Coverage

Bright Data's pricing

As published on brightdata.com/pricing/serp and /pricing/web-scraper, checked 2026-09-17. The AI scrapers are priced as Web Scraper API records.

Price per request

Bright Data figures are its pay-as-you-go price per successful request or record. This API's figures are its dollar price per request at the Starter tier and, beside it, the Max tier. Lower prices apply from each bigger tier, reached by 30-day spend.

How requests, geo, billing and delivery work

Where Bright Data fits

• A flat $1.50 per 1,000 records on pay-as-you-go for every engine; compare it with this API's per-request prices above for your engine mix.
• Their homepage claims 400M+ proxy IPs in 195 countries, seven search engines in the SERP API, and a dataset marketplace and scrapers for hundreds of other domains.
• Results can go straight to cloud storage or a data warehouse instead of a webhook receiver you run.

This API fits when you want one request contract across engines, with per-task idempotency keys and signed webhooks. The guide below compares the two integrations.

Choosing between them

Bright Data makes sense if you already buy its proxies or datasets, if your team is comfortable with zones and dataset ids, if you want results delivered straight into cloud storage or a warehouse, or if a flat price per record across engines is the deciding factor at your volume.

This API makes sense if the job is a recurring AI-visibility pipeline where each answer is one request with its own key, market and webhook, and you want one documented schema per engine instead of mapping scraper records.

Both return JSON over HTTPS; moving between them is mostly a change of request shape and delivery.

How the products are organized

Bright Data splits the job across two products (checked 2026-09-17):

• SERP API for Google Search, Google News and the AI Overview. You create a SERP zone and send either a full Google URL to its request endpoint, or query parameters to its async endpoint. Parsed JSON comes back when you ask for it.
• Web Scraper API for the assistants. Each engine is a scraper identified by a dataset id, called synchronously for small inputs or triggered asynchronously, with results delivered as a snapshot.

This API has one product. Every engine is POST /v1/monitor/<engine> for a synchronous answer, or a task with taskType set to the engine for async work. Auth, errors, charging, idempotency and webhooks are the same across engines.

Three things change when you migrate:

1. Identifiers. Zones and dataset ids disappear. Your code references an engine name.
2. Delivery. Snapshots delivered in bulk become one webhook delivery per finished task.
3. Geo. Bright Data’s scrapers take a country input; its SERP API takes gl, hl and uule. Here ChatGPT, Gemini, Google Search and Google AI Mode answer from 213 countries, and Gemini also takes a US state. Copilot, Perplexity and Grok take any country, Google Search and AI Mode also take location or uule and hl, and Google News takes country and hl.

Migration: the same ChatGPT job

On Bright Data

Bright Data’s docs show a synchronous scrape request with a dataset id in the query string, bearer auth, and a JSON array of inputs where each input has a url, a prompt and an optional country (checked 2026-09-17, docs.brightdata.com):

curl -X POST "https://api.brightdata.com/datasets/v3/scrape?dataset_id=gd_m7aof0k82r803d5bjm&format=json" \
  -H "Authorization: Bearer $BRIGHTDATA_API_KEY" \
  -H "Content-Type: application/json" \
  -d '[{ "url": "https://chatgpt.com/", "prompt": "Best payroll software for a UK startup", "country": "GB" }]'

The documented record fields include answer_text, answer_html, citations, search_sources, web_search_triggered and model. The same docs describe optional web_search and require_sources inputs.

On this API

curl -X POST https://api.answerline.dev/v1/monitor/chatgpt \
  -H "Authorization: Bearer $API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "prompt": "Best payroll software for a UK startup",
    "country": "GB",
    "include": { "markdown": true }
  }'

Field mapping for the parts most pipelines store:

Migration: Google with the AI Overview

On Bright Data

The SERP API’s async request, per its docs, posts query parameters with a country and asks for parsed JSON; to raise the chance of an AI Overview, their AI Overview page says to add brd_ai_overview=2 (checked 2026-09-17, docs.brightdata.com):

curl -X POST "https://api.brightdata.com/unblocker/req?customer=$ACCOUNT_ID&zone=$SERP_ZONE" \
  -H "Authorization: Bearer $BRIGHTDATA_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{ "country": "us", "query": { "q": "payroll software", "hl": "en", "gl": "us" }, "brd_json": "1" }'

The response id comes back in a header, and the result is collected later or delivered to a webhook configured on the zone or the request.

On this API

The same job is one task:

curl -X POST https://api.answerline.dev/v1/async/task \
  -H "Authorization: Bearer $API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "taskType": "GOOGLE",
    "payload": {
      "query": "payroll software",
      "country": "US",
      "include": { "aioverview": { "markdown": true } }
    },
    "idempotencyKey": "payroll-us-2026-09-17",
    "webhook": { "url": "https://your-app.com/hooks/answers" }
  }'

The delivery carries response.result.aioverview, or null when Google showed no AI Overview, with its sources, citationPills and relatedLinks, next to organicResults, peopleAlsoAsk and the other blocks. The AI Overview add-on is priced on the request, so it is charged whenever include.aioverview is present; see credits.

Receiving results: snapshots vs task deliveries

Bright Data’s scraper jobs return a snapshot: a batch of records you download, or that they push to a webhook or storage target. Its SERP async callbacks, per its docs, usually arrive within minutes but can take up to eight hours at peak, and results are stored for 48 hours.

This API sends one signed delivery per finished task. What that means for your receiver:

1. Verify first. Check Webhook-Signature (HMAC-SHA256 of timestamp and raw body) before parsing. The TypeScript SDK exports verifyWebhook.
2. Deduplicate by task.id. Deliveries can arrive more than once and in any order.
3. Answer fast. A delivery succeeds on a 2xx within 15 seconds and is otherwise retried, up to 10 attempts, the last about 21 to 43 minutes after the first.
4. Treat FAILED as data. A failed task is not charged; decide whether to resubmit it with a new idempotency key.

import express from "express";
import { verifyWebhook } from "@answerline/sdk";

const app = express();
app.post("/hooks/answers", express.raw({ type: "application/json" }), async (req, res) => {
  if (!(await verifyWebhook(req.body, req.get("webhook-signature"), process.env.WEBHOOK_SECRET!))) {
    return res.sendStatus(400);
  }
  const { task, response } = JSON.parse(req.body.toString("utf8"));
  await saveAnswer(task.id, task.status, response); // your storage
  res.sendStatus(204);
});

If you do want bulk files in a warehouse, write deliveries to object storage from this receiver; the per-task payload is the same JSON GET /v1/async/task/{id} returns.

Records versus per-request prices

Bright Data prices a record the same whatever the engine. This API prices each engine per request in dollars (for example, $0.0006 for a ChatGPT task and $0.0002 for a one-page Google News task at the Starter tier, with add-ons listed in credits); ChatGPT, Gemini, Perplexity and Google News cost less on higher tiers, reached by 30-day spend.

A fair comparison:

1. Count answers per engine per month, including every market variant.
2. For Bright Data, multiply total records by the pay-as-you-go rate, or use the Scale plan if your monthly total exceeds its included records.
3. For this API, sum the cost per engine at the prices on pricing.
4. Add the cost of what you’d build around each: dataset-to-row mapping and snapshot handling on one side, a webhook receiver on the other.
5. Check what is charged when an answer comes back incomplete. Bright Data says failed deliveries are not charged; here a failed task is not charged, and a completed one is charged even when an engine returned no sources.

Proving the switch with a parallel run

Before a dataset id changes in production, collect from both sides for a week or two and keep the rows together, tagged by provider.

1. Pick 30 to 50 prompts that matter to your reports, across the engines you use on Bright Data.
2. Keep Bright Data’s jobs unchanged. Add a task per prompt, engine and market here, with an idempotency key such as <prompt-id>-<engine>-<market>-<day>.
3. Normalize both into the same rows: answer text, cited domains, market, engine, collected-at time, and whether the answer came back at all.
4. Record Bright Data records that never arrived and tasks that ended FAILED in the same table, so gaps are visible on both sides.

Then read four things off the table:

• Completion rate per engine and market: answers you can use divided by answers you asked for.
• Cited domains: overlap of the domain sets per prompt. Expect differences between any two runs of the same prompt; compare the overlap between providers with the overlap between two days on one provider.
• Cost per usable answer, including anything you re-ran.
• Operational effort: time spent on snapshot handling and delivery failures versus webhook receiver issues.

Migrate one dataset id at a time, and keep the storage delivery running for the engines still on Bright Data. A snapshot pipeline and a webhook receiver can write the same table, so switching off the first is a separate, reversible change from switching on the second.

Failures and what they cost

Bright Data’s pricing page says failed deliveries are not charged (checked 2026-09-17), and code built around snapshots usually treats a missing record as a gap for the next job to fill. Task deliveries have no next job: a task either completes or ends FAILED, uncharged, and the gap stays in your table until you resubmit it under a new idempotency key.

Deciding that resubmission policy is the real work, because a snapshot pipeline never had to. After that, branch on the code in the error body rather than on the HTTP status: authentication and errors lists the codes, and rate limits explains each 429 and when it clears.

Questions that settle it

1. Which markets do you need? Bright Data’s scrapers take a country, though its Gemini docs said European countries are not available (checked 2026-09-17). Here ChatGPT and Gemini answer from 213 countries, including GB, DE and FR, and Gemini also takes a US state.
2. Where do results land? Warehouse-first teams benefit from Bright Data’s storage delivery; service-first teams from per-task webhooks.
3. Is proxy or dataset spend already committed? Consolidating on Bright Data can win on procurement alone.

Mistakes to avoid when migrating

• Comparing one record to one answer blindly. Check whether a record in your Bright Data job holds one prompt and one answer, as the ChatGPT example does, before multiplying prices.
• Losing the market in the key. Put the market in the idempotency key; otherwise a second market for the same prompt collides with the first.
• Treating aioverview: null as an error. Google shows AI Overviews for some queries and not others. Store the null; it is a measurement.
• Polling at scale. For thousands of tasks use webhooks, not a poll loop per task; async tasks covers the queue limits.

See the quickstart, or the ChatGPT engine page for every result field.

Bright Data is a trademark of its owner. AnswerLine is not affiliated with or endorsed by Bright Data.

Other comparisons