This guide outlines the structural and behavioral differences between V0 and V1 of the QuicklySign API.

V1 introduces document packs, improved flexibility, enhanced security features, and more granular update behavior.

Key New Features

Document Packs

V1 introduces document packs, allowing multiple documents to be submitted in a single request.

Requests are now grouped under a document_pack, replacing the single-document model used in V0.

You can merge multiple documents or templates into a single document pack, which wasn’t possible in V0.

Event Hooks

Server-side event handlers that run directly on QuicklySign’s infrastructure.

These differ from webhooks and can be tailored to specific business use cases without requiring external endpoints.

User-Defined Attributes

You may attach custom metadata to document packs, such as:

• Internal reference numbers
• External system IDs
• Values required by downstream automation

These attributes are settable at document pack creation and can be viewed by the owner/editor on the UI.

Generated Signing URLs

V1 allows you to generate signing links directly via API.

These links:

• Can be distributed through your own channels
• Enforce OTP verification
• Provide enhanced signing security

Enhanced Upload Options

V1 supports multiple document upload methods:

• Base64 encoded documents
• Remote file URLs
• Temporary upload URLs (legacy supported)

Conditional Signatory Allocation

You may leave a signatory unassigned during creation and allow a signer to nominate the correct participant during the signing process.

Structural Changes

The following structural updates were introduced in V1:

• signing_settings now groups all signing-related configuration
• mail_settings now groups all email-related configuration
• document_pack_name replaces the top-level document_name
• documents now exist within document_packs
• subscriptions have been renamed to webhooks

Note: We renamed subscriptions to webhooks to align with standard terminology. Existing subscription references should be updated. See: Subscription Webhooks

Example: V1 Document Pack (Simplified Structure)

This example shows the typical structure returned after a document pack has been created:

{
  "key": "<document_pack_key>",
  "document_pack_name": "My Example",
  "status": "awaiting_signatures",
  "documents": [
    {
      "key": "<document_key>",
      "document_name": "Child Document",
      "data_fields": [],
      "serve_pdf_url": "<document_download_url>"
    }
  ],
  "signatories": [
    {
      "uuid": "<signatory_uuid>",
      "name": "Signer 1",
      "email": "[email protected]",
      "role": "signer-1",
      "status": "setup"
    }
  ],
  "signing_settings": {
    "sequential_signing": true,
    "use_two_factor_authentication": true
  },
  "mail_settings": {
    "include_attachments_in_final_mail": false,
    "exclude_created_by_from_final_mail": false
  },
  "user_defined_attributes": [
    {
      "id": "reference_number",
      "name": "Reference Number",
      "value": "REF-12345",
      "required": false,
      "visible_on_ui": true
    }
  ]
}

Creating Documents Inside a Document Pack (V1)

In V1, documents are created inside the documents array using document_creation_settings.

Multiple creation methods can be combined per child document if needed (e.g., uploading a base64 document and applying a template).

1: Create From Remote URL

{
  "document_pack_name": "My Example",
  "documents": [
    {
      "document_creation_settings": {
        "document_url": "https://example.com/myfile.pdf",
        "extract_fields_by_tag": true
      }
    }
  ]
}

2: Upload Base64 Document

{
  "document_pack_name": "My Example",
  "documents": [
    {
      "document_creation_settings": {
        "base_64_document": "<base_64_encoded_document>",
        "extract_fields_by_tag": true
      }
    }
  ]
}

3: Create From Template

{
  "document_pack_name": "My Example",
  "documents": [
    {
      "document_creation_settings": {
        "create_from_template_key": "<template_key>"
      }
    }
  ]
}

4: Apply Template to Uploaded Document

{
  "document_pack_name": "My Example",
  "documents": [
    {
      "document_creation_settings": {
        "base_64_document": "<base_64_encoded_document>",
        "apply_template_to_document": "<template_key>"
      }
    }
  ]
}

5: Add Signing Page Template

{
  "document_pack_name": "My Example",
  "documents": [
    {
      "document_creation_settings": {
        "base_64_document": "<base_64_encoded_document>",
        "add_signing_page_template_to_document": "<signing_template_key>"
      }
    }
  ]
}

6: Extract Fields From PDF Form Fields

There are two modes:

1. Positioning only – uses PDF field positions to place data fields.
2. With metadata – also extracts field descriptions defined in the PDF.

{
  "document_pack_name": "My Example",
  "documents": [
    {
      "document_creation_settings": {
        "base_64_document": "<base_64_encoded_pdf>",
        "extract_fields_from_form_fields_with_metadata": true
      }
    }
  ]
}

Usage Changes

Endpoint Changes

All document creation requests must now be sent to the document_packs endpoint.

Update Behavior

V1 introduces partial update support:

• You only need to send the fields you wish to update.
• Full payload replacement is no longer required.

Deletion Rules

Deletion behavior for the following objects has changed:

• data_fields
• signatories
• Child documents

Explicit removal rules now apply when modifying nested objects.

Document Creation Settings

document_creation_settings now exist per child document.

Important:

• These settings are used during document creation only.
• They are not returned in the final payload.
• Multiple creation options can be combined per document.

Summary

V1 introduces:

• A document pack–based structure
• Improved upload flexibility (Base64, URL, templates)
• Ability to merge multiple documents/templates into one pack
• Stronger security controls (OTP for signing URLs, 2FA)
• Enhanced update behavior (partial updates, deletion rules)
• Clear separation of configuration groups (signing_settings, mail_settings, etc.)

If you are migrating from V0, ensure that your request structure and endpoints are updated accordingly before deploying to production.