Account Setup & Environments

This is the first thing to read after the Introduction. It explains how a new customer, partner, or integrator gets a Quik! account, what to do during onboarding, the assumptions Quik! is designed around, and how to use the UAT and Production environments.

What it covers

The account types Quik! supports and which one fits your business model
The step-by-step onboarding checklist from account sign-up to your first API calls
The UAT vs. Production environments and how to point your requests at each
Key assumptions, security expectations, and limits to design around before you build

Account types

Quik! supports a flexible account structure built around a top-level Parent (Master) Account and optional Child Accounts that roll up to it. Which structure you need depends on how you use Quik!.

Enterprise API customers — Most API customers need only one Quik! account, because your users interact with your platform rather than with Quik! directly. Add Child Accounts only if you need to support multiple subsidiaries or legal entities, give each client its own settings/forms/rules, segment independent users, or isolate private forms and CRM data per group.
Enterprise Quik! App customers — Typically use one Parent Account plus multiple Child Accounts (often one per office or team) so each group gets its own forms, branding, rules, and user management while shared settings push down from the parent.
Partners (resellers, distributors, integration partners) — Use one Parent Account and a separate Child Account per client. The Parent Account is your top-level account for rolled-up usage, billing, and pushed-down settings, and can double as your sales-demo or internal-use account. Each Child Account is a fully independent account with its own form library (including private forms), field rules, form groups, branding, and user controls.
Integrators (CRM providers, financial platforms, software embedding Quik!) — Typically need one Partner Account. This is enough if you are not provisioning users/clients inside Quik!, not reselling Quik!, and not handling customer signups. Integrators usually use a Referral Account with SAML to support Single Sign-On (SSO) so users reach Quik! seamlessly through your platform.

Suggested structure for partners:

Purpose	Suggested account type
Central management & billing	1 Parent Account
Sales demos & training	1 Sales Demo Account (optional)
Internal testing	1–3 Development Accounts
Client use	1 Child Account per client

You can create additional accounts through the Quik! team or automatically using the API/web services. For a deeper explanation of how accounts relate, see Understanding Parent & Child Accounts at Quik!

Onboarding steps

Two steps get you started; the rest are configuration steps you do once and revisit infrequently.

