Skip to main content
Read the Notte skill and follow its setup instructions when setting up Notte or building browser automation. This is the shared source for CLI setup, authentication, and the browser-to-code workflow.
A secret proxy is not limited to payment cards. It can swap any stand-in that the page sends to a listed host in an HTTP or HTTPS request: a username or password on a login form, a 2FA code, an API key or a bearer token. The agent, the page, screenshots, recordings and network logs only contain the stand-ins, provided your proxy also masks real values in responses. Notte only routes the traffic. Which values are swapped, and where in the request, depends on your secret proxy.

What you can swap

To cover every row, your secret proxy must replace stand-ins in request headers, the query string, form bodies and JSON bodies, including JSON strings written with \u escapes. See the Evervault, VGS and custom proxy pages for what each option supports. Each stand-in must also pass the page’s own checks before the form is sent: length, allowed characters, or a Luhn check for card numbers.

Log in with stand-ins

  1. Get stand-ins for the username, password and 2FA code from your provider or your own proxy.
  2. Start a session whose hosts lists the host that receives the login request.
  3. Fill the stand-ins and submit the form.
  4. Your secret proxy swaps them on the way to that host. The site receives the real values.
An agent can fill the stand-ins too. They are not secrets, so they can go in the agent’s task.

2FA codes

A TOTP code changes every interval, usually 30 seconds, so a stand-in cannot map to one fixed real value. Have your secret proxy compute the code when the request passes through:
  1. Store the TOTP seed in your proxy’s vault, next to a stable stand-in such as tok_otp_4Lm8Rv.
  2. The agent types that stand-in into the code field, at every login.
  3. On the request to the listed host, your proxy looks up the seed, computes the current code as defined in RFC 6238, with the interval, algorithm and number of digits the site set up for that account, and sends it in place of the stand-in.
The seed never leaves your systems, and the same stand-in works for every login.
  • Two logins in one interval. Both get the same code, and many sites accept a code only once. After a login, wait for the next interval before the next one.
  • Fields that only accept digits. If the code field only accepts six digits, the stand-in must be six digits too. A short number can also appear elsewhere in the request, so swap it only in the code field, selected by its form field name or JSON path.
  • Codes sent by SMS or email. The real code arrives on a phone number or inbox you control, so your proxy cannot compute it. It would have to fetch the code at request time, which depends on your setup.
  • Recovery and backup codes are fixed values. Treat them like a password.
  • Provider support. Evervault’s Browser Tokens docs list passwords, recovery codes and one-time backup codes, which are stored values, and do not describe computing a value at request time. VGS’s public docs do not describe it either. For TOTP codes, use this pattern with a custom proxy, or use a Notte vault.

Limits

List the host that receives the request

Swaps only happen on requests to the hosts you list. A login page often sends the password to another host than the one in the address bar: an auth domain, a regional API host or an identity provider. A request to an unlisted host carries the stand-in unchanged, and the login fails. To find the host, open the login page in a browser with developer tools, sign in with a test account and read the host of the request that carries the password. Do the same for the 2FA step. Remember that *.example.com does not match example.com. Your secret proxy decrypts all traffic to the listed hosts, so list only the hosts that receive secrets or send them back. A host you do not list returns its responses to the browser unchanged, so if a site shows a real value on another host, for example the account email on app.example.com, list that host too and mask its responses.

Plain HTTP

On a plain HTTP request, your secret proxy sends the real value to the site without encryption. hosts matches host names, not schemes, so a listed host the page also reaches over plain HTTP sends those requests through your proxy too. Configure your proxy to refuse plain HTTP requests or to leave their stand-ins unchanged. Evervault’s browser proxy only accepts HTTPS.

Values the page encrypts before sending

Some sites encrypt or hash the password or card number with JavaScript in the page before sending it. The request then carries a value computed from the stand-in, not the stand-in itself, so no proxy can swap it, and the site rejects the login or payment. Test each site with a stand-in before you rely on it. For these sites, a Notte vault fills the real value in the page and can work where a secret proxy cannot.

Channels other than HTTP requests

This page covers values sent in HTTP requests: headers, query strings, form bodies and JSON bodies. Whether values sent in WebSocket messages are swapped depends on your proxy. Evervault’s and VGS’s public docs do not cover it, so do not rely on it without testing.

Real values in responses

Many sites send account details back: the username or email on the next page, an API key shown once in a portal, a token in a JSON response. Notte does not change responses, so configure your secret proxy to replace real values with stand-ins in responses from the listed hosts. See Mask real values in responses. After a login, the site also issues its own session cookie or token. That value is real and lives in the browser, as in any session, unless your proxy replaces it with a stand-in in responses and swaps it back on requests.

Secret proxy or vault

Notte vaults also fill credentials without the agent seeing them. They work differently: Use a secret proxy when real values must never reach Notte, for example to keep Notte out of your compliance scope, or when the values already live with your tokenization provider. Use a vault when Notte holding encrypted credentials is acceptable. You can also fill logins from 1Password or Bitwarden. In both, the real value reaches the browser, as with a Notte vault.

Next Steps

Secret Proxies

Request fields, rules and response masking

Custom proxy

Run your own secret proxy

Secret Vaults

Let Notte store and fill credentials

Cookies

Set cookies on a session