Integration Models

Quik! gives you several ways to connect your application's e-signature workflow to DocuSign through the Quik! Forms Engine. This page explains each integration model, how it works, and how to decide which one fits your application.

What it is

An integration model defines who calls the DocuSign API and how much of the signing workflow you control versus hand off to Quik!. In every model, Quik! renders your forms, prefills data, and produces the DocuSign tab placement and recipient mapping. What differs is where the envelope-creation call to DocuSign happens and how much infrastructure you have to build and host.

You choose between four models:

• Callback — Quik! starts the envelope; you receive the resulting EnvelopeID at a URL you host.
• Pass-Thru — you host a thin endpoint that receives form data and passes it through to Quik!, which creates the envelope.
• Self-Service — you host an endpoint and build the envelope yourself, calling DocuSign directly while Quik! supplies the rendered PDFs and signing data.
• Direct-to-DocuSign — you call Quik!'s eSignature API directly with a two-call flow; Quik! handles all DocuSign communication, with no endpoint to host.

All models assume you already have a DocuSign account. The Callback and Direct-to-DocuSign models rely on a DocuSign OAuth token set up with Quik!.

Throughout this site the four models are written Callback, Pass-Thru, Self-Service, and Direct-to-DocuSign. Sample projects and code routes keep their original identifiers — for example the QuikESignTransport.PassThru and QuikESignTransport.SelfService projects and the /sign/passthru and /sign/selfservice routes.

How forms get generated (shared foundation)

Before any signing model runs, the same form-generation flow happens. When you run the Execute method in the Quik! Forms Engine:

1. Your application loads data and requests forms in the Quik! Forms Engine.
2. The Quik! Forms Engine calls the Quik! server over secure web services to validate and log the form-view request.
3. The Quik! server responds to the Forms Engine to generate the form.
4. The Forms Engine outputs the form as HTML and your web server serves the page to the end user.
5. The HTML loads in a compliant browser to display the form.
6. Client data, optional prefilled data, custom JavaScript, and Field Rules are loaded into the form.
7. Forms can be submitted back to your server for processing, storage, and/or e-signature.

Note: When printing a form, a PDF is generated by the Quik! server. Form data is sent to Quik! for a very short period to produce the PDF and is never stored.

The signing model you pick determines what happens at step 7.

Callback model

What it is

The Callback model is for applications that want to use Quik! Forms directly with DocuSign without participating in the DocuSign API calls that kick off the signing process. It was specifically designed for applications built on platforms like Salesforce, where it is difficult or impossible to intercept a POST from the form to call the DocuSign APIs yourself.

This model starts the e-signing process for you. You will still call the DocuSign APIs for other functions — for example, checking envelope status or downloading the final signed document. It is optimal for retail or individual users, or enterprise users who need a streamlined way to start the envelope process (such as Salesforce users).

How it works

You set up a DocuSign OAuth token with Quik! so that Quik! can call the DocuSign API on your behalf, then configure the ESignType object in your Forms Engine request:

{
  "HostFormOnQuik": true,
  "QuikFormID": "12",
  "PrintEditablePDF": true,
  "FormFields": [
    { "FieldName": "1own.FName", "FieldValue": "John" },
    { "FieldName": "1own.LName", "FieldValue": "Doe" },
    { "FieldName": "1own.H.Email", "FieldValue": "JohnDoe@test.com" }
  ],
  "ESignType": {
    "Type": "docusign",
    "AuthUserID": "<YourAuthUserID>",
    "SignCallBackURL": "<YourCallbackURL>",
    "SignEnvironmentID": 2
  }
}

Key ESignType properties:

• SignEnvironmentID — the DocuSign environment to use. Obtain valid values by calling GET /docusign/oauthtokens on the Swagger: REST ESignature API.
• SignCallBackURL — a URL you host. The Quik! Form posts the EnvelopeID to this URL so your system knows the transaction is complete. If SignCallBackURL is set, the Forms Engine automatically sets SignURL to https://websvcs.quikforms.com/rest/esignature/docusign/sign, even if you set SignURL yourself.
• AuthUserID — the Connection Name of the desired token. Find this value in the Quik! App under DocuSign Properties; it matches the name you assigned to your DocuSign connection.

