Help, troubleshooting, and answers for Auto API.

Two rails working together. The primary path attaches to the active tab via the Chrome DevTools Protocol (the chrome.debugger API) and listens for Network.requestWillBeSent + Network.responseReceived events. That gives Auto API access to every fetch and XMLHttpRequest with full headers and bodies, including responses.

The fallback path is a page-world script injected via chrome.scripting that hooks window.fetch and the XHR prototype. This catches edge cases CDP misses — for example, requests dispatched from service workers, or page contexts where CDP attachment is restricted.

Both rails feed the same in-memory store, deduplicated by request ID. You don't see duplicate rows even when both pick up the same call.

No. Every captured request, response body, header, and saved suite lives in your browser's own IndexedDB store (via Dexie). Nothing is sent to a server, no analytics, no telemetry, no remote logging. The extension has no network hosts allowlisted — you can verify this in manifest.json.

When you click Clear, the local store is wiped. When you uninstall the extension, Chrome deletes the IndexedDB store with it. There's no cloud component.

Three things to check, in order:

• The Start button should be showing as red Stop with a pulsing dot. If it still says Start, click it.
• Refresh the target tab after clicking Start. The page-world interceptor only hooks fetch and XHR at script-injection time; requests dispatched before injection are missed.
• If you have Chrome DevTools open on the same tab, only one client can attach via CDP at a time. Close DevTools or use a different tab.

Restricted pages (chrome://*, the Chrome Web Store, other extensions' pages) don't allow CDP attachment by design — Auto API can't capture there.

Export generates a complete runnable project bundle — test_*.py + conftest.py + requirements.txt + .env.example + README.md for pytest, or the equivalent Maven / Node project layout for RestAssured / Playwright. You download the .zip, drop it in your repo, and it runs in CI.

Run executes every captured request right inside the extension, sequentially, through the same engine. Each row shows pass / fail against the originally captured status code. It's a fast smoke test — "do my captured flows still work?" — without ever leaving the panel.

By far the most common cause: the Authorization bearer token captured during recording has expired. Auto API extracts auth tokens into a typed env var (AUTH_TOKEN) precisely for this — open .env in the exported project, drop in a fresh token, and re-run.

Other tokens follow the same pattern: API_KEY, CSRF_TOKEN, ACCESS_TOKEN, SESSION_ID. All live in .env; none are hard-coded in the test file.

Two approaches:

• Filter while capturing: use the search bar to narrow by URL, method, or GraphQL op name. Use the category sidebar to scope to a class of requests (Auth, Users, Orders, etc.). Toggle Show noise off to hide static-asset requests, beacons, and similar low-value traffic.
• Capture everything, export a subset: tick the checkboxes next to the requests you want, click Export N in the selection toolbar, and choose a format. The bundle contains only the requests you selected, in capture order.

Yes — click cURL in the top bar. The parser handles every flavor:

• Chrome DevTools "Copy as cURL" (backslash continuations, --compressed)
• Postman "Copy → cURL" (--location, multi-line --data JSON)
• Hand-written one-liners with -X, -H, -d
• -u user:pass becomes a proper Authorization: Basic … header
• Body Content-Type is sniffed from shape if not set

Once parsed, the same Export menu and Run flow that work on captured requests work on the pasted one.

Most. The exceptions are sites Chrome itself protects from extensions:

• chrome://* and the Chrome Web Store
• Other extensions' background and options pages
• Pages where another DevTools client is already attached (close DevTools to free the slot)
• Some sandboxed iframes

Everywhere else — your staging, your prod, third-party APIs, GraphQL endpoints, internal tools — works the same way.

In your browser's IndexedDB, scoped to the extension. The schema has four tables: current (the active capture), sessions (capture metadata), suites (auto-saved test suites), and settings (your preferences).

Clicking Clear empties the current and sessions tables. Deleting an individual suite removes it from the suites table. Uninstalling the extension removes the entire store.

It's the only way to listen for the network requests your page makes at a level that gives you full headers and full response bodies. The same permission powers Chrome DevTools itself.

When the extension is attached, Chrome shows a yellow infobar at the top of the tab — "Auto API started debugging this browser". That's Chrome being transparent about an extension having that capability. The bar disappears as soon as you click Stop or close the tab.

The permission is only used to attach to the tab you're capturing in, and never sends data anywhere. Full permission list.

Auto API regenerates the bundle every time you switch format or change the active suite, so direct in-extension editing isn't supported — your edits would be lost on the next regeneration. Instead, download the .zip and edit the files in your own editor. They're plain Python / Java / TypeScript with no tool-specific markup.

Yes — click any captured request to focus it, then open the Replay tab. You can edit method, URL, headers, and body before sending, then click Send to fire just that one request. The response shows up in the same panel, with headers and body fully inspectable.