Electronic Signatures

Product: InProQu
Effective date: 16 October 2026
Operator: InProQu · [email protected]

This document describes how built-in electronic acceptance and signature features work on InProQu shared documents. It forms part of the Terms of Service.

1. What the product provides

On public share pages (/p/{token}), depending on document settings, recipients may:

View a proposal or document
Accept or decline
Draw or apply a signature where a signature block is present
Complete payment via Customer’s connected payment provider (BYOK)

The product may store signature images/vectors, acceptance timestamps, related certificate/evidence metadata, and consent text with the record.

Optional third-party e-sign integrations (e.g. Dropbox Sign) are governed by those providers when Customer enables them.

At sign/accept time, the Service presents consent substantially as follows:

I agree to sign and accept this document electronically. I intend my electronic signature and acceptance to be legally binding to the same extent as a handwritten signature under applicable electronic signature laws in my jurisdiction (for example, simple / standard electronic signatures under frameworks such as eIDAS in the EU/UK, the U.S. ESIGN Act and UETA, and similar laws elsewhere). This is not a qualified electronic signature (QES) or other trust-service signature unless a separate qualified trust service provider is used.

References to eIDAS, ESIGN, and UETA are examples only. Consent is jurisdiction-neutral and does not create a qualified electronic signature (QES) unless a separate qualified trust service provider is used. Customer remains responsible for local formalities (see section 3).

3. Customer responsibilities

Customer (the workspace owner) is solely responsible for determining that:

Electronic signatures/acceptance are legally valid for the document type and parties’ jurisdictions.
Signers have authority to bind their organization.
Any required consumer disclosures, cooling-off rights, or wet-ink formalities are handled outside or in addition to the product.
Share link access control (password, expiry, disable) is appropriate.
Records retention meets Customer’s regulatory needs (export/archive as needed).
Disputes with signers or payers are between Customer and those parties — InProQu is not a party to Customer’s underlying contract.

4. What InProQu does not warrant

That a signature will be admitted in every court or satisfy every statute
Notary, witness, or qualified trust service functionality (unless a specific integration expressly provides it)
Identity proofing beyond what the recipient’s access method and Customer’s process provide
That IP hashing / user-agent logs alone prove identity

5. Evidence we may store

Depending on configuration: signature data, consent text, timestamps, document version context, hashed IP / user agent for views or actions, and payment status from Customer’s processor webhooks.

6. Contact