SIGNiX

What this does

Sends a generated Quik! form to SIGNiX for digital signature. Quik! transforms the form and its data into a SIGNiX transaction, manages the back-end communication with the SIGNiX APIs, and stores the transaction metadata so you can retrieve it later. You configure a handful of properties on the Forms Engine and Quik! handles the rest.

When to use this

Choose SIGNiX when you want a certificate-backed digital signature and your workflow fits the core e-sign feature set. If you need editable fields at signing time, in-person signing, send on behalf of, or a self-service direct integration, use DocuSign instead. See E-Signature Options for the full comparison.

This is Quik!'s hosted SIGNiX integration. It is the simplest to implement and the least flexible. You cannot run business logic between posting the sign data and the call to SIGNiX. The one place you control is after Quik! calls SIGNiX, using the SignCallBackURL property.

Before you start

You need:

A Quik! account with at least one library subscription. See Library Subscription.
Valid SIGNiX credentials added to your Quik! account.
A Quik! OAuth Bearer token. See Authentication.
The Sign button enabled in the Form Viewer. See Customizing the Form UI.

Setup

1. Add your SIGNiX credentials (required)

Add valid SIGNiX credentials to your Quik! account using either:

the E-Signature Setup page in the Quik! Forms Enterprise Manager, or
the E-Signature REST API. See the E-Signature API.

2. Set the required properties

Property	Value	Notes
`ESignType`	`Signix`	Routes the Sign button to SIGNiX.
`SignEnvironmentID`	`7` (Production) or `8` (Demo)	Required. Selects the SIGNiX environment.
`SignixSubmitterName`	Sender name	Required. If missing, the Sign button will not display.
`SignixSubmitterEmail`	Sender email	Required. If missing, the Sign button will not display.

3. Set the callback (recommended)

Set SignCallBackURL to a URL on your server if you want to receive the SIGNiX response after a successful transaction. The form posts the SIGNiX result to this URL in JSON so your system knows the transaction is complete. The property reference lists this as required, so set it unless you have a specific reason not to.

4. Add any optional configuration

Tune the transaction with the other supported SIGNiX properties. See SIGNiX Advanced Configuration for the full list, including authentication types, signing date format, reminder schedule, and document retention.

The runtime flow

Once setup is complete, this is what happens when a user clicks the Sign button on a launched form:

User / Quik! Form              Quik! API                    SIGNiX
   │                              │                            │
   │  Click Sign ────────────────│                            │
   │  (e-sign pop-up shows)       │                            │
   │  Enter signing data, Send ──▶│  Start transaction ───────▶│
   │                              │◀── success or failure ─────│
   │◀── success message ──────────│                            │
   │  (TransactionID + QFVUNID stored by Quik!)                │
   │  Post result to              │                            │
   │  SignCallBackURL ───▶ your server                         │
   │◀── JSON StatusCode/Message ──│                            │
   │                              │   Signers emailed by SIGNiX

The user clicks Sign. The e-sign pop-up appears.
The user enters signing data and clicks Send. The form posts the data directly to Quik!.
Quik! starts the transaction with SIGNiX using your stored credentials.
SIGNiX returns success or failure. On failure, the form alerts the SIGNiX error message.
On success, Quik! returns a success message to the form and stores the SIGNiX Transaction ID with the QFVUNID for later retrieval.
If you set SignCallBackURL, the form posts the SIGNiX response to your server, which should reply in JSON (see below).
Signers receive emails from SIGNiX inviting them to sign.
After everyone signs, you download the completed documents from your SIGNiX (MyDox) account.

SignCallBackURL response format

Your endpoint must respond to the form in JSON:

{
  "StatusCode": 0,
  "StatusMessage": "200 (ok)",
  "Message": "Your form has been submitted for signature. Each recipient will receive an email to begin the signature process. Check your email for signature updates."
}

StatusCode of 0 means the event succeeded. Any other value is a failure.
On success, the form displays your Message, or a default success message if you omit it.
On failure, the form displays your StatusMessage, or a default error message if you omit it.

Pitfalls

No Sign button means a missing submitter. If SignixSubmitterName or SignixSubmitterEmail is not set, the Sign button does not render. This is the most common SIGNiX setup miss.
Production vs Demo is an ID, not a flag. SignEnvironmentID must be 7 for Production or 8 for Demo. Pointing at the wrong environment is a silent way to send test transactions to production or vice versa.
You cannot inject logic before the SIGNiX call. The hosted integration posts straight to SIGNiX. Your only hook is SignCallBackURL, which runs after the transaction starts.
Retrieving completed documents is on you. Quik! stores the Transaction ID, but downloading signed documents happens in your SIGNiX account.

E-Signature Options. Compare SIGNiX against DocuSign and Native E-Signature.
SIGNiX Advanced Configuration. The full SIGNiX property and ClientPreference reference.
Authentication. Get the token you need before calling the API.
Roles and Role Prefixes. How Quik! assigns signers and signing order.

DocuSign — Advanced Configuration

SIGNiX — Advanced Configuration