Custom Visitor ID (Embedded Forms)

When you embed a NueForm inside your own app, you usually already know who the user is — they have an account in your system, you have an internal user ID, and you'd like the form to silently restore their previous answers each time they open it. Without you having to manage NueForm cookies, browser storage, or your respondents seeing a "Continue or start fresh?" prompt.

The nf_visitor URL parameter handles this. Paired with the Allow Resume + Auto-resume form settings, your end users see only the form — never NueForm's resume chrome.

Quick example

https://nueform.io/f/your-form-slug?nf_visitor=user-12345

If a partial response exists for user-12345, the form silently restores it. If not, the form starts fresh. The user never sees a modal, never picks "Continue or Start fresh", never knows there's a resume mechanism at all.

To "reset" a user (give them a fresh start), pick a new nf_visitor value:

https://nueform.io/f/your-form-slug?nf_visitor=user-12345-attempt-2

Identity tracking is your responsibility — pick whatever scheme suits your app.

Setup checklist

1. Open your form in the NueForm builder.
2. Expand the Allow Resume section.
3. Turn on Allow respondents to resume where they left off.
4. Turn on the new Auto-resume child toggle.
5. Embed the form using the URL pattern above, supplying your own nf_visitor value.

That's it.

How it works

• nf_visitor is read by the form-respondent page on every load.
• It replaces the cookie-based visitor ID NueForm normally uses for resume + dedup.
• Nothing is written to localStorage when nf_visitor is present — your value is the source of truth, and your respondent's browser stays clean.
• Submissions, partial saves, and resume look-ups all key off your value.
• The parameter is stripped from urlVariables before form-variable substitution runs, so it never leaks into hidden fields, webhook payloads, or analytics traffic-source detection.

Validation rules

The value must:

• Be 1–256 characters long
• Match [A-Za-z0-9_\-:.@]+ — letters, digits, underscore, hyphen, colon, period, and @

UUIDs, email addresses, and most opaque IDs from your own database fit naturally. If the value doesn't match, NueForm silently ignores it and falls back to the cookie-derived visitor ID. No error is surfaced to the user, so verify behavior with your test setup before going live.

When nf_visitor is ignored

nf_visitor is completely ignored when the form has Require respondent login turned on.

These two features are mutually exclusive — you can't have both. If Require respondent login is on, NueForm uses the respondent's authenticated identity (Auth0 session) and the URL parameter is treated as if it had never been provided. Everything flows naturally as a normal logged-in form load.

If you need both behaviors on the same form, you have to pick one — they're answering fundamentally different questions:

• Require respondent login says: "I need a verified identity I can trust on every submission."
• nf_visitor says: "I'll vouch for the identity myself, please use this opaque ID."

The two can't be reconciled at the form level. If you need verified identity inside an embedded scenario, use Require respondent login and let your users sign into NueForm directly.

Pairing with Auto-resume

Auto-resume is the feature that makes nf_visitor shine in embedded scenarios. With both on:

• Returning users see their previously-entered answers immediately. No prompt, no choice.
• New users (a fresh nf_visitor value) see an empty form.
• "Read-only after submit" is honored — once the user has submitted, subsequent loads with the same nf_visitor show the read-only completed view, which is exactly what you want for an embedded record/receipt scenario.

Without Auto-resume, returning users would still see NueForm's "Continue or Start fresh?" modal even though you've supplied identity — a UX wart for embedded use cases. Auto-resume removes it.

Privacy notes

• nf_visitor becomes the primary lookup key for the response in NueForm's database. Choose values you control and that don't collide between unrelated users.
• Don't put PII you don't want stored in NueForm in the value (e.g. don't pass raw email addresses if you can use an opaque ID instead). The value rides through to webhook payloads + analytics for the response.
• The value is visible to anyone with the URL — treat it like any other URL token. If your embedded scenario shows the URL bar to the user, consider an opaque ID rather than something guessable.

Combining with hidden fields

Other URL parameters still work as form variables alongside nf_visitor. For example:

https://nueform.io/f/your-form-slug?nf_visitor=user-12345&plan=premium&source=upgrade-flow

plan and source are available for variable interpolation in question titles, logic jumps, etc., per the standard hidden-field behavior. Only nf_visitor is reserved.