Use this file to discover all available pages before exploring further.
Modern web applications make extensive API calls via XHR and Fetch. This recipe demonstrates how to use bdg to monitor, filter, and analyze API traffic in real-time.
Launch bdg and load the application. Network collection is enabled by default.
bdg https://app.example.com/dashboard
Wait for the session to start and the page to load.
2
Filter for API requests only
Use the API preset to show only XHR and Fetch requests.
# Show all API callsbdg network list --preset api# Or filter explicitlybdg network list --type XHR,Fetch
Expected output:
NETWORK REQUESTS (API only)[0] GET /api/user → 200 OK (145ms) Size: 1.2 KB | Type: Fetch[1] GET /api/dashboard/stats → 200 OK (234ms) Size: 3.4 KB | Type: XHR[2] POST /api/events → 201 Created (89ms) Size: 567 B | Type: Fetch
3
Monitor API calls in real-time
Stream network requests as they happen using follow mode.
# Watch API calls livebdg network list --preset api --follow
Leave this running in one terminal while interacting with the app in another terminal or browser.
4
Find failing API requests
Filter for error status codes to identify issues.
# Show all 4xx and 5xx errorsbdg network list --filter "status-code:>=400"# Show only 401 Unauthorized (auth issues)bdg network list --filter "status-code:401"# Show server errors onlybdg network list --filter "status-code:>=500"# Combine with API filterbdg network list --preset api --filter "status-code:>=400"
Expected output:
NETWORK REQUESTS (errors)[0] GET /api/protected/resource → 401 Unauthorized (67ms) Size: 234 B | Type: Fetch[1] POST /api/data/submit → 422 Unprocessable Entity (112ms) Size: 456 B | Type: XHR
5
Inspect authentication headers
Check request and response headers for authentication issues.
# Get request ID from the failed requestREQUEST_ID=$(bdg network list --filter "status-code:401" --json | jq -r '.data.requests[0].requestId')# Inspect headersbdg network headers $REQUEST_ID
Check if the authorization header is present and properly formatted.
6
Filter API calls by domain
If the app calls multiple APIs, filter by domain to focus on one.
# Show only calls to main APIbdg network list --filter "domain:api.example.com"# Exclude CDN requestsbdg network list --filter "!domain:cdn.*"# Show calls to any subdomainbdg network list --filter "domain:*.example.com"
7
Inspect CORS headers
Check CORS headers on failing cross-origin requests.
# Find requests with CORS-related headersbdg network list --filter "has-response-header:access-control-allow-origin"# Inspect full CORS headersbdg network headers $REQUEST_ID | grep -i "access-control"
Expected output:
access-control-allow-credentials: trueaccess-control-allow-headers: Content-Type, Authorizationaccess-control-allow-methods: GET, POST, PUT, DELETEaccess-control-allow-origin: https://app.example.com
Common CORS issues:
Missing access-control-allow-origin header
Wildcard * origin with credentials
Missing method in access-control-allow-methods
8
Track retry attempts
If the app retries failed requests, identify the pattern.
# Show duplicate requests to same URLbdg network list --json | jq -r '[.data.requests[] | select(.url | contains("/api/retry-test"))] | group_by(.url) | .[] | {url: .[0].url, attempts: length, statuses: [.[].status]}'
This shows 2 failed attempts (500) followed by success (200).
9
Export API traffic as HAR file
Export all network data for analysis in external tools.
# Export while session is runningbdg network har api-debug-$(date +%Y%m%d-%H%M%S).har# Or stop and export final statebdg stopbdg network har final-api-capture.har
Import the HAR file into Chrome DevTools or online HAR viewers for detailed analysis.
10
Analyze request/response bodies
Get full request and response details including bodies.
# Get request ID for failed POSTREQUEST_ID=$(bdg network list --filter "method:POST status-code:422" --json | jq -r '.data.requests[0].requestId')# View full detailsbdg details network $REQUEST_ID
Symptom: OPTIONS requests fail before actual API call.Investigation:
# Show OPTIONS requestsbdg network list --filter "method:OPTIONS"# Check if preflight succeededbdg network list --filter "method:OPTIONS status-code:>=400"# Inspect CORS headersbdg network headers $REQUEST_ID | grep -i "access-control"
Slow API responses
Symptom: API calls take too long.Investigation:
# Export HAR and analyze timingbdg network har timing-analysis.har# Extract timing data via JSONbdg network list --json | jq '.data.requests[] | {url, duration: .timing.duration}' | sort -k2 -nr | head -10
Run commands in sequence and track which API calls they trigger:
# Clear existing databdg stop && bdg https://app.example.com# Perform actionbdg dom click "#refresh-button"# Wait for network to settlesleep 2# Show API calls after actionbdg network list --preset api --last 5
# Fill formbdg dom fill "#username" "testuser"bdg dom fill "#password" "testpass"# Submit and watch networkbdg dom submit "#login-form"# Check for auth API callsbdg network list --filter "domain:api.* method:POST" --last 3