Password protect forms for trading bot setup details

To password protect a form that collects trading bot settings, switch on password protection in the form's settings, send the password over a different channel than the link, and ask only for non-secret parameters such as symbols, position limits and schedules. Broker API keys never go in a form. They belong in a secrets store on the server.

Build your protected intake form

Where the form sits in a bot build

On our fixed-scope trading bot build, the first thing a developer needs from you is the strategy's operating envelope. That means which instruments it trades, how much it may risk, when it runs and what happens when something goes wrong. A form is a good way to collect it because the answers arrive in a consistent shape, and the developer can turn them straight into a config file for the risk module.

Those answers are sensitive without being secret. Your daily loss limit and position sizing say a lot about your account size and your edge. You would not post them in a public Slack channel, but they are also not credentials. That distinction decides what the form asks for and what it never touches.

What belongs in the form

Anything the bot reads as configuration, and that you could change tomorrow without losing money to a leak, is fair game. In practice that covers:

• The broker (Interactive Brokers, Alpaca, Binance or Bybit) and whether the first run is paper or live.
• Symbols or pairs, plus the asset class for each.
• Position limits: max size per order, max open positions, max exposure.
• Loss limits: daily, weekly and the drawdown level that should trip the kill switch.
• Schedule: time zone, trading window, days off, and behavior around holidays or rollovers.
• Order preferences: market or limit, time in force, how to handle partial fills.
• Who gets alerted when the kill switch fires, and how (email or a Slack incoming webhook).

Here is how we usually map form fields to what the developer does with them.

Why API keys never belong in a form

A form is built to store answers and pass them around. A submission lands in a table, may trigger an email notification, can be exported as CSV or JSON, and can be posted to a webhook. Each of tohse is another place the key now lives, and some of them (an inbox, a spreadsheet, a teammate's laptop download) are hard to clean up afterward.

The safer pattern is simple. Create the key yourself in the broker's dashboard, give it the narrowest permissions the strategy needs, and keep withdrawal rights off. On Binance and Bybit you can restrict a key to trading and bind it to the server's IP address. Alpaca issues separate paper and live keys, so the paper-trading gate uses keys that cannot touch real money. Interactive Brokers works through a logged-in TWS or IB Gateway session rather than a key pair, so there is no secret to paste anywhere.

The developer then receives the key through whatever channel your team uses for secrets, and it goes into an environment variable or secrets manager on the cloud host. It is never committed to the repository and never sits in a document. If a key ever does end up in a form, a password does not make that acceptable. Rotate it.

Step by step: set up the protected form

We build Qwenvo, a free form builder, and we use it for this kind of intake. Password protection, data retention and the rest below are all included at no cost.

1. Create the form from the client intake template, or describe it to the AI on the empty-form screen. Add the fields from the table above and nothing else.
2. Open the form's Settings drawer and turn on password protectipn. Choose a long random password rather than something memorable.
3. Turn on prevent duplicate submissions, so a client does not send two conflicting versions of the loss limiit by accident. If you need to revise later, ask for a fresh submission and mark which one is current.
4. Set the form to close after a date or after a number of responses. One response from one client is usually the right number.
5. Set data retention to auto-delete after a number of days that matches your project. The values are in the config file once the bot is built, so the form copy does not need to live on. The form data retention guide covers how to choose that window.
6. Decide who receives notifications and keep the list short.
7. Share the link in one message and the password in another, ideally on a different channel, such as the link by email and the password by a messaging app.

See the form settings guide

What the developer does with the answers

We read the submission once, then write the values into a config file that the bot loads at startup. The form is the human-friendly front door. The config is what the code trusts, and it gets reviewed like any other change.

{
  "broker": "alpaca",
  "mode": "paper",
  "symbols": ["AAPL", "MSFT", "SPY"],
  "risk": {
    "max_order_notional": 5000,
    "max_open_positions": 3,
    "daily_loss_limit": 400,
    "kill_switch_drawdown_pct": 4
  },
  "schedule": {
    "timezone": "America/New_York",
    "window": ["09:45", "15:45"],
    "skip_days": ["US_HOLIDAYS"]
  },
  "alerts": { "slack_webhook_env": "ALERT_SLACK_WEBHOOK" }
}

The numbers above are placeholders, not recommendations. Note the last line: the config stores the name of an environment variable, not the webhook URL itself. Keys and URLs lvie in the secrets store, and the config only points at them. This keeps the file safe to put in version control and easy for you to read.

If you want submissions pshed to the developer automatically, Qwenvo can send them to any URL through a webhook, which works with Zapier, Make or n8n. For a one-off intake, reading the submission and copying values across by hand is often better, because a human checks each number against the strategy.

What a password does and does not do

A form password is a gate on who can open the form. It is a shared secret, so anyone who has it can fill the form in, and it does nothing to protect an answer after it is submitted. That is why the retention setting and the short notification list matter as much as the password itself.

A few limits worth knowing. Qwenvo is hosted in the United States, so if your data must stay in the EU, Tally is hosted in Europe and may suit you better. There is no HIPAA offering, which is irrelevant for trading settings but worth knowing if you reuse the form elsewhere. The audit log shows who published, exported, deleted or changed things, which helps if more than one person on your side touches the form. On Tally, data retention is on the Business plan at $89 a month. On Qwenvo it is free.

Open the free form builder

Questions teams ask

Can I put my broker API key in a password protected form if the form is private?

No. Privacy at the door does not control where the answer goes afterward. Submissions can reach email notifications, exports and webhooks, so the key would be copied into several places. Keep keys in a server secrets store and share them through your normal secrets channel.

Is the account number safe to include?

Skip it where you can. If the developer needs to confirm the right account, ask for the last four digits only. The bot connects through its credentials, so it does not need the full number from a form.

How long should I keep the submission?

Only as long as the build needs it. Once the values are in the reviewed config file and you have confirmed them in paper trading, the form copy is redundant. Set auto-delete for a date shortly after go-live.

Should the paper-trading numbers match the live ones?

Start paper trading wih the same limits you intend to use live, so the risk module is tested as it will run. If you later raise a limit, submit a new form and treat it as a config change that goes through paper first.

Next step

Open the client intake template, cut it down to the fields in the table, turn on password protection and retrntion in Settings, and send the link and password separately. Then book the build, and keep your API keys in your own hands until the secrets store is ready on the server.