Submission trust

Submission trust can quarantine a response when the embedding application can't prove the respondent's identity.

How verification works

Your server computes an HMAC-SHA256 of a stable external user ID with the workspace identity secret. The embed passes the ID and hash with the respondent context, and Fillo marks the identity verified only when the signature matches.

import { createHmac } from "node:crypto";

export function filloRespondent(user: { id: string; email: string }) {
  const hash = createHmac("sha256", process.env.FILLO_IDENTITY_SECRET!)
    .update(user.id)
    .digest("hex");
  return { id: user.id, email: user.email, hash };
}

Never compute the hash in browser code. That would expose the identity secret and let any script forge a verified user.

What quarantine means

A quarantined submission is stored with a held marker but withheld from every normal consumer:

• It doesn't appear in the default response grid, counts, exports, or insights.
• It doesn't trigger webhooks, Sheets, Notion, Slack, Zapier, the team notification email, or respondent receipts.
• The submitter sees the same success response and can't probe whether the submission was held.
• An owner can open Held, release a legitimate response, or delete it.

Releasing clears the held state and runs normal delivery as a response.created event, keeping the original submission time.

In the dashboard

1. Generate an identity secret under Settings > Developers > Identity verification.
2. Add the server-generated hash to every signed-in embed.
3. Test a valid and an invalid hash.
4. Enable Hold unverified submissions for review in the form's Respondents settings.
5. Confirm the invalid submission appears only under Held.

Don't enable this policy on an anonymous hosted form — every genuine anonymous response would be held.

You can't disable workspace identity verification while any form's live or staged schema uses quarantine. Remove the policy from the published form and from any staged code or dashboard changes, publish or discard that change as appropriate, then disable identity verification. Staged changes count on purpose: without that guard, a later publish could silently reactivate a policy that has no usable secret.

In code

Code-managed forms own the policy in their synced schema:

settings: {
  trust: { unverified: "quarantine" },
}

The policy fails closed. If the workspace has no identity secret, or the submitted identity has no valid signature, Fillo holds the submission instead of accepting it. Generate the identity secret and verify a signed test respondent before enabling the policy — unless holding every submission is what you want.

What trust doesn't prove

Verification proves your server vouched for the external account ID attached to the submission. It doesn't prove the answer is true, that the account has a particular permission, or that the person behind it intended every field value. Keep authorization in the host application.

Related

• Respondents and identity: Configure claimed and verified respondent context.
• Spam and bot protection: Add the Turnstile human check — independent of trust, and a form can require both.
• Response is held for verification: Find and release a legitimate held response.
• Delivery health and replay: Inspect delivery only after a response is accepted or released.