The runtime flow:

1. The user clicks Sign, which displays the Quik! Form's e-sign popup and captures the envelope data.
2. The user enters envelope data and clicks SEND. The SEND event posts the form data directly to Quik! (https://websvcs.quikforms.com/rest/esignature/docusign/sign).
3. Quik! looks up your stored OAuth token and calls the DocuSign REST service to start the envelope. (The token must be set up once per CustomerID, CustomerUserID, and DocuSign environment.)
4. DocuSign responds with the EnvelopeID, which Quik! stores with the QFVUNID for later retrieval as a backup.
5. Quik! responds to the form (HTML window) with the EnvelopeID in JSON.
6. The form posts the EnvelopeID to your SignCallBackURL in JSON, along with any status message.
7. You independently download the envelope and documents from DocuSign.

Callback response format

Your callback 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."
}

• A StatusCode of 0 tells the form the event succeeded; any other code is a failure.
• On success (StatusCode = 0), the form displays your Message, or a default success message if none is provided.
• On failure (StatusCode not 0), the form displays your StatusMessage, or a default message if none is provided.

Hosted callback endpoint

If you do not need to do anything with the returned EnvelopeID yourself (for example, you will not check status or download documents through your own integration), you can use Quik!'s hosted callback endpoint instead of hosting your own. It simply returns a message that the DocuSign envelope has been started:

https://websvcs.quikforms.com/rest/ESignature/callbackurl

Optional configuration

• Set SignSubmitCombined to true to make the e-sign SEND button first invoke the Submit event and Submit URL before starting the signature process. Required-field Submit validation is also triggered, but a failed validation will not stop the signature process under the default Submit JavaScript.
• Set SignSendJavascript to override the default JavaScript on the e-sign SEND button with your own.
• Set ESignVendorSuccessJavaScript to run a JavaScript command after a successful transaction.

Pass-Thru model

What it is

The Pass-Thru model lets you host and control the beginning of the process of sending a Quik! form to DocuSign. Data flows from the Quik! form to a web page you host, which passes it through to Quik!; Quik! then creates the envelope at DocuSign. It exposes control only at the start of the transaction — if you need full control over the DocuSign integration, use Self-Service instead.

To make implementation easier, Quik! ships the QuikESignTransport.PassThru sample project (source included). Download it from the Downloads page.

How it works

The sample project is a .NET Web API project with a SignController containing one PassThru HttpPost method that:

1. Reads the posted data as a raw JSON string. This string must not be manipulated or the DocuSign transaction will fail.
2. Generates a token at Quik! in order to consume the REST service and generate the envelope. (The sample reads your Quik! UserName and Password from Web.Config keys QUIK_USERNAME and QUIK_PASSWORD.)
3. Makes a POST request to the REST service to generate the envelope at DocuSign.
4. Returns the DocuSign response. This result must not be manipulated so the Quik! Forms Engine can read it and notify the user.

Expected DocuSign response format:

{
  "ErrorCode": 0,
  "Message": "string",
  "EnvelopeResponse": "string"
}

You can use the sample project as-is or build your own that matches your needs.

Wiring it up

After hosting the project, set the SignURL property on the ESignTypeDocusign object to your endpoint:

string domainPath = "https://your.domain.com";
ESignTypeDocusign docusign = new ESignTypeDocusign {
	SignURL = domainPath + "/sign/passthru",
	SignEnvironmentID = ESignTypeDocusign.SignEnvironment.DocuSignDEMO
};
objQFE.SetESignType(docusign);

/sign/passthru is the controller's method route. If you use the sample project as-is, you must set that value.

Self-Service model

What it is

