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 dollar figure is its credits per request at the credit price of the lowest paid plan. Reference plan: Lite.

How requests, geo, billing and delivery work

Where Bright Data is stronger

• 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.

Choose this API for one request contract across engines, US state targeting on the assistants, and per-task idempotency and signed webhooks instead of zones, dataset ids and snapshot downloads. The guide below compares the two integrations.

Which to pick

Pick Bright Data 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.

Pick this API 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 organised

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, credits, 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 the assistants take country and a US state, and Google Search takes country, location, uule, hl and device.

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

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",
      "location": "Austin,Texas,United States",
      "include": { "aioverview": { "markdown": true } }
    },
    "idempotencyKey": "payroll-us-austin-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.

Comparing cost

Bright Data prices a record the same whatever the engine. This API prices each engine in credits (for example, 5 credits for a ChatGPT task and 3 for a one-page Google Search task, with add-ons listed in credits), and the dollar value of a credit depends on your plan.

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 credits per engine and pick the smallest plan that covers them 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.

Running both side by side before cutting over

Start with a parallel run: the same prompts, markets and schedule on Bright Data and on this API for one or two weeks, stored in the same table with a provider column.

1. Pick 30 to 50 prompts that matter to your reports, across the engines you use on Bright Data, plus Google Search with the AI Overview.
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. Normalise 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.

What to compare at the end of the run:

• 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.

Cut over one engine at a time and keep the parallel data: it is the only record of how the switch itself moved your numbers.

Handling errors after the switch

Bright Data reports failures per request on the SERP API and per record or snapshot on its scrapers, and does not charge failed deliveries. Code built around snapshots usually treats a missing record as a gap to fill in the next job.

This API’s errors carry a stable code to branch on (authentication and errors):

Every response carries an X-Request-Id; send your own to tie a request to your logs, and quote it to support. The TypeScript SDK applies this retry policy for you.

Decision checklist

1. Do you need Grok? Bright Data’s docs marked its Grok scraper unavailable on 2026-09-17; this API has a Grok endpoint.
2. Do you need Gemini answers from European markets? Bright Data’s Gemini docs exclude European countries; test your markets on this API’s free credits.
3. Is state-level US data required? This API’s assistants take state.
4. Where do results land? Warehouse-first teams benefit from Bright Data’s storage delivery; service-first teams from per-task webhooks.
5. Is proxy or dataset spend already committed? Consolidating on Bright Data can win on procurement alone.

Pitfalls

• 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 country and state 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.
• Parsing HTML you don’t need. Ask for include.html only when you archive snapshots; the structured fields already carry the answer.

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

Other comparisons