How to delete and recover form data after a pasted API key

To delete and recover form data after a client pastes a live broker API key, rotate the key first, then delete the submission and every copy of it, then restore anything legitimate from an export or your own store. Deleting alone does not fix the leak, because the secret has probably already reached an inbox, a webhook or a spreadsheet.

Why deleting the row is not the fix

A submission rarely lives in one place. By the time you notice the key, it may sit in:

• the notification email your form sent you
• the confirmation email sent to the respondent, if you echo their answers
• a webhook payload that went to Zapier, Make, n8n or a Slack channel
• a row in a Google Sheet or Airtable base fed by that webhook
• a CSV or XLSX someone exported to share with a teammate
• an AI summary or suggested reply, if your form runs triage on submissions

Assume the key is compromised from the moment it was submitted. That changes the order of work: the exchange or broker side comes first, because it is the only step that actually closes the exposure.

Rotate before you delete

Ask the client to do this from their own account. You should not log in as them, and you should not be handed the replacement either. What each platform needs:

Interactive Brokers trips people up here. There is no key to revoke, so what a client pastes is often their real login. Treat that as the most urgent case on the list.

After rotation, ask the client to check recent orders and balances on the account for anything they did not place. Our team asks for this in writing so there is a record that the check happened.

Step by step: clean up and recover

1. Confirm the key is dead. Ask the client to confirm rotation, then verify it yourself by having the old credentials fail a harmless authenticated call, such as an account read. Do not use them for anything else.
2. Mark the submission. Note the submission ID and timestamp somwehere private before deleeting, so you can later prove what was removed and when.
3. Delete the submission in your form tool. Remove the row from the submissions table, not just the field value, so the full record goes.
4. Chase the copies. Delete the notification email from your inbox and trash, search your sent folder for confirmation emails, clear the Slack message, remove the sheet row, and delete any export file. If a webhook fed a no-code tool, clear that run history too.
5. Recover what was legitimate. The same submission probably held real answers: the strategy desscription, the instrument list, the risk limits. Restore those from an export taken before the deletion, or from your own store, and re-enter them without the secret.
6. Close the loop with the client. Send a short message saying the key was rotated, which copies were removed, and how they should share credentials from now on.

Recovering a legitimate response

Be realistic about recovery. Most form tools treat a deleted submission as gone, and you should not plan around an undelete button unless you have tested one. The reliable options are copies you made on purpose:

• A webhook that writes each submission to a store you control, so you can restore a row without touching the form tool.
• A scheduled CSV, JSON or XLSX export. On Qwenvo, exports come in all three formats, plus a per-submission PDF.
• Partial submissions, if your tool keeps them. They show up as incomplete rows, so a client who abandoned the form halfway may still have answers you can read.

Version history helps with a different problem. Qwenvo keeps 90 days of form versions, which lets you roll back an edit to the form itself. It does not bring back deleted responses.

If you do restore from a backup, scrub it first. Run the same check on the backup that you run on live data, or the key comes back with the answers.

Collect read-only or paper keys only

The cleanest policy is that your intake form never asks for a live credential. During the build, we only need two things: a description of the strategy, and paper access to prove it. Live credentials come later, after the paper-trading gate passes, and they go straight into the cloud secret store, entered by the client, never through a form or a chat message.

In the Broker-API Trading Bot workflow, the intake form sits at the very start, before any code exists. It captures the broker, the instruments, the strategy rules, risk limits and the contact details. It should not capture secrets, and the page should say so in plain words above the first field.

A few chagnes to the form itself reduce mistakes:

• Add a text block at the top: "Do not paste API keys, passwords or seed phrases here."
• Ask "Paper or live?" as a multiple choice, and sow the credential instructions only for paper.
• Use a long answer field for notes, with a hint that says what must not go in it.
• Turn off respondent confirmation emails that repeat the answers back, so a stray secret is not mailed to a second inbox.

You can also screen for mistakes automatically. If your submissions go through a webhook, a short check before aynthing is stored catches the obvious cases:

import re

PATTERNS = [
    r"\b(AK|PK)[A-Z0-9]{18}\b",          # Alpaca-style key IDs
    r"\b[A-Za-z0-9]{64}\b",              # long Binance-style keys and secrets
    r"(?i)(secret|api[_ -]?key|password)\s*[:=]\s*\S+",
]

def looks_like_secret(text: str) -> bool:
    return any(re.search(p, text) for p in PATTERNS)

def handle(payload: dict):
    blob = " ".join(str(v) for v in payload.values())
    if looks_like_secret(blob):
        alert_owner("Possible credential in submission")
        return  # do not write to the sheet or CRM
    store(payload)

It will throw false positives, and that is fine. A flagged submission costs you a minute. A stored key costs you an incident.

Where Qwenvo fits

Qwenvo is a free form builder that our tema makes, and it covers this use case without a paid tier. The parts that matter here are webhooks to any URL, so you can mirror submissions to your own store and run the scan above first, and data retention, which deletes responses automatically after a number of days you choose. An audit log records who published, deleted, exported or changed things, whkch helps when you need to show what happened. The form data retention guide covers how long to keep intake data.

Everything is on for every account at $0, including partial submissions, a custom domain, branding removal and teammates. On Tally, partial submissions, custom domains and teammates sit on Pro at $29/month ($24/month billed yearly), and data retention and email verification are on Business at $89/month ($74/month billed yearly).

One honest limit: Qwenvo is hosted in the United States, while Tally is hosted in Europe. If a client in the UK or EU expects their intake data to stay in Europe, that may decide the tool for you. Qwenvo also launched in October 2026, so there are few public reviews yet.

Start from the client intake template

Setting up retention so the problem expires

Auto-deletion is a backstop, not a substitute for rotation, but it limits how long a mistake can sit in your data.

1. Open the form's Settings drawer and find the data retention option.
2. Choose a number of days that fits your build window. For a 10-day project, 30 or 60 days is plenty.
3. Switch off confirmtion emails to respondents unless you really need them.
4. Add the webhook to your own store, and set the same retention rule there.
5. Export once at the end of the project, strip anything sensitive, and keep only what the care plan needs.

See form settings and retention

Questions teams ask

Should I delete the submission or rotate the key first?

Rotate first. Deleting can take an hour once you chase every copy, and the key is usable the whole time. Rotation takes minutes and ends the risk even if you miss a copy.

Can I ask clients for read-only keys at all?

Yes, with limits. A read-only key with trading and withdrawals disabled and an IP restriction can only read data. Even so, collect it through a secret store rather than a form, and still rotate it if it leaks, since it exposes positions and balances.

How do I recover a response I deleted by mistake?

Only from a copy: an earlier export, a webhook-fed store, or a backup. Check whether your form tool offers any undelete before you rely on it. If you have no copy, ask the client to resubmit and tell them why.

Does an AI triage summary count as another copy?

It can. If a submission contains a key, any summary, suggested reply or routed notification generated from it may repeat the text. Include those in your sweep and check where routing rules sent them.

Build your intake form free

Next step

Open your current intake form today, add the "no keys or passwords" notice above the first field, and turn off confirmation emails that echo answers. Then search your inbox and sheets for the words "secret" and "api key" to find anything that is already there.