The Self-Service model gives you full control over your DocuSign integration. Some teams want to submit the PDF and XML data to DocuSign themselves through their own API calls. In that case Quik! still produces the final PDF and XML data to be sent, so Quik! remains part of the process — but you create and send the envelope.

Quik! ships the QuikESignTransport.SelfService sample project (source included) to guide implementation. Download it from the Downloads page.

How it works

The sample is a .NET Web API project with a SignController containing one SelfService HttpPost method that:

1. Reads the posted data as a raw JSON string. This string must not be manipulated or the DocuSign transaction will fail.
2. Generates a token at Quik! to consume the Quik! REST services and get the necessary data. (The sample reads QUIK_USERNAME and QUIK_PASSWORD from Web.Config.)
3. Makes a POST request to a Quik! REST method to get the information needed to generate an envelope at DocuSign, including the PDFs of the generated forms plus sign-related data.
4. Calls the EnvelopeCreator DLL to generate the envelope, passing DocuSign's integrator key and API version. (The sample provides these via Web.Config keys DocusignAPIVersion and DocusignIntegratorKey; you must supply your own values.)
5. Returns the DocuSign response. This result must not be manipulated so the Quik! Forms Engine can read it and notify the user.

Expected DocuSign response format:

{
  "ErrorCode": 0,
  "Message": "string",
  "EnvelopeResponse": "string"
}

Note: As of June 2018, the call to the selfservicedata endpoint returns Null in the Authentication object. You must provide it yourself. The sample project pulls this data (OAuthToken at DocuSign, DocuSign environment, etc.) from Web.Config.

EnvelopeCreator project

The Self-Service sample uses the EnvelopeCreator DLL as a reference for generating envelopes at DocuSign. It uses the REST service output to make a request to DocuSign. You can omit this DLL and build your own. It ships in the same zip as the Self-Service project on the Downloads page.

Note: DocusignIntegratorKey is used to create tokens at DocuSign. EnvelopeCreator exposes a token-creation method that uses it. If you do not create tokens via this project (for example, you already created a token elsewhere), the integrator key is not needed for signing alone.

Wiring it up

As with Pass-Thru, set SignURL to your hosted endpoint:

string domainPath = "https://your.domain.com";
ESignTypeDocusign docusign = new ESignTypeDocusign {
	SignURL = domainPath + "/sign/selfservice",
	SignEnvironmentID = ESignTypeDocusign.SignEnvironment.DocuSignDEMO
};
objQFE.SetESignType(docusign);

/sign/selfservice is the controller's method route. If you use the sample as-is, you must set that value.

Direct-to-DocuSign model

What it is

The Direct-to-DocuSign model lets you generate and send DocuSign envelopes directly through Quik!'s eSignature API. Instead of building or hosting your own envelope-creation service, you provide form IDs, prefill data, and recipient information; Quik! handles document rendering, tab mapping, and all DocuSign API communication.

This model is a good fit if you:

• Don't want to build or host your own envelope-creation service.
• Want Quik! to fully manage tab placement and role mapping.
• Need draft-review capability before sending.
• Need to bundle multiple forms into a single envelope.

Compared to Self-Service, Direct-to-DocuSign removes the infrastructure burden while still supporting role-based signing, draft workflows, and multi-package envelopes.

Authentication

All requests require a Bearer token obtained via the Resource Owner Password Credentials OAuth flow. Include it in the Authorization header of every request:

Authorization: Bearer <access_token>

Contact Quik! support for your token endpoint URL and credentials.

The two-call flow

Sending an envelope requires two sequential API calls:

1. Generate SignData and PrintData — call the QFE engine to render your forms and produce the tab mapping and recipient data needed for signing.
2. Create the envelope — pass the output from Call 1 into the envelope-creation endpoint, which constructs and sends (or drafts) the DocuSign envelope.

Call 1 — Generate SignData and PrintData

POST /rest/quikformsengine/qfe/execute/html

