Bright Data Client Workspace Provisioning and Usage Guardrails (Onboarding)

Bright Data Client Workspace Provisioning and Usage Guardrails (Onboarding)

1. 01

   Create the Bright Data account under the agency entity, not the client's

   Keep billing and API ownership with the agency so a client offboarding does not strand proxy credentials or dataset history mid-retainer.

2. 02

   Provision the specific products the engagement needs in the dashboard

   Enable only what the scope calls for: Scraper APIs for the target domains, SERP API for search monitoring, Browser API for anti-bot pages, or residential proxy access. Extra enabled products invite accidental consumption.

3. 03

   Issue a dedicated API key per client engagement

   One key per client makes usage attribution clean when reconciling consumption-based billing against the retainer, and lets you revoke access without touching other accounts.

4. 04

   Map the client's target domains against Bright Data's pre-built Scraper API coverage

   For domains already covered, use the pre-built scraper rather than a custom Browser API build. Custom builds only where coverage gaps exist, since each custom pipeline adds maintenance hours to the retainer.

5. 05

   Validate extracted data against the client's expected schema before the first delivery

   Run a sample pull, compare field names, types, and freshness against what the client's BI dashboard or spreadsheet expects, and get written sign-off on the schema.

6. 06

   Set spend and request ceilings on the account before handing over any dashboard access

   Consumption-based pricing means a runaway crawl on a client's behalf lands on the agency invoice. Cap monthly requests and page loads at a level the retainer can absorb.

7. 07

   Document the pipeline architecture and handoff runbook

   Record which products are enabled, which API keys map to which client, the alerting thresholds configured, and the escalation path when a target site changes its anti-bot posture.