Filtering console and network capture

The SDK gives you precise control over what gets captured, and the filtering runs in the browser before anything is transmitted. Excluded data is never sent to BugDump.

This is the right tool when your app handles data that should not leave the user's machine.

Filtering network requests

Bugdump.init({
  apiKey: 'your-api-key',
  networkFilter: {
    excludeUrls: [/\/auth\//, 'https://api.stripe.com'],
    includeUrls: [/\/api\//],
    excludeMethods: ['OPTIONS'],
    filter: (entry) => entry.status !== 401,
  },
});

The filter callback receives the complete entry, so you can decide on anything in it:

interface NetworkFilterEntry {
  method: string;
  url: string;
  status: number | null;
  statusText: string | null;
  requestHeaders: Record<string, string>;
  responseHeaders: Record<string, string>;
  requestBody: string | null;
  responseBody: string | null;
  duration: number | null;
  startedAt: number;
  error: string | null;
}

A common pattern — keep your own API traffic, drop third parties and auth:

networkFilter: {
  includeUrls: [/^https:\/\/api\.myapp\.com/],
  excludeUrls: [/\/auth\//, /\/payment\//],
}

Another — keep only what failed, when reports are getting large:

networkFilter: {
  filter: (entry) => entry.status === null || entry.status >= 400,
}

Filtering console logs

Bugdump.init({
  apiKey: 'your-api-key',
  consoleFilter: {
    levels: ['error', 'warn'],
    exclude: [/\[analytics\]/, 'Download the React DevTools'],
    filter: (entry) => !String(entry.args[0]).includes('token'),
  },
});

The entry passed to filter:

interface ConsoleFilterEntry {
  level: ConsoleLogLevel;
  args: unknown[];
  timestamp: number;
}

Restricting to ['error', 'warn'] is the most common configuration. Chatty console.log output from third-party libraries adds size without adding signal.

A caution on over-filtering

Filtering aggressively is tempting and can backfire. Reports exist to explain bugs, and a report filtered down to nothing explains nothing.

Two specific traps:

Excluding the endpoint that breaks. Dropping everything but /api/ also drops the CDN request that 404s, and that was your bug.

Keeping only errors. A request returning 200 with a wrong body produces no error anywhere. If you filter to status >= 400, that class of bug becomes invisible.

Filter for privacy and for genuine noise. Resist filtering for size alone — reports are not that large, and the entry you drop is the one you will want.

Filtering versus feature toggles

These solve different problems.

Feature toggles turn a whole capability off — no screenshots at all, no session replay at all. Use them when a data type should never be collected.

Filters keep a capability on and remove specific entries. Use them when you want console and network data but must exclude particular endpoints or messages.

For sensitive routes, combining both is reasonable: filter network by URL, and disable session replay entirely.

Where this fits with captureNetworkBodies

captureNetworkBodies is off by default, so bodies are not collected at all unless you opt in. If you enable it, the network filter callback becomes considerably more important — that is where you strip the specific payloads that must not be stored, while keeping the ones you need to debug.

Bugdump.init({
  apiKey: 'your-api-key',
  captureNetworkBodies: true,
  networkFilter: {
    excludeUrls: [/\/auth\//, /\/billing\//],
  },
});

See also

• Feature toggles and handling sensitive data

• SDK API reference