> ## Documentation Index > Fetch the complete documentation index at: https://docs.brightdata.com/llms.txt > Use this file to discover all available pages before exploring further. # Scraper API error codes > Look up Bright Data Scraper API error codes: HTTP 400, 401, 404 and 429 messages with fixes, the 429 IP block rule and record-level errors like dead_page. This reference lists the errors the Bright Data Scraper API returns, what each one means and what to do about it. Scraper API errors come in two layers: * **HTTP errors:** the request itself failed. The API answers with a 4xx status and no job runs * **Record errors:** the request succeeded, but one input could not be scraped. The failed record carries an `error_code` field inside the results ## What do the Scraper API HTTP errors mean? The Scraper API returns these HTTP errors from `POST /datasets/v3/trigger` and `POST /datasets/v3/scrape`. | Status | Message | Meaning | Retry? | What to do | | - | - | - | - | - | | 400 | `{"error": "Invalid input provided", "code": "validation_error", "errors": [[FIELD, REASON]]}` | An input field failed validation. `errors` names the field and the reason, for example `["url", "This field must be a valid url"]` | No | Fix the input value named in `errors` and resend | | 400 | `{"error": "Parser cannot parse input: ...", "code": "parse_error"}` | The request body is not valid JSON | No | Fix the JSON and resend | | 400 | `No data to trigger` | The request holds no inputs | No | Send at least one input | | 400 | `Should be at least LIMIT inputs` | The request holds fewer inputs than the scraper requires. Returned by `/trigger` | No | Send at least the number of inputs the message names | | 401 | `Credentials are missing` | No `Authorization` header was sent | No | Send `Authorization: Bearer YOUR_API_KEY` | | 401 | `Auth method is not supported` | The `Authorization` header is not in a supported format | No | Send `Authorization: Bearer YOUR_API_KEY` | | 401 | `Invalid credentials` | The API key is wrong | No | Check the API key and resend | | 404 | `Collector not found` | The request has no `dataset_id` query parameter | No | Add the `dataset_id` query parameter | | 404 | `dataset does not exist` | No scraper matches the `dataset_id` | No | Check the `dataset_id` value | | 429 | `You have too many running jobs for this dataset. Please wait until some of them finish or consider combining multiple inputs into a single request. Running jobs: RUNNING_JOBS>=JOBS_LIMIT` | You exceeded the concurrent job limit of 5,000 active jobs or snapshots | Yes, after waiting | Wait the seconds in the `Retry-After` header, or back off 2, 4, 8, 16 and 32 seconds. See [the 429 block rule](#what-happens-if-i-get-too-many-429-errors) | | 202 | `Your request is still in progress and cannot be retrieved in this call.` | **Not an error.** A `/scrape` request ran past 1 minute and the job continues asynchronously. The body carries a `snapshot_id` | No | Poll [Monitor progress](/api-reference/scrapers/management-apis/monitor-progress) with the `snapshot_id`, then [Download snapshot](/api-reference/scrapers/delivery-apis/download-snapshot) | Unless a row names one endpoint, `/trigger` and `/scrape` return the same message. The `validation_error` and `parse_error` bodies are JSON. Every other message is plain text. ## What happens if I get too many 429 errors? Bright Data blocks any IP that receives 25 or more 429 responses within 5 minutes. A blocked IP is refused on every API request until [Bright Data support](mailto:support@brightdata.com) clears it. Treat a 429 as a signal to slow down, not to retry at once: 1. Stop sending new requests as soon as you receive a 429. 2. Wait the number of seconds in the `Retry-After` header. If the header is missing, back off 2, 4, 8, 16 and 32 seconds. 3. Reduce concurrency if 429 responses keep coming. Ten or more 429 responses within 5 minutes means you are close to the 25-in-5-minutes block threshold. Reduce the request rate right away. The retry code is in [Getting a 429 Too Many Requests error?](/products/scrapers/scrapers-library/async-requests#getting-a-429-too-many-requests-error) on the async guide. ## What do Scraper API record errors mean? A record error means the Scraper API job ran, but one input returned no data. The failed record appears in the results only when the request sets `include_errors=true`. Branch on the `error_code` field, not on the free-text `error` message, because the message text changes as scrapers are updated. Bright Data does not charge for failed records. | `error_code` | Meaning | | - | - | | `dead_page` | The page does not exist or is no longer available, for example a 404 or a removed product | | `bucket_rate_limit` | Requests to the target domain are being rate limited | | `global_rate_limit` | Requests to the target domain are being rate limited | A `dead_page` record from `POST /datasets/v3/scrape` with `include_errors=true` looks like this. The request itself returns HTTP 200: ```json theme={null} [ { "timestamp": "2026-09-30T08:37:27.027Z", "input": { "url": "https://www.amazon.com/dp/B09XXEFFA4", "asin": "", "zipcode": "", "language": "" }, "error": "The navigation resulted in a dead page (404 status code)", "error_code": "dead_page" } ] ``` The record keeps the original `input`, so you can match the error back to the URL you sent. For the full list of record error codes, see [Scraper Studio error codes](/products/scraper-studio/error-codes). ## Is an empty result an error? No. An empty result (`[]`) means the job returned no data. It is not an HTTP error. To see why an input returned nothing, resend the request with `include_errors=true` and read the `error_code` on each record. ## Related pages * [How to scrape in bulk with async requests](/products/scrapers/scrapers-library/async-requests) * [Scraper async requests reference](/api-reference/rest-api/scraper/asynchronous-requests) * [Scraper sync requests reference](/api-reference/scrapers/synchronous-requests) * [Scraper API FAQs](/products/scrapers/scrapers-library/faqs)