One project per site,
and you decide where reports land

Create a project per site: list the domains allowed to submit, and bind the integration its reports should reach. Each site gets its own rules β€” no cross-talk.

Four things a project decides

Everything else inherits from these four settings.

πŸ“

Project

A container for one site or product, with its own key, reports and retention.

🌐

Domain whitelist

Only the domains you list can submit reports through the Web SDK key.

πŸ”€

Routing

Which integration receives this project's reports by default.

πŸ”‘

Access

A project belongs either to you or to a team, and inherits that visibility.

Protect the key with a domain list

The Web SDK key is visible in your page source. The whitelist is what makes that safe.

MatchingExact host and wildcard subdomains
Unlisted domainsSubmissions are rejected server side
Local developmentAdd localhost with a port to test safely
Rate limitsApplied per project per day and per IP per day
Allowed domains
acme.com
app.acme.com
*.staging.acme.com
localhost:3000
One entry per line. Wildcards cover subdomains.

Each site reports to its own table

Every project is bound to its own integration: your UAT site reports into the UAT table, your marketing site into its own. The default already lands in the right place, with no manual sorting.

Where it came fromDefault destination
Web SDK submission on a whitelisted domainThe project's bound integration
Browser extension on a whitelisted domainThe site project, as chosen in the destination dropdown
Extension on a domain with no projectThe reporter's team or personal destination
Manual override by the reporterWhatever they select, remembered for that site

More from BugCapturer