Sessions and UNIDs

What it is

A UNID (Unique Identifier) is the read-only ID that identifies a specific generated form package in Quik!. Every time you ask Quik! to generate a form, the response includes a UNID.

A session is the lifecycle of one form package from the moment it is generated until it is signed, submitted, or abandoned. The UNID is the thread that ties every step of that lifecycle together. When a user saves a form mid-completion and comes back to it later, the UNID is what lets Quik! recognize they are resuming work instead of starting fresh.

Why it matters

Most users do not fill out a form in one sitting. They get partway through, realize they need an account number or a beneficiary's address, and need to come back later. Without a way to save and resume, those users either drop the form entirely or have to start over. Either way, you lose them.

Sessions and UNIDs solve that. With a UNID, you can:

Save a form in progress and bring the user back to exactly where they left off, with all their data intact.
Re-render a previously generated package without counting it as a new transaction against your forms usage. (UNIDs are free to re-launch.)
Track a form across saving, signing, submitting, and archiving with one consistent identifier.

How it works

The session lifecycle

Every form package goes through some version of this lifecycle. The UNID stays the same throughout.

Stage	What happens	What you get back
Generated	You call `execute/html` or `execute/pdf` with a list of Form IDs and prefill data.	The form viewer (or PDF) plus a UNID in the response.
In progress	The user fills out fields in the form viewer.	Nothing on your side until they save or submit.
Saved	The user clicks the Save button. Quik! sends the form data and the UNID to your save destination.	Form data and UNID, posted to your URL (or stored in browser local storage).
Resumed	Your application calls `execute/html` again, passing the UNID along with the previously saved field data.	The form re-renders with prior data intact, using the same UNID. No new transaction is counted.
Submitted or signed	The user submits the form or sends it for e-signature.	The completed package, still tied to the same UNID.

Where the UNID comes from

The UNID is generated automatically when you call execute/html or execute/pdf. You will find it in two places:

In the API response under ResultData.UNID.
As a hidden field inside the rendered form viewer (HTML element ID QFVUNID). The hidden field value has a UNID= prefix that needs to be stripped before you can use it.

You do not generate UNIDs yourself. You just hold on to whichever one Quik! gives you.

What gets saved when a user clicks Save

Two save behaviors are available.

Default: save to the browser's local storage. The browser stores the field name and value pairs locally on the user's machine. The user clicks Load in the form viewer to bring the data back. This is simple to enable but the data only lives in that one browser, and it is wiped when the browser cache is cleared.

Configured: save to your server. You provide a SaveURL and Quik! posts the form data there when the user clicks Save. You decide how to store it, how long to keep it, and how to secure it. This is the recommended approach for production. Optionally, you can include e-signature recipient details in the save payload by setting SaveRecipientData to true.

When you save to your own server, you should typically persist three things:

The form data (the full posted payload is easiest, individual field/value pairs if you prefer to parse).
The UNID (so you can re-launch the package later).
A label the user can recognize (account name, owner name, save date, or a custom name they provide).

UNIDs do not expire

The UNID itself never expires. You can re-launch a saved form years later and Quik! will accept the UNID.

Two things that can change between save and re-launch:

Forms can be updated by Quik!. If a Form ID was republished while your saved form was sitting in your database, the re-launched form reflects the latest version. The user's saved data still applies.
Forms can be removed from your library. If a Form ID in a saved package is no longer available to your account, the re-launch will fail for that form.

For developers: where this shows up in the API

This section is for the technical reader implementing the integration.

ResultData.UNID in the response from execute/html and execute/pdf. Save this.
UNID property in the request body of execute/html or execute/pdf. Pass it back to re-launch a saved package. When re-launching:
- Include the UNID.
- Include all the field data again (the UNID does not carry data on its own).
- For execute/pdf specifically, you can pass the UNID alone without QuikFormID. The Form IDs are already associated with the UNID.
HTMLButtonSave.Show: true to display the Save button in the form viewer.
HTMLButtonSave.SaveURL to post saved data to your server. The form viewer will alert whatever response your endpoint returns, so respond with a clear success or failure message.
HTMLButtonSave.SaveRecipientData: true to include eSignData (recipient info) in the save payload. Off by default.
Hidden field in the form DOM: element ID QFVUNID contains the UNID with a UNID= prefix. Strip the prefix to use. Example jQuery: $('#QFVUNID').val().replace('UNID=','').

Pitfalls

A UNID alone does not restore form data. When you re-launch a saved package, you must pass back both the UNID and the saved field data. The UNID identifies the package; it does not store the values inside it.
Checkbox field names need the QuikRadio<FormID> prefix stripped on re-launch. Quik!'s save event includes the prefix in the saved data, but the prefix must be removed before passing the field back in. Otherwise the checkbox will not render as checked. Example: stored as QuikRadio5653.1acc.RegType, re-launched as 1acc.RegType.
Browser local storage is not reliable for production. It is wiped when the user clears their browser cache, scoped to one browser on one machine, and not shareable across devices. Use the customer-hosted save option (SaveURL) for anything that needs to persist.
The UNID= prefix in the hidden field is not part of the UNID itself. If you read the UNID directly from the DOM and forget to strip the prefix, re-launches will fail because the value will not match.
Re-launching a saved package does not count as a new transaction in your forms usage. This is intentional and saves cost, but it also means you cannot tell from the transaction count alone how many times a user opened a form. Track re-launches in your own system if you need that visibility.

Continue with these articles to understand the related concepts and workflows:

Saving Forms — Learn how sessions and UNIDs support saving and returning to a form.
Launch a Form — See where sessions fit into the basic form launch workflow.
HTML vs PDF Execution — Understand how session behavior differs between interactive forms and generated PDFs.
Authentication — Review how authenticated requests connect to session-based workflows.

Form Groups and Instances

HTML vs PDF Execution