Authenticated flows
CrawlVolt supports authentication to accounts that the API customer owns or is explicitly authorized to automate. It is not a credential vault and does not accept a reusable username/password object.
Supported pattern
- Create a short-lived CrawlVolt session.
- Send the current login values as
fillortypeactions over HTTPS. - Submit the form and wait for an authenticated page signal.
- Reuse only the returned
session_idfor later calls. - Revoke the session as soon as the workflow ends.
Action values exist only in request memory while the browser operation runs. CrawlVolt does not write request bodies, passwords or one-time codes to the session table. Only the resulting bounded cookie jar is persisted, encrypted at rest, and cookies never appear in the public response.
Session-scoped responses carry Cache-Control: private, no-store; session traffic also bypasses the shared render cache.
One-time codes and MFA
A caller may submit a one-time code it already obtained through an authorized channel as an ordinary fill action. CrawlVolt does not generate, retrieve or persist TOTP seeds, recovery codes or magic-link inbox access.
Passkeys, WebAuthn security keys, device approval prompts and CAPTCHA solving are unsupported public flows. File upload actions are also not exposed in the preview.
Cookie import
Raw cookie import is intentionally not part of the public V2 API. A session cookie jar must be established by the isolated browser flow. This keeps cookie material out of client responses and gives every stored jar an account, project, expiration and revocation boundary.
High-risk operations
Payments, purchases, money movement, password or recovery-method changes, account deletion, permission changes and other irreversible actions are outside the supported preview. The browser API cannot infer business intent from a generic click selector, so customers must not use CrawlVolt for those actions.
Only automate accounts and websites you are authorized to access. Use a dedicated least-privilege account, a short session lifetime and one in-flight request per session. Never place credentials in URLs, selectors, idempotency keys or logs.