/billing

name: billing
description: 'Use when the question is about money on a Bright Data account: current balance, credit left, what was charged, spend or cost history, credits or free tier used, cost per zone, product or dataset, or what a job will cost before it runs. Read-only, and it never buys or changes anything. Not scraping or extraction (use scrape), not how to drive the CLI itself (use brightdata-cli), not a refused or failing call (use agent-onboarding).'

Bright Data - Billing

Two questions come up: what has this account already spent, and what will this job cost? The first has an exact answer from the account's own numbers. The second is always an estimate, so say so.

Read-only, no exceptions

Read the numbers, report them, stop. Never add or change a payment method, never top up a balance, never set auto-recharge, never change a plan, never buy a dataset, never cancel anything. Those actions belong to the person, not the agent, even when the user asks the agent to do them. Send them to brightdata.com/cp/billing/settings and let them click it themselves.

Never run a real job to find out what the account can do or what something costs. A Web Unlocker request, a scraper trigger and a browser session all spend money. Every read below is free and starts nothing.

The reads

| The question | Command | Endpoint behind it | |---|---|---| | How much money is left | `bdata budget balance` | `GET /customer/balance` | | What one zone cost | `bdata budget zone <name> --from <date> --to <date>` | `GET /zone?zone=<name>` and `GET /zone/cost?zone=<name>` | | What all active zones cost | `bdata budget zones --from <date> --to <date>` | `GET /zone/get_active_zones`, then one `/zone/cost` per zone | | What each product, zone, dataset or domain cost | no CLI command, call it directly | `POST /costs/export/json` | | What scraping cost | no CLI command, call it directly | `POST /costs/export/json` with `dimension` `web_apis` for Web Scraper API, `collectors` for Scraper Studio | | Which zones exist, including deleted ones | no CLI command, call it directly | `GET /zone/get_all_zones` | | Which website ate the budget | no CLI command, call it directly | `GET /domains/req` and `GET /domains/bw`, dates required | | How many records a snapshot delivered | no CLI command, call it directly | `GET /datasets/v3/snapshots?dataset_id=<id>`, read `dataset_size` |

Base host is `https://api.brightdata.com` and auth is the header `Authorization: Bearer <key>`. Read the key from the environment or the CLI's own store. The exact file path for each OS, and the safe way to read it without printing it, live in the `agent-onboarding` skill's auth reference. That reference also has the thing that trips agents here: after a CLI login, `BRIGHTDATA_API_KEY` is unset, and that is normal rather than a sign the machine is logged out, because login writes the key to the CLI's store and never to the environment. Never ask the user to paste a key into the conversation, and never print one: to check that a key exists, run `node scripts/check-auth.mjs` from the `agent-onboarding` skill, never `cat`, `echo` or `jq` the credentials file or the variable.

`/zone/cost` only sees zone-backed products such as Web Unlocker, SERP, Browser API and the proxy networks. Web Scraper API and Scraper Studio spend is keyed by dataset id and collector rather than by zone name, so it never appears there. Those go to the cost export.

Which key can read this

API keys carry one of five permission levels: Admin, Finance, Ops, User and Limit. Billing and cost data needs Finance or Admin, and Finance is the least-privileged one that works, so prefer it. Use a Finance key directly in the `Authorization` header for these reads: `bdata login --api-key` expects a full-access key, so keep the CLI logged in with an Admin key and the Finance key for the API. Only account admins create or change keys, at brightdata.com/cp/setting/users. A 401 means the key is missing, revoked or wrong. A 403 means the key is real but under-privileged for billing, so name the missing access instead of retrying. A Finance key may not read product data such as snapshots or Studio jobs, and that split is fine: report the half you can read and say which access the other half needs. A 404 means a wrong or expired snapshot, job or dataset id, while a wrong zone name answers 422.

Using the budget commands well

Three habits make the `bdata budget` output reliable. Always pass `--from` and `--to` to `budget zone` and `budget zones`, so the figure covers exactly the window you asked about. For the pending charge, read `pending_costs` from `GET /customer/balance` directly. And when you need machine-readable output, call the endpoint rather than the balance command.

Before writing any parsing code, read `references/cost-api.md` for the field lists and the live response samples, including how the date parameters behave (`to` is exclusive on these endpoints).

What a job will cost before it runs

No endpoint returns a quote, so never present one as if it came from the API. Build the estimate in three steps and label it an estimate.

1. **Find the billing unit for the product.** Web Unlocker and SERP bill per successful request, and failed requests are not charged, with one exception: enabling custom headers or cookies bills every request. A SERP request that returns several result pages is still one request. Web Scraper API bills per delivered record, and attempts that fail because of incorrect inputs still bill. Scraper Studio bills per page load, with file downloads charged separately per GB. Browser API and the proxy networks bill per GB of traffic, and some proxy plans are a fixed charge per IP instead. 2. **Count the units, not the inputs.** One input is not one record. Five listing URLs that each hold twenty products produce a hundred records. A batch of ten URLs is ten separate billable requests. Pagination pages, detail pages and extra navigations each co