Include GenerateSignData: true and GeneratePrintData: true alongside your form and recipient data:

{
  "HostFormOnQuik": true,
  "QuikFormID": "95507",
  "ForSign": true,
  "GeneratePrintData": true,
  "GenerateSignData": true,
  "FormFields": [
    { "FieldName": "1own.FullName", "FieldValue": "Margaret Holloway" },
    { "FieldName": "1own.H.Email", "FieldValue": "m.holloway@example.com" },
    { "FieldName": "2own.FullName", "FieldValue": "Derek Fontaine" },
    { "FieldName": "2own.H.Email", "FieldValue": "d.fontaine@example.com" }
  ],
  "ESignType": {
    "AuthUserID": "DocuSignEngiIAM",
    "SignMultipleDocs": true,
    "EnforceSignerVisibility": true,
    "SignEnvironmentID": 2,
    "SignCallbackURL": "https://websvcs.quikforms.com/rest/ESignature/callbackurl",
    "Type": "DocuSign",
    "RecipientsLock": true
  }
}

The response returns three fields inside ResultData that you use to build the Call 2 body:

Note: PrintData, SignData, and SignSettings are returned as serialized JSON strings. You must JSON.parse() each one before passing it into Call 2. The source page provides a transformToEnvelopeRequest JavaScript helper that parses these strings and normalizes PascalCase keys to camelCase for the Call 2 body.

Call 2 — Create the envelope

POST https://websvcs.quikforms.com/rest/esignature/docusign/envelope/sign
Authorization: Bearer <access_token>
Content-Type: application/json

Key request fields:

Selected signSettings fields:

signEnvironmentID is traditionally 1 or 2. If you are testing outside these environments, contact Quik! support.

• 1 = https://www.docusign.net
• 2 = https://demo.docusign.net

On success, the API returns the DocuSign Envelope ID:

{
  "EnvelopeId": "b3d2e1a0-xxxx-xxxx-xxxx-xxxxxxxxxxxx",
  "ErrorCode": 0,
  "Message": "Envelope created successfully"
}

Envelope status and draft review

The status field in signSettings controls what happens after the envelope is created:

If you set status to "created", the envelope is saved to DocuSign Drafts and no recipients are notified. You or your team can log into DocuSign, review the envelope, and send it manually. You can also deep-link directly to the draft:

https://apps.docusign.com/send/prepare/{envelopeId}

Multi-package envelopes

To include multiple forms in a single DocuSign envelope, add additional objects to the packagesData array. Each package has its own printData and signData, but all packages are combined into one envelope and sent together:

{
  "packagesData": [
    { "printData": {}, "signData": {} },
    { "printData": {}, "signData": {} }
  ]
}

Authorization and errors

The customerID in the request body must match the authenticated customer account or belong to an authorized child account; requests with unauthorized customerID values are rejected.

Choosing a model

Use this comparison to decide. The core trade-off is control versus the amount of infrastructure you build and host.

Draft-before-send and multi-package envelopes are documented behaviors only of the Direct-to-DocuSign model, where you control them through signSettings.status and the packagesData array. Callback offers limited draft control; for Self-Service, what you can do with drafts and bundling depends on the envelope logic you build against the DocuSign API. For the exact request fields, see the Forms Engine API reference and the Swagger: REST ESignature API.

Quick guidance:

• Use Callback when your platform makes it hard to intercept the form's POST and call DocuSign yourself (the classic Salesforce case), or when you want the simplest path to start an envelope.
• Use Pass-Thru when you want to control the start of the transaction through your own endpoint but don't want to build the full DocuSign integration.
• Use Self-Service when you need complete control and intend to call DocuSign yourself, with Quik! supplying the rendered PDFs and signing data.
• Use Direct-to-DocuSign when you want Quik! to manage all DocuSign communication, you don't want to host anything, and you need draft review or multi-form envelopes.

Related articles

• Introduction
• Authentication
• Forms Engine API reference
• Swagger: REST ESignature API