---
title: "You have already responded"
description: "What this message means, which response-limit rule matched, and what to do about it."
group: "Reference"
order: 7
type: "troubleshooting"
parent: "troubleshooting"
keywords:
  - "already responded"
  - "duplicate"
  - "response limit"
  - "repeat"
updated: "2026-07-14"
---

This message means the form's response limit found a standing response under the same identity — and the same scope, if one is configured. It isn't a generic rate-limit error.

## Check the matching rule

Open the form's **Respondents** settings and inspect **Limit responses**.

| Rule | What matched |
| --- | --- |
| Browser | A device-local Fillo browser identifier |
| Email or phone field | The normalized answer in the configured field |
| Signed-in person | The stable respondent ID supplied by the host product |
| Optional scope field | The same person or browser plus the same scalar scope value |

With **Keep first response**, Fillo keeps the original and blocks the repeat. With **Update in place**, a verified signed-in person sees their earlier answers and updates the same response ID.

## If the match looks wrong

1. Confirm the embed is resolving the intended form and published version.
2. Inspect the configured identity field and scope field IDs.
3. Check URL prefill or application `initialData` for a reused scope value.
4. For signed-in people, confirm the host sends the correct stable ID and a valid server-generated hash.
5. Check whether the person already submitted from another device.

Restarting the controller clears current answers but doesn't erase a standing response. Clearing browser storage only bypasses the browser-based mode — that's why it's better suited to light friction than strict enforcement. Typing a different email or phone bypasses a field-based rule the same way.

## Choose what happens on a repeat

Browser or contact-field matching cuts down accidental duplicates. Verified signed-in identity is for when the product needs one response per account, or a safe update in place. Add a scope field for patterns like one vote per account per article.

If a legitimate respondent needs to submit again under a keep-first rule, review their original response, then either change the form policy or delete the original — but only if that fits your data policy. Don't tell them to submit under a different identity.

## Related

- [Response limits](/docs/response-limits): Configure matching, scope, and repeat behavior.
- [Respondents and identity](/docs/respondents): Sign product account IDs on your server.
- [Save and resume](/docs/save-and-resume): Distinguish a recoverable draft from an accepted response.