Sign up and get credentials. Sign up at https://quikformsapp.com/signup. (Choose the Premium plan for the free 14-day trial; add a credit card to continue beyond 14 days, or talk to the Quik! team if you have an enterprise agreement.) Then email support@quikforms.com to request your API Master Credentials. Quik! sends your master (API) credentials by email once your account is ready. End-user credentials do not work with the APIs — every request must use Master Credentials.
Subscribe to forms. Using forms via the APIs requires first choosing the forms you want on your account. Subscribe to forms through Enterprise Manager (https://qcc.quikforms.com/QFE/MainMenu.aspx), or ask Quik! to do it for you.
Create form groups (optional). If you plan to use form groups, set up at least one for testing. For more than 10 groups, it is often easier to have Quik! bulk-upload a spreadsheet.
Add your logo (optional). Upload your logo file in Enterprise Manager (https://qcc.quikforms.com/QFE/ConfigureSettings.aspx).
Set up e-sign (optional). If you plan to use an e-sign vendor (such as DocuSign or SIGNiX), set up authentication between Quik! and that vendor in Enterprise Manager (https://qcc.quikforms.com/QFE/ESignSetup.aspx). You can also request a default recipient so all e-signed forms route to a specific email account.
Enable e-sign on forms (optional). E-Sign Enablement shows users which forms are signable and automatically disables e-signing when a non-signable form is selected. It is off by default in the API — set the ESignTrackingEnabled property to TRUE in your /execute/html calls and configure signable forms/companies at https://qcc.quikforms.com/QFE/ESignableCompany.aspx.
Configure field rules (optional). Field rules let you require fields, set default values, apply formats/masks, and set background colors — either in Enterprise Manager (https://qcc.quikforms.com/QFE/ManageFieldRules.aspx) or at run time in the API. Field rules are tricky, so request assistance or training; Quik! can bulk-upload large rule sets for you.
Map fields. Field mapping is done once initially and rarely after. Work with the Quik! implementation team. Review the field-mapping articles and the full field list before you start.
Review form-generation properties. The form-generation method (/execute) is the one you will use most. It exposes over 200 properties for generating HTML forms, giving you broad control over output. Review the Quik! Forms Engine property list.
Review the REST APIs. Beyond form generation, Quik! offers REST APIs to search for forms, use form groups, get PDFs, configure e-signing, and run reports. If you need an API you cannot find, ask Quik! to point you to it.

Environments: UAT vs. Production

Quik! provides a Production environment and a User Acceptance Testing (UAT) environment. The Quik! development team deploys upcoming product updates to UAT before a Production release, so UAT exists primarily to test upcoming Quik! features in a non-production environment.

Importantly, most partners and integrators do not need UAT for routine development, implementation, or testing. Instead, test in Production using Draft Mode (set the DraftMode property), which reflects each customer's real settings and is usually the most accurate way to confirm everything works. Note that changes made in UAT do not transfer to Production — you must reapply them manually in the live environment.

To call UAT instead of Production, you change two things: the username and the service URL host. Your Customer ID and password stay the same.

	Production	UAT
Purpose	Live form generation, e-signing, real customer data	Testing upcoming Quik! features before they reach Production
Username	e.g. `johnsmith`	Prefix with `uat`, e.g. `uatjohnsmith`
Customer ID & password	As issued	Unchanged (same as Production)
Service URL	`https://websvcs.quikforms.com/rest/QuikFormsEngine/qfe/execute/html`	`https://uatwebsvcs.quikforms.com/rest/QuikFormsEngine/qfe/execute/html`
URL rule	Standard host	Prefix the host with `uat`, or replace `www` with `uat`

Apply the same username and URL pattern to all Quik! service URLs when testing in UAT.

What to test where:

Recent form changes → test in Production by setting TestFinalFormsMode to true while the form is in Final status. (UAT should not be used to validate finalized form changes.) See How Do I Test a Form?
Field rules → test in Production, using the FieldAttributesManagerOff property to control whether rules are enforced or ignored at run time. (UAT should not be used to validate field-rule behavior.) See Field Rules: Configuring Field Rules Programmatically (At Run Time).

Key assumptions

Quik! is designed around the following assumptions. Read these before you build.

Setup

You implement Quik! within your own application — Quik! does not host or build an application on your behalf.
You must have a valid Master Customer Account and supply Master Credentials with every request.
If the Quik! Forms Engine component is installed locally, it may need read/write access to a temporary file location on your computer or server.
You implement one or more web services with a Quik! server to send and retrieve the data used with Quik! services.
End users view Quik! forms in a current, evergreen web browser with JavaScript enabled.
To use e-signature: e-signing requires SSL (HTTPS); you procure and use your own account with the signing vendor (e.g. DocuSign), set up a vendor-specific API key, and reference Efficient Technology Inc. as the referral source; you own the validity/acceptance of electronic signatures; you may need to deploy QuikESignTransport in the same domain as the HTML forms; and you are responsible for calling the e-sign vendor's APIs to check signing status and download final signed documents (Quik! only kicks off the signing process).

Security

Quik! servers do not store, save, or persist client data sent for generating, printing, signing, or transmitting forms. Data, if sent, is encrypted in transport and discarded once processed.
Your computer/server/program is responsible for deleting any temporary files generated by the software (HTML files, error logs, etc.).
You create a secured SSL connection between your user's browser and your web application to deliver Quik! output and forms.

Limitations

Keep form packages reasonable: do not request more than 20 forms or 100 pages in a single package. Quik! caps requests at 100 FormIDs, but large packages may still fail on resulting file size.
The HTML form viewer expires and is no longer viewable after a maximum of 10 days from generation (or sooner at your discretion).
Forms do not fully function for iPad users in Private Browsing (Save/Load local storage is disabled by Apple).
Editable PDFs cannot be saved unless the user has an Adobe Acrobat version that allows saving; field collisions can occur in combined editable PDFs.

Domains and IPs to allowlist

Ensure connections to Quik! domains are unobstructed. Allowlist or exempt the following from your security policies:

www.quikforms.com, quikforms.com
websvcs.quikforms.com, qcc.quikforms.com
quikformsmanager.com, etiforms.com
uat.quikforms.com, uatwebsvcs.quikforms.com
Production IPs: 54.163.253.215, 184.73.172.182, 34.194.148.75, 34.192.179.113, 34.193.98.155
Disaster recovery IPs: 18.220.1.124 (inbound), 3.134.188.250 (inbound), 3.134.182.3 (outbound), 3.134.56.161 (outbound)
UAT IPs: 34.193.105.241, 34.224.135.79

Introduction

Authentication