# Leegality Knowledge Base — Complete Content > Source: https://knowledge.leegality.com > Generated: 2026-10-29 > Contains every page as plain markdown. For the page index see https://knowledge.leegality.com/llms.txt. --- URL: https://knowledge.leegality.com/document-execution/getting-started/create-an-account # Create an account 1. Go to [dashboard.leegality.com/sign-up](https://dashboard.leegality.com/sign-up) 2. Provide either an **email address** or **phone number** and click **Send OTP**. > **Warning — Important: Please Use a Permanent Contact** > > You **cannot** change the email address or phone number after creating your account. Please ensure you have long-term access to it. > **Why can't I change it?** > > > For security and legal reasons, your email or phone number acts as your unique identifier. It is permanently linked to the audit trail of every document to ensure the signature is always verifiable and legally binding. Changing it would break this critical link. 3. Enter OTP and the **Name** of the user and click **Sign Up**. > **Info — Note** > > This is not a username and cannot be used to log in to the Leegality account. 4. Create a **password** and click **Update**. Your Leegality account has been created and is ready to use. ## FAQs **Can I log in with my phone number if I signed up with my email address (or vice versa)?** > No. You can only log in with the identifier you used to sign up. If you signed up with an email address, log in with that email address. If you signed up with a phone number, log in with that phone number. **Can one user log in on multiple devices at the same time?** > No. A Leegality account can only be actively signed in on **one device at a time**. If you try to log in on a second device while you're already signed in elsewhere, you'll see a prompt with two choices: > - **Keep the existing session** — cancels the new login attempt; your original device stays signed in. > - **Continue here** — automatically logs you out of the other device and signs you in on the current one. > > You can't have both sessions active simultaneously. **Will my session expire if I'm inactive?** > Yes. If your dashboard tab is inactive for **15 minutes**, your session ends automatically and you'll need to sign in again. --- URL: https://knowledge.leegality.com/document-execution/getting-started/dashboard-overview # Get to Know Leegality Dashboard This guide will introduce you to Leegality’s main interface and its key features, helping you navigate through the platform with ease. ## Top Bar At the top of the screen, you’ll find the navigation bar, giving you quick access to core features: ![Leegality Dashboard](https://knowledge.leegality.com/img/get-to-know-leegality-dashboard.png) 1. **Dashboard**: Access and manage templates, workflows, contact book, and activity logs. 2. **Documents**: Manage your documents, from drafts to completed ones. 3. **Stamps**: Access and manage your stamp series and groups. 4. **+ Create Button**: Allows you to create: - [New document](https://knowledge.leegality.com/document-execution/getting-started/sending-journey) - [Stamp series](https://knowledge.leegality.com/document-execution/stamps/stamp-series/create-a-stamp-series) and [Stamp group](https://knowledge.leegality.com/document-execution/stamps/stamp-group/stamp-groups) - [Template](https://knowledge.leegality.com/document-execution/template/) - [User](https://knowledge.leegality.com/document-execution/settings/Admin/user-management#create-a-new-user) - [Contact](https://knowledge.leegality.com/document-execution/contact-book) - [Run Workflow](https://knowledge.leegality.com/document-execution/workflows/run-workflow) - [Purchase eSign credits and stamps](https://knowledge.leegality.com/document-execution/getting-started/buy-eSign-credits) 5. **eSign Credits Indicator**: Shows how many credits you have left. 6. **Support Links**: Access resources like Knowledge Base, API Documentation, and Product Updates. 7. **Settings**: Customize your account preferences. More details on Settings. 8. **Profile**: View your profile, switch users, switch to the legacy UI, or log out. --- ## Exploring the Dashboard The Dashboard is divided into five key sections, accessible from the left-side panel: | Section | Description | |-------------------------------------|---------------------------------------------------------------------------------------------------------------------------| | **Home** | **Transactions Overview**: Displays a graph summarizing key transaction data: Invitations sent, signed documents, and completed documents. You can also download these transactions. **Recent eSigning Activity**: Shows the five most recently sent documents, including invitee details and activity type. | | [**Activity Logs**](https://knowledge.leegality.com/document-execution/activity-log) | Comprehensive logs recording all account activities, including invitations, payments, stamps, workflows, and more. | | [**Templates**](https://knowledge.leegality.com/document-execution/template/template) | Stores all your templates. You can create, edit, and manage templates. | | [**Workflows**](https://knowledge.leegality.com/document-execution/workflows/overview) | Provides access to all saved workflows. You can run, download API payload, and edit workflows. | | [**Contact Book**](https://knowledge.leegality.com/document-execution/contact-book) | Stores invitee contact information. You can add contacts using the Create button or import contacts in bulk using an Excel file. | --- ## Documents Section The Documents section provides a centralised view of all your documents and their current status. Learn more about in [Manage Document](https://knowledge.leegality.com/document-execution/manage-documents/overview). ![Documents Section](https://knowledge.leegality.com/img/getting-started-guide-documents.png) ### Documents - **Sent:** Documents you have sent for signing or review but are not fully executed. - **Received:** Documents you have received for signing or review. These remain in the Received folder until all invitees have completed their actions. - **CC:** Documents where you are marked as a CC invitee. - **Drafts:** Documents that were initiated via a new document or workflow run but were not sent. > **Note:** Invitee and document-level configurations made during the sending journey are not retained. - **Completed:** Documents where all invitees have signed. - **Expired:** Documents where the signing or review invitation has expired. ### Quick Access - **Action Required:** Documents awaiting your action, such as signing, reviewing and/or drafts waiting to be sent for signing. - **Waiting for Others:** Documents you sent that are pending signatures or reviews from others. - **Expiring Soon:** Documents that will expire in a few days and may require action from you or other invitees. - **Failed:** Documents that expired due to reasons like invitation timeout, retry attempt exhaustion, or certificate details mismatch. - **Rejected:** Documents you sent but were rejected by the reviewer. - **NeSL Errors:** Documents with NeSL errors that may need a retry or status refresh. See [Documents with NeSL Errors](https://knowledge.leegality.com/document-execution/nesl/nesl-errors). --- ## Stamps Section ![Stamps Section](https://knowledge.leegality.com/img/getting-started-guide-stamps.png) The Stamps section provides an overview of your stamp series and groups. From here, you can: - View denomination values for stamps - Track stamp status (unused, reserved, used, blocked) - Purchase more stamps - View consumption history - Extend stamp expiry For more information, check out [Stamps](https://knowledge.leegality.com/document-execution/stamps/stamps). --- URL: https://knowledge.leegality.com/document-execution/getting-started/buy-eSign-credits # Buying eSign Credits The article guides you through the step-by-step instructions for setting up a billing profile and purchasing eSign credits and stamps. > **Info — Note** > > Only admin and billing users can purchase eSign credits and stamps. ## Create a Billing Profile 1. Click on the Setting icon ⚙️. 2. In the left navigation panel, go to **Wallet > Billing Profiles**. 3. Click **+ Create Billing Profile** and a pop-up will open to add a billing profile. 4. Fill in the required information. 5. Click **Create**. > **Info — Note** > > Billing Profile information will be displayed in the invoice. ## Purchase eSign Credits or Stamps 1. Click on the Setting icon ⚙️ and go to **Wallet > Purchase**. 2. In Transaction Items, click **+ Add Items** to add desired products like eSign and Stamps. > **Info — Stamps Prerequisite** > > Before purchasing Stamps, create a related Stamp Series. Learn [**how to create a Stamp Series**](https://knowledge.leegality.com/document-execution/stamps/stamp-series/create-a-stamp-series). 3. **Add quantity** for each product as needed. 4. Click **Proceed** on the bottom right. You will see the total base cost here. 5. Review the selected items and quantities in the Confirm Order screen. Click **Edit** to make changes otherwise **Confirm** to proceed. 6. Click **Pay** and choose payment methods like UPI, Credit/Debit Card, Net Banking, and Wallet. 7. Alternatively, you can pay directly into our bank account using NEFT, RTGS, or IMPS. Click **View Bank Details** for more information. Depending on your chosen payment method, processing may take a few hours. Once payment is successful, eSign credits will be added to your account. If you've purchased stamp papers, we'll initiate the stamp procurement process which usually takes 7-10 business days. > **Warning** > > eSign credit expires after 365 days of purchase. You ***cannot*** extend the expiry of eSign credits. --- ## How Leegality eSign Credits Work To understand your eSign credit balance and consumption, it's best to think of the system in two distinct phases: **purchasing** credits and **consuming** credits. The system works like a flexible prepaid wallet: you purchase credits, and then you spend those credits based on the services you use. ### Phase 1: Purchasing Your eSign Credits This phase is straightforward. When you add funds to your Leegality account, they are converted into eSign credits at a simple, fixed rate. **₹1 (INR) \= 1 eSign Credit** For example, if you purchase **₹10,000** worth of credits, you will have **10,000 eSign credits** added to your account wallet. This is the amount you have available to spend on getting documents signed using any eSign type. > **Note:** Minimum eSign credit purchase value should be 100 INR #### **Understanding the Purchase Page: Your Credits are Flexible** When you purchase credits from the Leegality Dashboard, you may be presented with options to add specific eSign types to your cart (for example, "10 Aadhaar eSigns"). The dashboard uses this selection to help you calculate the **total number of credits** you might need. > **Tip — Example** > > Adding "10 Aadhaar eSigns" to your cart at a rate of 25 credits/sign will calculate a total purchase of **250 eSign credits**. However, it's crucial to understand that you are **not** buying "Aadhaar-only" credits. Once the payment is complete, your account is credited with a universal pool of **250 eSign credits**. These credits can be used to pay for **any type of eSign transaction**, whether it's an Aadhaar eSign, a Virtual Sign, or any other type offered. ### Phase 2: Consuming Credits for Signatures This is the most important phase to understand. When you send a document for signing, you consume credits from your wallet. However, the number of credits consumed is **variable** and depends entirely on the **type of eSign** used by the signer. Different eSign types (like Aadhaar eSign, Virtual Sign, Doc Signer, etc.) have different underlying costs. This is reflected in the number of credits they consume. For instance, the cost might be: * **Aadhaar eSign:** 25 eSign credits per signature * **Virtual Sign:** 15 eSign credits per signature ### Putting It All Together: An Example Imagine you need to get a single document signed by three different people (Invitees A, B, and C). You've configured the document so that all three will use the **Aadhaar eSign** method. Here’s how the credits would be consumed: | Invitee | eSign Type | eSign Credit Cost per Signature | | :---- | :---- | :---- | | Invitee A | Aadhaar eSign | 25 credits | | Invitee B | Aadhaar eSign | 25 credits | | Invitee C | Virtual Sign | 15 credits | | **Total Consumption** | | **65 eSign credits** | Therefore, getting this **one document** signed by **three people** will consume a total of **65 eSign credits** from your account. > **Warning — Disclaimer** > > The actual consumption rates for different signature types are based on your agreed-upon commercials with Leegality. Now the eSign credits are in your account, you are all set to [**send your first document for eSign**](https://knowledge.leegality.com/document-execution/getting-started/sending-journey). --- URL: https://knowledge.leegality.com/document-execution/getting-started/sending-journey # Sending a Document for eSignature ## Step 1: Prepare Your Document 1. Click **+ Create** > **New Document**. This will direct you to the *Create* page. 2. Choose how to prepare Your document: #### Option 1: Upload a PDF 1. Click **Upload** to add document(s) from your computer. > **Info — Note** > > - **Supported file type:** PDF > - **Upload Limit:** 10 files > - **Maximum total size:** 30 MB (15 MB recommended for optimal performance). > **Tip — Having trouble uploading?** > > See [Upload Errors](https://knowledge.leegality.com/document-execution/troubleshooting/sending-journey/upload-errors) for common errors and their resolutions. 2. Drag and drop files into the designated area or browse and select files manually. 3. If multiple PDFs are uploaded, use the up ( ↑ ) and down ( ↓ ) arrows to arrange them in the desired order. > **Note:** When multiple PDFs are uploaded and arranged, they will be merged into a single document before sending for signing. 4. Click the delete icon (🗑️) to remove unwanted files. #### Option 2: Use a Template > **Tip — Prerequisite** > > You must have an existing template. Learn how to create a [**templates**](https://knowledge.leegality.com/document-execution/template/). 1. Navigate to the **Templates** tab. 2. Select the desired template. 3. *(Optional)* Enable **Append PDF files to template** if you want to attach extra PDF files alongside the selected template. Follow the same upload steps as above. > **Example:** A company uses a **Vendor Agreement Template** but occasionally needs to include an **NDA**. Instead of modifying the template, they use Append PDF files to template to attach the NDA while sending the document for signing. > **Note:** Additional PDF(s) will attach after the template. 3. **Name the Document:** Leegality automatically assigns a name based on the uploaded file and selected template. You can change it as desired. The document name will appear in the email subject and body. The **Name** and **Internal Reference Number (IRN)** fields have a maximum character limit of 255. The following special characters are allowed: **| - : () , _. [] &/**. > **Tip — Example** > > **Email Subject:** “Invitation to eSign: Service Level Agreement” 4. You can use [folders](https://knowledge.leegality.com/document-execution/manage-documents/folders) to group and manage your document. Select a folder from the dropdown and save your document into it. --- ## Step 2: Add Stamp Papers ### Use Leegality's Bharat Stamp 1. Enable the **Use Stamps** toggle. 2. Choose from the following stamp usage methods: - **Use Stamp Series (Single Stamp):** Select a stamp series from dropdown. A single stamp from that series will be attached. - **Use Stamp Series (Multiple Stamp):** Select a stamp series and specify the number of stamps required. Click **+ Add More** to add stamps from other series. The specified number of stamps will be attached. - **Use Stamp Group:** Select a stamp group and enter the total stamp value required. Stamps worth the specified amount will be automatically attached to the document. - **Use Revenue Stamp:** Select a Revenue stamp series and enter the number of stamps. Revenue stamps can be used alongside state stamp series, stamp groups, and upload stamps. ### Upload your stamp 1. Enable the **Upload Stamp** toggle. 2. Provide the following information: 1. **State** 2. **Denomination** 3. **First Party's Name** 4. **Second Party's Name** 5. **Stamp Serial Number** 3. Upload the stamp paper’s PDF file and click **Save**. --- ## Step 3: Add Invitees 1. By default, the sender is included as a signer. Use the **"I want to sign the document"** toggle to include or remove yourself as a signer. 2. To add another invitee, click **+ Add Invitee**: - Each invitee’s default role is "Signer" with the default eSign type configured in [**Settings ➔ Department ➔ eSignature**](https://knowledge.leegality.com/document-execution/settings/Department/esignature-settings#set-the-default-esign-type). - Enter the invitee’s **Name** and **Contact Details** (Email and/or Phone). - Notifications will be sent via email/SMS/WhatsApp containing a signing link. > **Info — Note** > > While adding an invitee, enable the **Add new invitee to Contact Book** checkbox to save their details to your [Contact Book](https://knowledge.leegality.com/document-execution/contact-book). This allows you to auto-fill their details the next time you add them as an invitee. ### Set Signing Order 1. Toggle **Request invitees to sign in fixed order**: - **Disabled:** All invitees receive the signing link simultaneously. - **Enabled:** Signing links are sent sequentially based on the specified order. > **Tip — Example** > > If there are two signers, the documents would be sent to the second signer only after the first signer has signed the document. 2. Use the up ( ↑ ) and down ( ↓ ) arrows to adjust invitee order. ### Configure Invitee Settings #### eSign Type - [**eSign Type**](https://knowledge.leegality.com/category/esign-types)**:** Choose from Aadhaar, DSC, Doc Signer, Virtual Sign, Visual Sign, or Quick Sign. #### Invitee Type - [**Reviewer:**](https://knowledge.leegality.com/document-execution/leegality-features/invitee-level/types-of-invitee/reviewer) A non-signing invitee who needs to review the document’s content and then approve or reject it. - [**Group Invitee:**](https://knowledge.leegality.com/document-execution/leegality-features/invitee-level/types-of-invitee/group-invitee) A Group Invitee allows multiple signers, but only a specified number need to sign. - **For example**, if a group has three authorized signers and any two signatures are required, the document progresses once two members sign. - [**CC Invitee:**](https://knowledge.leegality.com/document-execution/leegality-features/invitee-level/types-of-invitee/cc) A CC Invitee does not sign the document but receives notifications about the document's progress. - **Invitation & Reminders:** When an invitation is sent, resent, or nearing expiry. - **Signing Progress:** When an invitee signs, a reviewer approves/rejects, or the document is completed. - **Failures & Expiry:** If signing fails due to expiry, face match, liveliness, or location issues. - **Final Documents:** Completed document and audit trail upon signing completion. #### Security Features - **Authentication:** Invitees must authenticate their identity before accessing the document to ensure only the intended recipient can proceed. - [**One-factor Authentication**](https://knowledge.leegality.com/document-execution/leegality-features/invitee-level/security/one-factor-authentication)**:** OTP verification via email or phone number. - [**Two-factor Authentication**](https://knowledge.leegality.com/document-execution/leegality-features/invitee-level/security/two-factor-authentication)**:** OTP verification via both email and phone number. - **GPS Location:** - [**Capture GPS Location:**](https://knowledge.leegality.com/document-execution/leegality-features/invitee-level/security/capture-gps-location?type=new-document-journey) Record the invitee's location at the time of signing the document. - [**Accuracy-based restriction:**](https://knowledge.leegality.com/document-execution/leegality-features/invitee-level/security/capture-gps-location?type=new-document-journey) Don’t allow the invitee to sign if the captured location is not accurate up to a certain number of meters. - [**Location-based restriction:**](https://knowledge.leegality.com/document-execution/leegality-features/invitee-level/security/capture-gps-location?type=new-document-journey) Restrict signing if the signer is outside of the configured area. - **Identity Verification** - [**Face Capture:**](https://knowledge.leegality.com/document-execution/leegality-features/invitee-level/security/capture-photo) Capture the photo of the signer before allowing them to sign the document. - [**Face Match:**](https://knowledge.leegality.com/document-execution/leegality-features/invitee-level/security/face-match) Capture the photo of the signer and match it against the reference image uploaded by the sender. - **User Liveliness![External Link](https://knowledge.leegality.com/img/external-link-svgrepo-com.svg):** Ensure real-time presence of the signer. - [**Manual User Liveliness (OTP-based):**](https://knowledge.leegality.com/document-execution/leegality-features/invitee-level/security/manual-liveliness) The signer needs to capture a photo of themselves while showing the OTP appearing on the screen. - [**Smart User Liveliness (AI-powered):**](https://knowledge.leegality.com/document-execution/leegality-features/invitee-level/security/smart-user-liveliness) AI-based solution that ensure the person sitting in front of camera is actively present there. It detects spoofs like photo and pre-recorded videos. #### Signature Appearance - [**Invitee Name on Signature:**](https://knowledge.leegality.com/document-execution/leegality-features/invitee-level/esignature-appearance/invitee-name-in-signature) Choose whether to display the invitee’s name in the signature. - [**Company Seal:**](https://knowledge.leegality.com/document-execution/leegality-features/invitee-level/esignature-appearance/company-seal) Ask invitee to upload the image company (organization) seal. If the signer has a Leegality account, the company seal will auto-fill based on the preferences. - [**Invitee Name Editing:**](https://knowledge.leegality.com/document-execution/leegality-features/invitee-level/esignature-appearance/invitee-name-editing) Allow or restrict name editing during signing. #### Other Features - [**Custom Webhook and URL:**](https://knowledge.leegality.com/document-execution/leegality-features/invitee-level/custom-url-and-webhook/webhook-and-url) Enable integrations for real-time updates. - [**Supporting Documents:**](https://knowledge.leegality.com/document-execution/leegality-features/invitee-level/other-features/supporting-documents) The Supporting document helps you request additional documentation, which invitee needs to upload during signing journey. - [**Additional Consent Terms:**](https://knowledge.leegality.com/document-execution/leegality-features/invitee-level/other-features/additional-consent) Add custom terms and conditions alongside default consent. - [**Mask Contact Details:**](https://knowledge.leegality.com/document-execution/leegality-features/invitee-level/other-features/mask-contact-details) Hide other invitees' contact details for privacy. - [**Reject to Sign:**](https://knowledge.leegality.com/document-execution/leegality-features/invitee-level/other-features/reject-to-sign) Provide an option to reject to sign the document. --- ## Step 4: Configure Document Settings - [**Signing Link Expiry**](https://knowledge.leegality.com/document-execution/leegality-features/document-level/document-expiry)**:** Set a deadline for invitees to sign or review the document. The signing or reviewing link can expire: - After a specific number of days - Within 45 minutes - By the end of the day Once expired, the invitee cannot access the document. Sender needs to re-activate the document. > **Info — NOTE** > > You can update the expiry date for documents that have already been sent. However, invitees will not receive a notification about the updated expiry date. - [**Reference Attachments**](https://knowledge.leegality.com/document-execution/leegality-features/document-level/reference-attachments)**:** Add attachments for invitees to refer to during signing. - [**Transfer Completed Document**](https://knowledge.leegality.com/document-execution/leegality-features/document-level/sftp)**:** Automatically transfer signed documents via SFTP. - [**Custom Message**](https://knowledge.leegality.com/document-execution/leegality-features/document-level/custom-message)**:** Add a personalized note to the email body. - [**Branding Profile**](https://knowledge.leegality.com/document-execution/settings/Department/branding)**:** Choose which branding profile to apply to this document's signing journey. The dropdown lists all branding profiles configured in **Department > Branding**. If no profile is selected, the default profile is applied. --- ## Step 5: Notification Delivery Method Select methods for sending signing or reviewing invitation, reminders and other updates. Available delivery methods are: - Email - SMS - WhatsApp 1. Click **Invitee Level Options**. 2. Enable or disable **Email, SMS, and/or WhatsApp Notifications**. > **Info — Note** > > For CC invitees, only email notifications are available. --- ## Step 6: Placing Signature Coordinates A signature coordinate is where you want the invitee’s signature to be on the document. By default, signature coordinates are placed at the bottom-left corner of every page in the document. To place signature coordinates in your desired place: 1. Hover over **☰** icon and select **custom coordinate**. 2. Click on the document where you want to place the signature. 3. Use the dropdown to assign the signer. The signature placeholder size can be increased or decreased as per requirement by simply dragging from its edges. > **Info** > > For a multi-page document, you must click **custom coordinate** before placing coordinates in each page. > > 1. Navigate to each page that requires a signature. > 2. Hover over the **☰** icon and select **custom coordinate** again. > 3. Drop the signature coordinate on that page. > 4. Repeat for every page that needs a signature. > 5. Preview the document and visually confirm the coordinate marker is visible on every required page before sending. --- ## Step 7: Preview and Send Once you have added the document, invitees, and signature coordinates, you can preview the final version before sending it. - Click the **View Invitees** button to review all invitees associated with the document. Each invitee will have a label indicating their role (**Signer, CC, or Reviewer**). You can also verify their contact details (Email address and/or phone number). - Click **Send**, and invitations will be sent to all invitees for signing or reviewing the document. After sending, you will be redirected to the [**Document Details**](https://knowledge.leegality.com/document-execution/manage-documents/document-details/view-document-details#detailed-view-for-specific-document) page, where you can monitor the status of invitees and track the progress of the document. --- URL: https://knowledge.leegality.com/document-execution/getting-started/signing-journey # Signing a Document This guide will walk you through every step—from receiving your document notification to completing your secure signature. > **Info — Note** > > The invitee may not need to perform all the steps mentioned in this guide. The required actions depend on how the sender has configured the document. ## Step 1: Access the Document You will receive a notification via email, SMS, WhatsApp, or a direct link shared by the sender. 1. Click the **Review/Sign** button for email or the **signing link** if you received an *SMS* or *WhatsApp* message. #### Choose a language - [**Local Language**](https://knowledge.leegality.com/document-execution/leegality-features/invitee-level/local-language#signing-journey)**:** At the start of your signing journey, select the language in which you would like to proceed. #### Authenticate Your Identity For added security, the sender may require identity verification before you access the document. This option is set by the person or business that is sending the documents. Identity authentication methods include: - [**One-Factor Authentication**](https://knowledge.leegality.com/document-execution/leegality-features/invitee-level/security/one-factor-authentication#signing-journey)**:** Either email or SMS OTP authentication - [**Two-Factor Authentication**](https://knowledge.leegality.com/document-execution/leegality-features/invitee-level/security/two-factor-authentication)**:** The first step is accessing the signing link via email or SMS. The second step requires entering an OTP sent to the alternate method (SMS if you used email, or vice versa). > **Info — OTP Expiry** > > All OTPs during signing journey expire after **10 minutes**. If the OTP expires, you will need to start the signing process again. --- ## Step 2: Preview the Document Once authenticated, you will be redirected to the document preview page. 1. Scroll through the document to review its content thoroughly. 2. Once satisfied, click **Proceed**. #### Additional Options - **Invitee List:** All invitees to whom the document has been sent. - [**Local Language Selector**](https://knowledge.leegality.com/document-execution/leegality-features/invitee-level/local-language#signing-journey)**:** Change the language of the signing journey as desired. - [**Custom Message**](https://knowledge.leegality.com/document-execution/leegality-features/document-level/custom-message#signing-journey)**:** Click on the message icon to view any additional message from the sender. - [**Reference Attachment (📎)**](https://knowledge.leegality.com/document-execution/leegality-features/document-level/reference-attachments#accessing-reference-attachments-during-the-signing-journey)**:** Click on the attachment icon to view and download any reference documents uploaded by the sender. > **Info — Fill document Fields (If Applicable)** > > If you’re the first to sign/review and the sender has enabled the **Allow first invitee to fill** option, you must fill out the details before proceeding. > 1. Fill out the fields. > 2. Use the **Preview** option to verify your entries. > 3. Once all required fields are filled, click **Proceed**. --- ## Other Invitee Actions - [**Uploading Supporting Documents**](https://knowledge.leegality.com/document-execution/leegality-features/invitee-level/other-features/supporting-documents#signing-journey) If the sender requests additional documentation, the name of the required file will appear on your screen. - Click the upload button and select the document from your device. Supported formats: .pdf, .png, .jpg (Maximum file size: 2 MB) - [**Company Stamp/Seal**](https://knowledge.leegality.com/document-execution/leegality-features/invitee-level/esignature-appearance/company-seal#example-of-company-seal-with-signature) - Authorised Signatory Seal - Director Seal - Upload Company Seal - [**GPS Location**](https://knowledge.leegality.com/document-execution/leegality-features/invitee-level/security/capture-gps-location#signing-journey-of-capture-gps-location) > **Info — Recommended** > > For GPS-based signing, it is recommended to use a smartphone because of their better location accuracy. Options include: - Capture your current GPS location. - Capture your current GPS location (With Accuracy Threshold). - **Geofencing:** Allows signing only if you are within a predefined area configured by the sender. - **Face Capture** - [**Capture your photo**](https://knowledge.leegality.com/document-execution/leegality-features/invitee-level/security/capture-photo#signing-journey)**:** Take a real-time photo using your device. - [**Face Match**](https://knowledge.leegality.com/document-execution/leegality-features/invitee-level/security/face-match#signing-journey)**:** Your photo will be compared with the identity information provided by the sender. If not matched, you cannot proceed to sign. - **User(Invitee) Liveliness Detection**: Confirms that the person signing is physically present. Failure to detect liveliness prevents signing. - [**Manual Liveliness**](https://knowledge.leegality.com/document-execution/leegality-features/invitee-level/security/manual-liveliness)**:** OTP-based verification - [**Smart User Liveliness**](https://knowledge.leegality.com/document-execution/leegality-features/invitee-level/security/smart-user-liveliness)**:** AI-based verification - [**Name Editing**](https://knowledge.leegality.com/document-execution/leegality-features/invitee-level/esignature-appearance/invitee-name-editing)**:** If allowed by the sender, you can edit the name that will appear on the signature. - [**Reject to Sign**](https://knowledge.leegality.com/document-execution/leegality-features/invitee-level/other-features/reject-to-sign#invitee-rejection-journey)**:** If permitted, you can choose to reject the document at any time during the signing journey. - [**Payment Collection**](https://knowledge.leegality.com/document-execution/leegality-features/invitee-level/payment-collect#signing-journey)**:** In some cases, the sender may require you to make a payment before completing the signing process. This could be for fees related to the document, such as service charges, registration fees, or other costs. You will be prompted to make the payment securely within the signing journey, and once the payment is completed, you can proceed to sign the document. --- ## Step 3: Sign or Review the document Based on your role, proceed as follows: #### Signer 1. **Select an eSign Type:** - Availabe options can be - [**Aadhaar**](https://knowledge.leegality.com/document-execution/esign-type/aadhaar/?type=otp#signing-a-document-using-aadhaar-esign) - [**DSC Token**](https://knowledge.leegality.com/document-execution/esign-type/dsc-token) - [**Virtual Sign**](https://knowledge.leegality.com/category/virtual-sign) - [**Visual Sign**](https://knowledge.leegality.com/document-execution/esign-type/visual-sign) - [**Quick Sign**](https://knowledge.leegality.com/document-execution/esign-type/quick-sign) 2. Agree to the default and any additional consent terms. 3. Click **Sign Document**. On successful signing, you will receive a confirmation via email or SMS. Once all invitees have signed the document, you will receive the fully signed document and an audit trail via email. You will also be redirected to the **Public Details Page** page, where you can monitor the progress and view invitee actions. #### Reviewer 1. Review the Document. After reviewing, click **Proceed**. 2. Complete OTP verification if required. 3. Choose to either **Approve** or **Reject** the document. 4. Click **Submit**, check the consent box, and confirm your action. > **Info** > > Refer to [**Reviewer Journey**](https://knowledge.leegality.com/document-execution/leegality-features/invitee-level/types-of-invitee/reviewer#reviewer-journey) for more details. ## Step 4: Track Document Status on the Public Details Page The Public Document Details Page is generated for every signer. It serves as a central hub where signers can view document information, track signing progress, and manage their signed copy. ### Information and Actions Available on the Public Details Page On this page, you can perform several key actions and view important information related to the document and its signers. * **View and Manage the Document** * See a preview of the signed document. * **Download** **the signed document** to your device. * **Download the Audit Trail** of the completely signed document. * **Save the document** directly to the Leegality account for permanent storage. * **Delete** **the document copy** permanently deletes the signer's copy, and that particular signer will no longer be able to access the Public Details Page link received via email, SMS, or WhatsApp. * **Track Signer Progress** * View a list of all invitees, including their names and contact details. * Check the current signing status of each invitee (e.g., "Signed," "Pending"). * See the exact date and time the invitation was sent and when each person completed their signature. * **Review Document Details** * Find the unique Document ID and the Document Name. * Check the overall status of the document (e.g., "Completed," "Signed"). ### Accessing Public Details Page #### **First 48 Hours** For the first **48 hours** after you complete your signature, the link to the Public Details Page provides open access. This means you can click the link and immediately view the page without needing to log in to a Leegality account. **Important:** **The 48-Hour Window is Invitation-Specific.** The 48-hour open access period begins for each signer *individually* at the moment they apply their signature. It is not based on when the document was first sent or when the first person signed. For example, in a sequential signing process: * **Signer 1** signs on **Monday at 2:00 PM**. Their public link will be open until Wednesday at 2:00 PM. * **Signer 2** signs on **Tuesday at 10:00 AM**. Their public link will be open until Thursday at 10:00 AM. #### **After 48 Hours** Once the 48-hour open access window for your specific invitation has expired, the link automatically becomes a **secure link**. To protect the document's information for the long term, you will be required to authenticate yourself to view the page. When you click the public link received via email, SMS, and/or WhatsApp: 1. You will be directed to a secure login page. 2. The default login option will be **Login with OTP**. 3. You must enter the **email address or phone number** associated with your signing invitation to receive the OTP. 4. Once you successfully log in, you will be redirected to the Public Document Details Page with full access. --- URL: https://knowledge.leegality.com/document-execution/manage-documents/overview # Overview The **Documents** page serves as the central repository for all your documents and related activities. This includes invitations you have sent, received, or those requiring further action. The page is designed to simplify managing your documents by categorizing them into different sections, such as **Sent**, **Received**, **Completed**, and those that require action. ### Managing Documents From the **Documents** section, you can: - View details of sent, received, completed, or in-progress documents. - Use [filters](https://knowledge.leegality.com/document-execution/manage-documents/find-documents) to quickly locate documents based on their status, workflow, or creation mode (e.g., Workflow or Non-Workflow). - Create custom [folders](https://knowledge.leegality.com/document-execution/manage-documents/folders) to efficiently organise your documents. - Perform actions such as [signing](https://knowledge.leegality.com/document-execution/manage-documents/sign-documents-in-your-account), [deleting](https://knowledge.leegality.com/document-execution/manage-documents/delete-a-document), [editing](https://knowledge.leegality.com/document-execution/manage-documents/how-to-edit-a-document), or [resending](https://knowledge.leegality.com/document-execution/manage-documents/resend-a-document) invitations. - Download signed documents along with their associated audit trails. --- URL: https://knowledge.leegality.com/document-execution/manage-documents/document-details/view-document-details # Overview There are two ways to view document information: - **List View:** Provides general information about all documents. - **Detailed View:** Offers comprehensive information about a specific document. ## List View for Basic Information This provides the basic information of your documents. The List view contains the following details. - **Document Name:** Name of the document. - **All Invitees:** List of all invitees in a document. - **Created On:** The date on which the document was created. - **Document ID:** The unique ID of the document. - **Status:** Specifies the status of the document, such as Pending Signature, Under Progress, Failed, Rejected, Completed, and Expired. Click **⦀** icon on the right to see more information, including: - **Expires In:** The number of days or months until the document expires. - **Last Updated:** The date on which the document was last updated. - **IRN:** Internal Reference Number assigned to the document by the sender during the sending journey. - **Folder:** The folder in which the document is saved. ## Detailed View for Specific Document You can access the detailed view by clicking on the document name. This view provides specific information such as: - **Invitee List:** See all invitees for the document. - **Signing Status:** Track the signing progress of each invitee. - **Document:** View the document in its current state. - **Activity Logs:** Track key events in the order they happened, including when the sender sent the invitation, when the invitee opened it, OTP generation and verification, and the document signing time. It also includes the sender's and recipient's contact details. ### Actions You Can Perform: - **[Edit invitation](https://knowledge.leegality.com/document-execution/manage-documents/how-to-edit-a-document):** Modify the details of the invite or resend it. - **Mark as complete:** Finalise the document’s signing process. - **[Delete document](https://knowledge.leegality.com/document-execution/manage-documents/delete-a-document):** Deleting a document revokes all outstanding signing and reviewer invitations. - **Upload reference attachment:** Add additional documents as references. - **Re-activate invitation:** Resend the invitation if expired. - **Check notification logs:** Check detailed record of all notifications sent to invitees. - **Resend notification to specific invitee:** Resend the invitation to sign or review. - **Verification Result:** Check the signature certificate verification results. - **Share completed document and audit trail:** Send the completely signed document and audit trail via email. ### Invitee Status The status of each invitee reflects their actions and pending tasks, with some statuses being role-specific: - **Signed:** The invitee has signed the document. Click *Details* to see the signing date and eSign type used for signing. - **Payment:** The invitee has made the payment. Click *Details* to see the payment status, date, amount, and ID. - **Rejected:** Reviewer/Signer has rejected the document. Click *Message* to see the reason for rejection (if provided). - **Approved:** The Reviewer has approved the document. - **Active:** The document is ready to be signed by the invitee but has not been signed yet. - **Unsigned:** The invitee needs to sign the document. - **Inactive:** The document is inactive for the invitee and cannot be signed by them. The sender cannot manually make an invitation inactive. To remove an invitee, the sender can [delete their invitation](https://knowledge.leegality.com/document-execution/manage-documents/delete-an-invitation) instead. ### Invitee Details This tab is visible at any stage of document execution. Click the **Details** tab under the document to view the following: - **Name:** The invitee's name. - **Email:** The invitee's email address. - **Invitation Date:** The date and time the invitation was sent. - **Status:** Current state of the document (e.g., Active, Expired). If the document is not yet signed, the document's **Expiry Date** is visible. If the document is already signed, two additional details are displayed: - **Type of eSign:** The specific signing method used by the invitee. - **Sign Date:** The date and time the document was signed. --- URL: https://knowledge.leegality.com/document-execution/manage-documents/document-details/notification-logs # Notification Logs The Notification Logs feature offers a detailed record of all notifications sent to invitees. It helps you confirm whether a notification was successfully delivered to invitees or encountered any delivery issues. By checking the Notification Logs, you gain real-time visibility into notification delivery, including: * Tracking each notification sent to the invitee * Viewing the status (e.g., sent, delivered, read, or failed) * Checking the time and date of each notification * Monitoring notifications across all delivery channels (Email, SMS, or WhatsApp) ## How to Access Notification Logs To view the Notification Logs for a specific document: 1. Click on **Documents** at the top of the page. 2. Locate the document whose notification logs you want to check. You can search using the **Document ID**, **Document Name**, or **IRN**. 3. Click on the document name to open the detailed view. 4. In the invitee list, find the specific invitee's card. 5. Click on the **Three Dots (⋮)** on the top-right corner of the invitee card and select **Notification Logs**. A pop-up window will appear displaying the notification logs for the chosen invitee. > **Info — Note** > > Only notifications from the last 10 days are available in the logs. ## Details in Notification Logs ![Notifications Logs](https://knowledge.leegality.com/img/notification-logs-details.png) ### Channel The medium through which the notification was sent (SMS, Email, or WhatsApp). In the top-right corner, you will find the contact details of the invitee. * **Email only visible:** Notifications are sent to the email address. * **Phone number with message icon:** Notifications are sent via SMS. * **Phone number with WhatsApp icon:** WhatsApp is the primary mode of communication, but SMS is still sent in cases like virtual sign OTP verification. * **Both email and phone number (with SMS or WhatsApp icon):** Notifications are sent to both the email address and phone number (via WhatsApp or SMS). ### Notification Type The type of notification sent to the invitee. Below is a list of all available notification types. * Document Invite * Document Complete * Invitation Expired * Invitation Reminder * Invitation Signed * Verification OTP * NeSL Document Invite * Reviewer Document Invite * Reviewer Document Complete * Reviewer Invitation Expired * Reviewer Invitation Reminder * Review Complete * Document Reinvite * Reviewer Document Reinvite * Invitation Reject * Invitation Reject Signer * Partial Sign Complete * Invitation Expiration Sender * Invitation Expire Sender * Review Complete Partial * Audit Trail PDF * Completed Doc PDF * Group Invitee Completion * Group Invitee Self Sign * Group Invitee Sign Transaction ### Notification Status and Remark Explained | Status | Channel | Status Remark | Explanation | Suggested Action | | :---- | :---- | :---- | :---- | :---- | | **Sent** | Email, SMS, WhatsApp | Sent\! Awaiting delivery. | The notification has been successfully sent from Leegality and is pending delivery to the invitee. | Wait for delivery confirmation. | | **Delivered** | Email, SMS, WhatsApp | Delivered to the recipient | The invitee should now see the message. | No action required. | | **Read** | WhatsApp | Read by the recipient | Indicates that the invitee has engaged with the content. | No action required. | | **Error** | WhatsApp | Message Failed\! Please ensure the recipient’s phone number is correct and linked with WhatsApp | The message could not be sent because either phone number was incorrect or not linked with WhatsApp. | Check the number and resend the message. | | | Email | Delay in delivery due to network issues | There is a temporary issue affecting the delivery of the notification. This could be caused by problems with the recipient's email server or internet connectivity. | Monitor the status and check if the notification is delivered. If not, try resending the notification later. | | | | Failed\! The recipient's email inbox is full or the email account is inactive | The recipient cannot receive more emails until they clear space. | Ask the invitee to clear their inbox. | | | | Delivery failed\! The recipient's email is on the suppression list. Please contact the admin to remove it. | The email cannot be delivered | Contact [support@leegality.com](mailto:support@leegality.com) to resolve the issue. | | | | Failed\! Please ensure the recipient’s email ID is correct and active | Verify that the address you entered is valid. | Verify the email address. | ### Timestamp The date and time when the notification was sent. ### View Notification Specific Logs Displays all logs (sent, delivered, read) for a particular event notification. This makes it simple to track the status of any notification without having to search through the main table. > **Info — Example** > > Suppose you want to check the status of a Document Invite sent via WhatsApp to the above invitee, including when it was sent, delivered, and read. > > To do this, locate the Document Invite sent via WhatsApp in the logs and click the **View** button. This will display all stages of that specific notification, allowing you to easily track its progress. ## Filtering and Sorting * **Date Range Filter:** View logs for a time duration. There are predefined date filters such as last 5 days, today, yesterday, or a custom range. * **Change the Log Sort Order:** You can sort the logs by timestamp. By default, recent logs will appear at the top. * **Channel Filters:** You can view notifications specific to a channel (Email, SMS, WhatsApp), allowing you to isolate potential issues with specific delivery methods. * **Notification Type Filter:** Users can search for specific types of notifications, such as Document Invite or Document Complete, which helps in narrowing down what you need to check. --- URL: https://knowledge.leegality.com/document-execution/manage-documents/document-details/audit-trail # Understanding the Audit Trail An audit trail is a step-by-step summary of each activity performed by the sender and invitees in the document, from start to completion. This provides a complete, time-stamped history of every action: who did what, when, where, and how. An audit trail contains the following information. | Category | Details Included | | ---------------------------------- | ------------------------------------------------------------------------------------------------------------------------------- | | **Document details** | Name, ID, status, and hash | | **Stamp details** | State, amount, and stamp serial number(s) | | **Notifications** | Logs of notifications sent (Email and SMS) | | **Invitee authentication** | Details of Geo-fencing, face capture, and smart user liveliness | | **Actions of sender and invitees** | Chronological actions with timestamps — e.g., Opened, OTP steps, Consent, eSign method, Completion, Approval/Rejection, Payment | | **Digital signature certificate** | Information for Aadhaar-based eSign | ## How to Download Audit Trail from Dashboard 1. In the Documents section, click **Completed** documents in the left navigation panel. 2. Locate the document by searching, filtering, or simply skimming through the list. 3. Click on the document to show the details view. 4. Click the **Audit Trail** button to download the audit trail PDF file. > **Info — Note** > > * The audit trail can only be downloaded for completed documents, i.e. all invitees signed the documents. > * Each invitee receives a PDF of the audit trail and the fully signed document via email and WhatsApp. They also get a link to the document Details page, from which they can download both the audit trail and the completed document. > * Even after a document is purged, the audit trail remains accessible from the Activity Logs in the dashboard. > **Tip** > > If you want to generate the audit trail of a partially signed document, you need to manually mark it as complete. With this, only those invitee who signed the document will be recorded in the audit trail. ## Breakdown of the Audit Trail PDF ### Document Details * **Document Name:** Name of the document * **Document ID:** Unique ID of the document * **Stamp Document ID(s):** ID(s) of the attached stamps * **Document Hash** * **Status:** Final status of the document i.e. Completed ### Stamp Details * **State** * **Total Stamp Amount** * **Serial Number(s)** ### Details of Involved Parties A detailed list of sender and invitee actions in order of occurrence. Each entry shows the name, email, phone number, and role (e.g., sender, signer, reviewer) of the invitee. #### Invitee Actions * **Opened:** The invitee clicked the **Sign** button or link to view the document. Consent is not accepted at this stage. * **OTP Generated:** The invitee has generated the OTP. * **OTP Verified:** The invitee has verified the OTP. * **Consent Provided:** Accepting the electronic signature disclosure for the particular electronic document. * **eSigned:** Invitee has eSigned the document. This also shows the eSign type used for the signature. (Example: eSigned using Aadhaar). * Authentication Type * Signature Transaction ID * **Completed:** All invitees have finished signing the document. * **Document Rejected:** The Reviewer has rejected the document. * **Document Approved:** The Reviewer has approved the document. * **Payment Captured:** A payment has been successfully captured from the invitee. #### Sender's Actions * **Invitation Sent:** The document has been sent to an invitee. * **Invitation Resent:** New invitation notification has been sent to the specified invitee. * **Invitation Expired:** The invitation to eSign has expired, and a notification has been sent to inform the invitee. * **Re-invited:** The sender reactivated the invitation, and the invitee has been notified again to eSign the document. ### Invitee Authentication Details * **Smart User Liveliness:** X% * **Face Captured:** 3 Photos of the invitee * **Location Captured** * **Coordinates:** latitude and longitude * **The invitee’s location was accurate up to:** xxxx meters * **Region:** Address of the captured location as per Google Maps ### Digital Signature Certificate details **Signature Certificate Details (If eSigned using Aadhaar)**: Following details are as per Aadhaar at the time of signing the document. * **Name:** Name of the signer * **PIN Code:** PIN Code of the signer * **State:** State of the signer * **Year of Birth:** Year of birth of the signer * **Gender:** Gender of the signer * **Title:** Last 4 Digits of Aadhaar Number * **Serial Number:** Positive number of maximum Length 20 bytes and unique to each certificate issued by a CA. * **Issuer Name:** Certifying Authority that issued the digital certificate * **Issuer Organization** * **Validity Start and End** ### Device Information * **IP Address** * **Device name and model** * **OS (Operating System)** * **Browser** ## How to check the validity of Audit Trails? Every Audit Trail PDF is digitally signed by Leegality. This ensures that it hasn't been tampered with. You can check the digital signature validity in any standard PDF reader (like Adobe Acrobat Reader). If the document has been altered in any way after generation, the signature will show as invalid. --- URL: https://knowledge.leegality.com/document-execution/manage-documents/document-details/signature-certificate-details # Signature Certificate Details The **Document Details** page provides a comprehensive overview of the document's verification, signature certificate data, and invitee information. You can access **Invitee Details** at any stage of the document execution process. However, the **Certificate Details** and **Verification Results** are available only after the document has been fully signed and executed. ## Certificate Details Access the Certificate Details tab to view information extracted from the digital signature certificate. This information is only available after the document has been fully signed. The certificate details include the following fields: - Name - Gender - Year of Birth - PIN Code - State - Last 4 digits of Aadhaar ## eSign Verification Details The Signature Verification Status can be accessed in two ways: from the document owner's perspective in the Document Details page, or directly by signers after completing the signing process. The verification process ensures that the identity information provided during signing matches the trusted information stored in the digital certificate. #### Sender To review the verification status as a sender, navigate to the Document Details page and click the **Verification Results** tab. This tab is available only after the document has been fully signed and executed. ### Verification Information The verification status displays the following information: - **Signature Verification Status:** The right panel displays the overall signature verification status. - **Detailed analysis of signature verification:** This section outlines the results of the verification process through Aadhaar eSign or DSC token: - **Configured details:** The details configured during signature type setup, used as the verification standard. - **Input Values:** The values provided by the invitee during the signing process. - **Corresponding Certificate Value:** The matching value found in the invitee's digital certificate for comparison. - **Result:** The verification outcome (e.g., Match or Mismatch) indicating if the input value aligns with the certificate value. #### Signer After successfully signing a document, signers receive a confirmation email with a **View Document** link. To access the verification status: 1. Click the **View Document** link in the email. 2. Complete the OTP verification process. 3. You will be redirected to a page displaying the signed document. 4. Click the **Signature Verification Details** button to view the verification status. ### Verification Information The verification status page displays the same comprehensive information available to document owners: -**Signature Verification Status:** The right panel displays the overall signature verification status. - **Detailed analysis of signature verification:** This section outlines the results of the verification process through Aadhaar eSign or DSC token: - **Configured details:** The details configured during signature type setup, used as the verification standard. - **Input Values:** The values provided by the invitee during the signing process. - **Corresponding Certificate Value:** The matching value found in the invitee's digital certificate for comparison. - **Result:** The verification outcome (e.g., Match or Mismatch) indicating if the input value aligns with the certificate value. --- URL: https://knowledge.leegality.com/document-execution/manage-documents/document-details/complete-document-manually # Complete Document Manually You can manually complete a document that has been partially signed by at least one person. This action finalises the document and generates the audit trail, even if some invitees haven't signed. This is particularly useful when: * An invitee's signature is **no longer required**. * An invitation was sent to an **incorrect email or phone number**, and you need to finalise the document with the existing signatures. * An invitee is **unavailable or unresponsive**, and you have decided to proceed without their signature. ## Before You Begin: Prerequisites To manually complete a document, the following conditions must be met: * The document must have **at least two invitees**. * **At least one invitee** must have already signed. * Any remaining unsigned invitees **must be deleted** from the document journey first. ## How to Manually Complete the Document 1. From your dashboard, click **Documents** in the top navigation bar. 2. Navigate to the **Sent** from the left panel. 3. Locate the partially signed document you wish to complete. You can filter by *Document Status* or search by name. 4. Click the document name to open its details page. 5. Click the **Three dots (⋮)** menu in the upper-right corner and select **Complete**. ## Troubleshooting #### **Error: "Signing invitation(s) pending. Cannot complete the document right now."** * **Cause:** This error appears if you try to complete a document that still has active, unsigned invitees. The system requires all pending invitations to be resolved before completion. * **Solution:** You must first **delete the invitation** for each remaining unsigned invitee. 1. On the document details page, find the invitee who has not yet signed. 2. Click the **Three dots (⋮)** next to the invitee's name. 3. Select **Delete**. 4. Repeat for any other unsigned invitees. Once all have been deleted, you can proceed with the completion steps above. ## Result Once completed, the **final signed document and its audit trail are generated immediately**. The document's status changes to "Completed," and it moves from the **Sent** to the **Completed** section. --- URL: https://knowledge.leegality.com/document-execution/manage-documents/document-details/reactivate-document # Re-activate Expired Documents A sender needs to re-activate a document when one or more invitees fail to sign the document before it expires. Once a document has expired, the unsigned invitees cannot access and complete the signing process unless the sender re-activates the document. By re-activating the document, the sender extends the deadline, allowing invitees another opportunity to sign it. ## When Does a Document Expire? A document expires when the set time limit for its invitees to sign has passed. Once expired, the document becomes inaccessible for signing, and invitees are unable to view or interact with it. Expiry timelines can vary based on the sender's configuration, such as 45 minutes, end of day, or up to a specified number of days (e.g., 1–365 days). After this time, the document is considered expired until re-activated by the sender. Learn more about [**default document expiry configuration**](https://knowledge.leegality.com/settings/account-level/document-setting/Invitation-expiry-for-sent-documents-account-defaults). ### Exception cases | Scenario | Condition | Outcome | Location | | :---- | :---- | :---- | :---- | | **Scenario 1: Partial Signing** | The first invitee signs, but the second fails to sign within the set time frame. | Document/invitation expires but does not appear in the Expired folder. It shows in the *Waiting for Others* and *Failed* sections. | *Waiting for Others* and *Failed* sections. | | **Scenario 2: Rejection by Invitee** | The first invitee rejects signing, preventing activation for subsequent signers. | Document expires after the set time limit but appears in the *Waiting for Others* and *Failed* sections, not the Expired folder. | *Waiting for Others* and *Failed* sections. | > **Warning** > > **Expired Document:** Unsigned invitees will receive an error message when trying to access expired documents. > **Tip** > > Monitor the Expiring Soon section for documents set to expire in the next 5 days or less. Note that documents with a 45-minute expiry do not appear here. ## How to Access Expired Documents Expired documents are found in the **Expired** section and include those that expired: - 45 minutes after being sent - at the end of the day (EOD) after being sent - 1-365 days after being sent > **Info — Note** > > Documents in the expired folder for 30 days will be automatically deleted. > **Info — Stamp status affects deletion timing** > > - If an expired document is **completely unsigned** and has **stamps attached**, it is deleted **immediately** upon expiry — this resets the stamp status so the stamp becomes available for future use again. > - If a document is **partially signed** and has **no stamps attached**, it is **not** auto-deleted immediately on expiry. It remains available in the Sent folder, and the sender can re-activate it by setting a new expiry date. ## Reactivate an Expired Document Re-activating a document allows you to extend the expiration time and re-enable signing for the invitees. The steps for reactivation are: 1. Go to the **Documents** section in the top navigation bar. 2. Select **Expired** from the left-side panel. 3. Find the expired document you want to reactivate (use the filter or search options if necessary). 4. Open the document details and click on the **Re-Activate** button. 5. In the **Extend Document Expiry** modal, choose how long you want to extend the document’s expiration: * Extend by 45 minutes * Extend until 11:59 PM today * Extend by 1-365 days 6. Click **Confirm**. Once reactivated, the invitee will receive a re-invitation to eSign the document. --- URL: https://knowledge.leegality.com/document-execution/manage-documents/document-storage # How Documents are Stored in Leegality Leegality stores and categorises documents in your dashboard based on their current stage in the eSigning journey. Each category helps you track the document’s status and understand what actions (if any) need to be taken. ## Sent The Sent folder contains all documents for which signing and/or reviewing invitations have been sent, but not all invitees have completed their actions. This contains the documents that are partially signed but expired before all invitees acted. In this case, the sender needs to **re-activate** the document from its details page and set a new expiry date. ## Received The **Received** folder lists documents that you’ve been invited to **sign or review**. * Documents remain here **until all invitees (including you)** have completed their action. * Once the signing/review is complete by all invitees, the document automatically moves to the **Completed** folder. In case you are a signer, the document will *only* move to the Completed folder if the “[**Auto Save Signed Document**](https://knowledge.leegality.com/document-execution/settings/account-level/document-setting/auto-save-signed-documents)” is enabled or manually saved from the details page. ## CC The **CC** folder shows documents where you were added as a **CC invitee**. * You are not required to take any action. * The document will only appear in the CC folder if the sender has enabled the “**Share audit trail and signed document**” option in the CC Options while sending the document. ## Drafts The Drafts folder contains documents you began preparing but aborted before sending for signing. **When is a document saved as a draft?** A document is added to **Drafts** when, during the **New Document Journey** or a **Workflow run**, you: | **Stage** | **When Draft is Saved** | **If Canceled – What’s Retained** | | ------------ | ----------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Create** | Draft is saved when the sender clicks **Next** and proceeds to the **Invite** page. | Document(s) and Stamp(s) added in this stage are retained. | | **Invite** | Progress is **not** saved at this stage. | Even if every invitee, their configurations, and signatures are set, canceling will only retain the Document(s) and Stamp(s) from the Create stage. | | **Finalize** | Progress is **not** saved at this stage. | Even if signature coordinates are placed, canceling will only retain the Document(s) and Stamp(s) from the Create stage. | > **Warning — What's Retained in Drafts** > > Even if you configure invitees, signing options, or reach the final review stage, none of that progress is saved. Only the **document** and **attached stamps** are saved. > **Info — 📌 Stamps remain Resereved** > > If a stamp is attached, it remains **reserved** and **cannot** be used in other documents until the draft is deleted or sent. > **Tip — Draft Retention Period** > > Drafts are automatically deleted **30 days** after creation by default. You can customise the draft retention period from the [**Automatically Delete Draft Documents**](https://knowledge.leegality.com/document-execution/settings/Department/document-config#automatically-delete-draft-documents) setting in the dashboard. ## Completed The **Completed** folder shows documents where **all required parties have successfully signed the document**, and no further action is pending. ### For Signers However, whether a signer (invitee) sees the document in the **Completed** folder of their Leegality account depends on a feature called [**Auto Save Signed Document**](https://knowledge.leegality.com/document-execution/settings/account-level/document-setting/auto-save-signed-documents). #### What is “Auto-save signed documents”? This setting determines whether the signed document is **automatically saved** to the invitee’s Leegality account after they finish signing. * **If ON**: The document appears in the signer’s **Completed** folder immediately after signing. * **If OFF**: The document is **not saved automatically**. The signer must manually choose to save or delete it. #### How a Signer can Manually save a Signed Document from the Public Details page After the invitee signs the document, they are redirected to the **Public Details Page**. In the **bottom-left corner**, two options are available: * **Save the document:** Clicking this triggers an OTP verification (via registered email or phone). Once verified, the document is saved to the signer’s Completed folder. > **Note:** If the signer does not have a Leegality account then the system automatically creates a free, secure Leegality account for you using the email or phone number you provided during signing. The signed document is stored in this account. * **Delete my copy:** Clicking this will show a warning: “This will permanently delete this document. This action cannot be undone.” If confirmed, the document is deleted, and the signer will no longer be able to access it via email, SMS, or WhatsApp links. ### For Senders Regardless of the auto-save setting for invitees, the document is **always saved** in the **Completed** folder of the sender once all required actions are done. > **Info** > > Senders can enable [**Auto-delete Completed Documents**](https://knowledge.leegality.com/document-execution/settings/Department/document-security-settings#auto-delete-after-document-completion) to automatically remove completed documents from **their own account** after a chosen retention period. > > This setting **does not affect the signer’s copy**. If a signer has saved their copy, they will still be able to access it even after the sender’s copy is deleted. ## Expired The **Expired** folder contains documents where the **invitation to eSign or review has expired** before any invitee took action. In other words, these documents are considered **completely unsigned** — no invitee has signed or reviewed them. **As soon as a document expires:** * Invitees can no longer access or sign the document. * eSign credits are automatically reverted back to the unused pool. * If the expired document includes affixed stamps, the document is deleted immediately upon expiry. The status of those stamps is reset to Unused, making them available for future use. Unsigned documents in the Expired folder are automatically deleted after 30 days from the date of expiry. --- URL: https://knowledge.leegality.com/document-execution/manage-documents/find-documents # Find Documents You can find documents using search, filters, and Quick Access. This guide explains how to effectively use these methods to locate documents within your account. ## Quick Access Quick Access categorizes your documents to help you quickly identify and manage the ones requiring immediate attention. - **Action Required:** Documents awaiting your action, such as signing, reviewing and/or drafts waiting to be sent for signing. - **Waiting for Others:** Documents you sent that are pending signatures or reviews from others. - **Expiring Soon:** Documents that will expire in a few days and may require action from you or other invitees. - **Failed:** Documents that expired due to reasons like invitation timeout, retry attempt exhaustion, or certificate details mismatch. - **Rejected:** Documents you sent but were rejected by the reviewer. - **NeSL Errors:** Documents with NeSL errors that may need a retry or status refresh. See [Documents with NeSL Errors](https://knowledge.leegality.com/document-execution/nesl/nesl-errors). ## Search Documents Use the Search box at the top right of your Documents section to find documents by: - Document name - Document ID - IRN (Internal Reference Number) > **Tip** > > The search returns both exact and partial matches and is case-insensitive. 1. Select a category (**Sent, Received, CC, Drafts, Completed, Expired** or any **Quick Access** option). 2. Enter the search term in the search box at the top right corner. 3. Matching results will appear in real time as you type. **Example:** If you selected Sent, only documents in the Sent category will be shown. ## Filter Documents Filters help you find documents based on selected criteria for a more detailed search. > **Tip** > > You can use filters and search together to narrow down search results. ### To Apply Filter 1. Select a category (**Sent, Received, CC, Drafts, Completed, Expired** or any **Quick Access** option.) 2. Available filters will appear on the right. 3. Select filter(s) and the document list will update based on the selected filter. ### General Filters These filters are available in multiple statuses such as Completed, Waiting for Others, Expiring Soon, Expired, and Rejected. - **Workflow Used:** To find documents created using a specific workflow. - **Creation Mode:** To find documents created using Dashboard Workflow, API Workflow, Excel Workflow, and Non-Workflow. ### Filter by Document Status #### Sent - **Document Status:** To find documents you’ve sent - **Partially Signed:** At least one invitee has completed the assigned activity (sign or review). #### Received - **Invitation Status:** To find documents you’ve received. - **You Signed:** You have signed the invitation. - **Pending your signature:** The invitation is pending your signature. - **Pending your review:** The invitation is pending your review. - **You reviewed - Accepted:** You have reviewed and accepted the invitation. - **You reviewed - Rejected:** You have reviewed and rejected the invitation. #### Action Required - **Status:** To find the documents based on their current status. - **Draft:** Documents you have created and saved but not sent yet. - **Pending your signature:** Documents require your signature. - **Pending your review:** Documents you need to review. #### Failed - **Failure Reason:** Filter documents according to failure reasons. - **Invitation Expired** - **Certificate Detail Mismatch - Accepted** - **Certificate Detail Mismatch - Rejected** - **Aadhaar eSign - Retry Attempt Exhausted** --- URL: https://knowledge.leegality.com/document-execution/manage-documents/how-to-edit-a-document # How to Edit an Invitation You can edit the details of invitations you have sent but have not completed yet. You can modify the invitee's name, eSign type, invitee level and signing journey options. > **Info — note** > > You can only edit details of invitees who haven't signed or reviewed. ## To Edit an Invitation In the Documents section, find the document you want to edit. 1. Click the **Three Dots (⋮)** and select **Edit**. 2. You have options to edit the name, eSign type, invitee role, and change invitee-level options. 3. After completing your edits, click **Next**. 4. Finalise the signing coordinate position. 5. Once finished, click **Send**. > **Warning — Invitees with Automated Sign** > > If [**Automated Sign**](https://knowledge.leegality.com/document-execution/esign-type/automated-esign#sending-journey) is enabled for an invitee you edit, re-enter the Automated Sign password for that invitee before you click **Send**. Editing the invitation requires the password to be provided again; if it isn't, an error is displayed and the changes cannot be saved. ## Details you can Edit in an Invitation ### Invitees Level Options For invitees who haven't signed yet, you can enable/disable and edit: #### Invitee Information - Invitee Name - Invitee Role - eSign Type #### Aadhaar Preferences - Prioritize Aadhaar for Invitee - Define maximum Aadhaar signing attempts #### Signature Appearance - Prevent invitee from editing name in signing journey - Hide invitee's name in signature appearance #### Document Requirements - Require company seal from invitee - Require invitee to upload supporting documents - Allow viewing of all invitees' supporting documents #### Security and Permissions - Enable security features - Allow the signer to reject the document #### Notifications and Communication - Send Email Notifications - Send SMS Notifications - Add custom URLs and webhooks #### Consent and Payment - Set additional consent terms - Collect Payment ### Signing Journey Options You can edit any of the signing journey options. - Extend or reduce the expiry of the document. - Add a custom message for remaining the invitees - Upload reference attachment for the remaining invitees - Auto delete document after completion ### Documents You can only change the singing coordinates in the document. --- URL: https://knowledge.leegality.com/document-execution/manage-documents/resend-a-document # Resending an Invitation When you send a document for eSign, Leegality sends an original notification to each invitee through the channels you've enabled (email, SMS, and/or WhatsApp). You can also resend notification manually to the invitee. They receive the same signing URL that was sent in the original notification. The resend notification type will be the same as it was selected during the sending journey for the invitee. > **Info — Note** > > You can resend a notification only if the document is still active for the invitee. ## To Resend an Invitation 1. In the Documents section, [find the document](https://knowledge.leegality.com/document-execution/manage-documents/find-documents) containing the invitee you wish to resend the notification to. 2. Click on the document name to open the Detail View. 3. In the **Invitee List**, you can see all active and inactive invitees. 4. For active invitees, you can: - **Resend Notification:** Click to instantly send another eSign notification. - **Re-invite:** If the invitee has rejected the eSign request, the status will be `Unsigned` and `Rejected`. Click **Re-Invite**, optionally add a message, and confirm to send the invitation. The invitee will receive a notification consisting of the signing URL of the document. > **Info** > > You can use **Resend Notification** up to four times per invitee. > **Tip** > > Alternatively (or after you've used all four resends), click **Copy URL** button in the invitee card to copy the signing URL and share it with the invitee through their preferred mode of communication. --- URL: https://knowledge.leegality.com/document-execution/manage-documents/sign-documents-in-your-account # Sign Documents in your Account The Leegality dashboard allows you to sign the documents you received and is awaiting your signature. You can sign one document at a time or select multiple documents and sign them in bulk. ## Sign one document 1. From the Documents section, click on the **Action Required** under **Quick Access** in the left navigational panel. This list shows the documents that require your action, including those that need signing and review. 2. Find the document you want to sign and click the **Sign** button on the right. 3. This initiates the signing journey, allowing you to complete signing the document. Once signed, the document moves to the Completed section. > **Info** > > To sign multiple documents in bulk, use [**DSC-Token bulk signing**](https://knowledge.leegality.com/document-execution/esign-type/dsc-token#bulk-sign-using-dsc-token). --- URL: https://knowledge.leegality.com/document-execution/manage-documents/share-documents # Share documents You can share documents with internal team members and external users through multiple methods. Each method serves different purposes depending on who needs access and what level of visibility they require. ## Sharing methods overview Leegality provides four ways to share documents: | Method | Internal users | External users | Scope | Best used for | |--------|----------------|----------------|-------|---------------| | CC invitee | ✓ | ✓ | Single document | Real-time updates during signing process | | Impersonator mode | ✓ | ✗ | All user documents | Admin and granted user can access documents | | Completion notifications | ✓ | ✓ | All completed documents | Automated notifications when documents are signed | | Share specific document | ✓ | ✓ | Single document | One-time sharing of completed documents | ## Share with CC invitees Add a CC invitee to keep someone informed about a specific document's progress. CC invitees receive notifications throughout the document lifecycle, including when invitations are sent, signed, approved, rejected, or when the document is completed. > **Info — Note** > > This method shares a single document while it's in progress. The CC invitee receives notifications but cannot sign or review the document. Learn how [**to add a CC invitee**](https://knowledge.leegality.com/document-execution/leegality-features/invitee-level/types-of-invitee/cc). **Use this method when:** - Someone needs to monitor a specific document's progress - You want to keep stakeholders informed without giving them signing responsibilities - Both internal team members and external users need visibility ## Share via impersonator mode Impersonator mode allows admins to grant specific team members access to another user's entire document collection. This is an internal-only feature designed for administrative purposes. When you grant impersonator access, the authorized user can: - View all documents in the shared user's account - Download documents and audit trails - Perform administrative actions on behalf of the user > **Warning — Internal access only** > > Impersonator mode is available only for users within your organization. You cannot grant impersonator access to external users. Learn how [**to grant impersonator access**](https://knowledge.leegality.com/document-execution/settings/Admin/impersonator-mode#grant-impersonator-access-to-users). **Use this method when:** - Team members need ongoing access to another user's documents - Providing administrative support or troubleshooting - Managing documents when users are unavailable ## Share via completion notifications Configure completion notification recipients to automatically receive email notifications when any document is completed. Recipients receive notifications for all completed documents, not just specific ones. > **Info** > > Learn how [**to add completion notification recipients**](https://knowledge.leegality.com/document-execution/settings/Notifications/notification) **Use this method when:** - Finance, legal, or compliance teams need to be notified of all completed documents - You want automated notifications without manual sharing - Both internal team members and external users need to be informed ## Share specific document and audit trail Share a completed document and its audit trail directly via email. This is a one-time sharing action for individual documents. **To share a specific document:** 1. Navigate to the **Completed** section under documents. 2. Find the document you want to share and click on the **⋮** and select **share**. 3. Enter the email address of the recipient. (**Note:** You add up to 15 email addresses.) 4. Click **Send**. The recipient receives an email with the completed document and its audit trail attached. **Use this method when:** - You need to share a specific completed document once - The recipient needs both the document and audit trail - You want immediate, ad-hoc sharing without ongoing access --- URL: https://knowledge.leegality.com/document-execution/manage-documents/delete-a-document # Deleting a Document You can delete drafts and documents you have sent (under-progress, rejected, failed, expired, and completed). Deleting a document revokes all outstanding signer and reviewer invitations. > **Warning** > > Once you delete a document from your account, it cannot be retrieved. ## How to Delete a Document 1. In the Documents section, [search for the document](https://knowledge.leegality.com/document-execution/manage-documents/find-documents#search-documents) you want to delete. 2. Click on the **Three Dots (⋮)** and select **Delete**. 3. Confirm your action by clicking on **Delete**. > **Tip** > > You can download audit trails for completed documents that have been deleted from the activity logs. ## What happens when you delete ### Documents you sent Deleting a document has varying impacts depending on its status. The effects of deletion are as follows: #### Sent Documents (Under-Progress) As the sender, deleting a sent document that is under-progress revokes any outstanding signing and reviewer invites. - Invitees who haven’t signed yet but have an active invitation will be notified that the invitation was revoked. - Invitees who have already signed the document will be unable to access it and will receive a notification that the invitation was deleted. - Future invitees, who are later in the signing order, will not receive any notifications regarding the invitation. #### Completed Documents If you delete a completed document where all invitees have signed the document, the document and invitee are unaffected. Invitees can still view and download the document. ## When Are Invitees Notified? When a completely unsigned document is **deleted** Leegality notifies the invitees about the cancellation, depending on the notification settings. **When notifications are _enabled_ at the invitee level:** * The invitee will receive a notification stating: > *“The sender has revoked the invitation sent to you to eSign the document.”* * This applies **even if** the sender deletes the document **after** it has expired. **When notifications are _disabled_:** * The invitee **will not receive** any communication about the revocation of the document. > **Tip** > > Learn [**how to configure notification for each invitee**](https://knowledge.leegality.com/document-execution/leegality-features/invitee-level/notifications/email-notifications) during the sending journey. --- URL: https://knowledge.leegality.com/document-execution/manage-documents/delete-an-invitation # Deleting an Invitation You can delete an invitee's invitation at any stage of the signing journey, except after they have already signed the document. Once an invitee has signed, their invitation cannot be deleted individually — however, you can still [delete the entire document](https://knowledge.leegality.com/document-execution/manage-documents/delete-a-document). > **Info — Note** > > No email or message notification is sent to the invitee when their invitation is deleted, regardless of their status. ## How to Delete an Invitation 1. Go to the **Documents** section and select the document. 2. On the document details page, click the **Three Dots (⋮)** next to the invitee you want to delete. 3. Select **Delete**. 4. Confirm the deletion from the popup. ## What Happens When You Delete an Invitation ### Active and Unsigned An active invitee is one who has already received the signing invitation. If their invitation is deleted: - They are removed from the document without any notification. - Since they received an invitation email or message earlier, if they attempt to sign using the link they received, they will encounter an error page and will not be able to complete the signing. ### Inactive and Unsigned An inactive invitee is one who has not yet received the signing invitation (for example, they are later in the signing order and the previous invitee has not signed yet). If their invitation is deleted: - They are removed from the document without any notification. - Since they never received a signing invitation, no further action is required on their end. > **Info — Note** > > The sender cannot manually make an invitation inactive. They can, however, mark an inactive invitee as active. ### Rejected An invitee who has rejected the signing invitation can also be deleted. No notification is sent in this case either. ## Impact on Signing Order When an invitee is deleted, the signing journey does **not** automatically continue to the next person. The sender must **manually activate the next invitee** to send the signing invitation to them. --- URL: https://knowledge.leegality.com/document-execution/manage-documents/folders # Folders Folders provide a way to organise your documents. Leegality dashboard has some pre-built sections including Sent, Received, Draft, Completed, and Expired. However, folders give you flexibility if you want to categorise your documents any other way. > **Info — note** > > The order of folders is determined by creation time, with the earliest created folders appearing at the top of the list and newly created folders at the bottom. ## Create, Edit, Delete, and Move Folders 1. Go to the Documents section. - To **Create a Folder**: 1. In the **Folders** pane of the left, click the **+** icon. 2. In the Create Folder dialog, enter the desired **folder name**. 3. Click **Confirm** to create a folder. The new folder will appear in the list. - To **Create a subfolder**: 1. In the list of folders, find the parent folder in which you want to create a sub-folder. 2. Click the **Three dots (…)** and select **Create subfolder**. 3. In the Create folder dialog, enter the name and click **Confirm**. You can create multiple levels of sub-folders like this. - To **Edit or Delete a folder or subfolder**, click on the **three dots (…)** next to the folder. 1. To edit the folder name, select **Rename**. 2. To delete the folder, select **Delete**. **Note:** Deleting a folder will not delete the documents within it. - To **move a folder**: 1. Find the folder you want to move. 2. Click on the icon next to the folder and select **Move to folder**. 3. In the Move to folder dialog box, choose where you want to move the folder. You can move the folder into the existing folder or create a new parent folder. ## Move Documents to a Folder 1. In the Documents section, select the document you want to move. 2. Click on **Three dots (⋮)** and select **Move to folder**. 3. In the Move to folder dialog box, select the folder in which you want the document(s). Click **Move here**. > **Info — Note** > > Moving a document to a folder does not remove it from its original location. > > **For example**, if you move a document from the Completed section to a subfolder, it will appear in both places. ### Assigning a Folder in V4 You can also assign a folder to a document while sending it, so it is saved in the right place from the start: #### Workflow Creation In the v4 editor's **Create** stage, you can assign folders at two levels: - **Document Folder:** In a primary document's details, select the folder where that document will be saved. - **Pack Folder:** In the pack details on the right panel, select the folder for the entire pack. #### New Document Journey While preparing your document on the Create page, select a folder from the **Folder** dropdown to save your document into it. --- URL: https://knowledge.leegality.com/document-execution/stamps/stamp-series/create-a-stamp-series # Create a Stamp Series You need to create a **Stamp Series** in order to purchase the stamp papers of a specific state and denomination via Leegality. The series can be reused for purchasing more stamp papers as needed, and it also allows you to monitor their usage. 1. Click on the **+ Create** button on the top bar and select **Stamp Series** option. 2. Fill in the required information across the following sections. ## Basic Information - **Series Name**: Enter a unique name to identify this stamp series for easy reference and tracking. > **Info — Character Limit** > > You can enter a maximum of 20 characters for the series name. Allowed inputs include alphanumeric characters and the following special characters: **| - : () , _ . [] & / # + @ ; ' –** ## Stamp Paper Information - **State**: Select the state for which you need to procure stamp papers from the dropdown list. - **Purpose/Article Code**: Select the article code that represents the legal classification of your agreement type. This determines the stamp duty rates and compliance requirements applicable to your document. Note that you must select a state before this field becomes available. > **Info — Selection Requirements** > > - Only agreement types already configured for the selected state will appear in the dropdown > - The article code must be selected before you can specify the denomination - **Denomination (₹)**: Specify the stamp duty value to be affixed on your stamp papers. The available denomination options depend on the state and article code you selected. Denomination field changes according to the scenarios below: - **Range-based denominations**: If the selected state supports a range of denominations(For intance from ₹10 to ₹500), you must enter a value within this range. Values outside this range will result in an error. - **Fixed denomination**: For certain states and article codes, the denomination will be fixed and cannot be modified. The field will display the predetermined value. - **Mixed options**: Some states allow specific fixed values up to a threshold, then offer a range beyond that. (For example: ₹20, ₹50, ₹100, and then any value from ₹100 to ₹5000). Available fixed values appear in a dropdown, while invalid denominations trigger an error message. - **Consideration Price calculation**: For certain agreement types, an additional field called **Consideration Price** appears. Enter the transaction value here, and the system automatically calculates 2% stamp duty and populates the denomination field. > **Info — Denomination Rules** > > - Decimal values are not allowed in the denomination field > - Always verify that your entered value matches the permitted range or options for your selected state and article code > **Warning — Important** > > The **State, Purpose/Article Code, Denomination** fields cannot be changed once the stamp papers have been procured. Choose carefully before proceeding. - **First Party Name**: Enter the legal name of the first party involved in the agreement. You can enter a maximum of 52 characters for this field. - **Second Party Name**: Select or enter a generic name representing the second party in the agreement. You can choose from the preapproved dropdown list or provide a custom name based on your organization's entitlements. Note that you cannot change the Second party names once the stamp series is created. > **Info — NOTE** > > - The second party name must be generic rather than a specific individual or company name (e.g., Borrower, Tenant, Contractor, Customer, Vendor, Lender) > - Available options in the dropdown vary based on the state you selected > - You can only select the second party name after entering the first party name > - The ability to provide a custom name depends on your organization's configuration. Contact **support@leegality.com** for more information about custom name entitlements. - **Purchased By**: Enter the name of the entity or individual purchasing the stamp paper. This is a mandatory field and can be different from the first and second parties involved in the agreement. > **Info — NOTE** > > You can enter a maximum of 52 characters for this field. - **Stamp Duty Paid By**: Select the entity or individual who paid the stamp duty to procure the stamp papers. You must choose either the first party or the second party from the dropdown. ## Legend Configuration - **Legend Content**: Specify the text to be printed on the physical stamp papers. This content must include Leegality's Document ID, which is a unique identifier that links the stamp paper to its corresponding document in the system. > **Info — Auto-fill and Editing** > > - The system automatically populates this field with the first and second party names > - You can edit the legend content according to your requirements > - You can use alphanumeric characters and these special characters: **+ | - : () , _ . [] & / @ # ; ' –** > - Maximum allowed length is 255 characters and can span up to 8 lines > **Warning — Document ID** > > Do not remove or modify the Document ID from the legend content. This identifier is essential for tracking and linking the stamp paper to its document. ## Shipping Information Provide the delivery details for shipping the physical stamp papers to the correct recipient. - **POC Name**: Enter the full name of the point of contact who will receive the stamp paper delivery. - **POC Phone Number**: Provide the phone number of the point of contact for delivery coordination. - **POC Email Address**: Enter the email address of the point of contact. The procurement team will use this email to communicate updates about the stamp procurement process and delivery status. - **Address**: Enter the complete delivery address where the physical stamp papers should be shipped. > **Tip — Quick Address Entry** > > Enter the Pincode first, and the system will automatically populate the City and State fields for you. 3. Once you have completed all the required fields, click on the **Create Series** button. The newly created stamp series will appear in your stamp series list and will be ready for purchasing stamp papers. --- URL: https://knowledge.leegality.com/document-execution/stamps/stamp-series/purchase-stamp-series # Purchase Stamp Papers > **Tip — Prerequisite** > > You must [**create a stamp series**](https://knowledge.leegality.com/document-execution/stamps/stamp-series/create-a-stamp-series) in order to purchase stamp papers. You can purchase the stamp papers of a series directly from the Stamps section. To Purchase Stamp Series 1. Navigate to **Stamps > Series**. 2. Locate the Stamp Series you wish to purchase by searching using the series name or number. 3. Click the Cart icon on the right. 4. Specify the quantity of stamp papers needed. 5. Proceed to checkout. 6. Review your order details and click **Confirm**. 7. Select your payment method (credit card, debit card, UPI, net banking, wallet, or EMI) and click **Pay**. > **Info** > > After a successful payment, the stamp procurement process begins and usually takes 7-10 business days. Once completed, the purchased stamps will be available in your account. ## Bulk Purchase - Multiple Stamp Series 1. Select the checkbox for each stamp series you want to purchase. 2. Enter the required stamp paper quantity for each selected series. 3. Click **Purchase** and review your order details. 4. Click **Confirm** to proceed. 5. Choose a payment method (credit card, debit card, UPI, net banking, wallet, or EMI) and click **Pay**. ## Check Stamp Procurement Status You can monitor the status of your stamp order by clicking on the Procurement detail icon. This is visible only during active procurement for a series. Upon clicking the icon, you can view: - **Order Date:** Date when the order was placed. - **Order Quantity:** Number of stamps purchased. - **Estimated Due Date:** Expected date when the stamps will become available for use on the dashboard. - **Updated Due Date:** Revised due date in case of delays. - **Reason:** Explanation for any delays. ## Minimum Order Quantity (MOQ) for Stamp Paper Purchase There is no minimum order quantity requirement for purchasing stamp papers. Customers can place an order even for a single stamp paper. However, the applicable convenience fee and handling charges will be charged as follows: - **Basic/Personal Plan:** Convenience fee equivalent to 30 stamp papers per state and handling charges of ₹500 per state. - **Enterprise Plan:** As per the agreed commercial terms ### Convenience Fee Calculation (Basic/Personal Plan) - 30 × ₹45 = ₹1,350 convenience fee - Per state handling charges: ₹500 ### Important Points #### **Same State, Different Series** If a customer orders stamp papers from the same state but with different series, only one convenience fee equivalent to 30 stamp papers + 500 Handling fee will be charged. For example, if a customer purchases 1 stamp paper from Delhi 03 and another 1 stamp paper from Delhi 04, only one convenience fee, equivalent to 30 stamp papers, i.e., **₹1350, along with a ₹500 handling fee,** will be charged, since both stamp papers belong to the same state.   #### **Different States** If a customer orders stamp papers from multiple states, the convenience fee equivalent to 30 stamp papers will be applied separately for each state, along with ₹500 handling charges per state. For example, if a customer purchases 1 stamp paper from Delhi 03 and another 1 stamp paper from Maharashtra 02, the convenience fee equivalent to 60 stamp papers will be charged (30 for Delhi + 30 for Maharashtra), along with a handling fee of ₹500 per state. ### Why is the Convenience Fee Charged Even for a Single Stamp Paper? The stamp paper must first be procured from the respective state and sent to us via courier. Once received, we digitise the stamp paper, upload it to the system, and dispatch it to the customer via courier. These operational and logistics costs remain the same regardless of whether the customer orders one stamp paper or multiple stamp papers. ## FAQ **Can I get a refund on a stamp purchase?** > No, stamp purchases through Leegality are non-refundable. --- URL: https://knowledge.leegality.com/document-execution/stamps/stamp-series/edit-stamp-series # Edit a Stamp Series You have the option to edit a stamp series that you have already created. To do this; 1. Navigate to **Stamps > Series** 1. Find the stamp series you want to edit. You can search for it by using the series name or number. 2. Click on the Series or **Three Dots (︙)** and **Open**. 2. In the edit view, you can modify the following details: - **Series Name** - **Series Information** - First Party Name - Second Party Name - Purpose/Article Code - Purchased By - Stamp Duty Paid By - **Legend Configuration** - Legend Content - **Shipping details** - POC Details - Shipping Address 3. Click **Save** after making the desired changes. > **Info** > > - Changes will apply to all future orders placed with this stamp series. > - Changes will not affect stamps that are already in the procurement process or those currently available for use. --- URL: https://knowledge.leegality.com/document-execution/stamps/stamp-series/extend-expiry-of-stamps # Extend Expiry of Stamps When using stamp papers procured via Leegality, each stamp has a default expiry date of 6 months from the date of purchase. > **Tip — Example** > > If the stamps' purchase date is 01-January-2024, they will expire on 01-July-2024. Beyond this period, the stamp papers are automatically categorized as expired and removed from usable circulation. > **Info — Note** > > This Expiry date is an internal policy of Leegality and does not hold any regulatory significance in a legal context. To continue using beyond the default 6-month period, Leegality provides an Extend Expiry Date option within the dashboard. You must have admin access to extend expiry date of stamps. ## To Extend the Expiry of Stamps 1. From your Leegality Dashboard, navigate to **Stamps > Series**. 2. Find the stamp series with expired stamps that you want to extend. You can search using the series name or number. 3. Click on **Three Dots (⋮)** and select **Extend Expiry**. 4. Each row represents stamps based on the **Purchase Date** and **Expiry Date**, along with the quantity of stamps falling into this combination. 5. Select the row(s) for which you intend to extend the expiry date, then specify the **number of days** you wish to extend it. > **Tip — Example** > > Suppose the **Expiry Date** is 31-March-2024, and you specified an **additional 100 days**. The new expiry date will be 09-July-2024. 6. Click **Extend**. > **Info** > > Expiry dates can be extended regardless of whether the stamp papers are expired or not. ## Legal Validity vs Platform Expiry The expiry shown in the Leegality dashboard is a **platform expiry** — a soft 6-month default that an admin can extend internally. **Legal validity** is governed by your state's stamp laws and is independent of the dashboard setting. In the following states, stamp papers have a strict, non-extendible **6-month legal validity** by law. Extending the expiry in the Leegality dashboard does **not** extend legal validity in these states: - Maharashtra - Rajasthan - Gujarat - Karnataka > **Warning — IMPORTANT** > > The legal validity of stamps is governed by the respective state laws. Extending the expiry on Leegality does not extend it from a legal perspective. --- URL: https://knowledge.leegality.com/document-execution/stamps/stamp-series/block-stamp-papers # Block Stamp Papers The block stamp feature in Leegality enables users to remove specific stamp papers from the Unused category, thereby preventing them from being affixed to the document during sending journeys. **When to Block Stamp Papers?** You need to block a stamp paper when it is intended for physical use and to avoid its utilization in digital workflows via Leegality. > **Warning** > > Blocking stamp papers is an irreversible action. ## Steps for Blocking a Stamp Paper 1. Navigate to **Stamps > Series** from the top bar. 2. Click on the relevant stamp series to access the stamp papers associated with it. 3. Go to the **Stamps** tab to access all stamp papers. 4. This page will display the complete list of stamp papers procured for that series. 5. Locate the specific stamp paper you want to block within the list. You can also select multiple stamp papers and block them in one click. 6. Click on the 🚫 icon to block single stamp paper. You can also select multiple and click on the **Block** button at the top. 7. Confirm the action to block the selected stamp papers. > **Info — Note** > > Only unused stamp papers can be blocked. Your stamp paper is now successfully blocked and cannot be used for digital document creation. --- URL: https://knowledge.leegality.com/document-execution/stamps/stamp-series/download-stamp # Download stamps You can download your purchased stamps as PDF files. This is useful when you need to physically print and use stamp papers. ## Download a stamp paper 1. Navigate to **Stamps > Stamp Series**. 2. Click the stamp series whose stamps you want to download. 3. Click the **Stamps** tab to view all stamp papers in this series. 4. Hover over the stamp paper and click the preview icon ![Preview Stamp Paper Icon](https://knowledge.leegality.com/img/Icon=eye.svg). 5. In the preview panel, click the download icon ![Download Stamp Paper Icon](https://knowledge.leegality.com/img/Icon=download.svg). The stamp paper PDF downloads to your device. > **Warning — Block stamps before physical use** > > If you plan to use the stamp paper physically, you must [**block the stamp paper**](https://knowledge.leegality.com/document-execution/stamps/stamp-series/block-stamp-papers) before downloading. --- URL: https://knowledge.leegality.com/document-execution/stamps/stamp-series/consumption-history-of-stamps # Consumption History of Stamps The Consumption History section provides detailed records of how each stamp has been used, including: - Credits - Debits - Associated document IDs - Transaction dates It covers information for all stamp series and individual stamps within each series. You can access the Consumption History by: 1. Navigate to **Stamps > Series**. 2. Locate the Stamp Series whose history you want to check. 3. Click on the **Three Dots (⋮)** and select **History**. Here you can access the consumption history for your stamps. You can also customize your view by specifying a date range and transaction type (*credit, debit, reserve, release, and reduce*) for each stamp series individually. ## Stamp Consumption Details The Stamp Consumption History provides the following information: - **Series Number:** Identifies the stamp series for which consumption history is being viewed. - **Transaction:** Details the type of transaction: credit, debit, reserve, or release. - **Reference ID:** Document IDs associated with stamp usage in document transmission. (**Note:** Document IDs may repeat if invitations are revoked or expired.) - **Date:** Records the date of each transaction. - **Remark:** Provide additional details regarding each transaction. - **Release Date:** Indicates when stamps are released from reserve, whether credited or debited. - **Debit:** Displays the number of stamps deducted from the account for the relevant transaction. - **Credit:** Shows the number of stamps credited to the account, either through release or purchase. - **Balance:** Reveals the remaining number of stamps in the account for the specified series at the time of this transaction. --- URL: https://knowledge.leegality.com/document-execution/stamps/stamp-series/stamp-report # Stamp Series Report You can download an inventory report of a series from the Stamps listing page ## To Export Stamp Details 1. Open the stamp series for which you want to download the report. 2. In the detail view, go to the **Stamps** tab. 3. You will see a list of all stamp papers associated with that series. 4. You can use the Status filter to narrow the list by: Used, Unused, Blocked, Expired, and In Process. 5. Click the **Generate Report** button. 6. Choose the details you want to include in the report: - **Document ID** - **Stamp Serial Number** - **Status** - **Last Updated On (Date and Time)** - **Purchased On (Date and Time)** - **Expiry Date** 7. Click **Export** to download the report. An Excel file will be downloaded to a local device. The file name format will be Stamp *Series Number_State_Denomination*. --- URL: https://knowledge.leegality.com/document-execution/stamps/stamp-group/stamp-groups # Stamp Group Stamp Groups allow paying variable stamp duty on documents by letting you choose stamps of various denominations to meet the required amount. > **Tip — Example** > > **Understand Stamp Groups with an example.** > > Let’s say you need an 850-rupee stamp for an agreement in Maharashtra. The available stamp denominations are 200, 500, and 1000 rupees. > > - **Without Stamp Groups:** You would need to use a 1000-rupee stamp, which results in an extra payment of 150 rupees. > - **With Stamp Groups:** With stamp group, you simply enter the required stamp value, and Leegality's algorithms automatically select the combination of stamps that meet your exact needs. This eliminates the hassle of manually picking stamps and ensures you only pay what is required. This feature is especially useful for documents where the stamp duty is a percentage of the agreement value (ad-valorem). Instead of dealing with fixed stamp values, Stamp Groups allow you to tailor the stamp duty to match the exact amount needed for your document, saving you both time and money. ## Create a Stamp Group 1. Click on the **Stamps** on top and select **Groups** from the left. 2. Click on the **+ Create** button on the top right. 3. Enter a suitable **Group Name**. 4. Select a **State** to be associated with this group (e.g., Delhi). > **Info — Note** > > The state cannot be changed once the stamp group is created. 5. Specify the **Maximum Stamp Value** for this stamp group. This is the highest amount of stamp value that can be used when sending the document. 6. Choose the series of the selected states to be associated with this group. 7. Click **Create**. ## Edit a Stamp Group 1. Click on the **Stamp** and select **Groups** from the left. 2. Find the Stamp Group you want to edit. You can search for it by using the Group Name or Number. 3. Click on the edit icon on the right. 4. You can edit the following details of a stamp group. - **Group Name** - **Maximum Stamp value** - **Add or remove associated stamp series** 5. Once done, click on the **Update** button. --- URL: https://knowledge.leegality.com/document-execution/stamps/stamp-procurement-panel/create-a-stamp-series # Create a Stamp Series You need to create a **Stamp Series** in order to purchase the stamp papers of a specific state and denomination via Leegality. The series can be reused for purchasing more stamp papers as needed, and it also allows you to monitor their usage. > **Warning — Edit Access Required** > > Only users with **edit access** can create stamp series in the **Stamp Procurement Panel**. 1. Click on the **+ Create** button on the top bar and select the **Stamp Series** option. 2. Fill in the required information across the following sections. ## Basic Information - **Series Name**: Enter a unique name to identify this stamp series for easy reference and tracking. > **Info — Character Limit** > > You can enter a maximum of 20 characters for the series name. Allowed inputs include alphanumeric characters and the following special characters: **| - : () , _ . [] & / # + @ ; ' –** ## Stamp Paper Information - **State**: Select the state for which you need to procure stamp papers from the dropdown list. - **Purpose/Article Code**: Select the article code that represents the legal classification of your agreement type. Note that you must select a state before this field becomes available. > **Info — Selection Requirements** > > - Only Article codes available for the selected state will appear in the dropdown > - The article code must be selected before you can specify the denomination - **Denomination (₹)**: Specify the stamp duty value to be affixed on your stamp papers. The available denomination options depend on the state and article code you selected. The denomination field behavior varies based on the state and article code configuration: | Denomination Type | Description | Example | | :---- | :---- | :---- | | **Range-Based** | Enter any value within the allowed range for the selected state and article code. Values outside this range will result in an error. | If the range is ₹10 to ₹500, you can enter ₹150, ₹275, etc. | | **Fixed Denomination** | The denomination is predetermined and cannot be modified. The field displays the fixed value automatically. | State XYZ for Article Code ABC always requires ₹100 stamp duty. | | **Mixed Options** | Select from specific fixed values up to a threshold, then enter any value within a range beyond that threshold. Available fixed values appear in a dropdown. | Fixed options: ₹20, ₹50, ₹100. Range option: Any value from ₹100 to ₹5000. | | **Consideration Price-Based** | An additional **Consideration Price** field appears. Enter the transaction value, and the system automatically calculates stamp duty (typically 2%) and populates the denomination field. | Enter Consideration Price: ₹100,000. System calculates and sets denomination as ₹2,000. | > **Info — Denomination Rules** > > - Decimal values are not allowed in the denomination field > **Warning — Important** > > The **State, Purpose/Article Code, Denomination** fields cannot be changed once the stamp papers have been procured. Choose carefully before proceeding. - **First Party Name**: Enter the legal name of the first party involved in the agreement. You can enter a maximum of 52 characters for this field. - **Second Party Name**: Select or enter a generic name representing the second party in the agreement. You can choose from the preapproved dropdown list or provide a custom name based on your organization's entitlements. Note that you cannot change the Second party names once the stamp series is created. > **Info — NOTE** > > - The second party name must be generic rather than a specific individual or company name (e.g., Borrower, Tenant, Contractor, Customer, Vendor, Lender) > - Available options in the dropdown vary based on the state you selected > - You can only select the second party name only after selecting the state. - **Purchased By**: Enter the name of the entity or individual purchasing the stamp paper. This is a mandatory field and can be different from the first and second parties involved in the agreement. > **Info — NOTE** > > You can enter a maximum of 52 characters for this field. - **Stamp Duty Paid By**: Select the entity or individual who paid the stamp duty to procure the stamp papers. You must choose either the first party or the second party from the dropdown. ## Legend Configuration - **Legend Content**: Specify the text to be printed on the physical stamp papers. This content must include Leegality's Document ID, which is a unique identifier that links the stamp paper to its corresponding document in the system. > **Info — Auto-fill and Editing** > > - The system automatically populates this field with the first and second party names > - You can edit the legend content according to your requirements > - You can use alphanumeric characters and these special characters: **+ | - : () , _ . [] & / @ # ; ' –** > - Maximum allowed length is 255 characters and can span up to 8 lines > **Warning — Document ID** > > Do not remove or modify the Document ID from the legend content. This identifier is essential for tracking and linking the stamp paper to its document. ## Shipping Information Provide the delivery details for shipping the physical stamp papers to the correct recipient. - **POC Name**: Enter the full name of the point of contact who will receive the stamp paper delivery. - **POC Phone Number**: Provide the phone number of the point of contact for delivery coordination. - **POC Email Address**: Enter the email address of the point of contact. The procurement team will use this email to communicate updates about the stamp procurement process and delivery status. - **Address**: Enter the complete delivery address where the physical stamp papers should be shipped. 3. Once you have completed all the required fields, click on the **Create Series** button. The newly created stamp series will appear in your stamp series list and will be ready for purchasing stamp papers. --- URL: https://knowledge.leegality.com/document-execution/stamps/stamp-procurement-panel/edit-stamp-series # Edit Stamp Series Once you have created a stamp series in the **Stamp Procurement Panel**, you may need to update certain details such as shipping information, party names, or legend content. This guide explains how to edit an existing stamp series. > **Warning — Edit Access Required** > > Only users with **edit access** can create and edit stamp series in the **Stamp Procurement Panel**. ## Editable and Non-Editable Fields ### Editable Fields You can modify the following information in an existing stamp series: - **Series Name** - **First Party Name** - **Purchased By** - **Stamp Duty Paid By** - **Legend Content** - **Shipping Information** (POC Name, Phone, Email, Address) ### Non-Editable Fields The following fields **cannot be changed** once a stamp series has been created: - **State**: The state selection is permanent and cannot be modified - **Purpose/Article Code**: The legal classification cannot be changed - **Denomination**: The stamp duty value is fixed - **Second Party Name**: The name of the second party cannot be modified after series creation These restrictions ensure compliance with stamp duty regulations and prevent misuse of procured stamp papers. ## How to Edit a Stamp Series Follow these steps to make changes to an existing stamp series: 1. Log in to the **Stamp Procurement Panel** using your authorized email and OTP verification. 2. From the dashboard, locate the stamp series you want to edit in the inventory table. 3. Click the **View** button on the right side of the stamp series row. 4. A right-side panel will slide open, displaying the complete details of the selected stamp series. 5. Click the **Edit** button to enable editing mode for the stamp series. 6. The fields that can be modified will become editable, while locked fields remain grayed out. Update any of the editable fields as needed: > **Warning — Document ID Required** > > Do not remove or modify the Document ID in the legend content. This unique identifier is essential for linking stamp papers to their corresponding documents. 7. Once you have made all necessary modifications, click the **Save** button to apply the changes to the stamp series. - A confirmation message will appear indicating the series has been updated successfully. - The details panel will close, and you will return to the dashboard with the updated series information displayed. 8. If you decide not to save your modifications, click the **Cancel** button. A confirmation popup will appear with two options: - **Keep Editing**: Returns you to the editing panel without discarding changes, allowing you to continue making modifications. - **Discard Changes**: Closes the editing panel and returns you to the dashboard without saving any of your changes. > **Tip — Need Help?** > > If you have questions about editing stamp series or encounter issues, contact the Leegality support team at **support@leegality.com**. --- URL: https://knowledge.leegality.com/document-execution/stamps/stamp-procurement-panel/purchase-and-download-proforma # Purchase Stamp Papers and eSign Credits You can purchase stamp papers for multiple stamp series in one transaction and optionally add eSign credits. You can also generate and download a proforma invoice for approvals and accounting. ## How to Purchase Stamp Papers Follow the steps below to create a purchase: 1. Log in to the **Stamp Procurement Panel** dashboard. 2. Select checkboxes next to the stamp series you want to purchase. 3. Click the **Purchase** button from the top-right corner of the panel. A pop-up appears with your selected stamp series. 4. If there is an existing purchase, you must discard that purchase before creating a new one. Click **Discard and Create New.* 5. Enter the quantity for each stamp series. 6. Remove unwanted items using the *Delete** icon. 7. **Optional: You can also purchase eSign credits along with the stamp purchase.* 1. Click *+ Add Item** in the eSigns section. 2. Select eSign type from the dropdown. 3. Enter the quantity of each eSign type. 4. Repeat to add multiple eSign types. 8. Select a billing profile for the purchase. > **Info** > > Learn how to [create a billing profile in stamp procurement panel](billing-profile.md). 9. Review all items and quantities and click **Generate Proforma Invoice.* 10. The PDF invoice downloads automatically to your device. The proforma invoice includes Leegality's *virtual bank account number, which you can use to transfer funds directly to Leegality.* > **Info — NOTE** > > There is no limit to the number of stamp series you can purchase in a single transaction. You can select and purchase as many stamp series as needed for your organization. ## Deleting an Existing Purchase If you have an existing purchase that you want to discard, you can delete it from the header. The existing purchase can be seen in the header. Click *Delete** to discard the purchase. --- URL: https://knowledge.leegality.com/document-execution/stamps/stamp-procurement-panel/billing-profile # Billing Profile - Stamp Procurement Panel The Stamp Procurement Panel supports multiple billing profiles, allowing you to manage different billing addresses for your purchases. > **Info — NOTE** > > This feature works exactly as it does on the main dashboard. Any changes to billing profiles will reflect in your main account, and this feature is available for both user types of the procurement panel. ## Add New Billing Profile When you review your purchase items and click **Purchase**, a popup appears with billing profile options. If you don't have a billing profile configured, you can create one: 1. Click **Switch**. 2. Select **Add New** from the bottom of the panel. 3. Fill up the details with the following fields: - **Required Fields:** - **Name**: Your name or contact person's name - **Billing Address**: Complete billing address - **City**: City name - **Pincode**: Postal code - **Optional Fields:** - **Company Name**: Organization or company name - **State**: State or province - **Country**: Country name - **GST Number**: Goods and Services Tax identification number - **PAN**: Permanent Account Number > **Tip** > > Ensure all mandatory fields are filled correctly. The billing profile cannot be saved without Name, Billing Address, City, and Pincode. 4. Click **Create**. Your newly created billing profile will be saved and available for future purchases. ## View & Switch Billing Profiles If you have already configured billing profile(s), you'll see your current billing profile with the following options: - Click **Expand** to view the complete billing address details. ### Switch Billing Profile If you have multiple profiles configured, you can switch between them: 1. Click **Switch** to change the billing profile. A list of all configured billing profiles will appear. 2. Select the billing profile you want to use for this purchase. 3. You can also click **Create new billing address** from this list to add a new profile. > **Info — NOTE** > > Deletion of a billing profile can only be done from the main dashboard, not from the Stamp Procurement Panel. ## Edit Billing Profile You can edit any existing billing profile at any time: 1. Click **Edit** to modify the existing billing profile. 2. Make your desired changes to the address information. 3. Click **Update** to save the changes. 4. After choosing or configuring the billing profile, proceed by clicking **Generate Proforma Invoice**. 5. The PDF invoice downloads automatically to your device. The proforma invoice includes Leegality's **virtual account number**, which you can use to transfer funds directly to Leegality. --- URL: https://knowledge.leegality.com/document-execution/stamps/use-stamps # Use Stamps > **Tip — Prerequisites** > > Before using stamps, ensure you have stamp papers in your account: > 1. [**Create a Stamp Series**](https://knowledge.leegality.com/document-execution/stamps/stamp-series/create-a-stamp-series) > 2. [**Purchase Stamp Papers**](https://knowledge.leegality.com/document-execution/stamps/stamp-series/purchase-stamp-series) #### New Document Journey ### Use Stamps in New Document Journey Enable the **Use Stamps** toggle switch. #### Use Stamp Series 1. Enable the **Use Stamp Series** toggle switch. 2. **Single Stamp:** Use one stamp from a single stamp series. - Select the Stamp Series using the dropdown. One stamp from the selected series will be attached to the document. 3. **Multiple Stamps:** Use multiple stamps from multiple stamp series. - Select the Stamp Series using the dropdown. - Enter the number of stamps you want to attach from the selected stamp series. (**Note:** Minimum quantity: 1, Maximum quantity: 99) - Click **\+ Add More** to add stamps from another stamp series. Select the stamp series from the dropdown and specify the stamp quantity. (**Note:** Up to 15 stamp series can be added). >**Note:** If using multiple stamp series, all must be from the same state. Learn [**when to use Multiple Stamp Series**](https://knowledge.leegality.com/document-execution/stamps/multiple-stamp-series-vs-stamp-group). --- #### Use Revenue Stamp [Revenue Stamps](https://knowledge.leegality.com/document-execution/stamps/?type=revenuestamp) are a type of stamp series that are **state-agnostic** — they can be attached to documents regardless of the stamp-duty state, unlike regular stamp series which are tied to a specific state. 1. Enable the **Use Revenue Stamp** toggle switch. 2. Select the Revenue stamp series from the dropdown. 3. Enter the number of revenue stamps. One revenue stamp is worth one rupee. >**Note:** Revenue stamps can be used alongside any state stamp series, stamp group, or upload stamp. --- #### Use Stamp Group A Stamp Group is a collection of multiple stamp series of different denominations. It is used for value-based stamping, where stamps of different values are selected to match (approximately) a specific total amount. > **Tip — Prerequisite** > > You must have created a stamp group. Learn [**how to create a stamp group**](https://knowledge.leegality.com/document-execution/stamps/stamp-group/stamp-groups#create-a-stamp-group). 1. Enable the **Use Stamp Group** toggle switch. 2. Select a stamp group from the dropdown. 3. Enter the stamp amount. - Based on the entered amount, Leegality automatically calculates the number of stamps required and attaches them to the document. The system selects stamps from your chosen group to ensure the total stamp value matches (approximately) the required amount. --- ### Upload Stamp in New Document Journey If you have a physical stamp paper (or PDF), you can attach it to the document. 1. Enable the **Upload Stamp** toggle switch. 2. Provide the following information: - **State** - **Denomination** - **First Party's Name** - **Second Party's Name** - **Stamp Serial Number** 3. Upload the stamp paper’s PDF file and click **Save**. > **Info — Best practices for self-uploaded stamp papers** > > - Purchase the stamp paper from an authorized vendor. > - Ensure the stamp paper is valid and not expired (Advised to use in 6 months from the date of purchase) > - Use the correct stamp duty value as per your state's requirements. > - Ensure clear scanning with visible stamp paper details (serial number, value, date). > - Properly deface the physical stamp paper after scanning to prevent reuse. #### Workflow Creation ### Use Stamps in a Workflow Enable the **Use Stamps** toggle switch. #### Use Stamp Series 1. Enable the **Use Stamp Series** toggle switch. 2. **Single Stamp:** Use one stamp from a single stamp series. - The workflow creator has two options: 1. Select a stamp series. A stamp from that series will be automatically affixed to the document when the workflow runs. (**Note:** The workflow runner cannot remove or change the selected stamp series.) 2. Leave the stamp series selection blank, allowing the workflow runner to choose a stamp series when running the workflow. (**Note:** The workflow runner must select a stamp series.) 3. **Multiple Stamps:** Use multiple stamps from multiple stamp series. - The workflow creator has two options: 1. Select the stamp series and specify the number of stamps to be attached from each series. These will be automatically affixed to the document when the workflow runs. (**Note:** The workflow runner cannot remove or modify the selected series.) >**Note:** Stamp minimum quantity: 1, maximum quantity: 99 2. Leave placeholders (Stamp Series and Number of Stamps) blank. The workflow runner can choose the stamp series and number of stamps when running the workflow. - **Example:** If the workflow has placeholders for two stamp series: - The workflow runner must select the stamp series and specify the number of stamps. - They can use one or both stamp series (using both is not mandatory). - If using multiple stamp series, all must be from the same state. --- #### Use Revenue Stamp [Revenue Stamps](https://knowledge.leegality.com/document-execution/stamps/?type=revenuestamp) are a type of stamp series that are **state-agnostic** — they can be attached to documents regardless of the stamp-duty state, unlike regular stamp series which are tied to a specific state. 1. Enable the **Use Revenue Stamp** toggle switch. 2. The workflow creator has two options: - Select the stamp series and specify the number of stamps to be attached. These will be automatically affixed to the document when the workflow runs. (Note: The workflow runner cannot remove or modify the selected series.) - Select the Revenue Stamp Series using the dropdown and leave the Number of stamps blank. The workflow runner can choose number of stamps when running the workflow. - Leave placeholders (Revenue Stamp Series and Number of Stamps) blank. The workflow runner can choose the stamp series and number of stamps when running the workflow. >**Note:** Revenue stamps can be used alongside any state stamp series, stamp group, or upload stamp. --- #### Use Stamp Group > **Tip — Prerequisite** > > You must have created a stamp group. Learn [**how to create a stamp group**](https://knowledge.leegality.com/document-execution/stamps/stamp-group/stamp-groups#create-a-stamp-group). 1. Enable the **Use Stamp Group** toggle switch. - The workflow creator has three options: 1. **Leave placeholders (Stamp Group and Stamp Amount) blank**, allowing the workflow runner to select the stamp group and enter the stamp amount when running the workflow. 2. **Fix a stamp group but leave the stamp amount blank**, allowing the workflow runner to specify the stamp amount. The system will automatically affix the required stamps. 3. **Fix both the stamp group and stamp amount**, preventing the workflow runner from modifying them while running the workflow. --- ### Upload Stamp in a Workflow 1. Enable the **Upload Stamp** toggle switch. - The workflow creator has the following options: 1. Leave all stamp details blank, requiring the workflow runner to enter all details and upload the stamp paper. 2. Pre-fill the **State, Denomination, and First & Second Party’s Name** during workflow creation. The workflow runner will only need to provide the **Stamp Serial Number** and upload the stamp paper. > **Info — Best practices for self-uploaded stamp papers** > > - Purchase the stamp paper from an authorized vendor. > - Ensure the stamp paper is valid and not expired (Advised to use in 6 months from the date of purchase) > - Use the correct stamp duty value as per your state's requirements. > - Ensure clear scanning with visible stamp paper details (serial number, value, date). > - Properly deface the physical stamp paper after scanning to prevent reuse. --- URL: https://knowledge.leegality.com/document-execution/stamps/multiple-stamp-series-vs-stamp-group # Multiple Stamp Series Multiple Stamp Series lets you explicitly select up to **15 stamp series** and specify how many stamps to attach from each. This is different from a Stamp Group, where the system automatically selects a combination of denominations to meet a variable stamp duty amount. - **Multiple Stamp Series:** A user can select the stamp series from which they want to attach the stamp paper to the document. - **Stamp Group:** A user can only add the stamp amount that needs to be attached; they cannot choose from which stamp series the papers are coming from. > **Tip — Prerequisite** > > Before using Multiple Stamp Series, ensure you have stamp papers in your account: > 1. [Create a Stamp Series](https://knowledge.leegality.com/document-execution/stamps/stamp-series/create-a-stamp-series) > 2. [Purchase Stamp Papers](https://knowledge.leegality.com/document-execution/stamps/stamp-series/purchase-stamp-series) ## When to Use Multiple Stamp Series - The stamp duty amount is **fixed and known** before the document is sent. - You need stamps from **different series** — for example, series with different article codes meant for different types of agreements. - You want to **control exactly which series** a stamp is drawn from for a specific document. ## Enabling Multiple Stamp Series Multiple Stamp Series can be configured while creating a **New Document** or while configuring a **Workflow**. In both cases, go to the stamp configuration step in the respective flow (see [Use Stamps](https://knowledge.leegality.com/document-execution/stamps/use-stamps) for detailed steps) and follow the steps below. 1. Enable the **Use Stamps** toggle. 2. Enable the **Use Stamp Series** toggle and select **Multiple Stamps**. 3. Select a stamp series from the dropdown and enter the number of stamps to attach (min: 1, max: 99 per series). 4. Click **+ Add More** to add another series. Repeat as needed. 5. All selected series must be from the **same state**. > **Info — Note** > > In **Workflow Configuration**: > - The creator can either pre-select the series and lock them, or leave placeholders for the workflow runner to fill in. > - If placeholders are left blank, the workflow runner **must** select a series before running — it is mandatory. > - The runner is not required to use all added series; using one or more is allowed. --- ## Same Denomination in a Stamp Group When two series share the same denomination but have different article codes, adding them both to a Stamp Group is not recommended. Since the Stamp Group algorithm selects stamps based on denomination value alone, it cannot distinguish between the two series — making the selection unpredictable. **What to do instead:** If you need stamps from two series that share the same denomination (for example, two ₹500 series with different article codes), use **Multiple Stamp Series** instead. This lets you explicitly select each series and specify the quantity, giving you full control over which series is used for each document. > **Info — Note** > > Adding two or more series with the same denomination to a Stamp Group is not recommended, as the system cannot determine which series to draw from. ## Use Case Suppose a document requires multiple stamp papers from different stamp series, such as 100 INR stamp paper for an Affidavit, 100 INR for a Deed of Mortgage, and 100 INR for a Power of Attorney. In that case, you can use the Multiple Stamp Series Selection feature. Here's how it works: When sending the document, you can select the "Multiple Stamps" option. This allows you to affix one stamp from each of the three series. Simply: 1. Choose the Affidavit series and specify 1 stamp. 2. Choose the Deed of Mortgage series and specify 1 stamp. 3. Choose the Power of Attorney series and specify 1 stamp. With this feature, you can easily manage and allocate the required number of stamp papers for each specific purpose within a single document workflow, ensuring all necessary stamps are appropriately affixed. --- URL: https://knowledge.leegality.com/document-execution/template/pdf-editor/create-a-pdf-template # Create a PDF Template This guide shows you how to create a PDF template in three steps. > **Info — Note** > > - Only admins can create and edit templates. > - Users within the organisation can use these templates. ## 1. Upload PDF 1. In the **Dashboard**, click on the **Template** on the left. 2. Click **+ Create** in the top right corner. 3. Give a suitable **Template Name**. (**Note:** The Template Name is only visible on the dashboard and is not seen by the signers when using this template.) 4. Select **PDF Editor** as the template type and click **Proceed**. 5. Upload PDF files and click **Proceed**. This will take you to the template engine. > **Info — Note** > > You can upload up to 10 PDF files in one template and the maximum upload size of collective PDF files is 30 MB (15 MB recommended for optimal performance). ## 2. Add Fields to a PDF Template 1. In the **+ Add Fields** section on right, you can see the various types of dynamics fields that you can add. 2. To add a field, click on the type of field you want to add, then click on the document where you want to place the field. There are six types of fields that you can add and configure to the PDF. Let’s have a look at them one by one. - Textbox - Dropdown - Radio Button - Checkbox - Date - Image Attachment ## 3. Preview PDF Template 1. Click **Preview** on the top right. 2. In the middle, you will see the PDF template consisting of all the fields you added. 3. In the fields panel on the right, input the field values and then click **Filled Document Preview** to see a preview of the filled PDF. Once satisfied with the preview and all desired fields are added, click on the **Save and Finish** button on the top right. --- URL: https://knowledge.leegality.com/document-execution/template/pdf-editor/fields # Field Properties and Options The PDF Template Engine allows you to add dynamic fields on the PDF templates. Each field has properties that determine its appearance and behaviour. This article outlines the properties of each field type to help you configure your templates efficiently. ## Types of Fields - Textbox - Dropdown - Radio Button - Checkbox - Date Field - Image Attachment ### Common Properties Several basic properties are shared across multiple field types: - **Label:** The text that appears as the label for the field. - **Mandatory Field:** Indicates whether the field is mandatorily required either by the sender or an invitee (to be filled in the signing/review journey). - **Invisible Border:** Specifies whether the field border should be invisible. - **Location on the PDF (in px):** Determines the exact position of the field on the PDF document. - **Px from left:** Distance in pixels from the left side of the page. - **Px from top:** Distance in pixels from the top of the page. ### Field-specific Properties #### Textbox - **Allow only Numbers:** Specifies whether the textbox should only accept numeric input. - **Character Limit:** Defines the maximum and/or minimum number of characters that can be entered. - **Boxed Field:** Specifies if the text box should display a separate box for each character, similar to physical forms. - **Text Formatting:** Font Size, Family, and Style (e.g., bold, italic). #### Dropdown - **Dropdown Values:** List of options available in the dropdown. - **Default Value:** The value that is selected by default. #### Radio Button - **Value (single-selection):** List of available options. #### Checkbox - **Value (multi-selection):** List of available options. #### Date - **Date format:** The format in which the date should be displayed. #### Image - **Max upload size:** The maximum size of the image to be uploaded. (Note: Maximum size cannot exceed 200KB) - **Width (Px):** Width of the image frame in px - **Height (Px):** Height of the image frame in px ## Copy Field Copy Field allows users to reuse the field they have already created. By copying a field all the properties of the original field will also be copied. > **Info — Note** > > Unlike Duplicate Fields, these are not interconnected and need to be filled individually every time. ### To Copy a Field 1. Go to **List of Fields** in the right panel. 2. Click on the Copy icon ![Copy Field](https://knowledge.leegality.com/img/copy.png) and select **Copy**. 3. The Duplicate Field will be attached to the cursor tip, click on the desired place in the document to drop it. ## Duplicate Field Duplicate Fields allow users to enter information once, and then automatically replicate that input across multiple instances of a specific field that requires the same information. > **Info — Example** > > For instance, if a user needs to input their address multiple times in a bank account creation form, Duplicate Fields enable them to enter the address once, and the system will automatically populate the same address in all linked or duplicated address fields. ### To Duplicate a Field 1. Go to **List of Fields** in the right panel. 2. Click on the Copy icon and select **Duplicate**. 3. The Duplicate Field will be attached to the cursor tip, click on the desired place in the document to drop it. > **Info — note** > > Duplicate fields only work with Textbox and Date fields as of now. ## Cut Field To Cut a Field: 1. Go to **List of Fields** in the right panel. 2. Click on the Copy icon ![Copy Field](https://knowledge.leegality.com/img/copy.png) and select **Cut**. 3. The field will be attached to the cursor tip, click on the desired place in the document to drop it. ## Delete a Field To delete a field, 1. Find the field you want to delete. You can find the field directly in the PDF or from the **List of Fields** on the right. 2. Click on the field and then in the right panel, click on the **Delete** icon ![Delete Field](https://knowledge.leegality.com/img/delete.png). > **Info — Note** > > Deleting a field is an irreversible action. ## Download Form Fields The Download Form Fields option provides a JSON of the fields used in a template. You can use this JSON to pass field values in a POST API call. ### To Download Form Fields 1. Click on **Tools** on the top menu and select **Templates** on the left. 2. Find the template whose fields you want to download by searching the template name or template ID. 3. Click on the **three dots (⋮)** on the right and select the **Download Form Fields**. This will download a JSON file containing all template fields, which you can use to make an eSign request. To create an eSign request: 1. Make a POST request to: `https://sandbox.leegality.com/api/v2.1/sign/request` 2. Include the fields JSON in the request body under file > fields. --- URL: https://knowledge.leegality.com/document-execution/template/pdf-editor/replace-base-pdf # Replace Base PDF The Replace Base PDF template feature allows you to replace the existing PDF of the template with a new one while keeping the fields and their properties saved. When you’re working on a template sometimes the PDF content gets updated. So instead of creating a new template from scratch and adding fields to it, you can replace the base pdf on which the fields were dropped. This will keep the fields and their settings intact so you can use them in the new PDF. ## How to Replace Base PDF 1. In the **Dashboard**, click on the **Template** on the left. 2. Find the PDF template whose base PDF you want to change. 3. Click the **Three Dots (⋮)**, then choose **Replace Base PDF**. 4. In the pop-up, click to upload the new PDF. That’s it! Your original PDF will be replaced with your new PDF. Your fields will remain in the same positions, with the same Properties settings. ## Missing Fields When replacing the original PDF with a new version that has fewer pages, some fields may no longer be included. > **Info — Example** > > If a 10-page PDF is replaced by a 9-page PDF, any fields on the 10th page will be missing. > These missing fields retain all their original properties and can be found in the right panel under "List of Fields." To reuse these fields, click on the field and add it to the desired location in the new PDF document. --- URL: https://knowledge.leegality.com/document-execution/template/pdf-editor/download-and-reuse # Download and Reuse a PDF Template You can download a PDF template with all its fields intact and use it to create a new template. This is useful when you want to reuse an existing template — for example, to move a template from your sandbox environment to production. When a PDF template is downloaded and re-uploaded, all fields and their configurations are preserved. ## Download a PDF Template 1. Open the PDF template from the **Templates** section. 2. Click the **Generate PDF** button on the top bar. The PDF will be downloaded exactly as it appears on the screen, with all fields embedded. ## Reuse the Downloaded PDF To create a new template from the downloaded PDF: 1. Go to **Templates** and click **+ Create**. 2. Enter a **Template Name** and select **PDF Editor**, then click **Proceed**. 3. Upload the downloaded PDF and click **Proceed**. All fields from the original template will be intact and ready to use. > **Tip — Copying a Template from Sandbox to Production** > > Download the template from your sandbox environment using the steps above, then upload it in your production environment to create an identical template — no need to rebuild fields from scratch. --- URL: https://knowledge.leegality.com/document-execution/template/html-template/create-a-new-pdf # Create a New HTML Template HTML Templates allow you to create documents from scratch using an HTML-based editor. This provides flexibility and customization, letting you design documents that fit your specific needs without being restricted by a predefined layout. This guide walks you through creating a new HTML template from scratch. > **Info — Note** > > * Template creation and modification are restricted to Administrators (Organization accounts) or the Account Owner (Individual accounts). > * Once created, templates are available for use by all users within the organization. ## How to Create a New HTML Template 1. Log in to your Leegality account. 2. Navigate to the **Templates** section from the main dashboard. 3. Click **+ Create** to open a popup window. 4. Enter the template name in the field provided. 5. Select **HTML Template** as the template type. 6. Click **Proceed**. The HTML Template editor will open, allowing you to start building your document. ## Next Steps Once your template is created, you can begin formatting and editing your document using the comprehensive set of tools available in the HTML editor. **[Learn about Formatting and Editing →](https://knowledge.leegality.com/document-execution/template/html-template/formatting-and-editing)** --- URL: https://knowledge.leegality.com/document-execution/template/html-template/formatting-and-editing # Formatting and Editing The HTML Template editor provides a comprehensive set of tools to help you create professional documents. ## Available Tools Use these tools to add content, format your document, and create interactive elements: ### Form Elements - **[Checkbox](https://knowledge.leegality.com/document-execution/template/html-template/formatting-and-editing/checkbox):** Add checkboxes for multiple-choice selections - **[Radio Button](https://knowledge.leegality.com/document-execution/template/html-template/formatting-and-editing/radio-button):** Add radio buttons for single-choice selections - **[Small Textbox](https://knowledge.leegality.com/document-execution/template/html-template/formatting-and-editing/small-textbox):** Insert short, single-line text input fields - **[Large Textbox](https://knowledge.leegality.com/document-execution/template/html-template/formatting-and-editing/large-textbox):** Insert longer, multi-line text input fields - **[Dropdown](https://knowledge.leegality.com/document-execution/template/html-template/formatting-and-editing/dropdown):** Create dropdown menus with multiple options - **[Upload Image](https://knowledge.leegality.com/document-execution/template/html-template/formatting-and-editing/images-upload):** Allow users to upload images ### Text Formatting - **[Fonts and Text Formatting](https://knowledge.leegality.com/document-execution/template/html-template/formatting-and-editing/fonts):** Change fonts, sizes, colors, apply bold/italic/underline, copy formatting, and align text - **[Lists](https://knowledge.leegality.com/document-execution/template/html-template/formatting-and-editing/lists):** Create numbered and bulleted lists with sublists ### Styling and Layout - **[Margins and Borders](https://knowledge.leegality.com/document-execution/template/html-template/formatting-and-editing/margins-and-borders):** Control spacing and borders for elements - **[Insert Image](https://knowledge.leegality.com/document-execution/template/html-template/formatting-and-editing/images-static):** Add images directly to your template - **[Horizontal Lines](https://knowledge.leegality.com/document-execution/template/html-template/formatting-and-editing/horizontal-lines):** Add dividers between sections - **[Hyperlinks](https://knowledge.leegality.com/document-execution/template/html-template/formatting-and-editing/hyperlinks):** Add clickable links to your document ### Content Elements - **[Special Characters](https://knowledge.leegality.com/document-execution/template/html-template/formatting-and-editing/special-characters):** Add symbols and special characters - **[Tables](https://knowledge.leegality.com/document-execution/template/html-template/formatting-and-editing/tables):** Create structured tables for data - **[Page Breaks](https://knowledge.leegality.com/document-execution/template/html-template/formatting-and-editing/page-breaks):** Control page breaks for printing ### Document Structure - **[Header and Footer](https://knowledge.leegality.com/document-execution/template/html-template/formatting-and-editing/header-and-footer):** Add headers and footers to your document - **[Source HTML](https://knowledge.leegality.com/document-execution/template/html-template/formatting-and-editing/source-html):** Edit the raw HTML code for advanced customization > **Tip** > > Changes are auto-saved as you work, so you can safely close the editor and return later to continue editing. --- URL: https://knowledge.leegality.com/document-execution/template/html-template/formatting-and-editing/checkbox # Checkboxes Checkboxes allow signers to select one or more options from a list. Use checkboxes when you need "select all that apply" responses, such as consent forms, service selections, or document acknowledgments. > **Info — When to Use Checkboxes** > > Use checkboxes for multiple-choice selections where signers can pick more than one option. If signers should only pick one option, use **Radio Buttons** instead. ## Create & add checkboxes 1. In the HTML Template editor, place your cursor where you want the checkbox to appear. 2. On the toolbar, click the **Checkbox** icon. 3. The configuration popup will open with two tabs: - **Basic tab:** Configure the group name and value for the checkbox - **Select Group:** Choose an existing group or create a new one - **Group Name:** Name that organises related checkboxes together - **Value:** Unique identifier for this specific checkbox option - **More Options tab:** Control checkbox behavior - **Keep Selected by Default:** Pre-select this checkbox for signers - **Make Field Mandatory:** Require signers to interact with this checkbox 4. Configure your checkbox settings (explained in detail in the sections below). 5. Click **OK**. > **Tip — Label Your Checkboxes** > > Always add a text label next to each checkbox in the editor so signers know what they're selecting. Use clear, concise labels that describe the action or choice. ## Organise checkboxes into groups Grouping helps you organise related checkboxes together. When you create a group, all checkboxes in that group will appear together in the preview and final document. **Why use groups?** Think of each group as a single question with multiple checkbox options. For example: - **Question 1:** "Select the software tools you are proficient in:" → Create a group called `software_skills` - Checkboxes: Excel, PowerPoint, Word, Photoshop - **Question 2:** "Select your preferred communication channels:" → Create a group called `communication_preferences` - Checkboxes: Email, Phone, WhatsApp, Slack When you preview the document, all checkboxes from the same group will appear together under their respective question, making it easy for signers to understand which options belong to which question. > **Tip — Best Practice** > > Create a new group for each question that has multiple checkbox options. This keeps your form organised and makes it easier for signers to fill out. ### Add to a new group When creating checkboxes for a new question: 1. Open the Checkbox configuration popup. 2. In the **Basic** tab, ensure **New group** is selected in the **Select Group** dropdown. 3. In the **Group Name** field, enter a unique identifier (e.g., `software_skills`, `contact_preferences`). 4. In the **Value** field, enter a unique identifier for this specific checkbox (e.g., `excel`, `powerpoint`). 5. Click **OK**. > **Info — About the Value Field** > > The **Value** field is for your internal tracking and database purposes. It will not be visible to signers on the final PDF. Use clear, descriptive values that help you identify responses later. **Example:** For the question "Select the software tools you are proficient in:": - Group Name: `software_skills` - Values: `excel`, `powerpoint`, `word`, `photoshop` ### Add to an existing group When adding more checkbox options to the same question: 1. Open the Checkbox configuration popup. 2. In the **Basic** tab, select your existing group from the **Select Group** dropdown. 3. The **Group Name** field will auto-populate with the selected group name. 4. In the **Value** field, enter a new unique identifier for this checkbox option. 5. Click **OK**. > **Info — Note** > > You can edit the auto-populated group name to create a new group instead. The new name will be added to the **Select Group** dropdown for future use. **Example:** For the question "Select your preferred communication channels:": - Group Name: `communication_preferences` - Values: `email`, `phone`, `whatsapp`, `slack` ## Customise checkbox behavior After creating your checkboxes, you can control how they behave when signers open the document. Use the **More Options** tab in the checkbox configuration popup to access these settings. ### Set a default selection To pre-select a checkbox for signers: 1. Open the Checkbox configuration popup (or right-click an existing checkbox and select **Checkbox properties**). 2. Go to the **More Options** tab. 3. Check the **Keep Selected by Default** box. 4. Click **OK**. **When to use:** - Pre-selecting common or recommended options - Setting default selections in forms - Highlighting popular choices > **Info — Note** > > Unlike radio buttons, you can set multiple checkboxes in the same group to be selected by default. ### Require a selection (Mandatory) To make a checkbox mandatory: 1. Open the Checkbox configuration popup (or right-click an existing checkbox and select **Checkbox properties**). 2. Go to the **More Options** tab. 3. Check the **Make Field Mandatory** box. 4. Click **OK**. Signers will be unable to complete the document until they interact with this checkbox. **When to use:** - Required consent forms - Mandatory acknowledgments (e.g., "I have read the terms and conditions") - Critical selections that cannot be skipped ## Manage & edit checkboxes After placing checkboxes in your template, you can modify, move, or duplicate them as needed. ### Change checkbox properties To edit an existing checkbox: 1. **Right-click** on the checkbox inside the editor. 2. Select **Checkbox properties** from the menu. 3. Modify the group name, value, default state, or mandatory settings in the popup. 4. Click **OK** to save your changes. > **Info — Note** > > All the original settings (group, value, default state, and mandatory settings) will be visible and editable when you access Checkbox properties. ### Move or duplicate a checkbox To move or copy a checkbox to a different location: 1. Select the checkbox you want to perform the action. 2. **Right-click** the checkbox. 3. Select **Cut** (to move) or **Copy** (to duplicate). 4. Move your cursor to the new location. 5. **Right-click** and select **Paste**. ## Preview your checkboxes 1. Click **Preview** to view how your template will appear to signers. 2. Test clicking the checkboxes to verify grouping, default selections, and mandatory settings work as expected. 3. Exit preview mode and make any necessary adjustments. > **Tip** > > Always preview your template after creating or modifying checkboxes to ensure they appear and function as expected. --- URL: https://knowledge.leegality.com/document-execution/template/html-template/formatting-and-editing/radio-button # Radio Buttons Radio buttons allow signers to select exactly one option from a group of choices. Use radio buttons when you need mutually exclusive selections, such as payment method, gender selection, service tier, or Yes/No questions. > **Info — When to Use Radio Buttons** > > Use radio buttons when signers must select exactly one option from a group (e.g., "Yes" or "No", not both). If signers can pick multiple options, use **[Checkboxes](https://knowledge.leegality.com/document-execution/template/html-template/formatting-and-editing/checkbox)** instead. ## Create & add radio buttons Follow these steps to insert a radio button into your template: 1. In the HTML Template editor, place your cursor where you want the radio button to appear. 2. On the toolbar, click the **Radio Button** icon. 3. The configuration popup will open with two tabs: - **Basic tab:** Configure the group name and value for the radio button - **Select Group:** Choose an existing group or create a new one - **Group Name:** Name that organises related radio buttons together - **Value:** Unique identifier for this specific radio button option - **More Options tab:** Control radio button behavior - **Keep Selected by Default:** Pre-select this radio button for signers - **Make Field Mandatory:** Require signers to select an option from this group 4. Configure your radio button settings (explained in detail in the sections below). 5. Click **OK**. 6. Repeat these steps to add additional options to the same group. > **Tip — Label Your Radio Buttons** > > Always add a text label next to each radio button in the editor so signers know what they're selecting. Use clear, concise labels that avoid technical jargon. > **Info — Display All Options** > > Display all available radio button options at once so signers can see all choices before selecting. This helps them make informed decisions. ## Organise radio buttons into groups All radio buttons in the same group are mutually exclusive—selecting one automatically deselects the others. This ensures signers can only pick one option from the set. > **Info — How Grouping Works** > > Grouping works the same way as [Checkboxes](https://knowledge.leegality.com/document-execution/template/html-template/formatting-and-editing/checkbox#organise-checkboxes-into-groups), but with one key difference: radio buttons allow only **one selection per group**, while checkboxes allow multiple selections. > **Tip — Best Practice** > > Use radio buttons for 2-7 options. If you have more than 7 options, consider using a dropdown field instead for better user experience. **Example groups:** - `payment_method` → Credit Card, Debit Card, Net Banking, UPI - `service_tier` → Basic, Premium, Enterprise ### Add to a new group When creating radio buttons for a new question: 1. Open the Radio Button configuration popup. 2. In the **Basic** tab, ensure **New group** is selected in the **Select Group** dropdown. 3. In the **Group Name** field, enter a unique identifier (e.g., `payment_method`, `service_tier`). 4. In the **Value** field, enter a unique identifier for this specific radio button (e.g., `credit_card`, `debit_card`). 5. Click **OK**. 6. Repeat steps 1-5 to add more options to the same group. > **Info — About the Value Field** > > The **Value** field is for your internal tracking and database purposes. It will not be visible to signers on the final PDF. Use clear, descriptive values that help you identify responses later. **Example:** For the question "Select your preferred payment method:": - Group Name: `payment_method` - Values: `credit_card`, `debit_card`, `net_banking`, `upi` ### Add to an existing group When adding more radio button options to the same question: 1. Open the Radio Button configuration popup. 2. In the **Basic** tab, select your existing group from the **Select Group** dropdown. 3. The **Group Name** field will auto-populate with the selected group name. 4. In the **Value** field, enter a new unique identifier for this radio button option. 5. Click **OK**. > **Info — Note** > > You can edit the auto-populated group name to create a new group instead. The new name will be added to the **Select Group** dropdown for future use. **Example:** For the question "Select your service tier:": - Group Name: `service_tier` - Values: `basic`, `premium`, `enterprise` ## Customise radio button behavior After creating your radio buttons, you can control how they behave when signers open the document. Use the **More Options** tab in the radio button configuration popup to access these settings. ### Set a default selection To pre-select a radio button for signers: 1. Open the Radio Button configuration popup (or right-click an existing radio button and select **Radio Button properties**). 2. Go to the **More Options** tab. 3. Check the **Keep Selected by Default** box. 4. Click **OK**. **When to use:** - Pre-selecting the most common choice - Setting recommended selections - Guiding users toward a default option > **Warning — Important** > > Only **one radio button per group** can be set as default. If you enable "Keep Selected by Default" for one option and then enable it for another option in the same group, the first option will be automatically deselected. ### Require a selection (Mandatory) To make a radio button group mandatory: 1. Open the Radio Button configuration popup for any option in the group (or right-click an existing radio button and select **Radio Button properties**). 2. Go to the **More Options** tab. 3. Check the **Make Field Mandatory** box. 4. Click **OK**. Signers will be unable to complete the document until they select an option from this group. **When to use:** - Required selections - Mandatory choices (e.g., agreeing to terms) - Critical decisions that cannot be skipped ## Manage & edit radio buttons After placing radio buttons in your template, you can modify, move, or duplicate them as needed. ### Change radio button properties To edit an existing radio button: 1. **Right-click** on the radio button inside the editor. 2. Select **Radio Button properties** from the menu. 3. Modify the group name, value, default state, or mandatory settings in the popup. 4. Click **OK** to save your changes. > **Info — Note** > > All the original settings (group, value, default state, and mandatory settings) will be visible and editable when you access Radio Button properties. ### Move or duplicate a radio button To move or copy a radio button to a different location: 1. Select the radio button you want to perform the action. 2. **Right-click** the radio button. 3. Select **Cut** (to move) or **Copy** (to duplicate). 4. Move your cursor to the new location. 5. **Right-click** and select **Paste**. ## Preview your radio buttons 1. Locate the **Preview** button in the bottom-left corner of the editor. 2. Click **Preview** to view how your template will appear to signers. 3. Test selecting different radio buttons to verify mutual exclusivity works correctly (selecting one option deselects others in the same group). 4. Verify that default selections and mandatory settings work as expected. 5. Exit preview mode and make any necessary adjustments. > **Tip** > > Before finalizing your template, preview it to ensure radio buttons appear and function correctly. --- URL: https://knowledge.leegality.com/document-execution/template/html-template/formatting-and-editing/small-textbox # Small Textbox Small textboxes allow signers to enter short, single-line text input in your templates. Use small textboxes to collect information like names, email addresses, phone numbers, PAN numbers, or any other brief text-based data. > **Info — When to Use Small Textbox** > > Use small textboxes for short inputs with a maximum of 1028 characters. If you need to collect longer, multi-line text, use **[Large Textbox](https://knowledge.leegality.com/document-execution/template/html-template/formatting-and-editing/large-textbox)** instead. ## Create & add small textbox Follow these steps to insert a small textbox into your template: 1. In the HTML Template editor, place your cursor where you want the textbox to appear. 2. On the toolbar, click **Small Textbox**. 3. The configuration popup will open with two tabs: - **Basic tab:** Configure the group name, field name, and placeholder text - **Select Group:** Choose an existing group or create a new one - **Group Name:** Name for auto-filling the same information across multiple textboxes - **Name:** Unique identifier for this textbox (not visible to signers) - **Placeholder:** Helper text that appears inside the textbox - **More Options tab:** Control textbox behavior and appearance - **Maximum Character Limit:** Restrict the number of characters (up to 1028) - **Type:** Choose Text or Number input - **Mandatory Field:** Require signers to fill this field - **Boxed Field:** Display characters in individual boxes 4. Configure your textbox settings (explained in detail in the sections below). 5. Click **OK**. > **Tip — Use Helpful Placeholders** > > Provide clear placeholder text with examples or formatting guidance to help signers understand what to enter. For example: "Enter your full name", "name@example.com", or "+91 98765 43210". ## Understanding groups and auto-fill Grouping textboxes allows you to auto-fill the same information across multiple fields in your document. When textboxes are in the same group, filling one field automatically fills all other fields in that group. **Why use groups?** Use groups when you need the same information to appear in multiple places in your document. For example: - Name appearing in the header and multiple times in the document body - Email address needed in different sections - Phone number required in multiple locations **How it works:** When a signer fills in one textbox in a group, all other textboxes in that same group are automatically populated with the same value. This saves time and ensures consistency. > **Warning — Important** > > All textboxes in the same group should have the same **Type** (Text or Number). If you mix types: > - Filling a **Text** field won't populate **Number** fields (Number type only accepts numeric input) > - Filling a **Number** field WILL populate **Text** fields (Text type accepts both text and numbers) > > **Best practice:** Always use the same type for all fields in a group to avoid confusion and ensure proper auto-fill behavior. > **Tip — Use Grouping Wisely** > > Only group fields that should contain the exact same information. Don't group different fields together just for organisation purposes. Grouping is specifically for auto-filling repeated information. ## Configure small textbox options Use the **More Options** tab to customise the behavior and appearance of your small textbox. ### Set character limit Control the maximum number of characters allowed in the textbox: 1. Open the textbox configuration popup (or right-click an existing textbox and select **Text Field Properties**). 2. Go to the **More Options** tab. 3. In the **Maximum Character Limit** field, enter your desired limit (up to 1028). 4. Click **OK**. > **Warning — Character Limit** > > The Small Textbox has a hard limit of 1028 characters. If you need to collect more text, use a **[Large Textbox](https://knowledge.leegality.com/document-execution/template/html-template/formatting-and-editing/large-textbox)** instead. > **Tip** > > Set appropriate character limits based on expected input length to prevent overly long entries and improve data quality. ## Choose input type Restrict what type of data signers can enter: 1. Open the textbox configuration popup (or right-click an existing textbox and select **Text Field Properties**). 2. Go to the **More Options** tab. 3. In the **Type** dropdown, select: - **Text:** Allows letters, numbers, and special characters (default) - **Number:** Allows only numeric input 4. Click **OK**. **When to use Number type:** - Phone numbers - Age or quantity fields - Numeric codes - Any field requiring numbers only > **Tip** > > Using the Number type prevents invalid input and improves data quality by ensuring signers can only enter numbers. ## Enable boxed field Display each character in its own separate box: 1. Open the textbox configuration popup (or right-click an existing textbox and select **Text Field Properties**). 2. Go to the **More Options** tab. 3. Check the **Boxed Field** checkbox. 4. Click **OK**. **When to use Boxed Field:** - PAN numbers - Account numbers - Reference codes - Serial numbers - Any input where individual characters need emphasis ## Make field mandatory Require signers to fill in the textbox: 1. Open the textbox configuration popup (or right-click an existing textbox and select **Text Field Properties**). 2. Go to the **More Options** tab. 3. Check the **Mandatory Field** checkbox. 4. Click **OK**. Signers will be unable to complete the document until they fill in this field. **When to use:** - Required personal information - Mandatory contact details - Essential identifiers > **Tip** > > Only mark fields as mandatory when they are truly required. Too many mandatory fields can frustrate signers. ## Manage & edit textboxes After placing textboxes in your template, you can modify, move, or duplicate them as needed. ### Change textbox properties To edit an existing textbox: 1. **Right-click** on the textbox inside the editor. 2. Select **Text Field Properties** from the menu. 3. Modify any settings (group, name, placeholder, character limit, type, or field options). 4. Click **OK** to save your changes. > **Info — Note** > > All the original settings (group, name, placeholder, character limit, type, mandatory field, and boxed field) will be visible and editable when you access Text Field Properties. ### Move or duplicate a textbox To move or copy a textbox to a different location: 1. Select the textbox you want to perform the action. 2. **Right-click** the textbox. 3. Select **Cut** (to move) or **Copy** (to duplicate). 4. Move your cursor to the new location. 5. **Right-click** and select **Paste**. ## Preview your textboxes 1. Locate the **Preview** button in the bottom-left corner of the editor. 2. Click **Preview** to view how your template will appear to signers. 3. Test the textbox functionality: - Try entering text to verify character limits work correctly - If using Number type, confirm only numbers can be entered - If using Boxed Field, check that characters appear in separate boxes - Verify mandatory fields cannot be skipped 4. Exit preview mode and make any necessary adjustments. > **Tip** > > Always preview your textboxes after creation to ensure they work as expected and provide a good user experience. --- URL: https://knowledge.leegality.com/document-execution/template/html-template/formatting-and-editing/large-textbox # Large Textbox Large textboxes allow signers to enter longer, multi-line text input in your templates. Use large textboxes to collect information like full addresses, comments, detailed descriptions, or any other lengthy text-based data. > **Info — When to Use Large Textbox** > > Use large textboxes for longer, multi-line inputs without character restrictions. If you need to collect short, single-line text (up to 1028 characters), use **[Small Textbox](https://knowledge.leegality.com/document-execution/template/html-template/formatting-and-editing/small-textbox)** instead. ## Create & add large textbox Follow these steps to insert a large textbox into your template: 1. In the HTML Template editor, place your cursor where you want the textbox to appear. 2. On the toolbar, click **Large Textbox**. 3. The configuration popup will open with two tabs: - **Basic tab:** Configure the group name, field name, and placeholder text - **Select Group:** Choose an existing group or create a new one - **Group Name:** Name for auto-filling the same information across multiple textboxes - **Name:** Unique identifier for this textbox (not visible to signers) - **Placeholder:** Helper text that appears inside the textbox - **More Options tab:** Control textbox appearance and behavior - **Columns:** Width of the textbox in character columns - **Rows:** Height of the textbox in text lines - **Mandatory Field:** Require signers to fill this field 4. Configure your textbox settings (explained in detail in the sections below). 5. Click **OK**. > **Tip — Use Helpful Placeholders** > > Provide clear placeholder text with examples or formatting guidance to help signers understand what to enter. For example: "Enter your complete address" or "Provide any additional comments here". ## Understanding groups and auto-fill Grouping textboxes allows you to auto-fill the same information across multiple fields in your document. When textboxes are in the same group, filling one field automatically fills all other fields in that group. **Why use groups?** Use groups when you need the same information to appear in multiple places in your document. For example: - Complete address appearing in multiple sections - Detailed description needed in different parts of the document - Comments or notes required in various locations **How it works:** When a signer fills in one textbox in a group, all other textboxes in that same group are automatically populated with the same value. This saves time and ensures consistency. **Example:** If you create two large textboxes with the group name `full_address`: 1. Signer enters their complete address in the first textbox 2. The second textbox in the `full_address` group automatically shows the same address > **Tip — Use Grouping Wisely** > > Only group fields that should contain the exact same information. Don't group different fields together just for organisation purposes. Grouping is specifically for auto-filling repeated information. ## Configure large textbox options Use the **More Options** tab to customise the appearance and behavior of your large textbox. ### Set textbox dimensions Control the width and height of the textbox to match the expected content: 1. Open the textbox configuration popup (or right-click an existing textbox and select **Text Field Properties**). 2. Go to the **More Options** tab. 3. Set the dimensions: - **Columns:** Width in character columns (e.g., 40-50 for narrow, 80-100 for wide) - **Rows:** Height in text lines (e.g., 3-5 for addresses, 8-10 for comments, 15+ for descriptions) 4. Click **OK**. > **Info** > > The columns and rows settings control the initial display size of the textbox. Signers can enter more text than the visible area, and scrollbars will appear if needed. **Example dimensions:** - Address: 50 columns × 5 rows - Comments: 80 columns × 8 rows - Detailed description: 100 columns × 15 rows > **Tip** > > Set rows and columns appropriately so signers can see most of their input without excessive scrolling. This improves the user experience. ### Make field mandatory Require signers to fill in the textbox: 1. Open the textbox configuration popup (or right-click an existing textbox and select **Text Field Properties**). 2. Go to the **More Options** tab. 3. Check the **Mandatory Field** checkbox. 4. Click **OK**. Signers will be unable to complete the document until they fill in this field. **When to use:** - Required additional information - Mandatory feedback or comments - Essential descriptions > **Tip** > > Only mark fields as mandatory when they are truly required. Too many mandatory fields can frustrate signers. ## Manage & edit textboxes After placing textboxes in your template, you can modify, move, or duplicate them as needed. ### Change textbox properties To edit an existing textbox: 1. **Right-click** on the textbox inside the editor. 2. Select **Text Field Properties** from the menu. 3. Modify any settings (group, name, placeholder, columns, rows, or mandatory field). 4. Click **OK** to save your changes. > **Info — Note** > > All the original settings (group, name, placeholder, columns, rows, and mandatory field) will be visible and editable when you access Text Field Properties. ### Move or duplicate a textbox To move or copy a textbox to a different location: 1. Select the textbox you want to perform the action. 2. **Right-click** the textbox. 3. Select **Cut** (to move) or **Copy** (to duplicate). 4. Move your cursor to the new location. 5. **Right-click** and select **Paste**. ## Preview your textboxes 1. Locate the **Preview** button in the bottom-left corner of the editor. 2. Click **Preview** to view how your template will appear to signers. 3. Test the textbox functionality: - Ensure the dimensions (rows and columns) are appropriate for the expected content - Try entering multi-line text to verify the textbox works correctly - Verify mandatory fields cannot be skipped 4. Exit preview mode and make any necessary adjustments. > **Tip** > > Always preview your textboxes after creation to ensure they provide adequate space for the expected content and offer a good user experience. --- URL: https://knowledge.leegality.com/document-execution/template/html-template/formatting-and-editing/dropdown # Dropdown Dropdowns (also called select menus) allow signers to choose one or more options from a list. Use dropdowns to collect selections like country, payment method, industry, department, or any other choice from a predefined list. > **Info — When to Use Dropdowns** > > Use dropdowns when you have 7 or more options. For fewer options (2-6), consider using **[Radio Buttons](https://knowledge.leegality.com/document-execution/template/html-template/formatting-and-editing/radio-button)** instead, as they're easier to scan and require one less click. ## Create & add a dropdown Follow these steps to insert a dropdown into your template: 1. In the HTML Template editor, place your cursor where you want the dropdown to appear. 2. On the toolbar, click the **Dropdown** icon. 3. The configuration popup will open with two tabs: - **Basic tab:** Configure the dropdown name and options - **Dropdown Name:** Label visible to signers (e.g., "Select Country", "Choose Payment Method") - **Dropdown Options:** List of choices with Preview Text and Value for each option - **More Options tab:** Control dropdown behavior - **Allow Multiple Selections:** Let signers select multiple options - **Mandatory Field:** Require signers to make a selection 4. Configure your dropdown settings (explained in detail in the sections below). 5. Click **OK**. > **Tip — Use Clear Names** > > The Dropdown Name is visible to signers, so use a clear, descriptive label that indicates what should be selected. ## Build your dropdown list Add and organise the options that will appear in your dropdown menu. ### Understanding Preview Text vs Value For each dropdown option, you provide two pieces of information: - **Preview Text:** What you see while building the template (helps you identify options during creation) - **Value:** What signers see in the dropdown menu (the actual selectable text) **Example:** ``` Preview Text Value ------------------- ------------------- Option 1 India Option 2 United States Option 3 United Kingdom ``` ### Add options 1. In the Basic tab, enter the **Preview Text** in the Preview Text field. 2. Enter the **Value** in the Value field (this is what signers will see). 3. Click the **Add** button to add the option to the list. 4. Repeat for each option you want to include. You can add as many dropdown options as needed. > **Tip — Meaningful Values** > > Make sure the Value field contains clear, user-friendly text that signers will understand. This is what they'll see and select. ### Modify an option To edit an existing option: 1. **Select the entry** from the list you want to change. 2. Make changes to the Preview Text or Value fields. 3. Click **Modify** to update the option. ### Reorder options Use the ordering buttons to arrange options in the desired sequence: - **Move Up:** Move the selected option higher in the list - **Move Down:** Move the selected option lower in the list > **Tip — Logical Ordering** > > Organise your dropdown options in a logical order—alphabetically, by frequency of use, or by importance. Place the most commonly selected options near the top to reduce scrolling and improve user experience. ### Remove an option To delete an option: 1. Select an option from the list. 2. Click **Delete** to remove that entry. ### Set a default selection To pre-select an option: 1. Select the option you want to set as the default. 2. Click **Set as default selected value**. This option will be pre-selected when the document is opened. > **Tip — Set Defaults Wisely** > > Only set a default if there's a clear most-common choice. Avoid biasing responses in surveys or forms where neutral selection is important. ## Configure dropdown options Use the **More Options** tab to customise the behavior of your dropdown. ### Allow multiple selections To let signers select multiple options: 1. Open the dropdown configuration popup (or right-click an existing dropdown and select **Dropdown properties**). 2. Go to the **More Options** tab. 3. Check the **Allow Multiple Selections** checkbox. 4. Click **OK**. **When to use:** - Selecting multiple services or features - Choosing multiple categories - Multi-selection surveys or forms > **Info** > > When multiple selections are allowed, signers typically hold Ctrl (Windows) or Cmd (Mac) to select multiple items, or the interface may show checkboxes. > **Warning** > > Only enable multiple selections when it's truly necessary, as it can be less intuitive for users than single selection. ### Make field mandatory To require signers to make a selection: 1. Open the dropdown configuration popup (or right-click an existing dropdown and select **Dropdown properties**). 2. Go to the **More Options** tab. 3. Check the **Mandatory Field** checkbox. 4. Click **OK**. Signers will be unable to complete the document until they select at least one option. **When to use:** - Required selections - Essential categorisations - Critical choices that cannot be skipped > **Tip** > > Only mark fields as mandatory when they are truly required. Too many mandatory fields can frustrate signers. ## Manage & edit dropdowns After placing dropdowns in your template, you can modify, move, or duplicate them as needed. ### Change dropdown properties To edit an existing dropdown: 1. **Right-click** on the dropdown inside the editor. 2. Select **Dropdown properties** from the menu. 3. Modify any settings: - Change the dropdown name - Add, modify, or delete options - Reorder options - Adjust the default selection - Update multiple selection or mandatory settings 4. Click **OK** to save your changes. > **Info — Note** > > All the original settings will be visible and editable, including the complete list of options with their Preview Text and Values. ### Move or duplicate a dropdown To move or copy a dropdown to a different location: 1. Select the dropdown you want to perform the action. 2. **Right-click** the dropdown. 3. Select **Cut** (to move) or **Copy** (to duplicate). 4. Move your cursor to the new location. 5. **Right-click** and select **Paste**. ## Preview your dropdown 1. Locate the **Preview** button in the bottom-left corner of the editor. 2. Click **Preview** to view how your template will appear to signers. 3. Test the dropdown functionality: - Click the dropdown to view all options - Verify options appear in the correct order - Check that the default selection is appropriate - If multiple selections are enabled, test selecting multiple options 4. Exit preview mode and make any necessary adjustments. > **Tip** > > Always preview your dropdowns after creation to ensure all options are visible, the default selection is correct, and the ordering makes sense for signers. --- URL: https://knowledge.leegality.com/document-execution/template/html-template/formatting-and-editing/fonts # Fonts and Text Formatting This guide provides a comprehensive overview of how to manage the appearance of text in your document by changing fonts, sizes, colors, and applying formatting styles. All font options are available on the toolbar. > **Info** > > For all formatting options, ensure to select the text first. If no text is selected, the formatting will apply to text you type from that point forward. ## Apply text styles Apply formatting styles to emphasise or modify text appearance: ### Bold Make text bold for emphasis: 1. Select the text you want to make bold. 2. Click the **Bold** button (B) on the toolbar. **Keyboard shortcut:** Press **Ctrl+B** (Windows) or **Cmd+B** (Mac). ### Italics Make text italic for emphasis or titles: 1. Select the text you want to italicise. 2. Click the **Italics** button (I) on the toolbar. **Keyboard shortcut:** Press **Ctrl+I** (Windows) or **Cmd+I** (Mac). ### Underline Add an underline to text: 1. Select the text you want to underline. 2. Click the **Underline** button (U) on the toolbar. **Keyboard shortcut:** Press **Ctrl+U** (Windows) or **Cmd+U** (Mac). ### Strikethrough Draw a line through text to indicate its invalidity(e.g., ~~Agreement~~ ): 1. Select the text. 2. Click the **Strikethrough** button on the toolbar. ### Subscript Format text below the baseline (e.g., H₂O): 1. Select the text you want as subscript. 2. Click the **Subscript** button on the toolbar. ### Superscript Format text above the baseline (e.g., x²): 1. Select the text you want as superscript. 2. Click the **Superscript** button on the toolbar. ## Remove format Remove all font-based formatting from text: 1. Select the formatted text. 2. Click the **Remove Format** button on the toolbar. All formatting (bold, italic, underline, strikethrough, subscript, superscript, font type, font size, text color, and background color) will be removed. The text will return to default formatting. ## Change font type Change the font family: 1. Select the text you want to change. 2. Click the **Font Type** dropdown on the toolbar. 3. Choose a font from the list. **Common fonts:** Arial, Times New Roman, Calibri, Verdana, Georgia, Courier New ## Change font size Change the text size: 1. Select the text you want to resize. 2. Click the **Font Size** dropdown on the toolbar. 3. Choose a size from the list. ## Change text color Change the color of text: 1. Select the text you want to color. 2. Click the **Text Color** button on the toolbar. 3. Choose a color from the color sheet. > **Tip** > > Use colors that provide good contrast with your background. Black or dark gray on white is standard for body text. ## Change background color Apply a background color to text: 1. Select the text. 2. Click the **Background Color** button on the toolbar. 3. Choose a color from the color sheet. The selected text will have a colored background (like a highlighter effect). > **Info** > > Background color is useful for highlighting important information or creating visual emphasis without changing the text color itself. ## Copy formatting Copy the visual styling from one section and apply it to another: 1. Select the text that has the formatting you want to copy. 2. On the toolbar, click the **Copy Formatting** button (paintbrush icon). 3. Select the text where you want to apply the copied formatting. ### What copy formatting copies Copy formatting memorizes and applies: - **Font style:** Bold, italics, typeface, and font size - **Colors:** Text color and background color - **Alignment:** Left, center, right, or justified settings - **Table styles:** Cell borders and padding (if used within tables) ### Use copy formatting multiple times **Single application:** Click the **Copy Formatting** button once to apply formatting to one section. **Multiple applications:** Double-click the **Copy Formatting** button to lock it, then apply formatting to multiple sections. Click the button again to deactivate. > **Tip** > > Use copy formatting to ensure consistency across your document. You can style one header or field exactly how you want it, then copy that formatting to all similar elements. ## Align text Control how text aligns horizontally within your document: ### Align left Align text to the left margin: 1. Select the text or paragraph. 2. On the toolbar, click the **Align Left** button. ### Align center Center text horizontally: 1. Select the text or paragraph. 2. On the toolbar, click the **Align Center** button. ### Align right Align text to the right margin: 1. Select the text or paragraph. 2. On the toolbar, click the **Align Right** button. ### Justify Align text to both left and right margins: 1. Select the text or paragraph. 2. On the toolbar, click the **Justify** button. The text will stretch to align with both margins, creating even edges on both sides. > **Info** > > Alignment applies to entire paragraphs. If your cursor is in a paragraph, you don't need to select the whole paragraph—just click the alignment button. ## Adjust indent Control the indentation of text or paragraphs: ### Increase indent Move text further from the left margin: 1. Select the text or paragraph. 2. On the toolbar, click **Increase Indent**. You can click multiple times to increase indentation further. ### Decrease indent Move text closer to the left margin: 1. Select the text or paragraph. 2. On the toolbar, click **Decrease Indent**. You can click multiple times to decrease indentation further. > **Tip** > > Indent is useful for creating visual hierarchy, nested lists, or block quotations. Use it to make subsections stand out from main content. ## Change line height Control the spacing between lines of text: 1. Select the text where you want to adjust line height. 2. On the toolbar, click the **Line Height** dropdown. 3. Select a value from 1 to 2. **Line height values:** - **1.0:** Single spacing (minimal space between lines) - **1.5:** One and a half spacing (standard for readability) - **2.0:** Double spacing (maximum space between lines) > **Info** > > Line height controls the vertical distance between two subsequent lines. Higher values create more breathing room, while lower values make text more compact. --- URL: https://knowledge.leegality.com/document-execution/template/html-template/formatting-and-editing/lists # Lists Lists help organise information in a clear, easy-to-read format. You can create numbered lists for sequential items or bulleted lists for non-sequential items. ## Numbered list Create a numbered list that starts from 1: 1. Place your cursor where you want the list to begin. 2. On the toolbar, click **Insert/Remove Numbered List**. 3. Type your first list item and press **Enter** to create the next item. The list will automatically number each item (1, 2, 3, etc.). ### Create sublists in numbered lists Add nested sublists within your numbered list: 1. Position your cursor at the list item where you want to create a sublist. 2. Press **Tab** on your keyboard. The item will indent and become a sublist with its own numbering format (e.g., 1.1, 1.2 or a, b, c). > **Tip** > > You can press Tab multiple times to create deeper nested sublists (e.g., 1.1.1, 1.1.2). Each Tab press creates a new nesting level. ### Remove numbered list Remove numbering from a list: 1. Select the numbered list items. 2. On the toolbar, click **Insert/Remove Numbered List** again. The numbers will be removed and the text will return to normal paragraphs. ## Bulleted list Create a bulleted list with bullet points: 1. Place your cursor where you want the list to begin. 2. On the toolbar, click **Insert/Remove Bulleted List**. 3. Type your first list item and press **Enter** to create the next item. The list will automatically add bullet points (•) before each item. ### Create sublists in bulleted lists Add nested sublists within your bulleted list: 1. Position your cursor at the list item where you want to create a sublist. 2. Press **Tab** on your keyboard. The item will indent and become a sublist with a different bullet style (e.g., ○ or ■). > **Tip** > > You can press Tab multiple times to create deeper nested sublists. Each Tab press creates a new nesting level with different bullet styles. ### Remove bulleted list Remove bullets from a list: 1. Select the bulleted list items. 2. On the toolbar, click **Insert/Remove Bulleted List** again. The bullets will be removed and the text will return to normal paragraphs. > **Info — INFO** > > Press **Shift+Tab** to move a list item back to a higher level (reduce nesting). ## When to use lists **Use numbered lists when:** - Order matters (steps in a process, rankings, sequences) - Items need to be referenced by number - Creating instructions or procedures **Use bulleted lists when:** - Order doesn't matter - Listing features, benefits, or options - Breaking down information into digestible points > **Info** > > Lists automatically continue numbering or adding bullets when you press Enter after each item. Press Enter twice to exit the list and return to normal text. --- URL: https://knowledge.leegality.com/document-execution/template/html-template/formatting-and-editing/images-static # Insert Image The Insert Image feature allows you to embed static images directly into your HTML template. In the HTML Template editor, you can add images from a URL or by uploading files, configure dimensions, set margins and borders, and add alternative text for accessibility. ## Insert an image Add static images to your template that are part of the document itself. 1. In the HTML Template editor, place your cursor where you want the image to appear. 2. On the toolbar, click **Insert Image**. 3. A popup will open with **Basic** and **More Options** tabs. 4. Configure the image settings as needed. 5. Click **OK** to insert the image. ## Insert Image Configuration When you select the Insert Image option, a configuration popup appears with the following sections: ### Basic Settings Choose how you want to add the image to your template: #### 1. URL Option Select this checkbox to insert an image from a web URL: - Check the **URL** checkbox - Enter the complete image URL in the provided field - The image will be loaded from the specified web address **Example:** ``` https://www.example.com/images/logo.png ``` > **Info** > > Make sure the URL is publicly accessible and points directly to an image file. The URL should start with `http://` or `https://`. #### 2. Upload Option Select this checkbox to upload an image file from your computer: - Check the **Upload** checkbox - Click the file browser to select an image from your device - The image will be uploaded and embedded in the template **Supported Formats:** JPG, JPEG, PNG, GIF, SVG > **Warning — Important** > > You cannot choose both URL and Upload options simultaneously. Select only one method to insert your image. ### More Options These are optional settings to customise the image appearance and behavior: #### 1. Alternative Text Enter text that describes the image: - This text appears in the filled form if the image fails to load - It's also used for accessibility purposes (screen readers) - Helps users understand what the image represents #### 2. Image Vertical Margin (px) Set the vertical spacing above and below the image: - Controls the top and bottom margin around the image - Enter the value in pixels - **Default: 0 px** #### 3. Image Horizontal Margin (px) Set the horizontal spacing to the left and right of the image: - Controls the left and right margin around the image - Enter the value in pixels - **Default: 0 px** #### 4. Image Border (px) Add a border around the image: - Controls the thickness of the border around the image - Enter the value in pixels - **Default: 0 px** (no border) #### 5. Custom Width and Height Specify custom dimensions for the image: ##### Width (px) - Enter the desired width of the image in pixels - Leave empty to use original image width ##### Height (px) - Enter the desired height of the image in pixels - Leave empty to use original image height #### 6. Maintain Aspect Ratio Enable this checkbox to automatically adjust dimensions proportionally: - When **enabled**: Changing width automatically calculates the appropriate height (or vice versa) to maintain the image's original proportions - When **disabled**: You can set width and height independently, which may distort the image **When to use:** - **Enable** to preserve image proportions and prevent distortion (recommended for most images) - **Disable** only if you need exact dimensions regardless of distortion > **Info** > > Maintaining aspect ratio ensures your images don't appear stretched or squashed. It's recommended to keep this checkbox enabled for professional-looking documents. ## Manage & edit images Once an image is inserted, you can modify its properties or reposition it. ### Edit an image 1. **Double-click** on the image in the editor, or **right-click** and select **Image Properties**. 2. The Insert Image popup will open with current settings. 3. Make your desired changes to any field. 4. Click **OK** to save changes. ### Move or duplicate an image 1. **Right-click** the image. 2. Select **Cut** or **Copy**. 3. Move your cursor to the new location and right-click **Paste**. ### Remove an image 1. **Click** to select the image. 2. Press the **Delete** or **Backspace** key on your keyboard. ## Preview your image Before finalizing your template, check how the image will appear in the generated PDF. 1. Locate the **Preview** button in the bottom-left corner of the editor. 2. Click **Preview** to view how the image appears in the document. 3. Verify the image displays correctly with the configured settings. > **Info** > > The Insert Image feature is for static images that are part of the template. If you need users to upload their own images during document signing, use the [Upload Image](https://knowledge.leegality.com/document-execution/template/html-template/formatting-and-editing/images-upload) field instead. --- URL: https://knowledge.leegality.com/document-execution/template/html-template/formatting-and-editing/images-upload # Upload Image The Upload Image field allows signers to upload image files to your document. In the HTML Template editor, you can configure image dimensions, alignment, file size limits, quality requirements, and make the upload mandatory for signers. ## Create & add an upload image field 1. In the HTML Template editor, place your cursor where you want the upload image field to appear. 2. On the toolbar, click the **Upload Image** button. 3. In the configuration popup, enter your settings in the **Basic** and **More Options** tabs. 4. Click **OK**. ## Upload Image Configuration When you select the Upload Image option, a configuration popup appears with the following sections: ### Basic Settings These are the core settings required to create an upload image field: #### 1. Image Field Name (Required) Enter a unique name for the upload image field (e.g., `profile_photo`). - This serves as an internal identifier for the image field - **Must be unique** across your template - Choose a descriptive name that clearly identifies the field's purpose #### 2. Width (Required) Specify the display width of the uploaded image in pixels (px). - Determines how wide the image will appear in your document - Enter the value in pixels (this is a required field) #### 3. Height (Optional) Specify the display height of the uploaded image in pixels (px). - Determines how tall the image will appear in your document - **Default is auto** - automatically maintains aspect ratio based on the width you specify - If you want automatic height calculation, leave this field empty #### 4. Alignment Choose how the uploaded image should be aligned in the document. - **None (default):** No specific alignment - **Left:** Aligns image to the left - **Right:** Aligns image to the right - **Centre:** Centers the image ### More Options These are optional settings for advanced upload image configuration: #### 1. Maximum Upload File Size (in KB) Set the maximum file size limit for uploaded images in kilobytes. - Controls how large the uploaded file can be - Helps prevent overly large uploads that slow down processing - Enter the value in KB (1 MB = 1024 KB) #### 2. Picture Quality Set quality requirements for uploaded images by specifying width constraints: ##### Minimum Upload File Width (px) Specify the minimum width the uploaded image must have. - Ensures the uploaded image meets a minimum quality standard - Images narrower than this will be rejected ##### Maximum Upload File Width (px) Specify the maximum width the uploaded image can have. - Prevents excessively large or high-resolution uploads - Images wider than this will be rejected > **Info — NOTE** > > These width constraints validate the actual image dimensions, not the display size. The display size is controlled by the Width and Height fields in Basic Settings. #### 3. Mandatory Field Enable this checkbox to make the image upload mandatory. - Users must upload an image before proceeding with document signing - Use this for critical images that cannot be skipped ## Manage & edit upload image fields Once an upload image field is placed, you can move it or update its configuration. ### Change upload image properties 1. **Double-click** or **Right-click** on the upload image field. 2. The properties popup will open with all current settings. 3. Modify any settings as needed. 4. Click **OK** to save changes. > **Info — NOTE** > > When you edit the upload image field through Image properties, all the original settings (field name, dimensions, alignment, file size limits, quality constraints, and mandatory setting) will be visible and editable. ### Move or duplicate an upload image field 1. **Right-click** the upload image field. 2. Select **Cut** or **Copy**. 3. Move your cursor to the new location and right-click **Paste**. ## Preview your upload image field Before finalizing your template, check how the upload field will appear in the generated PDF. 1. Locate the **Preview** button in the bottom-left corner of the editor. 2. Click **Preview** to view the interactive elements. 3. Test the upload functionality to ensure it works as expected. > **Tip** > > Always preview your upload image fields after creation to ensure the dimensions and alignment look appropriate in the document layout. --- URL: https://knowledge.leegality.com/document-execution/template/html-template/formatting-and-editing/margins-and-borders # Margins and Borders Margins and borders help you control the spacing and visual boundaries of your HTML template. Use margins to add space around your document content, and borders to create a professional frame for formal documents like certificates, letterheads, or official notices. ## Add margins Set custom margins to control the space around your document content: 1. In the HTML Template editor toolbar, click **Add Margin**. 2. A properties box will open with margin settings. 3. Adjust the margin values as needed: - **Top:** Space from the top edge of the page (in pixels) - **Bottom:** Space from the bottom edge of the page (in pixels) - **Left:** Space from the left edge of the page (in pixels) - **Right:** Space from the right edge of the page (in pixels) 4. Click **OK** to apply the margins. ### Default margin values - **Top:** 62 px - **Bottom:** 62 px - **Left:** 48 px - **Right:** 48 px > **Tip — Use Default Margins** > > The default margins (62px top/bottom, 48px left/right) are optimised for most standard documents and work well for printing. Only adjust if you have specific requirements. ### Reset to default margins To revert to the default values: 1. In the margin properties box, click **Reset to default**. 2. All margin values will be restored to their defaults (top/bottom: 62px, left/right: 48px). 3. Click **OK** to apply. > **Info — Print Considerations** > > Ensure margins are adequate for printing. Too small margins may result in content being cut off. If documents will be bound, increase the left margin (for left binding) or top margin (for top binding) to account for binding space. ## Add borders Add visual boundaries around your document to frame the content: 1. In the HTML Template editor toolbar, click **Add Border**. 2. The Border Properties box will open. 3. Configure the border settings: - **Thickness (px):** Enter the thickness of the border in pixels - **Distance from page edge (px):** Enter how far the border should be from the page edge in pixels - **Style:** Choose the border style - **Solid:** A continuous line (recommended for formal documents) - **Dotted:** A line made of dots (for decorative purposes) 4. Click **OK** to apply the border. > **Info — Distance from Page Edge** > > The "Distance from page edge" setting controls the gap between the page edge and where the border begins. Set appropriate distance (at least 10px) to ensure the border doesn't look cramped and prints properly. ## Edit margins or borders To modify existing margin or border settings: 1. Click the **Add Margin** or **Add Border** button again. 2. The properties box will open with current settings displayed. 3. Make your desired changes. 4. Click **OK** to save. > **Tip — Preview Your Changes** > > Always preview your document after adding or modifying margins and borders to ensure they appear as intended before finalizing your template. ## Preview margins and borders 1. Locate the **Preview** button in the bottom-left corner of the editor. 2. Click **Preview** to view how your template will appear with the applied margins and borders. 3. Check that margins provide adequate spacing and borders frame the content properly. 4. Exit preview mode and make any necessary adjustments. > **Tip** > > Always preview after setting margins and borders to ensure they work well together and look professional before finalizing your template. > **Info — NOTE** > > When using **[Source HTML](https://knowledge.leegality.com/document-execution/template/html-template/formatting-and-editing/source-html)** to merge 2-3 different templates together, it's critical to ensure all templates have consistent margin and border values before merging. --- URL: https://knowledge.leegality.com/document-execution/template/html-template/formatting-and-editing/hyperlinks # Hyperlinks Hyperlinks allow you to add clickable links to your HTML template that direct users to web pages or other online resources. Use this feature when drafting contracts or agreements to link to terms and conditions, privacy policies, or supporting documentation without cluttering your document. In the HTML Template editor, you can insert hyperlinks with custom display text and specify the destination URL. ## Insert a hyperlink Add clickable links to your document that direct users to external URLs. 1. In the HTML Template editor, place your cursor where you want the hyperlink to appear. 2. On the toolbar, click **Insert Hyperlink**. 3. A popup will open with hyperlink settings. 4. Configure the hyperlink: - **Display Text:** Enter the text that should appear as the clickable link - **Link type:** URL (this is the default option and is already displayed) - **URL:** Enter the web address where users should be directed when clicking the link 5. Click **OK** to insert the hyperlink. **Example:** - Display Text: "Visit our website" - Link type: URL - URL: https://www.example.com The text "Visit our website" will appear as a clickable link in the document. > **Info** > > - The Display Text is what users will see in the document, while the URL is the actual web address they'll be taken to when clicking the link > - Use clear, descriptive text for Display Text instead of generic phrases like "Click here" (e.g., use "View our Privacy Policy" instead) > - Always enter complete, valid URLs starting with `http://` or `https://` (e.g., `https://www.example.com`, not `www.example.com`) ## Manage & edit hyperlinks Once a hyperlink is inserted, you can modify it, move it, or remove it entirely. ### Edit a hyperlink 1. **Right-click** on the hyperlink in the editor. 2. Select **Edit link** from the context menu. 3. The hyperlink properties popup will open with current settings. 4. Make your desired changes to Display Text or URL. 5. Click **OK** to save changes. ### Preview hyperlink View how your hyperlink will appear in the document before finalizing. 1. Hover over the hyperlink in the editor to see a preview of the link destination. 2. To test the link functionality, use the **Preview** button in the bottom-left corner of the editor. 3. Click on the hyperlink in preview mode to verify it directs to the correct URL. ### Move or duplicate a hyperlink 1. **Right-click** the hyperlink. 2. Select **Cut** or **Copy**. 3. Move your cursor to the new location and right-click **Paste**. ### Remove a hyperlink 1. Select the hyperlink text in the editor. 2. In the toolbar panel, click **Remove Hyperlink**. 3. The hyperlink will be removed, but the text will remain. > **Info — NOTE** > > Removing a hyperlink only removes the clickable link, not the text itself. The Display Text will remain as regular text in your document. --- URL: https://knowledge.leegality.com/document-execution/template/html-template/formatting-and-editing/horizontal-lines # Horizontal Lines Horizontal lines are visual separators that help organise content and improve readability in your document. They span the full width of the page wherever you insert them. ## Insert a horizontal line Add a horizontal line to separate sections of your document: 1. Place your cursor where you want the line to appear. 2. On the toolbar, click **Insert Horizontal Line**. The line will appear at the cursor position, spanning the full width of the page. ## Remove a horizontal line Delete a horizontal line from your document: 1. Click to position your cursor at the line. 2. Press **Backspace** or **Delete** on your keyboard. The line will be removed from your document. ## When to use horizontal lines **Good use cases:** - Separating major sections of a document - Before and after important notices - Creating visual breaks in long documents - Between different topics or subjects **Avoid using when:** - Content sections are already clearly separated by headings - The document is very short - White space alone would suffice > **Tip** > > Use horizontal lines sparingly. Too many lines can create visual clutter. For most documents, a simple line between major sections is sufficient. --- URL: https://knowledge.leegality.com/document-execution/template/html-template/formatting-and-editing/special-characters # Special Characters Special characters are symbols that aren't available on a standard keyboard, such as currency symbols (₹, €, $), mathematical symbols (×, ÷, ±), punctuation marks (©, ®, ™), and accented characters (á, é, ñ). ## Insert a special character Add special characters to your document: 1. Place your cursor where you want the character to appear. 2. On the toolbar, click **Insert Special Character**. 3. An elaborate list of special characters will open. 4. Click on the character you want to include. The selected character will appear in your document at the cursor position. ## Manage special characters Once inserted, special characters can be managed like regular text: ### Delete a special character 1. Position your cursor at the special character. 2. Press **Backspace** or **Delete** on your keyboard. ### Copy, cut, or paste special characters 1. Select the special character in your document. 2. **Right-click** on the selected character. 3. Choose **Copy**, **Cut**, or **Paste** from the menu. > **Info** > > Special characters behave exactly like regular text once inserted. You can format, move, copy, or delete them using the same methods you use for normal text. ## Common special characters The special character picker includes: - **Currency symbols:** ₹ (Rupee), $ (Dollar), € (Euro), £ (Pound), ¥ (Yen) - **Mathematical symbols:** × (Multiplication), ÷ (Division), ± (Plus-Minus), ≠ (Not Equal) - **Legal symbols:** © (Copyright), ® (Registered), ™ (Trademark), § (Section) - **Punctuation:** • (Bullet), … (Ellipsis), – (En Dash), — (Em Dash) - **Arrows and symbols:** → ← ↑ ↓ ★ ☑ ☐ - **Accented characters:** á é í ó ú ñ ç > **Tip** > > For frequently used special characters, you can copy them once and paste them wherever needed throughout your template. --- URL: https://knowledge.leegality.com/document-execution/template/html-template/formatting-and-editing/tables # Tables Tables help you organise and present structured data in rows and columns in your HTML templates. Use tables to display information like pricing plans, schedules, contact details, financial data, or any structured information that's easier to understand in a grid format. ## Insert a table Add a table to your template to display structured data: 1. In the HTML Template editor, place your cursor where you want the table to appear. 2. On the toolbar, click **Insert Table**. 3. A popup will open with table configuration options: - **Number of Rows:** Enter the number of horizontal rows (required) - **Number of Columns:** Enter the number of vertical columns (required) - **Cell Padding (px):** Space between cell content and cell border in pixels - **Table Width:** Width in pixels (e.g., 500) or percentage (e.g., 100%) - **Table Height:** Height in pixels - **Border Size (px):** Thickness of table borders in pixels - **Alignment:** Position of the table (Left, Right, Centre) - Default is `` 4. Click **OK** to insert the table. > **Tip — Set Table Width in Percentage** > > Use the % sign to set table width as a percentage (e.g., 100% for full width, 75% for three-quarters width). This makes tables responsive and adaptable to different screen sizes. ## Edit your table After inserting a table, you can modify its structure, appearance, and content using the right-click menu. **To access edit options:** 1. **Right-click** on any cell or area in your table. 2. Select from the available operations. ### Table editing operations - **[Cell operations](https://knowledge.leegality.com/document-execution/template/html-template/formatting-and-editing/tables/cell-operations):** Insert, delete, merge, split cells, and customise cell properties - **[Row operations](https://knowledge.leegality.com/document-execution/template/html-template/formatting-and-editing/tables/row-operations):** Add or remove rows from your table - **[Column operations](https://knowledge.leegality.com/document-execution/template/html-template/formatting-and-editing/tables/column-operations):** Add or remove columns from your table - **[Table properties](https://knowledge.leegality.com/document-execution/template/html-template/formatting-and-editing/tables/table-properties):** Modify overall table settings - **[Delete table](https://knowledge.leegality.com/document-execution/template/html-template/formatting-and-editing/tables/delete-table):** Remove the entire table from your template - **[Copy, cut, and paste](https://knowledge.leegality.com/document-execution/template/html-template/formatting-and-editing/tables/copy-cut-paste):** Move or duplicate table content --- URL: https://knowledge.leegality.com/document-execution/template/html-template/formatting-and-editing/tables/cell-operations # Cell Operations Access cell-specific operations by right-clicking on any cell and hovering over **Cell** in the menu. ## Insert cells Add new cells before or after the selected cell: 1. **Right-click** on a cell. 2. Hover over **Cell** in the menu. 3. Select **Insert Cell Before** or **Insert Cell After**. The new cell will be inserted in the selected position. > **Caution — NOTE** > > Inserting cells between existing rows or columns may automatically generate additional rows/columns to compensate, which can disrupt the table's layout. Exercise caution when modifying the table structure to prevent unintended formatting shifts. ## Delete cells Remove specific cells from your table: 1. **Right-click** on the cell you want to delete. 2. Hover over **Cell** in the menu. 3. Select **Delete Cells**. ## Merge cells Combine multiple cells into a single cell using different merge options: ### Merge selected cells 1. Select the cells you want to merge (click and drag). 2. **Right-click** on the selected cells. 3. Hover over **Cell** in the menu. 4. Select **Merge Cells**. The selected cells will combine into one cell, and content from all merged cells will be preserved. ### Merge right 1. **Right-click** on a cell. 2. Hover over **Cell** in the menu. 3. Select **Merge Right** to merge with the cell on the right. ### Merge down 1. **Right-click** on a cell. 2. Hover over **Cell** in the menu. 3. Select **Merge Down** to merge with the cell below. > **Tip — When to Merge Cells** > > Use merge cells for creating headers that span multiple columns, grouping related information, or creating custom table layouts with varying cell sizes. ## Split cells Divide a cell into multiple cells horizontally or vertically: ### Split horizontally 1. **Right-click** on the cell. 2. Hover over **Cell** in the menu. 3. Select **Split Cell Horizontally**. The cell will be divided into two cells stacked vertically. ### Split vertically 1. **Right-click** on the cell. 2. Hover over **Cell** in the menu. 3. Select **Split Cell Vertically**. The cell will be divided into two cells side by side. ## Cell properties Customise individual cell appearance and behavior: 1. **Right-click** on the cell. 2. Hover over **Cell** in the menu. 3. Select **Cell Properties**. 4. A popup will open with the following options: - **Width:** Cell width in pixels or percentage - **Height:** Cell height in pixels - **Word Wrap:** Enable or disable text wrapping (Yes/No) - **Horizontal Alignment:** Align content horizontally (Left, Right, Center, Justify) - **Vertical Alignment:** Align content vertically (Top, Middle, Bottom, Baseline) - **Cell Type:** Define cell type (Data or Header) - **Rows Span:** Number of rows the cell should span - **Columns Span:** Number of columns the cell should span - **Background Color:** Choose cell background color from the color chart - **Border Color:** Choose border color from the color chart with checkboxes to specify which borders to apply (Top, Bottom, Right, Left) 5. Configure your desired settings. 6. Click **OK** to apply the changes. > **Info — Cell Type: Header vs Data** > > Set cell type to "Header" for column or row headers. This helps with accessibility and can apply different default styling to make headers stand out. --- URL: https://knowledge.leegality.com/document-execution/template/html-template/formatting-and-editing/tables/row-operations # Row Operations Access row operations by right-clicking on any cell and hovering over **Row** in the menu. ## Insert rows Add new rows above or below existing rows: 1. **Right-click** on any cell in your table. 2. Hover over **Row** in the menu. 3. Select **Insert Row Before** to add a row above the selected cell. OR Select **Insert Row After** to add a row below the selected cell. The new row will be inserted with the same number of columns as existing rows. ## Delete rows Remove rows from your table: 1. **Right-click** on any cell in the row you want to delete. 2. Hover over **Row** in the menu. 3. Select **Delete Rows**. The entire row will be removed from the table. > **Warning** > > Deleting rows is permanent. Make sure you don't need the data before deleting. --- URL: https://knowledge.leegality.com/document-execution/template/html-template/formatting-and-editing/tables/column-operations # Column Operations Access column operations by right-clicking on any cell and hovering over **Column** in the menu. ## Insert columns Add new columns to the left or right of existing columns: 1. **Right-click** on any cell in your table. 2. Hover over **Column** in the menu. 3. Select **Insert Column Before** to add a column to the left of the selected cell. OR Select **Insert Column After** to add a column to the right of the selected cell. The new column will be inserted across all rows. ## Delete columns Remove columns from your table: 1. **Right-click** on any cell in the column you want to delete. 2. Hover over **Column** in the menu. 3. Select **Delete Columns**. The entire column will be removed from the table. > **Warning** > > Deleting columns is permanent. Make sure you don't need the data before deleting. --- URL: https://knowledge.leegality.com/document-execution/template/html-template/formatting-and-editing/tables/table-properties # Table Properties Modify the overall table settings after insertion. ## Edit table properties 1. **Right-click** anywhere in the table. 2. Select **Table Properties**. 3. The same popup from table insertion will open with these options: - **Number of Rows:** Adjust the number of rows - **Number of Columns:** Adjust the number of columns - **Cell Padding (px):** Space between cell content and cell border - **Table Width:** Width in pixels or percentage - **Table Height:** Height in pixels - **Border Size (px):** Thickness of table borders - **Alignment:** Position of the table (Left, Right, Centre) 4. Make your desired changes. 5. Click **OK** to apply. > **Tip — Set Table Width in Percentage** > > Use the % sign to set table width as a percentage (e.g., 100% for full width, 75% for three-quarters width). This makes tables responsive and adaptable to different screen sizes. --- URL: https://knowledge.leegality.com/document-execution/template/html-template/formatting-and-editing/tables/delete-table # Delete Table Remove the entire table from your template. ## Delete a table 1. **Right-click** anywhere in the table. 2. Select **Delete Table**. The entire table and all its content will be removed from your template. > **Warning** > > Deleting a table is permanent. Make sure you don't need the table or its data before deleting. If you're unsure, consider copying the table content to another location first. > **Tip** > > If you only want to remove certain rows or columns, use the **[Row operations](https://knowledge.leegality.com/document-execution/template/html-template/formatting-and-editing/tables/row-operations)** or **[Column operations](https://knowledge.leegality.com/document-execution/template/html-template/formatting-and-editing/tables/column-operations)** instead of deleting the entire table. --- URL: https://knowledge.leegality.com/document-execution/template/html-template/formatting-and-editing/tables/copy-cut-paste # Copy, Cut, and Paste Move or duplicate table content using standard clipboard operations. ## Copy cells Duplicate cell content to use elsewhere: 1. Select the cell(s) you want to copy (click and drag to select multiple cells). 2. **Right-click** and select **Copy**. 3. Navigate to the destination cell. 4. **Right-click** and select **Paste**. The content will be copied to the new location while keeping the original intact. ## Cut cells Move cell content from one location to another: 1. Select the cell(s) you want to move (click and drag to select multiple cells). 2. **Right-click** and select **Cut**. 3. Navigate to the destination cell. 4. **Right-click** and select **Paste**. The content will be moved to the new location and removed from the original. ## Copy entire tables Duplicate a complete table to another location in your template: 1. **Right-click** anywhere in the table. 2. Select the entire table (or use a keyboard shortcut to select all). 3. **Right-click** and select **Copy**. 4. Navigate to the location where you want the duplicate table. 5. **Right-click** and select **Paste**. > **Tip — Keyboard Shortcuts** > > You can also use standard keyboard shortcuts for faster operations: > - **Copy:** Ctrl+C (Windows) or Cmd+C (Mac) > - **Cut:** Ctrl+X (Windows) or Cmd+X (Mac) > - **Paste:** Ctrl+V (Windows) or Cmd+V (Mac) > **Info** > > When copying or cutting cells, formatting (colors, borders, alignment) is preserved along with the content. --- URL: https://knowledge.leegality.com/document-execution/template/html-template/formatting-and-editing/page-breaks # Page Breaks Page breaks control where one page ends and the next begins in your document. They ensure content appears on separate pages when your document is converted to PDF or printed. ## Insert a page break Add a page break to start content on a new page: 1. Place your cursor where you want the page break to occur. 2. On the toolbar, click **Insert Page Break**. A page break will be inserted at the cursor position. Content after the page break will move to the next page. ## Remove a page break Delete a page break from your document: 1. Position your cursor at the page break, or select the page break. 2. Press **Backspace** or **Delete** on your keyboard. The page break will be removed and content will flow continuously. > **Info** > > Page breaks are primarily important for printed documents and PDFs. They may not be visible in the web view of your template. ## When to use page breaks **Use page breaks to:** - Start major sections on new pages - Keep signature sections on separate pages - Separate appendices or attachments - Create cover pages or title pages **Avoid page breaks when:** - Content naturally flows across pages - The document is primarily for screen viewing - You have very little content per page --- URL: https://knowledge.leegality.com/document-execution/template/html-template/formatting-and-editing/header-and-footer # Header and Footer Headers and footers appear at the top and bottom of every page in your document. Use them to display consistent information like company names, page numbers, or document titles across all pages. ## Work with header Add content that appears at the top of every page: 1. Locate the **Header** toggle button in the top-left corner of the page. 2. Click the toggle to turn it **on**. 3. A separate header section will open. 4. Add your content (text, images, formatting) in the header section. Whatever you write in the header will appear at the top of all pages in the filled document. > **Info** > > The header applies to all pages by default. You can exclude specific pages using the Exclude Header option. ### Exclude header from specific pages Remove the header from certain pages: 1. In the header section, click **Exclude Header** from the toolbar. 2. A popup will open. 3. Enter the page numbers where you want to exclude the header. 4. Separate page numbers with commas (e.g., 1, 3, 5). 5. Click **OK**. The header will not appear on the specified pages. ### Add page numbers to header Display the current page number in the header: 1. In the header section, click **Add Page Number** from the toolbar. The page number will appear in the header. ### Add total pages to header Display the total number of pages in the header: 1. In the header section, click **Add Total Page** from the toolbar. The total page count will appear in the header. > **Tip** > > You can enable both page number and total pages. To separate them (e.g., "Page 1 of 10"), manually type a separator between them like "/" or ":" or "of" because there's no default separator. **Example:** - Type "Page ", click **Add Page Number**, type " of ", click **Add Total Page** - Result: "Page 1 of 10" ## Work with footer Add content that appears at the bottom of every page: 1. Locate the **Footer** toggle button in the bottom-left corner of the page. 2. Click the toggle to turn it **on**. 3. A separate footer section will open. 4. Add your content (text, images, formatting) in the footer section. Whatever you write in the footer will appear at the bottom of all pages in the filled document. > **Info** > > The footer applies to all pages by default. You can exclude specific pages using the Exclude Footer option. ### Exclude footer from specific pages Remove the footer from certain pages: 1. In the footer section, click **Exclude Footer** from the toolbar. 2. A popup will open. 3. Enter the page numbers where you want to exclude the footer. 4. Separate page numbers with commas (e.g., 1, 3, 5). 5. Click **OK**. The footer will not appear on the specified pages. ### Add page numbers to footer Display the current page number in the footer: 1. In the footer section, click **Add Page Number** from the toolbar. The page number will appear in the footer. ### Add total pages to footer Display the total number of pages in the footer: 1. In the footer section, click **Add Total Page** from the toolbar. The total page count will appear in the footer. > **Tip** > > You can enable both page number and total pages. To separate them (e.g., "1/10"), manually type a separator between them like "/" or ":" because there's no default separator. **Example:** - Click **Add Page Number**, type "/", click **Add Total Page** - Result: "1/10" > **Info — NOTE** > > Use formatting options (fonts, colors, alignment) in the header and footer sections just like you would in the main document body. --- URL: https://knowledge.leegality.com/document-execution/template/html-template/formatting-and-editing/source-html # Source HTML Source HTML gives you access to the backend code view of your template. The primary use of this feature is to duplicate templates with exact properties—including all features, fields, and formatting—without losing any details during the copy-paste process. When you copy and paste content normally in the visual editor, some properties can get lost, especially font types, spacing, or field configurations. The Source HTML feature solves this by letting you copy the complete HTML code and paste it into another document, ensuring an exact replica of your template. > **Info — No HTML Knowledge Required** > > You don't need to know HTML to use this feature. Simply copy the source code from one template and paste it into another to duplicate the exact structure and formatting. ## Access Source HTML view To view the HTML code of your template: 1. In the HTML Template editor, click the **`<>` Source** button in the top left corner of the toolbar. 2. The editor will switch to code view, displaying the HTML markup (backend view). 3. You can now copy the entire code or make edits if needed. 4. Click **`<>` Source** again to switch back to the visual editor. > **Warning — Toolbar Disabled in HTML View** > > When you're in Source HTML view, all other toolbar options (like inserting checkboxes, textboxes, images, etc.) are disabled. This is because Source HTML is the backend view, while the other toolbar options are frontend tools. You must switch back to the visual editor to use those features. ## When to use Source HTML - **Duplicate templates exactly:** Copy the source code from one template and paste it into another document to replicate all properties, fields, and formatting without any loss of detail. - **Copy HTML templates from Sandbox to Production:** Copy the source HTML from your sandbox template and paste the copied HTML code in the new production HTML template. - **Fix formatting issues:** If the visual editor creates unexpected formatting or spacing that you can't fix normally, you can adjust it directly in the source code. - **Clean up pasted content:** When content pasted from Word documents or websites brings unwanted formatting, you can clean it up in Source HTML view. - **Paste external HTML templates:** If you have an HTML template from another source (like an email template or web design), you can paste it into Source HTML view and adapt it for your document. > **Tip — Merging Multiple Templates** > > When merging 2-3 different templates together, ensure consistent **[margins and borders](https://knowledge.leegality.com/document-execution/template/html-template/formatting-and-editing/margins-and-borders)** across all templates to avoid distortion. --- URL: https://knowledge.leegality.com/document-execution/template/html-template/preview-and-download # Preview and Download After creating your HTML template, preview it to ensure everything looks correct before using it. You can also download form fields, generate PDFs, and save your work. ## Preview your template Check how your template will appear to users: 1. In the HTML Template editor, click the **Preview** button. 2. The preview window will open showing your template. 3. Review the layout, formatting, and form fields. 4. Click **Close Preview** or **Edit** to return to the editor. > **Info** > > Preview mode shows your template with placeholder text in all dynamic fields. This helps you check the overall layout and design. > **Tip** > > Always preview your template after making significant changes. This helps catch issues before using the template in production. ## Filled document preview See how your template looks with sample data filled in: 1. Click the **Preview** button. 2. Fill in sample data in the fields panel on the right. 3. Click **Filled Document Preview**. 4. Review how the completed document will look with actual data. > **Tip** > > Use Filled Document Preview to test how your template handles different data lengths and edge cases. This is particularly useful for checking text overflow and field sizing. ## Download form fields Export your template's form field configuration as a JSON file: 1. Locate the **Download Form Fields** button in the top-right corner. 2. Click the button. 3. A JSON file will download to your computer. This JSON file contains all the form field definitions, groups, and configurations from your template. ## Generate PDF Create a PDF version of your template: 1. In the editor or preview mode, click **Generate PDF**. 2. The template will appear as a PDF. 3. You can print the PDF or download it to your computer. > **Info** > > The generated PDF reflects your current template design. Use this to share your template layout or to print physical copies for review. ## Save your template The template automatically saves your work as you edit. You can also manually save: 1. Click the **Save** button in the toolbar. 2. Wait for the confirmation message. 3. Continue editing or close the editor. > **Info — NOTE** > > Templates auto-save every few seconds, so you don't need to manually save frequently. The Save button is available if you want to ensure your latest changes are saved before closing the editor. --- URL: https://knowledge.leegality.com/document-execution/workflows/overview # Workflow Overview Workflows allow you to create, save, and reuse the document sending journey configurations, eliminating repetitive setup. They store all invitee-level and document-level options, ensuring a consistent sending journey each time. **Invitee Level Options** - eSign type - Security settings - 1 or 2 Factor Authentication - GPS Capture (Geo-fencing) - Photo Capture (Face verification and Liveliness detection) - Custom consent - Signing retry attempts **Document Level Options** - Number of signers - Signing order - Signature positioning - Stamp paper requirements Workflow setup only needs to be done once and can be used over and over again. This removes the need for repetitive tasks of preparing documents from scratch each time. Workflows are ideal for frequently executed and complex document journeys, accelerating the process significantly. > **Info — Example - Loan Agreement** > > Your bank provides loans to multiple customers, requiring a loan agreement signed by both parties with all terms and conditions. > > To streamline this process, you can create a workflow and upload your loan agreement PDF or select the loan agreement template with variable fields like Beneficiary Name, Loan Amount, Tenure, and Guarantor. > > One-Time Workflow Configuration as per requirement > > - Add stamp papers as needed > - Add invitee roles such as "Beneficiary" and "Lender" as signers. > - Set a signing order, for example, the beneficiary signs first, followed by the lender. > - Specify the eSign type for each signer. > - Add other invitees as reviewers if needed. > - Configure any invitee-level and signing journey options during workflow creation. > - Set eSign coordinates where the signature would be placed. > > Whenever you need to send a loan agreement document, you don’t need to repeat all the above steps. Instead, run the workflow with a pre-configured sending journey. Provide the contact information of invitees and send the signing invitation. --- URL: https://knowledge.leegality.com/document-execution/workflows/create-workflow # Create a Workflow Creating a workflow is a lot similar to creating a document. > **Info — Note** > > Only admins have permission to create workflows. > **Tip** > > You can clone an existing workflow to modify it according to your needs. click on the **Three dots (⋮)** next to the desired workflow and select **Clone**. ## Step 1: Create a New Workflow 1. Go to the **Workflows** section using the left panel. 2. Click on the **+ Create** button in the top right corner. 3. Enter the **Workflow Name** and click on **Confirm**. This will direct you to the **Create** page. > **Info — Note** > > From here on, you can save the workflow at any stage. ## Step 2: Prepare Your Document 1. Choose how to prepare your workflow: #### Option 1: Upload PDF File(s) **Workflow user can upload:** - **Single PDF File:** Choose this if you want to use single PDF file. - **Multiple PDF Files:** Choose this if you want to use multiple PDF files. 1. Click **Upload** to add document(s) from your computer. > **Info — Note** > > - **Supported file type:** PDF > - **Upload Limit:** 10 files > - **Maximum total size:** 30 MB (15 MB recommended for optimal performance). 2. Drag and drop files into the designated area or browse and select files manually. 3. If multiple PDFs are uploaded, use the up ( ↑ ) and down ( ↓ ) arrows to arrange them in the desired order. > **Note:** When multiple PDFs are uploaded and arranged, they will be merged into a single document before sending for signing. 4. Click the delete icon (🗑️) to remove unwanted files. > **Warning — Important** > > While running the workflow, the workflow runner needs to upload the relevant PDF(s) in the same order. #### Option 2: Use a Template > **Info — Prerequisite** > > You must have an existing template. Learn how to create a [**templates**](https://knowledge.leegality.com/document-execution/template/). 1. Navigate to the **Templates** tab. 2. Select the desired template. 3. (Optional) Enable **Allow user to append single/multiple PDF files to the template** if additional documents need to be attached along with the selected template. 2. Optionally, you can use [folders](https://knowledge.leegality.com/document-execution/manage-documents/folders) to group and manage your document. Select a folder from the dropdown, and when the workflow is run, the document will be saved into the selected folder. > **Tip** > > Enable **Provide instructions for Workflow user** to add instructions for the workflow runner, such as which PDF to use or the required stamp duty. 3. Click **Next**. If you selected a template in Step 2, an additional screen appears before invitee configuration. The left panel shows a preview of the selected template, and the right panel lists all the template fields within it. > **Info — Note** > > The workflow creator cannot fill template fields. This is done by the workflow runner (and optionally the first invitee). Use the **Allow first invitee to fill** toggle to control how template fields are handled at runtime: - **Disabled:** The workflow runner must fill the template fields before sending the document. If there are mandatory fields, the workflow runner must fill them before proceeding in the sending journey. The workflow runner cannot enable this toggle while running the workflow. - **Enabled:** The workflow runner can fill some, all, or none of the fields before sending: - If the workflow runner fills all fields, the first invitee will have no role in template field filling. - If the workflow runner leaves some or all fields empty — including mandatory ones — the document can still be sent. The first invitee will then be required to fill all mandatory fields before proceeding in the signing journey. The workflow runner cannot disable this toggle while running the workflow. --- ## Step 3: Add Stamp Papers ### Use Leegality's Bharat Stamp The workflow creator can predefine stamps or enable the toggle only allowing the workflow runner to select required stamps during runtime. 1. Enable the **Use Stamps** toggle. 2. Choose one of the following stamp usage methods: [**Configure Stamp Series in Workflow**](https://knowledge.leegality.com/document-execution/stamps/use-stamps?type=workflow-creation#use-stamp-series) - **Single Stamp Series:** Select a stamp series from dropdown. Every time the workflow runs, a single stamp from that series will be attached. - **Multiple Stamp Series:** Select a stamp series and specify the number of stamps required. Click **+ Add More** to add another stamps series and specify the number of stamps. The specified number of stamps will be attached. [**Configure Stamp Group in Workflow**](https://knowledge.leegality.com/document-execution/stamps/use-stamps?type=workflow-creation#use-stamp-group-1) - **Use Stamp Group:** Select a stamp group and enter the total stamp value required. Every time the workflow runs, stamps worth the specified amount will be automatically attached to the document. ### Upload your stamp 1. Enable the **Upload Stamp** toggle switch. The workflow creator has the following options: 1. Leave all stamp details blank. 2. Pre-fill the **State, Denomination, and First & Second Party’s Name** during workflow creation. The workflow runner will need to enter required details and upload the stamp paper. --- ## Step 4: Add Invitees To add invitee, click **+ Add Invitee**: - Each invitee’s default role is "*Signer*" with the default eSign type configured in [**Settings ➔ Department ➔ eSignature**](https://knowledge.leegality.com/document-execution/settings/Department/esignature-settings#set-the-default-esign-type). The workflow creator has two options: - Leave the *Name, Email Address* and/or *Phone Number* placeholders empty, allowing the workflow runner to enter these while running the workflow. - Or, enable **Configure Invitee** and provide the *Name* and *Email Address/Phone Number* of the Reviewer. The workflow runner will not be able to modify these details. > **Info — Note** > > If **Configure Invitee** is enabled, the workflow creator must provide at least one invitee's Name and Email/Phone Number. In case of multiple invitee placeholders, the workflow runner can add details for other invitees if not configured by the workflow creator. ### Set Signing Order 1. Toggle **Request invitees to sign in fixed order**: - **Disabled:** All invitees receive the signing link simultaneously. - **Enabled:** Signing links are sent sequentially based on the specified order. > **Tip — Example** > > If there are two signers, the documents would be sent to the second signer only after the first signer has signed the document. 2. Use the up ( ↑ ) and down ( ↓ ) arrows to adjust invitee order. ### Configure Invitee Settings #### eSign Type - [**eSign Type**](https://knowledge.leegality.com/category/esign-types)**:** Choose from Aadhaar, DSC, Doc Signer, Virtual Sign, Visual Sign, or Quick Sign. #### Invitee Type - [**Reviewer:**](https://knowledge.leegality.com/document-execution/leegality-features/invitee-level/types-of-invitee/reviewer?type=v3-workflow&journey=workflow-creation) A non-signing invitee who needs to review the document’s content and then approve or reject it. - [**Group Invitee:**](https://knowledge.leegality.com/document-execution/leegality-features/invitee-level/types-of-invitee/group-invitee?type=workflow) A Group Invitee allows multiple signers, but only a specified number of signers need to sign. - **For example**, if a group has three authorized signers and any two signatures are required, the document progresses once two members sign. - [**CC Invitee:**](https://knowledge.leegality.com/document-execution/leegality-features/invitee-level/types-of-invitee/cc?type=v3-workflow&journey=workflow-creation) A CC Invitee does not sign the document but receives notifications about the document's progress. - **Invitation & Reminders:** When an invitation is sent, resent, or nearing expiry. - **Signing Progress:** When an invitee signs, a reviewer approves/rejects, or the document is completed. - **Failures & Expiry:** If signing fails due to expiry, face match, liveliness, or location issues. - **Final Documents:** Completed document and audit trail upon signing completion. #### Security Features - **Authentication:** Invitees must authenticate their identity before accessing the document to ensure only the intended recipient can proceed. - [**One-factor Authentication**](https://knowledge.leegality.com/document-execution/leegality-features/invitee-level/security/one-factor-authentication?type=workflow)**:** OTP verification via email or phone number. - [**Two-factor Authentication**](https://knowledge.leegality.com/document-execution/leegality-features/invitee-level/security/two-factor-authentication?type=workflow)**:** OTP verification via both email and phone number. - **GPS Location:** - [**Capture GPS Location:**](https://knowledge.leegality.com/document-execution/leegality-features/invitee-level/security/capture-gps-location?type=workflow) Record the invitee's location at the time of signing the document. - [**Accuracy-based restriction:**](https://knowledge.leegality.com/document-execution/leegality-features/invitee-level/security/capture-gps-location?type=workflow) Don’t allow the invitee to sign if the captured location is not accurate up to a certain number of meters. - [**Location-based restriction:**](https://knowledge.leegality.com/document-execution/leegality-features/invitee-level/security/capture-gps-location?type=workflow) Restrict signing if the signer is outside of the configured area. - **Identity Verification** - [**Face Capture:**](https://knowledge.leegality.com/document-execution/leegality-features/invitee-level/security/capture-photo?type=workflow) Capture the photo of the signer before allowing them to sign the document. - [**Face Match:**](https://knowledge.leegality.com/document-execution/leegality-features/invitee-level/security/face-match?type=workflow) Capture the photo of the signer and match it against the reference image uploaded by the sender. - **User Liveliness![External Link](https://knowledge.leegality.com/img/external-link-svgrepo-com.svg):** Ensure real-time presence of the signer. - [**Manual User Liveliness (OTP-based):**](https://knowledge.leegality.com/document-execution/leegality-features/invitee-level/security/manual-liveliness?type=workflow) The signer needs to capture a photo of themselves while showing the OTP appearing on the screen. - [**Smart User Liveliness (AI-powered):**](https://knowledge.leegality.com/document-execution/leegality-features/invitee-level/security/smart-user-liveliness) AI-based solution that ensure the person sitting in front of camera is actively present there. It detects spoofs like photo and pre-recorded videos. #### Signature Appearance - [**Invitee Name on Signature:**](https://knowledge.leegality.com/document-execution/leegality-features/invitee-level/esignature-appearance/invitee-name-in-signature?type=workflow) Choose whether to display the invitee’s name in the signature. - [**Company Seal:**](https://knowledge.leegality.com/document-execution/leegality-features/invitee-level/esignature-appearance/company-seal?type=workflow) Ask invitee to upload the image company (organization) seal. If the signer has a Leegality account, the company seal will auto-fill based on the preferences. - [**Invitee Name Editing:**](https://knowledge.leegality.com/document-execution/leegality-features/invitee-level/esignature-appearance/invitee-name-editing?type=workflow) Allow or restrict name editing during signing. #### Other Features - [**Custom Webhook and URL:**](https://knowledge.leegality.com/document-execution/leegality-features/invitee-level/custom-url-and-webhook/webhook-and-url?type=workflow) Enable integrations for real-time updates. - [**Supporting Documents:**](https://knowledge.leegality.com/document-execution/leegality-features/invitee-level/other-features/supporting-documents?journey=workflow-creation&version=v3) The Supporting document helps you request additional documentation, which invitee needs to upload during signing journey. - [**Additional Consent Terms:**](https://knowledge.leegality.com/document-execution/leegality-features/invitee-level/other-features/additional-consent?type=v3-workflow&journey=workflow-creation) Add custom terms and conditions alongside default consent. - [**Mask Contact Details:**](https://knowledge.leegality.com/document-execution/leegality-features/invitee-level/other-features/mask-contact-details?type=workflow) Hide other invitees' contact details for privacy. - [**Reject to Sign:**](https://knowledge.leegality.com/document-execution/leegality-features/invitee-level/other-features/reject-to-sign?type=workflow) Provide an option to reject to sign the document. --- ## Step 5: Configure Document Settings - [**Signing Link Expiry**](https://knowledge.leegality.com/document-execution/leegality-features/document-level/document-expiry?type=workflow)**:** Set a deadline for invitees to sign or review the document. The signing or reviewing link can expire: - After a specific number of days - Within 45 minutes - By the end of the day Once expired, the invitee cannot access the document. Sender needs to re-activate the document. - [**Custom Message**](https://knowledge.leegality.com/document-execution/leegality-features/document-level/custom-message?type=workflow)**:** Add a personalized note to the email body. - **Auto delete document after completion:** Enabling this will result in your copy of the document being deleted from the Leegality’s servers after the duration configured in [**Document Settings**](https://knowledge.leegality.com/document-execution/settings/Department/document-security-settings#auto-delete-after-document-completion). --- ## Step 6: Notification Delivery Method Select methods for sending signing or reviewing invitation, reminders and other updates. Available delivery methods are: - Email - SMS - WhatsApp 1. Click **More Options**. 2. Enable or disable **Email, SMS, and/or WhatsApp Notifications**. > **Info — Note** > > For CC invitees, only email notifications are available. --- ## Step 7: Place Signature Coordinates A signature coordinate is where you want the invitee’s signature to be on the document. By default, signature coordinates are placed at the bottom-left corner of every page in the document. To place signature coordinates in your desired place: 1. Hover over **☰** icon and select **custom coordinate**. 2. Click on the document where you want to place the signature. 3. Use the dropdown to assign the signer. The signature placeholder size can be increased or decreased as per requirement by simply dragging from its edges. > **Info — Note** > > #### How Signatures are Placed on Multiple Stamps in a Workflow > > At the **Preview** stage, only one stamp paper is displayed—even if multiple stamp papers are attached. > > The signature coordinates you set on the reference stamp are automatically replicated across all attached stamps. This means all stamps will have the identical signature layout. --- ## Step 8: Preview and Save Once you have added the document, invitees, and signature coordinates, you can preview the workflow configuration. - Click the **View Invitees** button to review all invitees associated with the document. - Click **Save**. Your workflow is now published and ready to use. --- URL: https://knowledge.leegality.com/document-execution/workflows/run-workflow # Run a Workflow #### Via Dashboard ## Via Dashboard 1. Click on the **Workflows** in the left panel. 2. Find the workflow you want to run. (**Note:** You can search by workflow name or ID.) 3. To run the workflow; - **For a template workflow:** Click on the **Three dots (⋮)** and select **Run**. - **For a PDF workflow:** Click on the **Run** button on the right. > **Info — Note** > > Options available for you to use is the matter of [**workflow creation**](https://knowledge.leegality.com/document-execution/workflows/create-workflow). --- ### Step 1: Prepare Your Document Depending on the workflow configuration, you may need to upload a pdf or the template which was configured in the workflow creation stage will be automatically selected. 1. **Name the Document:** Enter the name of the document. The document name will appear in the email subject and body. > **Tip — Example** > > **Email Subject:** “Invitation to eSign: Service Level Agreement” 2. **Internal Reference Number:** Enter the Internal Reference Number for the document. The **Name** and **Internal Reference Number (IRN)** fields have a maximum character limit of 255. The following special characters are allowed: **| - : ( ) , _. [ ] &/**. --- ### Step 2: Add Stamps Papers Depending on the workflow configuration, you may have options to select or simply confirm the stamp settings when running the workflow. > **Info — Note** > > The options below are based on the workflow configuration. Not all workflows will allow selection or modification of stamp settings. #### Single Stamp Series **Option 1:** - You must select a stamp series from the dropdown. This selection is mandatory to proceed. **Option 2:** - The workflow creator has fixed the stamp series, which cannot be disabled or modified. #### Multiple Stamp Series #### Multiple Stamp Series **Option 1:** - You may select a stamp series and specify the number of stamps to attach. This is optional; you can proceed without making a selection. **Option 2:** - The stamp series is fixed by the workflow creator, but you must enter the number of stamps to use from that series. You cannot select any other series. **Option 3:** - Both the stamp series and the stamp quantity are fixed by the workflow creator and cannot be changed. #### Revenue Stamp #### Revenue Stamp **Option 1:** - You may select a Revenue stamp series and specify the number of revenue stamps to attach. This is optional; you can proceed without making a selection. **Option 2:** - The Revenue stamp series is fixed by the workflow creator, but you must enter the number of revenue stamps. You cannot select a different Revenue stamp series. **Option 3:** - Both the Revenue stamp series and the number of revenue stamps are fixed by the workflow creator and cannot be changed. #### Stamp Group #### Stamp Group **Option 1:** - You can select a stamp group and specify the total stamp value to be attached. Both the selection and the stamp value are mandatory to proceed. **Option 2:** - The stamp group is fixed by the workflow creator, but you must enter the stamp value. You cannot select a different stamp group. **Option 3:** - Both the stamp group and the stamp value are preset by the workflow creator and cannot be modified. --- ### Fill Template Fields (Optional) > **Info — Conditional Step** > > This step appears only when the workflow uses a template with fillable fields. If your workflow includes a template with form fields, you will have the option to fill them before proceeding. The Fill Template screen is divided into two sections: - **Left Panel - Live Preview:** Displays a real-time preview of the document as you fill in the fields. Changes made on the right are immediately reflected here. - **Right Panel - Form Fields:** Lists all available fields in the template. Enter or select values for each field as required. As you complete each field on the right, the corresponding field in the document preview on the left updates instantly, allowing you to verify your entries before continuing. > Sender can enable **Allow first invitee to fill** to allow the first invitee in the signing order to fill the template fields before signing the document. > **Tip — Best Practice** > > We recommend filling template fields at this stage rather than during the signing journey. When fields like addresses or descriptions are filled, they may expand and shift the document content downward. Since signature coordinates are placed at fixed positions on the document, filling fields beforehand ensures that signatures align perfectly with the final document layout. Once you've filled all required fields, click **Next** to proceed. --- ### Step 3: Invite Configuration > **Info — Note** > > All settings configured during workflow creation are automatically applied here. The availability of certain features depends on the workflow creator’s configuration. #### eSign Type eSign type will be enforced as defined during the workflow creation and cannot be modified. - [**eSign Type**](https://knowledge.leegality.com/category/esign-types)**:** Choose from Aadhaar, DSC, Doc Signer, Virtual Sign, Visual Sign, or Quick Sign. #### Invitee Type > **Info — Note** > > The workflow runner cannot change the invitee type. You can only enter the invitee-specific parameters—such as Name and Contact Details (Email or Phone) when running the workflow. - [**Reviewer:**](https://knowledge.leegality.com/document-execution/leegality-features/invitee-level/types-of-invitee/reviewer) A non-signing invitee who needs to review the document’s content and then approve or reject it. - [**Group Invitee:**](https://knowledge.leegality.com/document-execution/leegality-features/invitee-level/types-of-invitee/group-invitee) A Group Invitee allows multiple signers, but only a specified number need to sign. - **For example**, if a group has three authorized signers and any two signatures are required, the document progresses once two members sign. - [**CC Invitee:**](https://knowledge.leegality.com/document-execution/leegality-features/invitee-level/types-of-invitee/cc) A CC Invitee does not sign the document but receives notifications about the document's progress. - **Invitation & Reminders:** When an invitation is sent, resent, or nearing expiry. - **Signing Progress:** When an invitee signs, a reviewer approves/rejects, or the document is completed. - **Failures & Expiry:** If signing fails due to expiry, face match, liveliness, or location issues. - **Final Documents:** Completed document and audit trail upon signing completion. #### Security Features The availability of these security features depends on the workflow configuration. If not enabled during workflow creation, they may not be applicable. - **Authentication:** Invitees must authenticate their identity before accessing the document to ensure only the intended recipient can proceed. - [**One-factor Authentication**](https://knowledge.leegality.com/document-execution/leegality-features/invitee-level/security/one-factor-authentication)**:** OTP verification via email or phone number. - [**Two-factor Authentication**](https://knowledge.leegality.com/document-execution/leegality-features/invitee-level/security/two-factor-authentication)**:** OTP verification via both email and phone number. - **GPS Location:** If Allow Workflow Runner Modifications was enabled during workflow creation then the workflow runner can input or modify the Accuracy Threshold, Latitude-Longitude, and Permissible Radius while running the workflow. - [**Capture GPS Location:**](https://knowledge.leegality.com/document-execution/leegality-features/invitee-level/security/capture-gps-location?type=new-document-journey) Record the invitee's location at the time of signing the document. - [**Accuracy-based restriction:**](https://knowledge.leegality.com/document-execution/leegality-features/invitee-level/security/capture-gps-location?type=new-document-journey) Don’t allow the invitee to sign if the captured location is not accurate up to a certain number of meters. - [**Location-based restriction:**](https://knowledge.leegality.com/document-execution/leegality-features/invitee-level/security/capture-gps-location?type=new-document-journey) Restrict signing if the signer is outside of the configured area. - **Identity Verification** - [**Face Capture:**](https://knowledge.leegality.com/document-execution/leegality-features/invitee-level/security/capture-photo) Capture the photo of the signer before allowing them to sign the document. - [**Face Match:**](https://knowledge.leegality.com/document-execution/leegality-features/invitee-level/security/face-match) Capture the photo of the signer and match it against the reference image uploaded by the sender. - **User Liveliness![External Link](https://knowledge.leegality.com/img/external-link-svgrepo-com.svg):** Ensure real-time presence of the signer. - [**Manual User Liveliness (OTP-based):**](https://knowledge.leegality.com/document-execution/leegality-features/invitee-level/security/manual-liveliness) The signer needs to capture a photo of themselves while showing the OTP appearing on the screen. - [**Smart User Liveliness (AI-powered):**](https://knowledge.leegality.com/document-execution/leegality-features/invitee-level/security/smart-user-liveliness) AI-based solution that ensure the person sitting in front of camera is actively present there. It detects spoofs like photo and pre-recorded videos. #### Signature Appearance The features listed below are available only if configured in the workflow. - [**Invitee Name on Signature:**](https://knowledge.leegality.com/document-execution/leegality-features/invitee-level/esignature-appearance/invitee-name-in-signature) Choose whether to display the invitee’s name in the signature. - [**Company Seal:**](https://knowledge.leegality.com/document-execution/leegality-features/invitee-level/esignature-appearance/company-seal) Ask invitee to upload the image company (organization) seal. If the signer has a Leegality account, the company seal will auto-fill based on the preferences. - [**Invitee Name Editing:**](https://knowledge.leegality.com/document-execution/leegality-features/invitee-level/esignature-appearance/invitee-name-editing) Allow or restrict name editing during signing. #### Other Features The features listed below are available only if configured in the workflow. - [**Custom Webhook and URL:**](https://knowledge.leegality.com/document-execution/leegality-features/invitee-level/custom-url-and-webhook/webhook-and-url) Enable integrations for real-time updates. - [**Supporting Documents:**](https://knowledge.leegality.com/document-execution/leegality-features/invitee-level/other-features/supporting-documents) The Supporting document helps you request additional documentation, which invitee needs to upload during signing journey. - [**Additional Consent Terms:**](https://knowledge.leegality.com/document-execution/leegality-features/invitee-level/other-features/additional-consent) Add custom terms and conditions alongside default consent. - [**Mask Contact Details:**](https://knowledge.leegality.com/document-execution/leegality-features/invitee-level/other-features/mask-contact-details) Hide other invitees' contact details for privacy. - [**Reject to Sign:**](https://knowledge.leegality.com/document-execution/leegality-features/invitee-level/other-features/reject-to-sign) Provide an option to reject to sign the document. --- ### Step 4: Document-level configurations - [**Signing Link Expiry**](https://knowledge.leegality.com/document-execution/leegality-features/document-level/document-expiry)**:** Set a deadline for invitees to sign or review the document. The signing or reviewing link can expire: - After a specific number of days - Within 45 minutes - By the end of the day Once expired, the invitee cannot access the document. Sender needs to re-activate the document. - [**Transfer Completed Document**](https://knowledge.leegality.com/document-execution/leegality-features/document-level/sftp)**:** Automatically transfer signed documents via SFTP. - [**Custom Message**](https://knowledge.leegality.com/document-execution/leegality-features/document-level/custom-message)**:** Add a personalized note to the email body. Once all necessary details are entered, click **Next** to continue. --- ### Step 5: Finalize Page This page provides a preview of the final document that will be sent out for signing. Here, you can verify the signature coordinates as configured in the workflow. - **Signature Coordinates:** - The signature placement is fixed according to the workflow configuration. - If invitee details for any signature coordinate are left blank, that signature box will remain empty. > **Tip — Example** > > In a workflow with three invitees, if the second invitee's details are not provided, the corresponding signature coordinate box will remain empty as well. - **Final Check:** - Review the preview to ensure all elements (including signature coordinates) appear as expected. - Once satisfied, click **Send**. After clicking **Send**, your workflow is executed and the document is dispatched for signing. You will be redirected to the Document Details page to monitor progress and view invitee actions. #### Via API ## Via API **Prerequisites** * [Auth token](https://knowledge.leegality.com/document-execution/settings/account-level/API/how-to-enable-api.md) * Workflow API payload To run a workflow via API, you need a request body which is called API payload. To download it 1. Click on the **Workflows** in the left panel. 2. Find the workflow you want to run. (**Note:** You can search by workflow name or ID.) 3. Click on the **three dots (⋮)** and select the **Download API Payload** option. A JSON file containing the workflow configuration will be downloaded. Use this file in a API 3.0 POST request to create an eSign request. > **Tip — **For more information:**** > > To learn how to create an eSign request using the API, refer to the [**API Reference Guide**](https://www.leegality.com/api-reference-guide/api-reference-guide). > > To explore available API 3.0 methods, check out the [**API Documentation**](https://docs.leegality.com/v3\#tag/Document-Execution-Platform). --- URL: https://knowledge.leegality.com/document-execution/workflows/excel-upload/run-workflow # Run Workflow via Excel Upload > **Info — Using a v4 workflow?** > > This page covers v3 workflows. For v4 workflows, see [Run a v4 workflow via Excel Upload](https://knowledge.leegality.com/document-execution/workflows/v4/excel-upload/run-via-excel-upload). The Excel Upload is a way to send out documents for eSignature in bulk by uploading an Excel file with invitee specific information. ## Excel Upload via Dashboard > **Info — Note** > > Excel Upload only works for template-type workflows. 1. Click on **Workflows** in the left panel. 2. Locate the workflow you want to run by searching for the workflow name or ID. 3. Click on the **Upload** button on the right of the workflow. 4. In the pop-up, click on the **Download Excel** button. The downloaded Excel file will serve as a template. The workflow runner needs to fill in the following details: * **Document Details:** Document Name and IRN * **Stamp Details:** Stamp Series to be used and the number of stamp papers to be affixed * **Template Fields:** Fields required in the template * **Sending Journey Details** * **Invitee Details:** Invitee name, email address, and/or phone number > **Info** > > Here, you can learn [**how to fill an Excel template**](https://knowledge.leegality.com/document-execution/workflows/excel-upload/fill-excel-file) 5. After filling in the Excel template, click the **Upload** button. 6. A pop-up will open; upload the Excel file and click the **Upload** button. 7. After uploading, you will be redirected to the **Reports** section to check if the file was successfully uploaded. > **Warning** > > To ensure a successful upload, your Excel file must not contain: > > - **Formulas** — values must be entered directly, not as `=A1+B1` or any other formula. > - **Invisible or special characters** — extra spaces, line breaks, tabs, or hidden characters inside parameter values can cause the upload to fail silently. > > If your upload is stuck on **In Process** in the Reports section, make sure to remove any hidden characters and re-upload. ## Excel Upload via Email You can also run a workflow by emailing the Excel file as an attachment. 1. In the workflows section, find the workflow you want to run. 2. Click on the workflow name to open the detail view. 3. Here, you will see the **Upload Email Address**. You can also run a workflow by emailing the Excel file to this email address. > **Info — Note** > > The sender’s email address needs to be added as an Authorized Email address beforehand. To add an email to the Authorized Email address: 1. Click on the **Three dots (⋮)** on the right and select the **Edit** option. 2. In the pop-up, select the **Invitee Configuration** and click on **Confirm**. 3. In the next screen, click on the **Advanced option** in the bottom left corner. 4. Toggle on the Authorized Emails option and enter the email address(es) in the field, separating multiple addresses with a comma. 5. Click **Save**, then **Save and Exit** to save the workflow configuration. Now, you can send the Excel file as an attachment to the Upload Email address. Ensure the sender’s email is added as the authorized email address. --- URL: https://knowledge.leegality.com/document-execution/workflows/excel-upload/fill-excel-file # How to Fill Excel Template > **Info — Using a v4 workflow?** > > This page covers v3 workflows. For v4 workflows, see [Fill the v4 Excel template](https://knowledge.leegality.com/document-execution/workflows/v4/excel-upload/fill-excel-template). The Excel template is designed to streamline document sending process. Each row in the template represents a single document, ensuring that multiple documents can be processed efficiently for different groups of invitees. ### How Excel Upload Works? Every row in the spreadsheet corresponds to a distinct document that needs to be sent to a unique set of invitees. > **Tip — **Example**** > > - **Row 1:** A document sent to Invitee A, Invitee B, and Invitee C. > - **Row 2:** A separate document sent to Invitee D, Invitee E, and Invitee F. > > You can add multiple rows to send the same document to different groups separately. ## Understanding the Excel Template Before filling out the template, it is essential to understand its structure and restrictions. ### Preview of the Template When running a workflow via Excel upload, it is crucial to maintain the integrity of the spreadsheet template to ensure seamless processing. Please adhere to the following guidelines: - **Preserve the Header Row:** Do not alter the header row in the template, as changes can disrupt the workflow's functionality. - **Avoid Modifying Specific Columns:** Columns labeled **`field(n).id`** and **`field(n).name`** are essential for mapping data accurately. Refrain from making any changes to these columns. > **Info — Please Note** > > - **Color Codes for Guidance:** While reference materials may use color codes (e.g., orange) to highlight specific columns, these colors are for instructional purposes only and are not present in the actual template. - **Custom Mapping for Different Field Names:** If you're using a custom spreadsheet with field names that differ from those in the Leegality template, you'll need to set up [custom mapping](https://knowledge.leegality.com/document-execution/workflows/excel-upload/custom-mapping). This process aligns your internal spreadsheet fields with Leegality's required fields, facilitating accurate data integration. By following these guidelines, you can ensure that your workflows operate smoothly and that all necessary data is correctly processed within the Leegality platform. ## Template Fields & Data Input ### Field Components Each form field in the document has **three key components**: - **field.id**: A unique identifier for each form field. (*Do not modify this value.*) - **field.name**: The label for the field in the document. (*For reference only, do not change this.*) - **field.value**: The actual input value for the field. (*This is the field you need to fill.*) ### Field Types & Accepted Formats #### Radio Button #### Radio Button A single-choice selection from predefined options. - Each option has a separate `field.id`, `field.name`, and `field.value`. - Enter **`TRUE`** in the `field.value` for the selected option. > **Info — Note** > > Ensure only one `field.value` is marked as **`TRUE`** per radio button group. > **Tip — Example** > > Suppose there is a radio button field for **Gender**, with three options: **Male**, **Female**, and **Other**. > > Each option is a separate field with a unique `field.name`, such as `gender(Male)`, `gender(Female)`, and `gender(Other)`. > > If the user selects **Female**, then the `field.value` for `gender(Female)` should be set to `TRUE`, while the `field.value` for both `gender(Male)` and `gender(Other)` should be left empty. This ensures only one option is selected, as required for radio buttons. #### Checkbox #### Checkbox Allows multiple selections from predefined options. - Multiple options are available, each with its own `field.id`, `field.name`, and `field.value`. - Enter **`TRUE`** in the `field.value` to select an option. > **Info — Note** > > You can select multiple options by entering **`TRUE`** in multiple rows. > **Tip — Example** > > Suppose there is a checkbox field for **Preferred Communication Channels**, with three options: **Email**, **Phone**, and **WhatsApp**. > > Each option is a separate field with a unique `field.name`, such as `communication(Email)`, `communication(Phone)`, and `communication(WhatsApp)`. > > If the user selects **Email** and **WhatsApp**, then the `field.value` for `communication(Email)` and `communication(WhatsApp)` should be set to `TRUE`, while the `field.value` for `communication(Phone)` should be left empty. This allows multiple selections, as expected from checkboxes. #### Dropdown #### Dropdown A collapsible list for selecting one option. - Enter the **exact text** of the selected option in the `field.value`. > **Tip — Example** > > Suppose there is a dropdown field for **Country of Residence**, with options like **India**, **Canada**, and **Australia**. > > This is a single field with the `field.name` as `country_of_residence`. > > If the user selects **Canada**, then the `field.value` for `country_of_residence` should be set to `"Canada"`. The value must match the exact text of the selected option. #### Textbox #### Textbox A field for entering freeform text. - Enter any required text input in the `field.value`. > **Tip — Example** > > Suppose there is a textbox field for **Full Name**. > > This is a single field with the `field.name` as `full_name`. > > If the user enters **Ayesha Khan**, then the `field.value` for `full_name` should be set to `"Ayesha Khan"`. The textbox allows freeform text input. #### Date #### Date A field for entering a date. - Use the format **dd-mm-yyyy** unless specified otherwise. > **Info — Note** > > Ensure the date format matches the expected input in the document. > **Tip — Example** > > Suppose there is a date field for **Date of Birth**. > > This is a single field with the `field.name` as `date_of_birth`. > > If the user enters **12th April 1995**, then the `field.value` for `date_of_birth` should be set to `"12-04-1995"`. The date must follow the **dd-mm-yyyy** format unless specified otherwise. #### Image Upload #### Image Upload A field for storing an image as a Base64-encoded string. - Enter a **Base64 encoded URL** of the image in the `field.value`. > **Tip — Example** > > Suppose there is an image upload field for **Profile Photo**. > > This is a single field with the `field.name` as `profile_photo`. > > If the user uploads an image, the `field.value` for `profile_photo` should contain a **Base64-encoded string** representing that image — for example, `"data:image/png;base64,iVBORw0KGgoAAAANSUhEUg..."`. ## Configuring Invitees #### Invitee ### Invitee Contact Details Invitees can be designated as Signers or Reviewers. For each invitee, provide the following information: - **Invitee(0).name:** Full name of the invitee. - **Invitee(0).email:** Email address for sending notifications and signing links. - **Invitee(0).phone:** Phone number for SMS notifications and OTP verifications. ### Group Invitee Details Group Invitees allow multiple participants to sign or review a document, with a specified number required for completion. To configure a group: - **InviteeGroup(1).name:** Name of the group. - **InviteeGroup(1).completion_threshold:** Number of invitees required to complete the group's action. - **Group(1).Invitee(0).name:** Name of each invitee within the group. - **Group(1).Invitee(0).email:** Email address of each group invitee. - **Group(1).Invitee(0).phone:** Phone number of each group invitee. ### CC (Carbon Copy) Invitee Contact Details CC invitees receive updates about the document's progress but do not participate in signing or reviewing. For each CC invitee, provide: - **CC(0).name:** Full name of the CC invitee. - **CC(0).email:** Email address for receiving notifications. > **Info — Note** > > If the workflow creator has pre-configured certain invitee contact details, these will take precedence over any information provided in the Excel template. #### Stamp ### Stamp Details Leegality offers a few ways to affix stamp papers to documents digitally. Depending on your requirements, configure one of the following: #### Single Stamp Series - **Stamp Series:** Specify the stamp series number to use a single stamp paper from the selected series. > **Info — Note** > > If the workflow creator has pre-configured the stamp series, the workflow runner will not get the option to fill the stamp series details in the Excel Template. #### Multiple Stamp Series #### Multiple Stamp Series To configure multiple stamp series for a document, enter the following details in the Excel template. - **multipleStampSeries(n).stampSeries:** Specify the stamp series number. - **multipleStampSeries(n).seriesQuantity:** Specify how many stamps to affix from this series. > **Tip — Example of Multiple Stamp Series in Excel Upload** > > If a workflow includes one stamp series, the fields will be: > > * `multipleStampSeries(0).stampSeries` > * `multipleStampSeries(0).seriesQuantity` > > If two stamp series are configured, the fields will be: > > * For the first stamp series: > > * `multipleStampSeries(0).stampSeries` > * `multipleStampSeries(0).seriesQuantity` > * For the second stamp series: > > * `multipleStampSeries(1).stampSeries` > * `multipleStampSeries(1).seriesQuantity` > > Each additional stamp series follows the same pattern, with the index increasing by 1 for each new entry. > **Info — Note on Pre-Configured Stamp Series** > > - If the *workflow creator has pre-filled stamp series and quantities*, the *workflow runner will not* get the option to fill stamp details in the Excel Template. > - If *only the stamp series is pre-filled* (not the quantity), the *Excel template will have `multipleStampSeries(0).stampSeries` pre-filled*, the *workflow runner must fill in the `multipleStampSeries(0).seriesQuantity`*. > - If *one of the stamp series is fully pre-configured* and another is not: > - The pre-configured series will be hidden in the Excel template. > - The workflow runner must fill in the stamp details only for the remaining series. #### Stamp Group #### Stamp Group - **Stamp Group:** Specify the stamp group number to use a combination of stamp papers. - **Stamp Amount:** Total value of stamps to affix to the document. > **Info — Note** > > If the workflow creator has pre-configured the stamp group and stamp amount, the workflow runner will not get the option to fill the stamp details in the Excel Template. #### GPS Location ### GPS Location Settings To enhance security, you can restrict document signing based on the invitee's geographic location. Configure the following as needed: ### For Single Invitee --- #### **Geo-fencing (Latitude and Longitude Based Restriction):** - **Invitee(0).gps.allowedLatitude:** Latitude coordinate where signing is permitted. (Format: XX.XXXXX, range: -90 to 90) - **Invitee(0).gps.allowedLongitude:** Longitude coordinate where signing is permitted. (Format: XX.XXXXX, range: -180 to 180) - **Invitee(0).gps.permissibleRadius:** Radius (in meters) around the specified coordinates within which signing is allowed. > **Info — Note** > > 1. **When "Allow sender to make changes while running the workflow" is *disabled*:** > > * If **Apply location based restrictions** is enabled but the **Latitude**, **Longitude**, and **Permissible Radius** are *not* pre-filled by the workflow creator: > > → The workflow runner needs to provide the **Latitude**, **Longitude**, and **Permissible Radius** in the excel template. > > 2. **When "Allow sender to make changes while running the workflow" is *enabled*:** > > * Regardless of whether **"Location-based restriction"** is enabled or disabled: > > → The workflow runner can optionally provide **Permissible Radius** in the Excel Template. If left blank, no such restrictions will apply to the invitee. #### **Accuracy Based Restriction:** - **Invitee(0).gps.accuracyThreshold:** Required accuracy (in meters) of the captured location to proceed with signing. > **Info — Note** > > 1. **When "Allow sender to make changes while running the workflow" is *disabled*:** > > * If **Apply accuracy-based restrictions** is enabled but the **Accuracy Threshold** is *not* pre-filled by the workflow creator: > > → The workflow runner will not be able to enter this value in the Excel Template. Instead, the default value from *Settings > Department > Invitee Configs* will apply. > * If the **Accuracy Threshold** *is* pre-filled: > > → The workflow runner cannot edit this value in the Excel Template. > 2. **When "Allow sender to make changes while running the workflow" is *enabled*:** > > * Regardless of whether **"Accuracy-based restriction"** is enabled or disabled: > > → The workflow runner can optionally provide **Accuracy Threshold** in the Excel Template. If left blank, no such restrictions will apply to the invitee. #### For Group Invitee If geo-fencing is enabled for a group invitee, configure the following: - **InviteeGroup(0).gps.allowedLatitude** - **InviteeGroup(0).gps.allowedLongitude** - **InviteeGroup(0).gps.permissibleRadius** - **InviteeGroup(0).gps.accuracyThreshold** #### Company Seal ### Company Seal If the document requires a company or organizational seal: - **Invitee(0).organization.name:** Name of the signer's organization to appear as the company seal in the signature. If left blank, the invitee will be prompted to provide this information during the signing process. #### Certificate Verification ### Certificate Verification To ensure the authenticity of the signer, configure verification against official certificates such as Aadhaar or DSC (Digital Signature Certificate). #### Aadhaar Certificate Details - **Invitee(0).aadhaar.verifyPincode:** PIN code as per the invitee's Aadhaar. - **Invitee(0).aadhaar.verifyYob:** Year of birth as per Aadhaar records. - **Invitee(0).aadhaar.verifyTitle:** Last four digit of Aadhaar Number. - **Invitee(0).aadhaar.verifyGender:** Gender as mentioned in Aadhaar. - **Invitee(0).aadhaar.verifyState:** State of residence as per Aadhaar. #### DSC Token Certificate Details - **Invitee(0).dsc.verifyPincode:** PIN code associated with the invitee's DSC. - **Invitee(0).dsc.verifyState:** State as recorded in the DSC. ## Common Mistakes to Avoid ✅ **Do not modify header fields** – they are essential for processing. ✅ **Ensure required fields are filled** – missing values can cause errors. ✅ **Match data formats** – dates, dropdown values, stamp series, and others must follow specified formats. ✅ **Make sure not to change the headers** – enter data only in the rows below the pre-filled headers, and do not modify, delete, or duplicate the header row. ✅ **Do not change the column structure** – altering the existing columns can cause the upload to fail. > **Info — Upload still failing?** > > If the error persists, the template's data fields may have been modified. Download a fresh Excel template and re-enter your data. Once the file is updated, upload the corrected Excel sheet and try again. --- URL: https://knowledge.leegality.com/document-execution/workflows/excel-upload/custom-mapping # Custom Mapping > **Info — Using a v4 workflow?** > > This page covers v3 workflows. For v4 workflows, see [Custom Mapping for v4 Excel Upload](https://knowledge.leegality.com/document-execution/workflows/v4/excel-upload/custom-mapping). The custom mapping allows you to map your internal spreadsheet to the fields available in the Leegality-generated spreadsheet, streamlining the process of uploading user-formatted spreadsheets instead of the standard Leegality template. This mapping process is a one-time setup and only needs to be revisited if there are changes in the template variable fields, prompting updates to the spreadsheet template. ## To do Custom Mapping in workflow: 1. Select **Workflows** from the left panel. 2. Locate the relevant workflow and click on the **Three Dots (⋮)** on the right. 3. Select **Custom Mapping**. 4. Upload your excel file and click **Upload**. (Supported format xls and xlsx.) Leegality will extract the column headers from your uploaded spreadsheet and present them in a dropdown menu against each field in the Leegality Excel Column Headers. 5. Each field can be mapped to a corresponding header in your internal spreadsheet. 6. Once all fields are mapped, you can use your internal spreadsheet to send out workflows seamlessly. By utilizing custom mapping, users can leverage their existing spreadsheet formats within the Leegality platform, enhancing efficiency and user experience. --- URL: https://knowledge.leegality.com/document-execution/workflows/edit-workflow # Edit a workflow Editing a workflow allows you to make changes to specific stages of your workflow configuration even after it has been created and published. You can modify document settings, adjust invitee configurations, or update signature placement without rebuilding the workflow from scratch. > **Info — Note** > > Editing a workflow does not affect documents that have already been sent. Changes only apply to documents sent using the modified workflow after the edits are saved. ## How to edit a workflow 1. Go to **Dashboard** and select **Workflows** from the left panel. 2. Locate the workflow you want to edit. 3. Click on the **Three Dots (⋮)** on the right side of the workflow. 4. Select **Edit** from the dropdown menu. 5. A dialog box appears with three options. Choose the stage you want to modify and click **Confirm**. ### Document Configuration Select this option to make changes to the document preparation stage of your workflow. You can: * Choose a different template or change template settings * Add or remove PDF files * Update stamp usage settings (stamp series, stamp groups, or uploaded stamps) * Change instructions for workflow runners ### Invitee Configuration Select this option to modify invitee-related settings. You can: * Add or remove invitees from the workflow * Change invitee roles (Signer, Reviewer, Group Invitee, CC) * Modify eSign type and configuration for each invitee * Update signing order settings * Adjust security features (authentication, GPS location, identity verification) * Configure notification delivery methods (Email, SMS, WhatsApp) * Modify signature appearance settings * Update other invitee-specific options (webhooks, supporting documents, additional consent) * Update the invitation expiry, for example after the [**account-level invitation expiry**](https://knowledge.leegality.com/document-execution/settings/account-level/document-setting/Invitation-expiry-for-sent-documents-account-defaults) has changed ### Signature Placement Select this option if you only want to change signature coordinate placement on the document. This allows you to: * Adjust the position of signature boxes on the document * Add or remove signature placements > **Tip** > > If you only need to adjust signature positions, use the Document Placement option to skip directly to that stage and save time. ## Save your changes After making your edits in the selected stage: 1. Review your changes carefully. 2. Click **Save** to apply the modifications to the workflow. ## Download API payload after editing If you use API to run workflows, you must download the updated JSON payload after editing a workflow. The previous payload will not reflect your recent changes. To download the updated API payload: 1. Go to **Dashboard** and select **Workflows** from the left panel. 2. Locate the edited workflow. 3. Click on the **Three Dots (⋮)** and select **Download API Payload**. The updated JSON file will be downloaded, containing all your recent modifications. Use this file in your API 3.0 POST requests to ensure your workflow runs with the correct configuration. --- URL: https://knowledge.leegality.com/document-execution/workflows/v4/overview # v4 Workflow v4 is an advanced workflow system that provides more flexibility and control when sending documents for eSignature. It enables multi-document packs, selective document assignment, and enhanced configuration options. ## What is v4? v4 is a workflow created by Leegality for your specific use cases. As a workflow runner, you use these pre-configured workflows to send documents for eSignature. Leegality creates v4 workflows based on your requirements. Once created, you can run these workflows repeatedly to send documents to invitees. ## Key capabilities ### Send multiple documents as a pack Create packs containing multiple primary documents. Each primary document can contain one or more sub-documents. Assign specific primary documents to individual invitees based on the invitee's roles. **Example:** Send a loan agreement, property documents, and insurance policy together. Assign all documents to the borrower, only loan agreement to the guarantor, and only property documents to the bank officer. ### Multi-document signing in one journey Invitees sign multiple primary documents in a single unified session. They receive one notification, access one signing link, and complete all assigned documents in one flow. ### Flexible stamping options Configure stamps at the primary document level with two options: - **Stamps for merged document:** One stamp at the beginning of all sub-documents - **Separate stamps for sub-documents:** Dedicated stamps before each sub-document Different primary documents can have different stamping configurations. ### Selective document assignment Assign specific primary documents to each invitee. Each person sees and signs only the documents relevant to them, maintaining privacy and reducing confusion. ### Document pack processing Configure pack-level settings including pack name, internal reference number, folder selection, auto-deletion timeframe, and SFTP transfer for signed documents. ### Enhanced invitee configuration Set signing order, configure eSign types, and customize security settings, notifications, and other invitee-level options for each invitee. ## Document structure v4 uses a three-level hierarchy: - **Sub-documents:** Individual PDF files you upload — the building blocks of primary documents. - **Primary documents:** One or more sub-documents combined. Each is signed independently, has its own audit trail, and can be assigned selectively to invitees. - **Document pack:** The collection of all primary documents, sent together in a single, unified journey. For a detailed explanation, see [Packs and documents](https://knowledge.leegality.com/document-execution/workflows/v4/understanding-v4/packs-and-documents). ## Roles and responsibilities | Role | Responsibilities | |------|------------------| | **Workflow creator** | Creates v4 workflows based on your requirements. Configures workflow structure and boundaries. | | **Workflow runner** (Document Sender) | Runs workflows to send documents. Adds sub-documents, configures invitees, assigns documents, sets signature coordinates, and sends packs. | | **Invitees** | Receive and complete assigned documents in a unified signing journey. | ## v4 vs current workflows Both v4 and current workflows coexist. v4 will gradually replace the current system over the next few years. **Use v4 when you need:** - Multiple documents sent together with selective assignment of documents to invitees - Different stamping options (stamp for the merged document vs separate stamps per sub-document) - Ability to add constraints or flexibility to all fields to tailor the workflow runner's flow - Save eSign Coordinates per sub-documents so that sub-documents exclusion at runtime does not change eSign coordinate placement of subsequent sub-documents - Unified signing experience for multiple documents **Use current workflows when:** - Your existing workflows meet your needs - You have simple document sending requirements > **Info — Note** > > You cannot convert existing workflows to v4 or use the same API integration. ## Getting started with v4 To use v4 workflows: 1. Identify use cases requiring v4 capabilities 2. Review and test the configured workflow 3. Run the workflow to send documents > **Info — Note** > > Contact your account manager in case you have a complex workflow requirement. ## Next steps - [Learn how to run v4 workflows](https://knowledge.leegality.com/document-execution/workflows/v4/run-a-pack) - [Understand pack and document structure](https://knowledge.leegality.com/document-execution/workflows/v4/understanding-v4/packs-and-documents) --- URL: https://knowledge.leegality.com/document-execution/activity-log # Activity Logs The Activity Logs page provides a comprehensive record of all user actions within your Leegality account. Use these logs to audit account activity, track document status changes, monitor user actions, and maintain compliance records. Activity Logs give you visibility into: * All document-related activities (invitations, signatures, completions, rejections) * Stamp transactions and management actions * Workflow executions and updates * Payment and credit transactions * User authentication events (sign in, sign out) * System-level changes (contacts, templates, settings) ## How to Access Activity Logs ![Activity Log window](https://knowledge.leegality.com/img/Activitylogs.png) 1. Click **Dashboard** at the top of the page. 2. Select **Activity Logs** from the left navigation panel. ## Understanding the Activity Log Table The activity log displays entries in reverse chronological order, with the most recent activity at the top. Each log entry contains the following information: | Column | Description | | :---- | :---- | | **Date** | The exact date and time when the activity occurred (e.g., Dec 15, 2025 04:54 PM) | | **Remarks** | A detailed description of the action taken, including document ID, IP address, or device information | | **User** | The name and email address of the user who performed the activity | | **Report Type** | The category of action that occurred (see Activity Types below) | ## Filtering and Search The top section of the Activity Logs page contains filters and tools to help you quickly find specific log entries. ### Search Use the search bar to find specific text within the logs. You can search by document name, document ID, user name, or keywords from the activity description. ### Date Range Filter Click the date range selector to view logs for a specific time period. You can: * Select predefined ranges (today, yesterday, last 7 days, last 30 days) * Choose a custom start and end date using the calendar picker > **Info — Note** > > By default, logs from the last 30 days are displayed. All activity logs are retained forever. ### User Filter Filter logs by specific users to view activities performed by particular team members. Click the user filter to select one or more users from your account. ### Refresh Click **Refresh** to reload the log data and ensure you're viewing the most up-to-date activity. ## Activity Types The Report Type column categorizes each activity. Below is a comprehensive list of all activity types and their meanings: ### Document Activities | Report Type | Description | | :---- | :---- | | **Create** | A new document was created in the system. | | **Invite** | An invitation was sent to a party to sign a document. | | **You Signed** | You completed a signature action on a document. | | **Invitation Sign** | An invited party successfully signed the document you sent. | | **Complete** | The document reached its final signed status with all parties having signed, or the sender manually marked the document as complete. | | **You Rejected** | You chose to reject or decline signing a document. | | **Invitation Reject** | An invited signer rejected or declined signing the document. | | **Delete** | The document was deleted. Completed documents and drafts can be deleted after a fixed period as configured in settings, or the sender can manually delete the document anytime. | ### Invitation Management | Report Type | Description | | :---- | :---- | | **Resend** | The signing invitation was resent to an existing invitee. This can be done for active invitations if the recipient did not receive the original notification via email, WhatsApp, or SMS. Maximum 5 times including the initial send. | | **Reinvite** | A new signing invitation was sent after a previous invitation was rejected by the signer. There is no limit on reinvites until the invitation times out. | | **Invitation Timed Out** | The time limit for an invitee to sign the document expired. | ### Verification and Signing Status | Report Type | Description | | :---- | :---- | | **Verification Failed** | A verification step (OTP or identity check) required for signing failed. | | **Signed but Verification Failed** | The document was signed, but a subsequent verification check failed based on department-level eSign configuration. | | **Retry Attempt Exhausted** | The maximum number of signing attempts was reached without success. This applies only to Aadhaar eSign. | ### Stamp Activities | Report Type | Description | | :---- | :---- | | **Stamp Used** | A stamp was reserved and applied to a document for signing. | | **Stamp Reversed** | A previously used stamp was reversed and credited back. This occurs when an unsigned document with a stamp is deleted by the sender. | | **Stamp Expiry Extended** | The expiry date for a stamp series was updated and extended. | | **Stamp Create** | A new stamp series was created in the system. | ### Template and Workflow Activities | Report Type | Description | | :---- | :---- | | **Template Create** | A new document template was created and saved. | | **Workflow Created** | A new document execution workflow was designed and saved. Only admin users can create workflows. | | **Workflow Updated** | An existing workflow was modified. Only admin users can update workflows. | | **Workflow Published** | A workflow was finalized and made active for use. | | **Workflow Deleted** | A workflow was permanently removed from the system. Only admin users can delete workflows. | ### User Authentication | Report Type | Description | | :---- | :---- | | **Sign In** | A user successfully logged into the application. | | **Sign Out** | A user logged out of the application. | ### Payment Activities | Report Type | Description | | :---- | :---- | | **Payment Authorised** | Initial approval for a payment transaction was received from the signer during the signing journey. | | **Payment Captured** | Funds were successfully collected after the signer completed signing without any verification errors or rejections. | | **Payment Capture Failed** | The attempt to collect funds was unsuccessful. | | **Payment Reversed** | A captured payment was refunded or cancelled because the signer could not complete signing due to document deletion or invitation deletion. | ### Contact Management | Report Type | Description | | :---- | :---- | | **Contact Deleted** | A contact from the Contact Book was removed. | | **Contact Sent** | A contact was successfully shared with another user or system. | | **Contact Shared** | A contact was shared with another user within the platform. | > **Tip** > > Use the Report Type filter to quickly find specific categories of activities when auditing or troubleshooting. ## Download Report You can export activity logs in two ways: * **Full report:** Click **Download Report** without applying any filters to export all activity log entries. * **Customised report:** Apply filters for **Date Range**, **User**, and/or **Report Type** to narrow down the entries, then click **Download Report** to export only the filtered results. The exported file includes the date, activity description, user, and report type for each entry. > **Info — Note** > > Reports are exported as CSV files that you can open in Excel or other spreadsheet applications. ## Common Use Cases Activity Logs help you: * **Audit compliance**: Maintain records of all actions for regulatory requirements * **Troubleshooting**: Track the sequence of events when investigating issues * **User monitoring**: Review actions performed by specific team members * **Document tracking**: Follow the complete lifecycle of a document from creation to completion * **Security**: Monitor authentication events and identify unusual activity > **Tip** > > Export activity logs regularly for long-term record-keeping and compliance requirements. ## Related Features - [Audit Trail](manage-documents/document-details/audit-trail): Document-specific audit information with detailed invitee actions - [Notification Logs](manage-documents/document-details/notification-logs): Track notification delivery status across all channels --- URL: https://knowledge.leegality.com/document-execution/contact-book # Contact Book The Contact Book stores invitee contact information so you can quickly add signers and reviewers during document execution without re-entering their details each time. > **Info — Note** > > Contact Book entries are **not** login accounts or signing IDs. They are shortcuts for filling in invitee details when sending documents. The same person may appear more than once if their details (e.g., email address) were entered differently across documents. Duplicate entries do not affect document signing or user access — they exist purely for your convenience while composing new sending requests. ## Access Contact Book 1. Click **Dashboard** at the top of the page. 2. Select **Contact Book** from the left navigation panel. ## Contact Book Table The Contact Book displays all saved contacts in a table with the following fields: | Field | Description | | :---- | :---- | | **Contact Name** | The name of the invitee. | | **Email ID** | The invitee's email address. | | **Phone Number** | The invitee's phone number. | | **Label** | A tag or category assigned to the contact for easy identification. | | **Ownership** | Indicates whether the contact is owned by you or shared with you by another user. | --- ## Add a Contact #### V3 Workflow 1. Click the **+ Create** button in the top right corner. 2. Enter the contact's details: - **Name** - **Email** - **Phone Number** - **Label** (optional) 3. Click **Save**. The contact will appear in your Contact Book and will be available to use during the sending journey. ### Import Contacts in Bulk You can add multiple contacts at once using an Excel file. 1. Click the **Import** button. 2. Download the sample Excel template if needed. 3. Fill in the contact details (Name, Email, Phone Number, Label) in the template. 4. Upload the completed Excel file. 5. Click **Submit**. All valid contacts from the file will be added to your Contact Book. #### V4 Workflow 1. Open the **Contact Book**. 2. Enable the **Add invitee to contact book** toggle. 3. *(Optional)* Add an **Invitee Label** to help you identify the invitee later. --- ## More Actions ### Filter Contacts Use filters to narrow down contacts in the Contact Book. 1. Click the **Filter** icon in the Contact Book. 2. Apply one or more of the following filters: | Filter | Options | | :---- | :---- | | **Label** | Filter by one or more labels assigned to contacts. | | **Ownership** | **Personal** – contacts you created; **Shared** – contacts shared with you by others; **Organisation** – contacts available across the organisation. | | **Sharing** | **On** – contacts you have shared with others; **Off** – contacts not yet shared. | 3. The table updates to show only the contacts matching your selected filters. ### Send a Contact You can send contacts to other users in your organisation. 1. Find the contact you want to send and click the **Three dots (⋮)** (More Options) next to it. 2. Select **Send**. 3. Select the user(s) you want to send the contact to from the list. 4. Click **Send**. ### Edit a Contact 1. Find the contact you want to edit and click the **Three dots (⋮)** (More Options) next to it. 2. Select **Edit**. 3. Update any of the following fields: - **Name** - **Email ID** - **Phone Number** - **Labels** 4. Click **Confirm**. ### Delete a Contact 1. Find the contact you want to remove and click the **Three dots (⋮)** (More Options) next to it. 2. Select **Delete**. 3. Confirm the deletion from the popup. > **Info — Note** > > Deleted contacts are recorded in the [Activity Logs](https://knowledge.leegality.com/document-execution/activity-log). ## Use Contacts During Document Execution When the Contact Book is enabled in [**Settings → Department → Invitee Configurations**](https://knowledge.leegality.com/document-execution/settings/Department/invitee-configurations), you can select saved contacts while adding invitees during the sending journey. 1. During the sending journey, click **+ Add Invitee**. 2. Start typing the invitee's name or email in the contact field. 3. Select the contact from the suggestions that appear. The invitee's name and contact details will be auto-filled from the Contact Book. > **Info — Note** > > The Contact Book option must be enabled by your admin in **Settings → Department → Invitee Configurations** for it to appear during the sending journey. --- URL: https://knowledge.leegality.com/document-execution/settings/account-level/Profile/change-your-name # Change your name Your name is an essential part of your identity in Leegality. It appears in email notifications sent to invitees. Below example shows how your name appears in invitations sent to invitees. ![Profile Name in Notification](https://knowledge.leegality.com/img/profile_name_example.png) To change your name: 1. Click on the **Setting** icon ⚙️ on the top right. 2. From the left panel, go to **Settings > Profile**. 3. Make changes to the Name as you desire. 4. Click on the **✔** icon. --- URL: https://knowledge.leegality.com/document-execution/settings/account-level/Profile/change-your-password # Change your password You can change your password at any time. > **Info — Note** > > Leegality requires you to update your password every six months To change your password: 1. Click on the **Setting** icon ⚙️ on the top right. 2. From the left panel, go to **Settings > Profile**. 3. Under the Account Security section, click **Change Password**. 4. To set a new password, you have to verify your identity by: - Either entering your old password. - Or authenticating with a Reset Code sent to your registered email address. 5. Click **Update**. > **Info — Note** > > You will be automatically logged out after successfully changing your password. --- URL: https://knowledge.leegality.com/document-execution/settings/account-level/Profile/multi-factor-authentication # Multi Factor Authentication Multi-Factor Authentication (MFA) adds an **extra layer of security** on top of your existing login method (OTP or password) in Leegality. With MFA enabled, a user must have: 1. **Their existing login credentials** (OTP or password) **and** 2. **A one-time passcode (TOTP)** generated by a third-party authenticator app. This helps safeguard against unauthorised access — even if someone has your primary login credentials. ## How MFA Works When you log into your Leegality account with MFA activated: * After entering your **username** and **OTP/password**, you will be prompted to enter a **TOTP**. * The TOTP is generated by an authenticator app (e.g., Google Authenticator, Microsoft Authenticator) on your phone. * Each code refreshes every **30 seconds** and is valid for **60 seconds**. ## How to Enable Multi-Factor Authentication (MFA) > **Info — Note** > > MFA is a *user-level setting*. Each user in your organisation must enable it individually. 1. Click the **gear icon** (top-right corner). 2. Select **Settings → Profile** from the left-hand menu. At the bottom of your profile page, you will find **Multi-Factor Authentication**. 3. Click the **Set Up Multi-Factor Authentication** button. A pop-up will guide you through setup. 4. Install an Authenticator App. Recommended options: Google Authenticator, Microsoft Authenticator, or similar. Available on iOS and Android app stores. 5. Open your authenticator app and scan the QR code shown in the setup pop-up. This links your Leegality account to your authenticator app. 6. Enter the 6-digit code displayed in your authenticator app for Leegality: \[your email\]. 7. Click **Enable MFA**. You have now activated MFA for your account. ## Logging in with MFA Once MFA is enabled: 1. Enter your username and OTP/password as usual. 2. A pop-up will appear asking for your TOTP. 3. Open your authenticator app, find the Leegality entry, and enter the code displayed. You will be logged in once the TOTP is verified. --- URL: https://knowledge.leegality.com/document-execution/settings/account-level/document-setting/Invitation-expiry-for-sent-documents-account-defaults # Set Default Inivtation Expiry You can configure a default expiry period for eSign and review invitations sent from your account. After this period, invitees will no longer be able to access invitation via link to eSign or review the document. However, as the sender, you can reactivate the invitation and set a new expiry date. ## To Set Up Document Expiry on Account Level: 1. Click on the **Setting** ⚙️ icon on the top right corner. 2. From the left panel, go to **Settings > Documents**. 3. Under Enforce Invitation Expiry, you have four options: - **Minimum:** Expires after 45 minutes of sending. - **End of Day Expiry:** Expires at the end of the day the document was sent. - **Custom Range:** Expires after the specified number of days (from 1 to 365 days). - **Disable enforcement of document expiry:** Allows setting the expiry during the sending process; the default is 10 days. 3. Click **Update**. > **Info — Note** > > The expiry period begins at midnight the day after the document is sent. For example, if a document is sent at 4:00 PM on January 1, 2024, with a 2-day expiry, the countdown starts at 12:00 AM on January 2, and the document will expire at 12:00 AM on January 4, 2024. > **Warning — alert** > > The document expiry cannot be changed during the sending process unless you have selected the **Disable enforcement of document expiry** option. > **Warning — Existing workflows** > > Changing the account-level invitation expiry does not update workflows that are already saved. Running such a workflow shows the error: *"The expiry configuration saved in the workflow no longer matches the current expiry settings configured in your account."* > > To fix this, [**edit the workflow**](https://knowledge.leegality.com/document-execution/workflows/edit-workflow), select **Invitee Configuration**, update the expiry to match your current account setting, and save the workflow. --- URL: https://knowledge.leegality.com/document-execution/settings/account-level/document-setting/auto-save-signed-documents # Auto-Save Signed Documents The auto-save signed document toggle allows you to automatically save documents received for eSigning or review from other Leegality users to your Leegality account upon completion. Saved documents can be accessed from the Received folder. 1. Click on the **Setting** ⚙️ icon on the top right corner. 2. From the left panel, go to **Settings > Documents**. 3. Enable or Disable **Auto-Save Signed Documents**. 4. Click **Update**. --- URL: https://knowledge.leegality.com/document-execution/settings/account-level/document-setting/invitee-notifications-and-reminders-account-default # Invitee Notifications and Reminders This setting allows you to control email, SMS, and WhatsApp notifications sent to invitees for all documents from your Leegality account. ## To Enable or Disable Invitation Reminders and Notifications 1. Click on the **Settings** ⚙️ icon on the top right. 2. From the left panel, go to **Settings > Document**. 2. Enable or disable the **Send Invitation Reminders And Notifications** toggle. - **Enabled:** Both mandatory and optional notifications are sent to invitees. - **Disabled:** Only mandatory notifications are sent. --- ## Notification Types **Mandatory Notifications** - Document completion notifications **Optional Notifications** - Invitation to eSign/Review, including re-sent invitations - Reminder notifications before expiry - eSign/Review completion notifications - Rejection notifications - Expiry notifications - Re-activation notifications - Deletion notifications > **Info — Note** > > *Document completion notifications* are sent to all invitees as required by ASP regulations. The CCA mandates that Leegality (ASP) send the completed signed document to each signer. --- URL: https://knowledge.leegality.com/document-execution/settings/account-level/API/how-to-enable-api # Leegality API By default, APIs are deactivated for every account and must be manually activated. You need to enable API in order to generate Auth Token and Private Salt. ## How to Enable API To activate API in your account: 1. Click on the **Setting** ⚙️ icon on the top right corner. 2. From the left panel, go to **Settings > API**. 3. Click the **Enable API** button. This will generate the two API credentials; Auth Token and Private Salt. > **Warning** > > Do not share your Auth Token and Private Salt with anyone. Your Auth Token and Private Salt are sensitive credentials that grant access to your Leegality account and verify API calls and webhook requests. Sharing these credentials compromises the security of your account and exposes your data to unauthorized access and potential misuse. ## How to get Auth Token The Auth Token is a unique identifier that allows Leegality to validate API calls. It must be passed in the X-Auth-Token header parameter while making API calls (refer to [API documentation](https://docs.leegality.com/v3)). You can get the Auth Token to by clicking the “Copy” icon. You can also generate the new Auth Token by clicking the “Refresh” icon next to the Auth Token field. > **Tip** > > If you suspect that your Auth Token has been compromised, regenerate it immediately and take necessary security measures to safeguard your account. ## How to get Private Salt The Private Salt is used to verify the webhook calls made by Leegality. To verify webhook calls using the Private Salt, refer to the ‘mac’ parameter in our webhook documentation. Private Salt can only be regenerated by disabling and enabling the API. ## How to Disable API To disable your API access for your account, click the “Disable API” button, and Leegality will delete the associated auth token, private salt, and whitelisted IP addresses. --- URL: https://knowledge.leegality.com/document-execution/settings/account-level/API/how-to-whitelist-ip # How to Whitelist IP Addresses You can the Whitelist IP feature to restrict IP addresses that can make API calls to Leegality. You can add up to 10 IP addresses to this list. To whitelist an IP address: 1. Click on the **Setting** ⚙️ icon on the top right corner. 2. From the left panel, go to **Settings > API**. 3. Enter a valid **IPv4 address** and click the **+** icon. > **Info — Note** > > The IPv4 address needs to be input in x.x.x.x format, where the value of x can range from 0-255. --- URL: https://knowledge.leegality.com/document-execution/settings/Wallet/overview # Overview The Wallet section offers management of your account's financial activities, including purchasing, tracking usage, and managing billing information. Here’s what you can do: - **Purchase eSign Credits and Stamps**: Easily buy eSign credits and stamp papers directly from your account. - **View Purchase History**: Access a detailed history of all your eSign credits and stamp paper purchases. - **Monitor Consumption History**: Track the usage of eSign credits and stamp papers, giving you insights into your consumption patterns and remaining balances. - **Manage Billing Profiles**: Set up and maintain multiple billing profiles, making it easy to manage different payment methods or departments within your organization. - **Configure Low Balance Notifications**: Set up alerts for low eSign credit and stamp paper balances to ensure you’re never caught without the necessary resources. --- URL: https://knowledge.leegality.com/document-execution/settings/Wallet/manage-billing-profiles # Manage Billing Profiles ## Create a Billing Profile 1. Click on the Setting icon ⚙️. 2. In the left navigation panel, go to **Wallet > Billing Profiles**. 3. Click **+ Create Billing Profile**. It will open a pop-up Add New Billing Profile. 4. Provide information as required. 5. Click **Create**. > **Info — Note** > > Billing Profile information will be displayed in the invoice. You can create multiple billing profiles following the same steps. ## Edit a Billing Profile To edit a billing profile: 1. Click on the **Edit** option. 2. Modify details as you desire. 3. Click **Update**. ## Delete a Billing Profile To delete a billing profile: 1. Click on the **Delete** option. 2. Confirm your action by clicking on the **Delete** button. > **Warning** > > Deleting a Billing Profile cannot be undone. ## Set a Default Billing Profile To set a default billing profile for all your purchases, you need to click on **Set as default** option. The default billing profile will be selected automatically while purchasing eSign credits and stamps. However, you can switch the billing profile while making the purchase. --- URL: https://knowledge.leegality.com/document-execution/settings/Wallet/purchase # Purchase eSign and Stamps 1. Click on the **Setting** ⚙️ icon on the top right corner. 2. Go to **Wallet > Purchase**. 3. In Transaction Items, click **+ Add Items** to add desired products like eSign and Stamps. 4. Add quantity for each product as needed. 5. Click **Add Balance** on the bottom right. You will see the total base cost here. 6. Review the selected items and quantities in the Confirm Order screen. Click **Edit** to make changes or **Confirm** to proceed. 7. Click **Pay** and choose payment methods like UPI, Credit/Debit Card, Net Banking, and Wallet. 8. Alternatively, you can pay directly into our bank account using NEFT, RTGS, or IMPS. Click **View Bank Details** for more information. > **Info** > > Before purchasing Stamps, create a related Stamp Series. Learn [**how to create a Stamp Series**](https://knowledge.leegality.com/document-execution/stamps/stamp-series/create-a-stamp-series). Depending on your chosen payment method, processing may take a few hours. Once payment is successful, eSign credits will be added to your account. If you've purchased stamp papers, we'll initiate the stamp procurement process. Now the eSign credits are in your account, you are all set to send your first document for eSign. --- URL: https://knowledge.leegality.com/document-execution/settings/Wallet/download-invoice # Invoices The Invoice section allows you to access, view, create, and download all invoices for your purchases. ## Accessing and Download Invoices 1. Click on your **profile icon** in the top right corner of the dashboard 2. Select **Wallet** from the left navigation menu 3. Click on the **Invoice** tab to view all invoices generated for your purchases In the invoice list view, you will see: - **Invoice number** for each transaction - **View button** to open and view the complete invoice details ### Invoice Information Each invoice contains: - Invoice number and date - Billing address - Item and description (credits purchased) - Amount breakdown - Tax details (GST, if applicable) - Payment method From the Invoice tab, you can access the following invoice types: - Tax Invoice / Bill of Supply (B.O.S) - Proforma Invoice (accessible in the Proforma Invoice tab) ## Understanding Invoice Types Leegality generates different types of invoices depending on the transaction stage and your tax registration status: ### Proforma Invoice A proforma invoice is a preliminary document issued **before payment** is made. It serves as: - A quotation or estimate for the purchase - A reference for the amount due - A document for internal approval processes **How it's generated:** A proforma invoice is automatically created when you add eSign credits for relevant products to your cart. Right before payment, the proforma invoice is generated and can be accessed in the **Proforma Invoice tab**. **When you receive it:** Before completing the payment for credits or subscriptions. ### Tax Invoice A tax invoice is the official document issued **after payment** is completed. It includes: - Complete transaction details - GST/tax breakdown (if applicable) - Payment confirmation - Legally valid proof of purchase **When you receive it:** Immediately after successful payment completion. ### Bill of Supply (B.O.S) A Bill of Supply is issued instead of a Tax Invoice when the transaction is exempt from GST or when the seller is not registered under GST. --- URL: https://knowledge.leegality.com/document-execution/settings/Wallet/notifications-for-low-balance-of-esign-and-stamp # eSign & Stamps Low Balance Reminder This feature allows you to set a low balance threshold for eSign credits and stamp papers in your account. When the threshold is reached, a notification is triggered and sent to the configured email addresses. > **Tip — Notification Recipients** > > Notifications will be sent to the email addresses configured in the notifications section. To add more recipients for low-balance notifications, navigate to Manage Notifications. ## Setting the Low Balance Notification Threshold 1. Click on the **Setting** ⚙️ icon on the top right corner. 2. In the left navigation panel, go to **Wallet > Low Balance Configs**. 3. Choose either the **default threshold** or set a **custom threshold** to trigger notifications. ### Option 1: Default Low Balance Notification Thresholds: Selecting this option sets notifications at the following consumption levels: **50%**, **75%**, **90%**, and **100%** of the most recent purchase. - **eSign Credits**: Notifications are triggered when 50%, 75%, 90%, and 100% of your most recent eSign credits are consumed. - **Stamp Papers**: Notifications are triggered at 50%, 75%, 90%, and 100% of your most recent stamp paper purchase. > **Info — Example** > > If you purchased 1,000 eSign credits: > > * Notification at **500 credits** consumed. > * Notification at **750 credits** consumed. > * Notification at **900 credits** consumed. > * Notification at **1,000 credits** consumed. --- ### Option 2: Set Custom Low Balance Notification Thresholds This option allows you to set custom threshold percentages. You can set different thresholds for eSign credits and stamp papers. **Single Percentage Limit**: Unlike the default, you can set only one percentage limit. When this threshold is reached, a notification is triggered. **Example:** If you set a custom threshold at **95%** and recently purchased 1,000 eSign credits: * You will receive a notification when **950 credits** are consumed. > **Info — Note** > > Setting a custom threshold deactivates default notifications, and only custom notifications will be sent. --- URL: https://knowledge.leegality.com/document-execution/settings/Wallet/purchase-history # Purchase History The Purchase History shows you the record of all purchases made for your Leegality organization. To Access Purchase History, 1. Click on the **Setting** ⚙️ icon on the top right corner. 2. In the left navigation panel, go to **Wallet > Purchase History** option. ## eSign Purchase History The eSign Purchase History tab displays records of all purchases made for eSign credits, including: - **Purchase Date:** Date when the purchase transaction was initiated or completed - **Expiry Date:** Date until which the purchased credits remain valid for use. - **Purchase Value:** Number of credits purchased - **Consumed:** The quantity of credits that have been used for signing documents. - **Expired Credits:** The quantity of credits that have reached their expiry date and are no longer usable. - **Balance:** The remaining balance indicates the number of eSign credits that are still available for use after considering the consumed and expired credits. > **Info — Note** > > eSign credits are consumed on a FIFO (First in First Out) basis. > When eSign credits are consumed on a FIFO basis, the credits are used starting with the earliest purchase first. > > **Example:** > > - On **August 1, 2024**, you purchased 500 eSign credits. > - On **August 15, 2024**, you purchased an additional 300 eSign credits. > > **Usage:** > > - On **August 30, 2024**, you used 400 eSign credits. According to FIFO: > - 400 credits are deducted first from the August 1 purchase (leaving 100 credits remaining from this batch). > - The August 15 purchase batch still has 300 credits. > > - On **September 5, 2024**, you used another 200 eSign credits. FIFO dictates: > - 100 credits are taken from the remaining August 1 batch (which now depletes this batch completely). > - The remaining 100 credits are taken from the August 15 batch (leaving 200 credits still available from this batch). > > **Remaining Credits:** > > - **August 1 Purchase** – 0 credits remaining. > - **August 15 Purchase** – 200 credits remaining. ## Stamps Purchase History The "Stamps Purchase History" tab shows records of all purchases made for Stamps, including: - **State:** State for which stamps are purchased. - **Denomination:** Denomination refers to the face value of each stamp. - **Series:** Stamp Series for which stamps are purchased. - **Purchase Amount:** The total cost spent on purchasing the stamps. - **Purchase Quantity:** The total number of stamps purchased in the transaction. - **Used:** The number of stamps that have been affixed to documents. - **Expired:** The number of stamps that are expired and are no longer valid for use. (**Note:** You can [**extend the expiry date of expired stamps**](https://knowledge.leegality.com/document-execution/stamps/stamp-series/extend-expiry-of-stamps.mdx), making them available for use again.) - **Unused:** The number of stamps that have not yet been used or affixed to the document. - **Under Process:** The number of stamps that are currently being procured and digitized. These stamps are in the process of being prepared for use but have not yet been made available for application. --- URL: https://knowledge.leegality.com/document-execution/settings/Wallet/consumption-history # Consumption History To access your consumption history; 1. Click on the **Settings** ⚙️ icon on the top right. 2. Select **Wallet > Consumption History** History in the left panel. #### eSign and Subscription Consumption History ## eSign and Subscription Consumption History | Transaction Type | Description | | ---- | ---- | | **Credit** | When eSign credits are purchased, they are recorded under "Credit" with the date of the addition. | | **Reserve** | Number of eSign credits are put on hold when an invitation is sent, based on the invitee’s role and eSign type. | | **Debit** | When a document is signed, the reserved eSign credits are debited from the account. | | **Release** | Reserved eSign credits are either debited upon signing or refunded if the invitation expires without a signature. | > **Info — Note** > > Reserved **eSign credits will not be refunded** if certificate verification (Aadhaar eSign, NeSL, DSC) fails due to mismatched details, even if the document remains unsigned. ### Transaction Details * **Transaction type:** Whether the transaction was a credit, debit, release, or reserve. * **Date and Time:** The date and time of the transaction. * **Remark:** A brief summary, including the associated invitation hash. * **Debit or Credit:** Shows whether the transaction resulted in a debit or credit of eSign credits. * **Balance:** The remaining balance after the last transaction. ### Filters You can filter transactions by: * **Date Range:** View transactions within a specified time frame. * **Transaction Type:** Filter by Credit, Debit, Reserve, Release, or Reduce. > **Note:** Ensure the resulting selection contains less than 10,000 transactions. * **Balance Type:** Filter by eSign Balance or Subscription Balance. #### Stamps Consumption History ## Stamps Consumption History You can access the Consumption History by clicking on the **Stamp** tab. This section provides detailed records of stamp usage. Use **Series** dropdown to choose a stamp series and view its consumption history. ### Transaction Type | Transaction Type | Description | | ---------------- | ----------- | | **Credit** | Stamps are added to the series, and the date of addition is recorded. | | **Reserve** | Stamps are deducted from the account, holding them for documents sent for signing. The document ID and reservation date are noted. | | **Debit** | Stamps are deducted from the account after a document is signed, with the document ID and transaction date recorded. | | **Release** | Stamps are refunded back to the account if a document remains unsigned and has expired or been deleted. | ### Stamp Consumption Details The Stamp Consumption History provides the following information: - **Series Number:** Identifies the stamp series for which consumption history is being viewed. - **Transaction:** Details whether the transaction is a credit, debit, reserve, or release. - **Reference ID:** Document IDs associated with stamp usage. (**Note:** Document IDs may repeat if invitations are revoked or expired.) - **Date:** The date of each transaction. - **Remark:** Additional details regarding each transaction. - **Release Date:** Indicates when stamps are released from reserve, whether credited or debited. - **Debit:** The number of stamps deducted from the account for the transaction. - **Credit:** The number of stamps credited to the account through release or purchase. - **Balance:** The remaining number of stamps in the account for the specified series after the last transaction. ## Download Consumption Report Apply the relevant filters on either tab and click **Download Consumption Report** to export the filtered records as a CSV file. The downloaded report includes the transaction type, date and time, remark, debit/credit, and balance for each entry. --- URL: https://knowledge.leegality.com/document-execution/settings/Admin/admin # Admin The Admin section provides controls for managing your Leegality account, the people in it, and how they work in Document Execution. > **Info — Access required** > > The Admin section is visible only to users with the **Admin** role. If you cannot see it, contact your account administrator to grant you Admin role access. ## What Admins can do - **Manage users and roles** — add, edit, and lock users and assign Admin, Billing, or User roles. - **Access other users' accounts** — use Impersonator Mode to view documents and act on a user's behalf. - **Control workflows, templates, and stamps** — create, edit, and management access (other roles get run-only or use-only access). - **Configure account-wide settings** — branding, department-level configurations, and notification setup. - **Manage billing and credits** — buy eSign credits and stamps, manage billing profiles, and view purchase and consumption history. --- # User Roles URL: https://knowledge.leegality.com/document-execution/settings/Admin/user-roles > A user role determines the set of permissions and actions available to a user. The admin assigns roles to users when they are added to an account. There are thr A user role determines the set of permissions and actions available to a user. The admin assigns roles to users when they are added to an account. There are three organizational roles in Leegality. - Admin - Billing - User Each role has different permissions within the system. Refer to the table below. ## Roles and Permissions Table | Permission | Admin | Billing | User | |-------------------------------------------|-------|---------------|-------------| | **New Document Flow** | ✔️ | ✔️ (if granted) | ✔️ (if granted) | | **Workflows** | ✔️ | Run only | Run only | | **Templates** | ✔️ | Use only | Use only | | **Stamps** | ✔️ | Use only | Use only | | **Buy eSign Credits and Stamps** | ✔️ | ✔️ | ❌ | | **User Management** | ✔️ | ❌ | ❌ | | **Configure Notifications** | ✔️ | User-level | User-level | | **Impersonator Mode Access** | ✔️ | ❌ | ❌ | | **Profile (Name and Password)** | ✔️ | ✔️ | ✔️ | | **API Use** | ✔️ | ✔️ | ✔️ | | **Set Default eSignature and Seal** | ✔️ | ✔️ | ✔️ | | **Enforce Invitation Expiry** | ✔️ | ✔️ | ✔️ | | **Branding** | ✔️ | ❌ | ❌ | | **Department Level Settings** | ✔️ | ❌ | ❌ | --- URL: https://knowledge.leegality.com/document-execution/settings/Admin/user-management # User Management ## Create a New User You can add users to your account in accordance with your subscription plan. 1. Click on the **Settings** ⚙️ icon on the top right corner. 2. Go to **Admin > New Users**. 3. Provide the following information. - **Name:** Name of the user. - **Email Address:** This email address will be used as login credentials. - **User Role:** Select the role for the user (Admin, Billing, or User). - **Department:** Choose the department. - **New Document Access:** Whether you want to allow this user to use new document flows. 4. Click **Create**. An email will be sent to the user’s email address to activate their Leegality account. > **Info — Note** > > The number of users allowed per account depends on the subscription plan. ## Edit User and Lock User ### To edit a user’s details. 1. Click on the **Settings** ⚙️ icon on the top right corner. 2. Go to **Admin > Users**. 3. You need to search for the user you want to edit. 4. Hover your mouse over it and click the edit icon **🖉** on the right. 5. In the pop-up box, you can edit Name, Role, and Enable/Disable New Document Access. 6. Click **Save** Changes after making the desired changes. ### To Lock a user 1. Go to **Admin > Users**. 2. You need to search for the user you want to lock. 3. Hover your mouse over it and click the lock icon 🔒 on the right. A locked-out user will see this error message: *"Your account has been locked by your organization. Please contact your administrator."* Follow the same steps to unlock a locked user. ## Ghost User A Ghost User is a deactivated user in an organization who has been removed from active access but is retained in the system. This preserves the integrity and audit trail of those completed documents while ensuring the user can no longer interact with the org. > **Info** > > To convert a user into a Ghost User, reach out to our support team at support@leegality.com. **How can I delete a user account permanently?** > User accounts cannot be deleted from the dashboard due to legal reasons. To delete a user account and profile permanently, you need to approach support@leegality.com. --- URL: https://knowledge.leegality.com/document-execution/settings/Admin/impersonator-mode # Impersonator mode Impersonator mode allows you to access other users' accounts to view their documents and perform actions on their behalf. This is useful for managing documents when users are unavailable. ## Use impersonator mode 1. Click the profile icon in the top-right corner. 2. Select **Switch Account** and choose the user whose account you want to access. You will enter impersonator mode. The header displays the email address of the user whose account you're accessing. To exit impersonator mode, click **Switch back to my account** in the top-right corner. ## Available actions in impersonator mode When in impersonator mode, you can: - View other users' dashboards - Download documents - Access user activity logs - Reactivate expired invitations - Delete invitations - Copy invitation URLs - View document details - View and download attachments - Re-invite rejected invitations - Resend notifications - Mark documents as complete ## Grant impersonator access to users You can grant impersonator mode access to specific users, allowing them to access another user's documents. 1. Click the Settings icon ![Settings Icon](https://knowledge.leegality.com/img/Icon=settings.svg) in the top-right corner. 2. Navigate to **Admin > Users**. 3. Locate the user whose documents you want to share. 4. Click the share icon ![Share user's documents icon](https://knowledge.leegality.com/img/Icon=share-2.svg). 5. In the **Add team members** dropdown, select the users you want to grant access to. 6. Click **Confirm**. --- URL: https://knowledge.leegality.com/document-execution/settings/Department/branding # Branding Branding in Leegality allows you to personalise the eSigning experience for invitees. You can use branding controls to reinforce your organization's identity and reassure signers that documents sent through Leegality originate from your organization. You can create **multiple branding profiles**, each with its own name, colour, and logo, and set one as the **default**. When sending a document, the sender can choose which branding profile to apply to that document's signing journey. Branding controls the styling of email notifications sent to invitees and the signing view. ## Create a Branding Profile 1. Click on the **Setting** ⚙️ icon on the top right corner. 2. Go to **Department > Branding**. You will see a list of your existing branding profiles. 3. Click **+ Add Profile** and provide the following details: - **Profile Name** *(required)*: A name to identify this profile within your department. This is used only for your reference and is not shown to invitees. - **Brand Name:** Visible as the sender name in all invitee communication. - **Brand Colour:** Adds the selected colour to the email and signing journey. Provide the colour as a hexcode (for example, `#000000`). The colour is applied to the header of email communications, the signing view, and buttons such as Sign and Proceed. - **Brand Logo:** Replaces the Leegality logo in emails and the signing journey. Recommended size: 250×100 px. - **Corner Radius** *(v4 only)*: Defines the corner roundness of elements such as buttons, cards, input fields, checkboxes, and badges. Use `0px` for sharp corners and `16px` for fully rounded corners. The default is `8px`. 4. Preview the mobile and desktop versions with the chosen settings on the right. You can preview both the V3 and V4 signing journeys based on your configuration. 5. Once satisfied, click **Save**. Repeat these steps to create as many branding profiles as you need. ## Set a Default Branding Profile The default profile is applied automatically to a document's signing journey unless the sender selects a different profile while sending. 1. Go to **Department > Branding**. 2. In the list view, hover over the profile you want to set as default. 3. On the right, select **Set as Default**. ## Apply a Branding Profile When Sending When sending a document, the sender can choose which branding profile to apply to that document's signing journey. In the [sending journey](https://knowledge.leegality.com/document-execution/getting-started/sending-journey), go to **Signing Journey Options > Branding Profile** and select a profile from the dropdown. The dropdown lists all branding profiles configured in **Department > Branding**. If the sender does not select a profile, the **default** profile is applied. ## Edit or Delete a Branding Profile To edit a profile, go to **Department > Branding**, open the profile, update its name, colour, or logo, and save your changes. > **Info — Things to keep in mind** > > - **Editing** a profile also updates the branding on invitations that have already been sent using that profile. For example, if you sent a document using Profile 1 and later change Profile 1's brand colour, the signing journey for that already-sent document reflects the new colour in real time. > - **Deleting** a profile that was used for a document already in the signing journey causes that document to fall back to the **default** branding profile. --- URL: https://knowledge.leegality.com/document-execution/settings/Department/document-config # Document Configuration ## Enforce PDF Flattening **What is PDF Flattening?** PDF flattening is the process of converting a dynamic or interactive PDF document into a static one by merging all the layers and interactive elements. This ensures that the visual appearance of the document remains consistent across different viewing platforms and prevents further editing of its contents. **Why enforce PDF Flattening?** When a PDF is digitally signed and then flattened after filling form fields, the signature and the filled form fields become part of the static image of the document. This process ensures that both the signature and the filled form fields are preserved and cannot be altered or tampered with without invalidating the signature. Flattening the PDF ensures that the signed document and the filled form fields are locked in place. This prevents anyone from modifying the contents of the document or the filled form fields without invalidating the signature. It helps maintain the integrity and authenticity of the signed document. **What happens if PDF flattening is not enabled?** If PDF flattening is not enabled, it means that the form fields remain editable even after the document has been digitally signed. This presents a significant risk because it allows anyone with access to the document to modify the variable fields without invalidating the signature. As a result, the integrity and authenticity of the document are compromised, as it becomes susceptible to tampering. ### To Enable PDF Flattening 1. Click on the **Setting ⚙️** icon on the top right corner. 2. Go to **Department > Document Configs**. 3. Enable **Enforce PDF Flattening toggle**. 4. Click **Update**. --- ## Automatically Delete Draft Documents You can use this feature to automatically delete all the documents in the draft after a pre-specified time duration. > **Info — note** > > By default, documents in the Draft will be deleted after 30 days of the creation date. For draft documents with affixed stamps, the stamps remain reserved and cannot be used in another document until the draft is deleted. ### To automatically delete documents in Draft 1. Click on the **Setting ⚙️** icon on the top right corner. 2. Go to **Departments > Document Configs**. 3. Enable **Enforce auto-deletion of draft documents** toggle. Provide the number of days for document retention. (Days can range from 1 to 365) 4. Click **Update**. --- ## Multiple Documents per Pack To send multiple documents as a single pack in [v4 workflows](https://knowledge.leegality.com/document-execution/workflows/v4/overview), you need to enable this setting. ### To enable multiple documents per pack 1. Click on the **Setting ⚙️** icon on the top right corner. 2. Go to **Department > Document Configs**. 3. Enable the **Multiple documents per pack** toggle. 4. Click **Update**. --- URL: https://knowledge.leegality.com/document-execution/settings/Department/document-security-settings # Document Security Settings ## Invitee authentication before accessing document This feature adds an extra layer of security to protect your documents from unauthorized access. They dictate whether invitee authentication is required before accessing the document. Once enabled, invitees undergo an OTP authentication process before viewing the document. ### Enforce invitee authentication before accessing document If enabled, these settings will apply to all of the documents sent from the account. 1. Click on the **Setting** ⚙️ icon on the top right corner. 2. Go to **Department > Document Security**. 3. There are two levels of authentication and you can choose any one: #### 1-Factor Authentication Invitees authenticate via OTP sent to their email address or phone number, as configured by the sender. #### 2-Factor Authentication Invitees authenticate via their email address as well as phone number. The sender provides both during the invitation process. > **Tip — 2-Factor Authentication Example** > > - The sender has provided the invitee's email address as well as phone number. > - The invitation link is sent via both email and SMS. > - If the invitee accesses the document link via email, the OTP is sent to the phone number for authentication. > - If the invitee accesses the document link via SMS, the OTP is sent to the email address for authentication. --- ## Auto Delete after Document Completion For enhanced security and automated document management, you can configure your account to automatically delete documents after they are completed. ### To set auto-delete document time duration: 1. Click on the **Setting** ⚙️ icon on the top right corner. 2. From the left navigation menu, go to **Department > Document Security**. 3. Enable **Enforce auto-delete after Document Completion** toggle. 4. Enter the number of days (from 7 to 365) that you wish to retain documents after completion before they are permanently deleted. > **Info — How it works** > > - If you enable auto-delete right now, it will only apply to documents you send from this point forward. It will not affect any documents that are already completed. > - If **enforce auto-delete on complete** is *Disabled* under **Department > Document Security** and a sender enables auto-delete from the **Signing Journey Options**, the completed document will be deleted after a default period of 7 days. > **Warning — Irreversible Action** > > Documents removed by the auto-delete feature are **permanently erased and cannot be recovered**. Please ensure you have downloaded and stored all necessary documents before the retention period ends. > **Info — note** > > Documents larger than 7 MB will not be shared as attachments via email. Instead, you will get a link in the email to download the signed agreement copy and audit trail. --- URL: https://knowledge.leegality.com/document-execution/settings/Department/esignature-settings # eSignature Settings When senders create a document for signature, they need to select a signature type for each invitee. The signature types available to a sender depend on the account configuration. You can use the eSignature Settings page to choose the signature types available for an account. ## Enable eSign Types for senders 1. Click on the **Setting ⚙️** icon on the top right corner. 2. Go to **Department > eSignature**. This will show you all available eSign types. 3. Use the toggle switch to add them to the sending journeys. 4. Some eSign types have sub-types, for example, Aadhaar eSign has OTP, Biometric, IRIS, and Face. You can add them individually. All toggled-on eSign types are now available to senders when they create a new document. ### Set the Default eSign Type You can set the default eSign type to apply to signers when senders have not specified any during the sending journey. Only one signature can be assigned as a default. 1. Click on the **Setting ⚙️** icon on the top right corner. 2. Go to **Department > eSignature**. 3. Find the signature type you want to set by default and click on the **✔** icon right next to it. 4. A confirmation message will show in the top right corner. The default eSign type will be pre-selected during every new document journey. However, the sender can choose others as required. ## Configure Certificate Verification Settings You can configure how Leegality verifies signer information against their digital signature certificate. This includes setting verification parameters, choosing between AI-based or text-based name matching, and defining actions for verification failures. > **Info — Prerequisites** > > Ensure that the eSign type (Aadhaar eSign or DSC Token) is enabled in your department settings before configuring verification parameters. #### Aadhaar eSign ### Configuring Aadhaar eSign Verification **Steps to Configure:** 1. Click the **Settings (⚙️)** icon on the top right corner. 2. Go to **Department > eSignature**. 3. Click the **⚙️ icon** next to **Aadhaar eSign** to open the configuration panel. **Configure Verification Parameters:** The configuration panel displays available verification types and their corresponding acceptance conditions. Available verification types for Aadhaar eSign: - Name - Gender - Year of Birth - Pincode - State - Title (Last 4 digits of Aadhaar number) For each verification parameter, select one of the following actions: - **Reject if failed (Default):** The signature is rejected if the parameter does not match the certificate details. - **Accept but respond with result:** The signature is affixed even if the parameter does not match, but the result is included in the details page and API response. **Smart Name Verification:** Configure how the system verifies the name on the Aadhaar certificate against the invitee's name. - **Name Matching Type:** Select between AI-Based name matching and Text-Based name matching. - **Match Threshold:** Define the required percentage match for name verification. - **Acceptance Condition:** Choose the action upon failure (Reject if failed / Accept but respond with result). **Save Your Configuration:** - Click **Save** to apply your changes. - Click **Close** to exit without saving. - Click **Reset to Default** to revert to system defaults. #### DSC Token ### Configuring DSC Token Verification **Steps to Configure:** 1. Click the **Settings (⚙️)** icon on the top right corner. 2. Go to **Department > eSignature**. 3. Click the **⚙️ icon** next to **DSC Token** to open the configuration panel. **Configure Verification Parameters:** The configuration panel displays available verification types and their corresponding acceptance conditions. Available verification types for DSC Token: - Name - Pincode - State For each verification parameter, select one of the following actions: - **Reject if failed (Default):** The signature is rejected if the parameter does not match the certificate details. - **Accept but respond with result:** The signature is affixed even if the parameter does not match, but the result is included in the details page and API response. **Smart Name Verification:** Configure how the system verifies the name on the DSC certificate against the invitee's name. - **Name Matching Type:** Select between AI-Based name matching and Text-Based name matching. - **Match Threshold:** Define the required percentage match for name verification. - **Acceptance Condition:** Choose the action upon failure (Reject if failed / Accept but respond with result). **Save Your Configuration:** - Click **Save** to apply your changes. - Click **Close** to exit without saving. - Click **Reset to Default** to revert to system defaults. --- URL: https://knowledge.leegality.com/document-execution/settings/Department/invitee-configurations # Invitee Configurations Invitee configurations allow admins to determine which invitee-level options are accessible to senders during the document sending process. Once activated, these options become available for senders to use as needed during the document sending journey. 1. Click on the **Setting ⚙️** icon on the top right corner. 2. Go to **Department > Invitee Configs**. 3. Enable or disable the option as required: - **Reviewer Role:** When enabled, the sender will be able to use Make Reviewer. - **Disable OTP authentication for Reviewer:** Select this and the sender will have the option to enable and disable OTP authentication for the reviewer. - **Group Invitees:** When enabled sender will have the option to create group invitees during the sending journey. - **CC Notifications:** When enabled sender will have the option to add CC invite(s) to the document during the sending journey. - **GPS location and accuracy based restrictions in the signing journey:** When enabled, senders can enable geo-fencing for invitees. You can also specify the default permissible radius and allowed accuracy deviation (in meters). - **Rejection in Signing Journey:** When enabled sender will be able to allow invitees to decline to sign a document. The sender can also require invitees to provide a reason why they are declining to sign. - **Contact Book:** When enabled, the sender will be able to use contacts saved in the contact book. - **Local Language Support:** When enabled, the sender can enable local languages for the invitees. - **WhatsApp Pings:** When enabled, the sender will have the option to send eSign notifications via WhatsApp. - **Face Match Verification:** When enabled, senders can enable face match verification for invitees. - **Acceptance percentage:** The minimum threshold required for successful face match verification. - **Failure treatment:** Configure how to handle verification failures. Select **Reject if Failed** to block the signing process, or **Accept but respond with results** to allow signing while recording the verification result. - **Smart User Liveliness:** When enabled, senders can enable smart user liveliness verification for invitees. - **Acceptance percentage:** The minimum threshold required for successful smart user liveliness verification. - **Mask PII data for Invitees:** When enabled the sender will have the option to enable PII masking for invitees during sending journeys. - **Advanced Signing Order (Workflow v4 only):** When enabled, user can configure invitees in a mix of sequential and parallel signing stages within the same signing flow. - **Multiple Combinations (Workflow v4 only):** When enabled, users can configure multiple combinations for the same invitee, with different documents, eSign types, and combination-specific options. --- URL: https://knowledge.leegality.com/document-execution/settings/Department/payment-collect # Payment Collect The Payment Collect feature allows Leegality users to collect payments from signers during the signing journey. Payment will be collected via a payment gateway Razorpay or BillDesk. ## Prerequisites - A Razorpay or BillDesk account with KYC completed. - A bank account should be linked with the payment gateway account. ## Create a Payment Collect Profile You need to connect your payment gateway account with Leegaity in order to use the Payment Collect feature. 1. Click on the **Settings** ⚙️ icon on the top right corner. 2. Go to **Department > Payment Collect**. 3. Select the any one Payment Gateway from dropdown **(Razorpay or BillDesk)** and click on **“+”** icon. ### Option 1: Connect Razorpay 1. Enter a suitable **Profile Name** and click on **Link** button. 2. You will be redirected to a Razorpay where you need to login to your Razorpay account and Link Leegality with it. 3. Click on checkbox **☑** and agree with **Terms & Conditions**. 4. After that, click on **Authorize**. Your Leegality and Razorpay account are now linked and can be used for collecting payments from invitees. ### Option 2: Connect BillDesk 1. Enter a suitable **Profile Name**. 2. Provide **Client ID, Merchant ID**, and **HMAC Key**. You will get these from BillDesk. 3. Click on the **Link** Button. Your Leegality and BillDesk account are now linked and can be used for collecting payments from invitees. > **Tip** > > You can set multiple Payment Collect profiles and use anyone to collect payments during the sending journey. ## Enable Payment Collect for Sender Toggle on **Payment Collection in signing/reviewer journey**, this will allow the sender to use the Payment Collect feature during the sending journey. --- URL: https://knowledge.leegality.com/document-execution/settings/Department/sftp # SFTP (Secure File Transfer Protocol) ## Why SFTP is Required? If you want to store the documents on your server then you need to add an SFTP profile to ensure the secure transfer of documents from the Leegality server to your server. ## Steps to add SFTP Profile #### Password 1. Click on the **Settings** ⚙️ icon on the top right corner. 2. Go to **Department > SFTP**. 3. Click the **Add New SFTP** button. 4. Provide the following information. - **SFTP Profile Name:** This profile name will be visible to the sender during the sending journey. - - **Authentication Method:** Select **Public Key**. - **Host URL:** This is the host URL of the server where completed documents will be sent. - **Destination:** This is the path of the folder where completed documents will be sent. - **Port:** Port number required to establish the connection. - **Username:** Username that will be used to connect with the server. - **Password:** Password that will be used to connect with the server. 5. Click **Save**. #### Public Key 1. Click on the **Settings** ⚙️ icon on the top right corner. 2. Go to **Department > SFTP**. 3. Click the **Add New SFTP** button. 4. Provide the following information. - **SFTP Profile Name:** This profile name will be visible to the sender during the sending journey. - **Authentication Method:** Select **Public Key**. - **Host URL:** This is the host URL of the server where completed documents will be sent. - **Destination:** This is the path of the folder where completed documents will be sent. - **Port:** Port number required to establish the connection. - **Username:** Username that will be used to connect with the server. 5. Click **Save**. Copy the **Public Key** and share it with SFTP server admin. You can also regenerate the **Public Key** by clicking on the **Regenerate Key Pair** option. A test file will be sent to the configured SFTP server, if the file is sent successfully only then the SFTP profile will be saved. You can create multiple SFTP profiles and select the one you would like to use during the sending journey. > **Info — Note** > > While Editing, you cannot change the password of the SFTP profile. ## Use SFTP Document Transfer in Sending Journey Toggle ON **Allow SFTP in document sending journey** to get the option to send the completed document on the server via SFTP. A zip file of the completed document and audit trail will be sent to the configured server after all invitees sign the document. The file transfer could take up to 15 minutes. An email/SMS notification will be triggered if the transfer via SFTP fails. --- URL: https://knowledge.leegality.com/document-execution/settings/Department/stamp-settings # Stamp Settings Control stamp-related features for your organisation. These settings are managed under **Settings > Department > Stamp**. ### To configure Stamp settings 1. Click on the **Setting ⚙️** icon on the top right corner. 2. Go to **Department > Stamp**. 3. Enable or disable the toggles as needed. - **Stamp Access** - **Stamp Series** — Allows admins to create stamp series which can be used to place stamp paper orders and attach stamp papers to documents. - **Attach multiple stamp series** — Allows users to select and attach stamp papers from multiple series to a single document. - **Stamp Groups** — Allows admins to create stamp groups which facilitate variable stamp duty payment by combining different stamp series. - **Self-Upload Stamp** — Allows self-uploaded stamps to be configured for a document. - **Revenue Stamp** — Allows revenue stamp series access for your organisation. - **Sub document level stamping** — Allow workflow creators to configure stamping at the sub-document level (stamp series, groups, revenue, and uploads on each sub-document). Learn more about [distributed stamping](https://knowledge.leegality.com/document-execution/workflows/v4/understanding-v4/distributed-stamping). 4. Click **Update**. --- URL: https://knowledge.leegality.com/document-execution/settings/Department/workflow-builder-config # Workflow Builder Config Control which workflow-builder features your workflow creators can use. These settings apply to [v4 workflows](https://knowledge.leegality.com/document-execution/workflows/v4/overview). ### To configure Workflow Builder settings 1. Click on the **Setting ⚙️** icon on the top right corner. 2. Go to **Department > Workflow Builder Config**. 3. Enable or disable the toggles as needed. - **Rule Engine** Allow workflow creators to add and execute rules on workflows. - **Custom fields** Allow workflow creators to define and use custom fields (`lecf_*`) in workflows. - **Custom validations** Allow workflow creators to set UI-driven and regex validations on workflow fields. - **Page visibility & field reorder** Allow workflow creators to hide pages in the workflow-runner UI and reorder fields. - **Custom page** Allow workflow creators to create [custom pages](https://knowledge.leegality.com/document-execution/workflows/v4/setup-configuration/custom-page) using custom fields. 4. Click **Update**. --- URL: https://knowledge.leegality.com/document-execution/settings/Notifications/notification # Notifications The notifications tab lets you control the various notifications that are sent by Leegality. You can configure the user-level and organization-level notifications. You can access the notification configuration. 1. Click on the **Settings** ⚙️ icon on the top-right. 2. Select **Notifications** from the left panel. ## User Level Notifications > **Info — Who receives these notifications** > > The **sender** of a document automatically receives all event notifications below — no opt-in needed. To send these notifications to anyone else (admins, teammates, or any other user), add them as a recipient under [Manage Recipients](#manage-and-configure-recipients-of-notifications). > > **Example:** An admin who wants alerts for *any* document signed in the organisation (not just the ones they sent) must add their email under Manage Recipients for the relevant notification. ### Document These are document event notifications. - **Completion Notifications:** Sent when a document is completed i.e. signed/reviewed by all invitees. - **Signing Updates:** Sent when an invitee signs the document and the reviewer approves or rejects the document. - **Failure Updates:** Sent when a document signing is failed for an invitee. The possible scenarios reasons are; - Invitation expired/timed out. - Invitee rejected signing the document. - Aadhaar eSign retry attempts exhausted. - Mismatched certificate details. - **Self-Sign Notification:** Sent for documents where you’re the sender and invitee. Notifications are received when you sign and approve or reject the document. - **Auto-Deletion Notification:** Sent before a document's scheduled deletion date. ## Organisation Level Notification > **Info — note** > > Only admins can configure Organization-Level notifications. ### eSign Credits Low Balance - **Low Balance Notification:** Sent when eSign credits balance is low. You can set a [low eSign balance threshold for receiving these notification](https://knowledge.leegality.com/document-execution/settings/Wallet/notifications-for-low-balance-of-esign-and-stamp). ### Downtime You will get these notifications from `support@leegality.com` - **NSDL Updates:** Sent when there are updates regarding NSDL. - **Virtual Sign Downtime:** Sent when there are updates regarding Virtual Sign. - **NeSL Updates:** Sent for NeSL updates, including downtime and article code updates. ### SFTP - **SFTP Failure Notifications:** Sent when a completed document transfer fails via SFTP. ### General - **Payment Gateway Notifications:** Sent when the payment gateway account linked to your Leegality account is unlinked. - **eSign Credits and Stamps Expiry Notifications:** Sent when eSign credits and stamps are about to expire. Notifications are sent 30, 15, 3, 2, and 1 day before the expiration date. ### Stamp Procurement Updates - **Order Updates Notification:** Sent at key stages of your stamp paper procurement. - **Order Placed:** When a stamp order is created in Leegality. - **Order Delayed:** When the Leegality stamp team revises the due date for an order. - **Order Completed:** When all stamp papers in the order go live for the customer. - **Courier Updates Notification:** Sent for dispatch and delivery of physical stamp paper shipments, including tracking details. - **Courier Dispatched:** When the Leegality team dispatches the courier to the customer. - **Courier Delivered:** When the courier partner marks the shipment as delivered. ## Manage and Configure Recipients of Notifications 1. Click on the **Manage Recipients (n)** option. 2. Enter the Recipient's **name, email address and/or phone number**. 3. Click on the ✔ icon. Use the same steps to add, remove and edit the recipients of other types of notifications. > **Info — Note** > > - You can add a maximum of **3 recipients** per notification type. > - Recipients can be added using **either an official or a personal email address** — there is no restriction on the email domain. > **Info — Note** > > There is currently no provision to control or customize the timing of reminder notifications. Reminders are system-generated automatically based on the document creation date and time. --- URL: https://knowledge.leegality.com/document-execution/leegality-features/document-level/document-expiry # Set expiry of signing link Set expiry of signing link allows you to set the expiry timeline of the document. ## Configuring Expiry Duration When setting the expiry duration for a document, the following options apply: - **Minimum Expiry (45 minutes):** Set by entering `-1`. - **Same-Day Expiry:** Entering `0` sets the invite to expire at 11:59:59 PM on the day it is sent. - **Custom Expiry (1+ Days):** Entering any number greater than `0` specifies the number of days the invite will remain valid. > **Info — Note** > > Expiry days must be set to 365 or less. ## How to Set Expiry #### V3 Workflow 1. In the Invite section, click **Signing Journey Options** on the bottom left. 2. Enable the **Set Expiry of signing link**. 3. Specify the expiry duration. 4. Click **Save** #### Workflow Creation 1. In the Invite section, click **Advanced Options** on the bottom left. 2. Enable the **Expiry**. 3. Enter the expiry duration ## Note - **Toggle OFF:** The workflow runner cannot enable the feature. - Toggle ON (details specified): The workflow runner cannot make any changes. #### V4 Workflow 1. Toggle on **Consent and Validity Controls**. 2. Enable the **Expiry** toggle. 3. Enter the number of days after which the link will expire. #### Workflow Creation 1. Toggle on **Consent and Validity Controls**. 2. Enable the **Expiry** toggle. 3. Enter the number of days after which the link will expire. > **Info — Note** > > If no expiry duration is specified, the eSign invitation will default to a validity of 10 days. You can extend/reduce the expiry of an active sent document. ## Invitee Experience Once the document is expired, the email/SMS notification will be sent to the invitee. > **Info — Note** > > Document expiry reminders are sent 3, 2 & 1 days before the documents expire. --- URL: https://knowledge.leegality.com/document-execution/leegality-features/document-level/reference-attachments # Reference Attachments for Invitees The **Upload Reference Attachments for Invitees** feature allows senders to include additional attachments with the document being sent to invitees. These reference attachments are accessible to invitees during their signing journey, providing them with supplementary information or context related to the document. ## Use a Reference Attachment #### V3 Workflow 1. On the Invite Configuration page, select **Signing Journey Options** on the bottom left. 2. Then toggle on **Upload reference attachments for invitees**. 3. Upload the Reference attachment and give it a suitable name. 4. After the reference document is selected, click the **Upload** button to attach the reference document. #### Workflow Creation Upload Reference Attachment option is not available for Workflow. #### V4 Workflow 1. In the **Create** stage, open the primary document's details in the **Configure Documents** section. 2. Enable the **Reference Attachment** toggle. 3. Upload the reference file and give it a suitable name. Supported file types are **PDF, JPEG, PNG, or JPG**. **Note:** The reference attachments' total file size must be **5 MB or smaller**. #### Workflow Creation 1. In the **Create** stage, open the primary document's details in the **Configure Documents** section. 2. Enable the **Reference Attachment** toggle. 3. Upload the reference file and give it a suitable name. Supported file types are **PDF, JPEG, PNG, or JPG**. **Note:** The reference attachments' total file size must be **5 MB or smaller**. > **Info — Note** > > A reference attachment size should be less than 5MB. ## Accessing Reference Attachments During the Signing Journey Invitees can view and download reference attachments provided by the sender during their signing journey. #### V3 Workflow To access reference attachments: 1. Click the **Attachment** icon (📎) located on the top-left side of the screen. 2. A list of all reference attachments will appear. 3. Click **Preview** to view the attachment or **Download** to save it to your device. #### V4 Workflow To access reference attachments: 1. Click the **Attachment** icon (📎) located on the top-left side of the screen. 2. A list of all reference attachments will appear. 3. Click **Preview** to view the attachment or **Download** to save it to your device. --- URL: https://knowledge.leegality.com/document-execution/leegality-features/document-level/sftp # Transfer Completed Document using SFTP SFTP, or Secure File Transfer Protocol, is a file transfer mechanism that uses secure shell encryption to provide a high level of security for sending and receiving file transfers. It builds on the File Transfer Protocol (FTP) and includes Secure Shell (SSH) security components. SFTP transfers files securely using SSH and encrypted FTP commands to avoid password sniffing and exposing sensitive information in plain text. Since the client needs to be authenticated by the server, SFTP also protects against man-in-the-middle attacks. Secure File Transfer Protocol helps in providing secure file access, file transfer, and file management of signed documents and audit trails. > **Info — Note** > > Note: The transfer of this zip file is triggered within 15 mins upon document completion. ## Steps to activate SFTP 1. Once the document is created or while creating the workflow, on the invitee page click on **Signing journey options**. 2. Toggle on **Transfer Completed Document using SFTP**. 3. Choose an **SFTP Profile** from the drop-down. > **Info — Note** > > The completed document and audit trail will be transferred to the selected SFTP profile once the document is completed. If SFTP is configured for a document, once all signatories sign the document, the completed document and audit trail will be transferred via SFTP as a single zip file. An email/SMS notification will be triggered if the transfer via SFTP fails. ## Name Format of Transferred Document > **Info** > > - Zip file: IRN_DocumentID.zip > - Signed Document: 1_Document Name.pdf > - Audit Trail: 1_Audit Trail.pdf The Document Name and Audit Trail are indexed to prevent the transfer of duplicate documents. --- URL: https://knowledge.leegality.com/document-execution/leegality-features/document-level/custom-message # Custom Message The **Custom Message** feature allows senders to personalise the signing invitation by including a tailored message. When you enable the **Send custom message with signing link** option, you can configure a unique message that will accompany the signing invitation sent to invitees. This helps provide additional context or instructions to the notification. > **Info — Note** > > The custom message is included only in email invitations, not in SMS or WhatsApp. ## Use Custom Message #### V3 Workflow 1. In the invite configuration, click on the **Signing Journey Options**. 2. Enable the **Send custom message with signing link** option. 3. In the text field, write the message. 4. Click **Save**. #### Workflow Creation 1. In the invite configuration, click on the **Advanced Options**. 2. Enable the **Message** option. 3. In the text field, write the message. 4. Click **Save**. #### V4 Workflow 1. On the **Invite** stage, select the invitee card. 2. In the right panel, open the **Settings** tab and go to **Manage Invitee Interactions**. 3. Use **Custom message** to add a message that the invitee sees with the signing invitation. #### Workflow Creation 1. On the **Invite** stage, select the invitee card. 2. In the right panel, open the **Settings** tab and go to **Manage Invitee Interactions**. 3. Use **Custom message** to add a message that the invitee sees with the signing invitation. **Note:** Whether the workflow runner can modify this setting depends on the [field properties](https://knowledge.leegality.com/document-execution/workflows/v4/setup-configuration/field-properties) set by the workflow creator. ## Signing Journey The invitee will receive the custom message in their email notification. Refer to the image below for details. --- URL: https://knowledge.leegality.com/document-execution/leegality-features/invitee-level/types-of-invitee/reviewer # Reviewer A **Reviewer** is a non-signing invitee who is responsible for approving or rejecting a document. This feature ensures that documents undergo a review process, allowing the reviewer to validate and approve the content before it proceeds to the designated signatories for signing. ## Activate Reviewer Role #### V3 Workflow 1. On the **Invitee card**, click on the **Reviewer Role** icon. **Note:** All eSign types are disabled for Reviewer invitees. If the sender manually activates an eSign type for a Reviewer, the invitee reverts to the default Signer type role. 2. **Record Reviewer’s Response:** Toggle this option to include the Reviewer’s approval or rejection in the audit trail. 3. **Require OTP for Approval/Rejection:** Toggle this option to mandate OTP verification for the Reviewer to approve or reject the document. #### Workflow Creation 1. On the **Invitee card**, click on the **Reviewer Role** icon. 2. **Record Reviewer’s Response:** Toggle this option to include the Reviewer’s approval or rejection in the audit trail. 3. **Require OTP for Approval/Rejection:** Toggle this option to mandate OTP verification for the Reviewer to approve or reject the document. Now, the workflow creator has two options: - Leave the **Name, Email Address and/or Phone Number** placeholders empty, allowing the workflow runner to enter these while running the workflow. - Enable **Configure Invitee** and provide the Name and Email Address/Phone Number of the Reviewer. The workflow runner will not be able to modify these details. **Note:** If Configure Invitee is enabled, the workflow creator must provide at least one invitee's Name and Email/Phone Number. The workflow runner can add details for other invitees if not configured by the workflow creator. #### V4 Workflow 1. In the **Invite** stage, open the dropdown at the top left of the invitee card — it lists all four roles. Select **Reviewer**. 2. Enter the reviewer's **Name**, **Label**, **Email**, and **Phone**. 3. Click **Assign Documents** and select which document(s) this reviewer should review. #### Workflow Creation 1. In the **Invite** stage, open the dropdown at the top left of the invitee card — it lists all four roles. Select **Reviewer**. 2. Enter the reviewer's **Name**, **Label**, **Email**, and **Phone**. 3. Click **Assign Documents** and select which document(s) this reviewer should review. The workflow creator has two options: - Leave the **Name, Email Address and/or Phone Number** placeholders empty, allowing the workflow runner to enter these while running the workflow. - Provide the Reviewer's details. Whether the workflow runner can modify them depends on the visibility and editability the creator sets on those fields using [Field Properties](https://knowledge.leegality.com/document-execution/workflows/v4/setup-configuration/field-properties). > **Info — Note** > > - If the Record the Reviewer’s Response option is enabled, all security check information will also be mentioned in the audit trail upon document completion. > - Signing order is mandatory if at least one invitee is a Reviewer. ## Reviewer Journey 1. The invitee receives a notification to review the document. 2. Click **Review** to be redirected to the Reviewer journey page. 3. Preview the document. - If you are the first invitee and the **Allow first invitee to fill** option is enabled for a template document, you can fill out the template fields before proceeding. 4. After reviewing, click **Proceed**. 5. Complete OTP authentication, if required. 6. Choose to either: - **Approve** the document. - **Reject** the document. 7. Click **Submit**, check the consent box, and confirm the action by clicking **Approve Document** or **Reject Document**. > **Info** > > If the Sender is the Reviewer, they cannot reject the document. ## Post Review ### Upon Approval - The next invitee in the signing order will receive their invitation. - The sender will be notified of the approval. ### Upon Rejection - The next invitee will not receive their invitation. - The sender can manually activate the next invitee's invitation from the Details page if needed. - On the Public Details page, the invitee card of the reviewer who rejected the document will display a View Message button (if the reviewer entered a message). Clicking it will open a side menu with: - The reviewer's message content. - Additional invitee-related information. > **Info — eSign Credit Consumption** > > eSign credits are deducted when the document is approved. No credits are deducted if the document is rejected by a reviewer. --- URL: https://knowledge.leegality.com/document-execution/leegality-features/invitee-level/types-of-invitee/cc # CC Invitee A CC (Carbon Copy) Invitee is someone added to a document to stay updated on its progress. They receive notifications to ensure they are informed about the invitee and document's status. #### When to Use a CC Invitee CC invitees can be used in scenarios where individuals need to: - Receive notifications when invitations are sent to other invitees. - Stay informed about actions such as signing, approving, or rejecting by other invitees. - Be updated when the document is completed. - Be alerted about failure events like verification failure, expired invitations, or document deletions. ## Activate CC Invitee #### V3 Workflow 1. On the Invite page, toggle on **Send copies of notifications (CC)**. This will add a new section labeled **CC (Receive copies of notifications)**. 2. Enter the name and email address of the CC invitee. **Note:** CC invitees only support email contacts. 3. Click on the **CC options** to customize notifications and other settings for the CC invitee. - Select the types of email notifications the CC invitee will receive: - **Invitation notifications:** CC invitees are notified when: - Other invitees are invited to sign/review the document. - The sender re-sends the invitation. - Invitees receive document expiry reminders. - **Signing/Approval/Rejection Notifications:** Sent when other invitees sign, approve, or reject the document. - **Completion Notifications:** Sent when the document is fully signed or completed. - **Expiry/Failure/Deletion Notifications:** Sent if the document expires, fails, or is deleted. - **Share Signing / Review Link within CC’ed email:** Enable this option to include actionable links for signing/reviewing in CC emails. **Note:** No invitation URL is sent for NeSL and Automated eSign in CC emails. - **Share document and Audit trail with CC:** Enable this to send the completed document and audit trail to the CC invitee. - **Record CC details in Audit Trail:** Enable this to include all notifications sent to the CC invitee in the document’s audit trail. 4. Click **Save**. 5. (Optional) Click **+ Add CC** button to add more CC invitees. #### Workflow Creation 1. On the invite page, toggle on **Send copies of notifications (CC)**. This will add a new section labeled **CC (Receive copies of notifications)**. 2. Click **CC Options** and enable the required options. (**Note:** The workflow runner cannot modify this configuration.) - Select the types of email notifications the CC invitee will receive: - **Invitation notifications:** CC invitees are notified when: - Other invitees are invited to sign/review the document. - The sender re-sends the invitation. - Invitees receive document expiry reminders. - **Signing/Approval/Rejection Notifications:** Sent when other invitees sign, approve, or reject the document. - **Completion Notifications:** Sent when the document is fully signed or completed. - **Expiry/Failure/Deletion Notifications:** Sent if the document expires, fails, or is deleted. - **Share Signing / Review Link within CC’ed email:** Enable this option to include actionable links for signing/reviewing in CC emails. **Note:** No invitation URL is sent for NeSL and Automated eSign in CC emails. - **Share document and Audit trail with CC:** Enable this to send the completed document and audit trail to the CC invitee. - **Record CC details in Audit Trail:** Enable this to include all notifications sent to the CC invitee in the document’s audit trail. 3. Click the **+ Add CC** button to add the desired number of CC invitees. **Note:** The workflow runner cannot add more CC invitees, so it's recommended that the workflow creator adds extra CC invitees to accommodate any future requirements. Now, the workflow creator has two options: - Leave the **Name, Email Address and/or Phone Number** placeholders empty, allowing the workflow runner to enter these details when running the workflow. - Enable **Configure Invitee** and provide the Name and Email Address of the CC invitee. The workflow runner will not be able to modify these details. **Note:** If **Configure Invitee** is enabled, the workflow creator must provide at least one invitee's Name and Email/Phone Number. The workflow runner can add details for other invitees if not configured by the workflow creator. #### V4 Workflow 1. On the **Invite** stage, click the **+ Add CC** button at the bottom. 2. Enter the CC invitee's **Name** and **Email**. **Note:** For CC invitees, only email notifications are available. #### Workflow Creation 1. On the **Invite** stage, click the **+ Add CC** button at the bottom. 2. Enter the CC invitee's **Name** and **Email**. **Note:** For CC invitees, only email notifications are available. The workflow creator can also leave the **Name** and **Email** placeholders empty for the workflow runner to fill while running the workflow. **Note:** The workflow runner can add more CC invitees only if the workflow creator has enabled the visibility and editability of the **+ Add CC** button. See [Field Properties](https://knowledge.leegality.com/document-execution/workflows/v4/setup-configuration/field-properties). > **Info — Note** > > CC email notifications are not related to the Invitee Level email notification settings. > **Info — Note** > > The sender can *delete* a CC invitee at any point and effective immediately any further notifications will not be sent to that invitee. --- URL: https://knowledge.leegality.com/document-execution/leegality-features/invitee-level/types-of-invitee/group-invitee # Group Invitee Group Invitee allows the sender to send signing invitations to a group of authorized signatories. Using this feature, anyone or all signers in one group can sign the document, thus, reducing the dependency on a single signer. The Group Invitee feature eliminates this bottleneck, enabling faster document processing and ensuring that the document can proceed as soon as the required signatures are gathered. > **Tip — Example** > > Suppose on an offer letter, you need signatures of 2 out of 3 HR executives, you can create a group with all 3 HR executives and set the signer threshold to 2. Any 2 invitees can sign the document at their convenience, and once 2 signatures are collected, the group signing is complete. ## Activate Group Invitee #### V3 Workflow 1. On the **invitee card**, click on the **Convert to group** icon. 2. Enter the **Group Name**. 3. Enter the invitee details. (**Name, Email Address or Phone Number**.) 4. Click **+ Add invitee in group** to add more invitees to the group. (**Note:** Minimum two invitees are required in a group.) 5. Configure the **Invitee actions required for Group completion**. This specifies the number of invitees required to sign the document for successful completion of the group invite, with the threshold ranging from a minimum of 1 to the total number of invitees in the group. #### Workflow Creation 1. On the **invitee card**, click on the **Convert to group** icon. 2. Click **+ Add Invitee in group** to add more invitees to the group. **Note:** The workflow runner cannot add more invitees to the group, so it's recommended that the workflow creator adds extra invitees to the group to accommodate any future requirements. 3. Choose a **Signature Type**. It cannot be modified by the workflow runner. 4. Configure **Invitee Level options** as required. These cannot be modified by the workflow runner. 5. The workflow creator can configure the following options or leave them empty for the workflow runner to configure: - Group Name - Threshold - Invitee Details Now, for the **Invitee Details**, the workflow creator has two options: - Leave the **Name, Email Address and/or Phone Number** placeholders empty, allowing the workflow runner to enter these details when running the workflow. - Enable **Configure Invitee** and provide the Name and Email Address of the invitee. The workflow runner will not be able to modify these details. **Note:** If **Configure Invitee** is enabled, the workflow creator must provide at least one invitee's Name and Email/Phone Number. The workflow runner can add details for other invitees if the workflow creator does not configure it. #### V4 Workflow 1. On the **invitee card**, use the role dropdown at the top left and select **Group Signer** or **Group Reviewer**. In v4, a group is treated just like any other invitee — there is no separate Group Name field. 2. Click **+ Add invitee in group** to add invitees to the group, and enter each invitee's **Name**, **Label**, and **Email Address**/**Phone Number**. **Note:** A minimum of two invitees is required in a group. 3. Configure the **Invitee actions required for Group completion** (the threshold). This specifies the number of invitees required to sign the document for successful completion of the group invite, with the threshold ranging from a minimum of 1 to the total number of invitees in the group. 4. Just like any other invitee, use **Assign Documents** on the group's card to assign primary documents to it — the whole group is treated as a single assignable invitee. #### Workflow Creation 1. On the **invitee card**, use the role dropdown at the top left and select **Group Signer** or **Group Reviewer**. In v4, a group is treated just like any other invitee — there is no separate Group Name field. 2. Click **+ Add invitee in group** to add invitees to the group. **Note:** A minimum of two invitees is required in a group. The workflow runner cannot add more invitees to the group, so it's recommended that the workflow creator adds extra invitees to accommodate any future requirements. 3. Configure the **Invitee actions required for Group completion** (the threshold). This specifies the number of invitees required to sign the document for successful completion of the group invite, with the threshold ranging from a minimum of 1 to the total number of invitees in the group. 4. For each invitee's **Name**, **Label**, and **Email Address**/**Phone Number**, the workflow creator has two options: - Leave the placeholders empty, allowing the workflow runner to enter these details when running the workflow. - Provide the details yourself. Whether the workflow runner can modify them depends on the visibility and editability the creator sets on those fields using [Field Properties](https://knowledge.leegality.com/document-execution/workflows/v4/setup-configuration/field-properties). 5. Just like any other invitee, use **Assign Documents** on the group's card to assign primary documents to it — the whole group is treated as a single assignable invitee. > **Info — Note** > > The eSign types and Invitee Group level options will be applicable to everyone in the group. > **Info — Note** > > Invitee Groups are also compatible with the “Reviewer Role”. ## Signing Journey for Group Invitee Once the signing invite is sent with the group invitee configured, the signer can sign the document. During the signing journey, the signer can see the group invitees by clicking on the **invitees** option Proceed with the signing of the document. Once the document is signed by any of the group invitees(depending on the threshold set while configuring the group invitee), the document gets completely signed. Once the document is completed, the signed document will be sent to all configured invitees in the group. > **Tip — Example** > > If the Group has 3 invitee and threshold is set as 2, the invitation for other signers gets expires once 2 invitees sign the document. --- URL: https://knowledge.leegality.com/document-execution/leegality-features/invitee-level/security/one-factor-authentication # One Factor Authentication **One Factor Authentication** adds an essential layer of security to the signing process by requiring invitees to authenticate their identity via OTP sent to their Email ID or Phone Number (as configured during document setup). This ensures that only the intended recipient can access and view the document, safeguarding against unauthorized access due to mistaken forwarding of signing invitations. ## Use One Factor Authentication #### V3 Workflow 1. On the **Invitee card**, click **Invitee level Options**. 2. Toggle ON **Enable Security Features**. 3. Enable the **Require 1-factor authentication before document preview**. 4. Click **Save** and continue. #### Workflow Creation 1. On the **Invitee card**, click **More Options**. 2. Toggle ON **Advanced Security Features**. 3. Enable the **Enforce 1-factor authentication before document preview**. 4. Click **Save** and continue. The workflow runner cannot disable notifications if enabled by the workflow creator, and vice versa. #### V4 Workflow 1. On the **Invite** stage, select the invitee card. 2. In the right panel, open the **Settings** tab and go to **Security Options**. 3. Enable **1 Factor Authentication before document preview** — the invitee must verify an OTP via email or phone number before they can preview the document. #### Workflow Creation 1. On the **Invite** stage, select the invitee card. 2. In the right panel, open the **Settings** tab and go to **Security Options**. 3. Enable **1 Factor Authentication before document preview** — the invitee must verify an OTP via email or phone number before they can preview the document. **Note:** Whether the workflow runner can modify this setting depends on the [field properties](https://knowledge.leegality.com/document-execution/workflows/v4/setup-configuration/field-properties) set by the workflow creator. > **Info — Note** > > One Factor Authentication does not work with Quick Sign. ## Signing Journey 1. Click the **Sign** button in the email invitation or the eSign link received via SMS. 2. Provide the OTP sent to the email address or phone number associated with the eSign invitation. 3. Check your email or SMS for the OTP. 4. Input the OTP and click **Proceed**. 5. Access the document and proceed with the signing/reviewing process. --- URL: https://knowledge.leegality.com/document-execution/leegality-features/invitee-level/security/two-factor-authentication # Two Factor Authentication **Two Factor Authentication** enhances document security by requiring invitees to authenticate using OTPs sent to both their Email ID and Phone Number before accessing the document. This ensures an additional layer of protection, preventing unauthorized access even if the signing invitation is mistakenly forwarded. To enable this feature, both the Email ID and Phone Number must be configured during document creation. ## How Two Factor Authentication Works 1. **Signing Link Accessed via Email or Phone Number:** - **Via Invitee Email:** If the signing link is accessed through the invitee's email, this counts as one authentication. The invitee will only need to complete OTP authentication for their mobile number. - **Via Invitee Phone Number:** If the signing link is accessed through the invitee's phone number, this counts as one authentication. The invitee will only need to complete OTP authentication for their email. 2. **Signing Link Accessed via Other Sources:** - If the signing link is accessed through any other source, both OTP authentications will be required—one for the email and one for the phone number. ## Use Two Factor Authentication #### V3 Workflow 1. On the **Invitee card**, click **Invitee level Options**. 2. Toggle ON **Enable Security Features**. 3. Enable **Require '2-factor authentication' before document preview**. This will open up both email and phone fields for you to enter for the signatory. Entering both fields is mandatory in case of a 2FA flow. #### Workflow Creation 1. On the **Invitee card**, click **More options**. 2. Toggle ON **Advanced Security Features**. 3. Enable **Enforce 2-Factor Authentication before document preview**. This will open up both email and phone fields for the signatory. If you are **Configuring Invitee** during Workflow creation, then you need to enter both fields at this step. In case you want to allow the Workflow Runner to enter these fields, leave the **‘Configure Invitee’** toggle off. Do note that the Workflow Runner will have to mandatorily enter both of these fields. #### V4 Workflow 1. On the **Invite** stage, select the invitee card. 2. In the right panel, open the **Settings** tab and go to **Security Options**. 3. Enable **2 Factor Authentication before document preview** — the invitee must verify OTPs via both email and phone number before they can preview the document. #### Workflow Creation 1. On the **Invite** stage, select the invitee card. 2. In the right panel, open the **Settings** tab and go to **Security Options**. 3. Enable **2 Factor Authentication before document preview** — the invitee must verify OTPs via both email and phone number before they can preview the document. **Note:** Whether the workflow runner can modify this setting depends on the [field properties](https://knowledge.leegality.com/document-execution/workflows/v4/setup-configuration/field-properties) set by the workflow creator. > **Info — Note** > > 2-factor authentication doesn't work with Quick Sign > **Info — Note** > > Organisation Admins can enforce Two-Factor Authentication (2FA) for all documents sent from their accounts to enhance security. To learn how to enable this setting, [**click here**](https://knowledge.leegality.com/document-execution/settings/Department/document-security-settings) --- URL: https://knowledge.leegality.com/document-execution/leegality-features/invitee-level/security/capture-gps-location # Capture GPS Location If the security feature "Capture GPS location" is enabled, the signers will need to allow access to their location coordinates before being permitted to sign the document. The GPS coordinates captured will be reflected in the audit trail. Geofencing is similar to creating a virtual barrier around a certain area. This fence designates the area we want to monitor, manage or control. In case of Leegality - Signing your clients documents within a designated area. ## Activate Capture GPS location #### V3 Workflow 1. On the **Invitee Card**, click **Invitee Level Options**. 2. Toggle ON **Enable Security Features**. 3. Enable **Capture GPS Location**, then configure the following options: - **Capture GPS Location Only:** If this is the only option enabled, the invitee’s GPS location will be captured without restrictions. - **Apply Accuracy-Based Restrictions:** If enabled, the invitee cannot proceed if the captured GPS accuracy deviation exceeds the specified value in the **Accuracy Threshold** field. - **Apply Location-Based Restrictions:** If enabled, the invitee cannot proceed if their GPS location falls outside the specified **Coordinates (Latitude and Longitude)** and **Permissible Radius**. - **Restrict to India:** If enabled, the invitee needs to be in India in order to sign the document. 4. Click **Save**. The default coordinates configured by the admin are automatically applied. However, the sender can either use the predefined settings or customize the **Accuracy Threshold** and **Lat-Long Coordinates** for individual signers or reviewers. #### Workflow Creation 1. On the **Invitee Card**, click **More options**. 2. Toggle ON **Advanced Security Features**. 3. Enable **Capture GPS Location**, then configure the following options: - **Capture GPS Location Only:** If this is the only option enabled, the invitee’s GPS location will be captured without restrictions. - **Apply Accuracy-Based Restrictions:** If enabled, the invitee cannot proceed if the captured GPS accuracy deviation exceeds the specified value in the **Accuracy Threshold** field. - **Apply Location-Based Restrictions:** If enabled, the invitee cannot proceed if their GPS location falls outside the specified **Coordinates (Latitude and Longitude)** and **Permissible Radius**. - **Restrict to India:** If enabled, the invitee needs to be in India in order to sign the document. Now, the workflow creator has two options, either: - **Predefined Settings:** Configure the *Accuracy Threshold, Latitude-Longitude*, and *Permissible Radius* during workflow creation. These settings are applied automatically, and the workflow runner cannot modify them. - **Allow Workflow Runner Modifications:** Enable **Allow sender to make changes while running the workflow**. The workflow runner can optionally add *Accuracy Threshold*, *Latitude-Longitude*, and *Permissible Radius* while running the workflow. If left blank, no such restrictions will apply to invitee. #### V4 Workflow 1. On the **Invite** stage, select the invitee card. 2. In the right panel, open the **Settings** tab and go to **Security Options**. 3. Enable **Capture GPS Location**, then configure the following options: - **Accuracy Based Restrictions:** Specify the **Accuracy Threshold** — the invitee cannot proceed if the captured GPS accuracy deviation exceeds this value. - **Location Based Restrictions:** Choose one of the following: - **Restrict to India:** The invitee must be in India to sign the document. - **Latitude, Longitude and Radius:** Specify the **Latitude**, **Longitude**, and **Permissible Radius** (in meters) the invitee must be within to sign. #### Workflow Creation 1. On the **Invite** stage, select the invitee card. 2. In the right panel, open the **Settings** tab and go to **Security Options**. 3. Enable **Capture GPS Location**, then configure the following options: - **Accuracy Based Restrictions:** Specify the **Accuracy Threshold** — the invitee cannot proceed if the captured GPS accuracy deviation exceeds this value. - **Location Based Restrictions:** Choose one of the following: - **Restrict to India:** The invitee must be in India to sign the document. - **Latitude, Longitude and Radius:** Specify the **Latitude**, **Longitude**, and **Permissible Radius** (in meters) the invitee must be within to sign. **Note:** Whether the workflow runner can modify this setting depends on the [field properties](https://knowledge.leegality.com/document-execution/workflows/v4/setup-configuration/field-properties) set by the workflow creator. > **Info — Note** > > In order to successfully capture a location, the **Accuracy Threshold** and **Permissible Radius** should be set at a greater range (2000 - 4000 m instead of 1000 m). This is because location capture depends on the device (e.g., laptops/computers have poorer accuracy compared to mobile devices). ## Signing Journey of Capture GPS location During the signing journey, the GPS location will be captured, and click on “proceed”, the captured location will appear in the audit trail. > **Info — Note** > > Signer has to give the location access to the browser for capturing GPS location while signing the document. ### Scenario A: Successful GPS Capture The flow will continue to operate as it does now if the invitation was signed or evaluated and did not violate the location-based or accuracy-based constraints and the document will be signed successfully. ### Scenario B: Failed GPS Capture Set configurations will be reviewed by the system and if there are any breaches then the invitee will be allowed to retry the signing or reviewing attempt. ​ 1. If **Accuracy-based Restriction** fails, the message *Your GPS accuracy is low. Please check your device’s location service and try again.* is displayed. Refer to the image below. 2. If **Location-based Restriction** fails, the message *You are outside the permissible area. Please try again from a different location.* is displayed. Refer to the image below. > **Info — Note** > > Accuracy-based restrictions function best on mobile devices and tablets, which have the necessary hardware for precise GPS capture. Laptops and desktops may not provide highly accurate GPS location data. --- URL: https://knowledge.leegality.com/document-execution/leegality-features/invitee-level/security/capture-photo # Capture Photo If the security feature "Capture photo" is enabled, the signer will need to grant access to their camera for live photo capture. The signer will not be allowed to sign the document until the live photo capture is completed. ## Activate Capture photo #### V3 Workflow 1. On the Invitee Card, click **Invitee Level Options**. 2. Toggle ON **Enable Security Features**. 3. Enable the **Capture photo**. 4. Click **Save**. #### Workflow Creation 1. On the Invitee Card, click **More options**. 2. Toggle ON **Advanced Security Features**. 3. Enable the **Capture photo**. 4. Click **Save**. **Note:** The workflow runner cannot disable this while running the workflow. #### V4 Workflow 1. On the **Invite** stage, select the invitee card. 2. In the right panel, open the **Settings** tab and go to **Security Options**. 3. Enable **Capture Photo** to capture the signer's photo before they sign. #### Workflow Creation 1. On the **Invite** stage, select the invitee card. 2. In the right panel, open the **Settings** tab and go to **Security Options**. 3. Enable **Capture Photo** to capture the signer's photo before they sign. **Note:** Whether the workflow runner can modify this setting depends on the [field properties](https://knowledge.leegality.com/document-execution/workflows/v4/setup-configuration/field-properties) set by the workflow creator. ## Signing Journey 1. During the signing journey, the signer is presented with a set of on-screen instructions to follow. 2. After ensuring the prerequisites mentioned on the instruction page are met, click **Proceed**. The signer must grant camera access for photo capture. 3. Click **Capture** to take the photo. 4. Review the captured photo. If satisfied, click **Proceed**; otherwise, click **Retry** to retake the photo. --- URL: https://knowledge.leegality.com/document-execution/leegality-features/invitee-level/security/face-match # Face Match The **Face Match** feature enhances document security by leveraging facial recognition technology to verify the signer's identity. It matches the signer's face image, captured during the signing journey, with a reference image—such as an uploaded identity document or face verification photo—provided by the sender when sending the document. This ensures that only the intended recipient is authorized to sign, offering an additional layer of identity verification. ## Activate Face Match #### V3 Workflow 1. On the **Invitee Card**, click **Invitee Level Options**. 2. Toggle ON **Enable Security Features**. 3. Enable **Capture Photo**. 4. Enable **Face Match**. 5. Upload a **Reference Image**: An image uploaded by the sender, used to verify the invitee's identity during the signing journey by comparing it with the photo captured at the time of signing. - This may include identity documents such as a PAN Card, Aadhaar Card, or onboarding forms. For accurate facial recognition, crop or mask the document to show only the signer's face before uploading. 6. Set the **Retry Attempts**: Specify the number of attempts the signer can make to successfully capture and match their face. #### Workflow Creation 1. On the **Invitee Card**, click **More Options**. 2. Toggle ON **Advanced Security Features**. 3. Enable **Capture Photo**. 4. Enable **Face Match**. 5. A **Reference Image**: An image uploaded by the sender, used to verify the invitee's identity during the signing journey by comparing it with the photo captured at the time of signing. (**Note:** It needs to be uploaded by the workflow runner while sending the document.) 6. Set the **Retry Attempts**: Specify the number of attempts the signer can make to successfully capture and match their face. (**Note:** Workflow runner cannot modify the Retry Attempts.) **Note:** The workflow runner cannot disable this if enabled by the workflow creator, and vice versa. #### V4 Workflow 1. On the **Invite** stage, select the invitee card. 2. In the right panel, open the **Settings** tab and go to **Security Options**. 3. Enable **Capture Photo**, then enable **Face Match**. 4. Upload a **Reference Image** — an image used to verify the invitee's identity by comparing it with the photo captured at signing. - This may include identity documents such as a PAN Card, Aadhaar Card, or onboarding forms. For accurate facial recognition, crop or mask the document to show only the signer's face before uploading. 5. Set the **Retry Attempts** — the number of attempts the signer can make to successfully capture and match their face. #### Workflow Creation 1. On the **Invite** stage, select the invitee card. 2. In the right panel, open the **Settings** tab and go to **Security Options**. 3. Enable **Capture Photo**, then enable **Face Match**. 4. Upload a **Reference Image** — an image used to verify the invitee's identity by comparing it with the photo captured at signing. - This may include identity documents such as a PAN Card, Aadhaar Card, or onboarding forms. For accurate facial recognition, crop or mask the document to show only the signer's face before uploading. 5. Set the **Retry Attempts** — the number of attempts the signer can make to successfully capture and match their face. **Note:** Whether the workflow runner can modify this setting depends on the [field properties](https://knowledge.leegality.com/document-execution/workflows/v4/setup-configuration/field-properties) set by the workflow creator. ## Signing Journey 1. During the signing journey, the signer is presented with a set of on-screen instructions to follow. 2. After ensuring the prerequisites mentioned on the instruction page are met, click **Proceed**. The signer must grant camera access for photo capture. 3. Click **Capture** to take the photo. 4. Next, - **Successful Face Match:** The invitee will see a success message and can proceed to sign or review the document. - **Failed Face Match:** If the captured face does not match or no face is detected, the invitee will be prompted to retry. --- URL: https://knowledge.leegality.com/document-execution/leegality-features/invitee-level/security/manual-liveliness # Manual User Liveliness This feature prompts the signer to do a face capture along with an OTP verification (the OTP will appear on the screen) in order to proceed with the signing process. ## Activate Manual User liveliness #### V3 Workflow 1. On the **Invitee Card**, click **Invitee Level Options**. 2. Toggle ON **Enable Security Features**. 3. Enable **Capture Photo**. 4. Enable **Liveliness** and select the **User Liveliness (Manual Check)** option. 5. Click **Save**. #### Workflow Creation 1. On the **Invitee Card**, click **More Options**. 2. Toggle ON **Advanced Security Features**. 3. Enable **Capture Photo**. 4. Enable **Liveliness** and select the **User Liveliness (Manual Check)** option. 5. Click **Save**. **Note:** The workflow runner cannot disable this if enabled by the workflow creator, and vice versa. #### V4 Workflow *V4 content coming soon.* #### Workflow Creation *V4 content coming soon.* ## Signing Journey 1. During the signing journey, the below instructions will appear on the screen which has to be followed. - Capture a 5-second video clip of yourself - Displaying OTP in front of you - Sit in well-lit place - Only 1 person before the camera - Remove accessories such as spectacles and headphones. 2. After having the prerequisites as mentioned on the instruction page click on “Proceed”. 3. The signer will need to allow access to their camera for capturing the short live video and show the OTP that is appearing on the screen. - **Two ways to show OTP during liveliness:** - **QR Code:** Scan the QR code in the phone camera which will lead to the OTP page in the phone browser which the signer has to show in front of the camera and capture the photos. - **On blank page:** Write down the OTP on the blank page and show it in front of the camera and capture the photos. 4. Once the photos are captured, click on “Proceed” to proceed with the signing of the document. > **Info — Note** > > The signer will not be allowed to sign the document until the system verifies the OTP appearing on the screen that is written on paper or shown on the phone. --- URL: https://knowledge.leegality.com/document-execution/leegality-features/invitee-level/security/smart-user-liveliness # Smart User Liveliness Smart User Liveliness ensures that the signatory is actively present during the eSigning process using AI-based facial recognition. It detects and rejects spoofing attempts such as photos and recorded videos. By analysing facial cues and other behavioural patterns, Smart User Liveliness ensures signer identity, enhancing the security and integrity of electronic signatures. ## Enable Smart User Liveliness in Department-Level Settings You can enable Smart User Liveliness in the Department-level settings, depending on your subscription plan. > **Info — Note** > > The availability of Smart User Liveliness in Department-level Settings depends on your subscription plan. > > If included in your plan, only one version (either Smart User Liveliness Version 1 or Version 2 Beta) will be active for your Leegality account at any given time. 1. Click on the **Setting ⚙️** icon on the top right corner. 2. Go to the **Department > Invitee Configs**. 3. Toggle Enable **Smart User Liveliness** (**Note:** Version 1 or 2 will be shown based on your subscription). 4. Set the **Acceptance Percentage**. The Acceptance Percentage indicates the confidence score at which Smart User Liveliness confirms the authenticity of the document signer. (We recommend setting this percentage to around 65%.) 5. Click **Update** to save settings. > **Info — note** > > OTP-based (Manual) User Liveliness will not appear in Department settings but you will get it in the Sending Journey if included in your plan. ## Use Smart User Liveliness #### V3 Workflow 1. Click on **+ Create** and start a new document journey or select a template. 2. On the Invite screen, click on **Invitee level options** of those invitees for whom you want to enable Smart User Liveliness. 3. Toggle **Enable security features**. After that, enable **Capture photo**, and then enable **Liveliness**. 4. Select the **Smart User Liveliness** option. > **Info** > > Smart User Liveliness replaces Old User Liveliness in the sending journey if enabled in department-level settings. 5. Set the **number of retry attempts** allowed by the signer for Smart User Liveliness. The drop down offers options ranging from 0 to 3. “0” signifies no retry attempts, while each increment from 1 onwards represents an additional retry attempt beyond the original. 6. Click **Save** and send your document. > **Info** > > Smart User Liveliness is unavailable for Automated eSign (Virtual & Doc Signer) & Doc Signer. #### Workflow Creation The same steps apply for workflow-based sending journeys (Excel and Dashboard). 1. Open the workflow and go to the Invite stage. 2. Click on **Invitee level options** of those invitees for whom you want to enable Smart User Liveliness. 3. Toggle **Enable security features**. After that, enable **Capture photo**, and then enable **Liveliness**. 4. Select the **Smart User Liveliness** option. > **Info** > > Smart User Liveliness replaces Old User Liveliness in the sending journey if enabled in department-level settings. 5. Set the **number of retry attempts** allowed by the signer for Smart User Liveliness. The drop down offers options ranging from 0 to 3. “0” signifies no retry attempts, while each increment from 1 onwards represents an additional retry attempt beyond the original. 6. Click **Save** and send your document. > **Info** > > Smart User Liveliness is unavailable for Automated eSign (Virtual & Doc Signer) & Doc Signer. #### V4 Workflow 1. On the **Invite** stage, select the invitee card. 2. In the right panel, open the **Settings** tab and go to **Security Options**. 3. Enable **Capture Photo**, then enable **Liveliness** and select the **Smart User Liveliness** option. 4. Set the **number of retry attempts** allowed by the signer (0 to 3). > **Info** > > Smart User Liveliness replaces Old User Liveliness in the sending journey if enabled in department-level settings. #### Workflow Creation 1. On the **Invite** stage, select the invitee card. 2. In the right panel, open the **Settings** tab and go to **Security Options**. 3. Enable **Capture Photo**, then enable **Liveliness** and select the **Smart User Liveliness** option. 4. Set the **number of retry attempts** allowed by the signer (0 to 3). > **Info** > > Smart User Liveliness replaces Old User Liveliness in the sending journey if enabled in department-level settings. Whether the workflow runner can modify this setting depends on the [field properties](https://knowledge.leegality.com/document-execution/workflows/v4/setup-configuration/field-properties) set by the workflow creator. ## Signing Journey Here, we outline the signing process with Smart User Liveliness. The signer needs to follow the steps mentioned below to complete the Liveliness check in their signing journey. > **Info — Note** > > These instructions must be followed strictly for successful signer’s verification. 1. The invitee receives the invitation via email, SMS, or WhatsApp. Start the journey by clicking signing link/button. 2. Preview the document and click on the **Proceed** button 3. Read and follow the instructions carefully and click on Proceed at the bottom right. 4. Next, a camera preview will be shown to the signer. Here they can switch between front or back cameras and also ensure the face is properly visible. 5. Once satisfied with the preview, click Capture to **continue**. 6. The signer must align their face within the oval frame within 15 seconds. ### Case I: Success - The signer will see a success message with 3 captured photos. - If the signer is unsatisfied with the outcome, they can click on **Retry** for another face capture attempt. ### Case II: Failure - The signer encounters a failure message (e.g., Time Out or Threshold not matched). - In case of Time out, the signer needs to retry the face capture attempt and place their face in the oval within the set time frame. - In case, the Threshold is not matched, the signer needs to retry the face capture (If additional attempts are allowed) and make sure they are in a well-lit environment with no accessories on like spectacles, headphones, etc. 7. Click **Proceed** in the bottom right corner to eSign the document. ## Face Match + Smart User Liveliness If you have configured both Smart User Liveliness and Face Match then the process of both will be carried out simultaneously in a single face capture. The signer will not be required to separately perform Face Match and Smart User Liveliness. The results of both will be shown on a single screen as well. > **Info — note** > > If Smart Face Liveliness fails then Face Match will not happen at all and only the liveliness result will be shown. If both Liveliness and face match are successful, a success screen will be shown. The remaining attempts displayed will reflect the lower count between Smart Face Liveliness and Face Match. Once attempts for either verification are exhausted, the signer cannot retry both liveliness and face match. For example, Face Match has 2 retry attempts and Smart Face Liveliness has 3 retry attempts. Then, After 2 retry attempts the signer cannot do both, neither Face Match nor Liveliness. ## Best Practices for Signers - Smart User Liveliness The signer can optimise their confidence score by adhering to these best practices during the liveliness check. - Make sure the signer is in a well-lit place. - Only one intended person should be in front of the camera. - Remove accessories like spectacles, masks, hats, headphone, etc. - Set the display’s screen brightness to a maximum level. - The surrounding environment should have fairly uniform light, and not too dark or too bright. - Lighting on the face should be flat, avoiding varied lighting such as shadows. - The signer’s face should have neutral facial expressions with mouth closed and little to no smile. - Minimum video recording resolution: 320x240px. ## Details Page: View Remaining Retry Attempts To check the remaining retry attempts for Smart user liveliness and/or face match verification for a signer: 1. Go to the details page of the document. 2. Hover over the info icon ⓘ next to the specific invitee. 3. A tooltip will display the remaining retry attempts for smart user liveliness and face match for that invitee. In the event of a timeout (where the system couldn’t detect your face within the oval in approximately 40 seconds), the number of retry attempts will not decrease. However, if the Smart User Liveliness check is unsuccessful, the number of attempts will decrease by 1. --- URL: https://knowledge.leegality.com/document-execution/leegality-features/invitee-level/notifications/email-notifications # Email Notifications Email notifications keep invitees informed about key events in the document signing journey, including status updates and required actions, ensuring timely and efficient completion of tasks. For a full list of optional and mandatory notification types — including reminder notification frequency — see [Invitee Notifications](https://knowledge.leegality.com/document-execution/leegality-features/invitee-level/notifications). If email notifications are **disabled**, invitees will not receive optional notifications. Some notifications are always sent regardless of this setting. See [Invitee Notifications](https://knowledge.leegality.com/document-execution/leegality-features/invitee-level/notifications) for the complete breakdown. ## Use Email Notifications #### New Document Journey Email notifications are enabled by default but can be disable if not needed. 1. On the **Invitee Card**, click **Invitee Level Options**. 2. Enable or Disable **Send Email Notifications**. 3. Click **Save**. #### Workflow Creation All notifications are disabled by default During workflow creation. 1. On the **Invitee Card**, click **More Options**. 2. Enable **Send Email Notifications**. 3. Click **Save**. The workflow runner cannot disable notifications if enabled by the workflow creator, and vice versa. --- URL: https://knowledge.leegality.com/document-execution/leegality-features/invitee-level/notifications/sms-notifications # SMS Notifications SMS notifications keep invitees informed about key events in the document signing journey via their phone number. For a full list of optional and mandatory notification types — including reminder notification frequency — see [Invitee Notifications](https://knowledge.leegality.com/document-execution/leegality-features/invitee-level/notifications). If SMS notifications are **disabled**, invitees will not receive optional notifications. Some notifications are always sent regardless of this setting. See [Invitee Notifications](https://knowledge.leegality.com/document-execution/leegality-features/invitee-level/notifications) for the complete breakdown. ## Use SMS Notifications #### New Document Journey SMS notifications are enabled by default but can be disabled if not needed. 1. On the **Invitee Card**, click **Invitee Level Options**. 2. Enable or Disable **Send SMS Notifications**. 3. Click **Save**. #### Workflow Creation All notifications are disabled by default during workflow creation. 1. On the **Invitee Card**, click **More Options**. 2. Enable **Send SMS Notifications**. 3. Click **Save**. The workflow runner cannot disable notifications if enabled by the workflow creator, and vice versa. --- URL: https://knowledge.leegality.com/document-execution/leegality-features/invitee-level/notifications/whatspp-notifications # WhatsApp Notifications In addition to SMS and Emails, communications can be sent to the invitees via WhatsApp messages as well. WhatsApp provides a better experience and robust delivery. WhatsApp can be activated for the invitees with their phone numbers. For a full list of optional and mandatory notification types — including reminder notification frequency — see [Invitee Notifications](https://knowledge.leegality.com/document-execution/leegality-features/invitee-level/notifications). ## Use WhatsApp Notifications #### New Document Journey WhatsApp notifications are enabled by default but can be disable if not needed. 1. On the **Invitee Card**, enter the invitee's phone number and toggle ON **Activate WhatsApp**. (This sends only mandatory notifications via WhatsApp) 2. Click **Invitee Level Options**. 3. Enable **Send WhatsApp Notification** for non-mandatory notifications. 4. Click **Save**. #### Workflow Creation During workflow creation, all notifications are disabled by default. Workflow creator needs to enable them as per requirement. 1. On the **Invitee Card**, enter the invitee's phone number and toggle ON **Activate WhatsApp**. (This sends only mandatory notifications via WhatsApp) 2. Click **Invitee Level Options**. 3. Enable **Send WhatsApp Notification** for non-mandatory notifications. 4. Click **Save**. The workflow runner cannot disable notifications if enabled by the workflow creator, and vice versa. ## How WhatsApp Notifications Work? On Invitee Card, when **Activate WhatsApp** toggle is Enabled for an invitee: - Mandatory notifications, like document completion notifications and manual reminders, will always be sent via both SMS and WhatsApp, regardless of whether you’ve enabled WhatsApp or SMS notifications in the invitee level options. - Non-mandatory notifications, like automatic reminders, will be sent to invitees based on the selection of WhatsApp and SMS notifications in the invitee level options. The table below illustrates all combinations of SMS Notifications and WhatsApp Notifications, along with the corresponding notification delivery scenarios. | Invitee Level Options | | Non Mandatory Notifications | | | ----- | :---- | ----- | :---- | | **SMS Notification** | **WhatsApp Notification** | **SMS** | **WhatsApp** | | Off | Off | No | No | | Off | On | No, except when WhatsApp notifications failed to deliver. | Yes | | On | Off | Yes | No | | On | On | Yes, along with WhatsApp notification | Yes, along with SMS Notification | --- URL: https://knowledge.leegality.com/document-execution/leegality-features/invitee-level/esignature-appearance/invitee-name-in-signature # Invitee Name in Signature By default, the signer’s name configured during the invitee setup or entered by them during the signing journey appears inside the signature box. Enabling the option *Don't show invitee name in signature appearance* removes the invitee's name from the signature box. ## Show or Hide Invitee's Name in Signature #### V3 Workflow 1. On the **Invitee Card**, click **Invitee Level Options** (labelled **More Options** in a workflow). 2. Toggle **Don't show invitee name in signature appearance** to: - **Enabled:** The invitee's name will *not* be visible on signature. - **Disabled:** The invitee's name will be visible on signature. **Note:** Within a reusable workflow, the workflow runner cannot disable this if enabled by the creator, and vice versa. #### V4 Workflow 1. On the **Invite** stage, select the invitee card. 2. In the right panel, open the **Settings** tab and go to **Signature Appearance**. 3. Use **Invitee Name on Signature** to choose whether the invitee's name is displayed in the signature. **Note:** Within a reusable workflow, whether the workflow runner can modify this setting depends on the [field properties](https://knowledge.leegality.com/document-execution/workflows/v4/setup-configuration/field-properties) set by the workflow creator. > **Info — Note** > > This feature cannot be enabled for Automated eSign and NeSL. ## Signature Example The signer's name will appear within the signature, as shown in the image below. --- URL: https://knowledge.leegality.com/document-execution/leegality-features/invitee-level/esignature-appearance/company-seal # Company Seal from Invitee An eSignature seal is a digital version of the traditional rubber stamp. It is used to authenticate signatures. Enable the option **Require company seal from invitee** while sending the document to get an organizational signature. Leegality will create a digital impression of a rubber seal and apply it on the signature of the signer. Configure your eSignature seal here. When a sender requests your signature with a seal, the one you have set up will be automatically pre-selected. To set up the eSignature seal for your account: 1. Click on the **Settings ⚙️** icon in the top right corner. 2. From the left panel, go to **Settings > eSignature & Seal.** 3. In the Default eSignature Seal section, you can choose between three types of eSignature seals: - **Authorised Signatory:** Requires organization's name. - **Director:** Requires organization's name. - **Upload Physical Seal:** Upload an image of the physical seal. (Supported image formats are .jpg, .jpeg, and .png) > **Info** > > The company seal feature is available in every signing method, including **Aadhaar eSign**. When using Aadhaar eSign with a company seal, the signature will display your company seal instead of the Aadhaar logo. 4. You can see the preview of the eSignature seal on the right. 5. Click **Update** to save your settings. ## Requiring a Company Seal from Invitees #### V3 Workflow 1. On the **Invitee Card**, click **Invitee Level Options** (labelled **More Options** in a workflow). 2. Enable **Require company seal from invitee** (labelled **Require Organisational Signature** in a workflow). 3. **Set organisation name:** The sender can either enter the organisation's name on behalf of the invitee or leave it blank for the invitee to provide during the signing journey. Within a reusable workflow, this becomes a three-way choice: leave it disabled so the invitee provides it, enable it without a name so the workflow runner must provide it while running the workflow, or enable it with a fixed name that neither the runner nor the invitee can modify. 4. **Choose a Seal Type:** Select one of the following options: - **Authorised Signatory Seal** - **Director Seal** - **Allow Upload of Custom Seal:** The invitee will be required to upload an image of their company seal during the signing journey. 5. Click **Save**. **Note:** Within a reusable workflow, the workflow runner cannot disable this if enabled by the creator, and vice versa. #### V4 Workflow 1. On the **Invite** stage, select the invitee card. 2. In the right panel, open the **Settings** tab and go to **Signature Appearance**. 3. Enable **Require Organisational Seal**. 4. **Set Org Name:** Enter the organisation's name, or leave it blank for the invitee to provide it during the signing journey. 5. **Choose a Seal Type:** Select one of the following options: - **Authorised Signatory Seal** - **Director Seal** - **Allow Upload of Custom Seal:** The invitee will be required to upload an image of their company seal during the signing journey. **Note:** Whether the workflow runner can modify these settings depends on the [field properties](https://knowledge.leegality.com/document-execution/workflows/v4/setup-configuration/field-properties) set by the workflow creator. ## Example of Company Seal with Signature --- URL: https://knowledge.leegality.com/document-execution/leegality-features/invitee-level/esignature-appearance/invitee-name-editing # Invitee Name Editing Enabling the option “Don't allow invitee from editing name in signing journey” restricts the invitee (signer/reviewer) from editing their name while signing the document. ## Allowing Invitee Name Editing in Signing Journey #### V3 Workflow 1. On the **Invitee Card**, click **Invitee Level Options** (labelled **More Options** in a workflow). 2. **Don't allow invitee from editing name in signing journey:** - **Disabled:** The invitee can edit their name during the signing journey. - **Enabled:** The invitee *cannot* edit their name during the signing journey. 3. Click **Save**. **Note:** Within a reusable workflow, the workflow runner cannot disable this if enabled by the creator, and vice versa. #### V4 Workflow 1. On the **Invite** stage, select the invitee card. 2. In the right panel, open the **Settings** tab and go to **Signature Appearance**. 3. Use **Allow invitee to edit name in signing journey**: - **Enabled:** The invitee can edit their name during the signing journey. - **Disabled:** The invitee *cannot* edit their name during the signing journey. **Note:** Within a reusable workflow, whether the workflow runner can modify this setting depends on the [field properties](https://knowledge.leegality.com/document-execution/workflows/v4/setup-configuration/field-properties) set by the workflow creator. > **Info — Note** > > This feature cannot be enabled for Automated eSign and NeSL. --- URL: https://knowledge.leegality.com/document-execution/leegality-features/invitee-level/custom-url-and-webhook/webhook-and-url # Add custom URLs and webhooks Custom URLs and webhooks provide a flexible way to manage signer journeys and receive document-related updates based on specific events during the eSign process. These configurations allow organizations to redirect signers to specific pages or receive structured payloads for enhanced tracking and integration with external systems. ## Use Custom URLs and Webhooks #### V3 Workflow 1. On the **Invitee Card**, click **Invitee Level Options** (labelled **More Options** in a workflow). 2. Enable **Add custom URLs and webhooks** and provide details as required. The URL format must be https://www.example.com/ - **Base URL:** A fallback URL for failed transactions. The signer is redirected here if the process is terminated due to a failed Liveliness/Face Match check after all retry attempts, or a mismatch in the signer's certificate details. - **Redirect URL:** A destination URL for finalized transactions. The signer is directed here upon successfully signing the document, or explicitly rejecting the request to sign. - **Webhook:** Sends document-related payloads to a publicly accessible URL for real-time data integration. - **Error Webhook:** Provides detailed payloads for specific error scenarios, such as Aadhaar eSign retry limit exhaustion, certificate mismatch, or expired invitations. - **Webhook Version:** There are four webhook versions that can be selected from the drop-down. 3. Click **Save**. **Note:** Within a reusable workflow, the workflow runner cannot disable this if enabled by the creator, and vice versa. #### V4 Workflow 1. On the **Invite** stage, select the invitee card. 2. In the right panel, open the **Settings** tab and go to **Webhooks**. 3. Configure the custom **Webhook** and **URL** for real-time status updates. (**Note:** The URL format must be https://www.example.com/) 4. To customise the signing-journey URLs, go to **Manage Invitee Interactions** and set the **Base URL** and/or **Redirect URL**. **Note:** Within a reusable workflow, whether the workflow runner can modify this setting depends on the [field properties](https://knowledge.leegality.com/document-execution/workflows/v4/setup-configuration/field-properties) set by the workflow creator. > **Info — Note** > > The URL must not exceed 255 characters. > **Info — Note** > > To know about custom webhook headers, [click here](https://docs.leegality.com/webhooks_resources) --- URL: https://knowledge.leegality.com/document-execution/leegality-features/invitee-level/custom-url-and-webhook/webhook-authentication # Webhook Authentication Webhooks enable the communication of invitation status and signed documents to your application. Previously, a standard webhook structure was available for such needs. You may also add additional header parameters to the webhook calls for authentication purposes. You can add the following to the Webhook headers: - Basic authentication parameters (like username and password) - Bearer/Token authentication parameters (fetching token or code from an API request and adding it to the webhook headers) - Any other static or dynamic (values fetched real-time from APIs) parameters. Steps to configure authentication parameters to webhooks headers Share your authentication requirements with Leegality Support Team from your registered admin email ID at support@leegality.com over a secure email. > **Info — Note** > > Please ensure the response gets parsed in the destination system properly and all access and permissions are set up if third-party integrations are implemented on your side. --- URL: https://knowledge.leegality.com/document-execution/leegality-features/invitee-level/other-features/supporting-documents # Supporting Documents By enabling the option “Require invitee to upload supporting documents” you can request the signer/reviewer to upload documents while signing/reviewing the document. ## Use Supporting Documents #### V3 Workflow 1. On the **Invitee Card**, click **Invitee Level Options** (labelled **More Options** in a workflow). 2. Enable **Require invitee to upload supporting documents** (labelled **Require Supporting Documents from Invitees** in a workflow). 3. In the **Document to be uploaded** field, specify the name of the document(s) the invitee must upload before signing. 4. Use the **+** icon to add additional document fields or the **🗑** icon to delete them. 5. *(Optional)* Enable **Allow viewing uploaded Supporting Documents of all invitees** to make these documents visible to other invitees. 6. Click **Save** to confirm the configuration. **Note:** Within a reusable workflow, the workflow runner cannot disable this if enabled by the creator, and vice versa. #### V4 Workflow 1. On the **Invite** stage, select the invitee card. 2. In the right panel, open the **Settings** tab and go to **Manage Invitee Interactions**. 3. Enable **Add Supporting Documents** and specify the additional documents the invitee must upload while signing. **Note:** Within a reusable workflow, whether the workflow runner can modify this setting depends on the [field properties](https://knowledge.leegality.com/document-execution/workflows/v4/setup-configuration/field-properties) set by the workflow creator. > **Info — Note** > > Sender can ask for upto 50 supporting documents from the invitee. ## Signing Journey #### V3 Workflow 1. After reviewing the document, click the **Proceed** button. 2. The list of required supporting document(s) will be displayed. 3. Click on the document name to upload the corresponding file. 4. Once the upload is complete, click **Proceed** to continue the signing journey. - **Allowed file types:** `.png`,`.pdf`,`.jpg`,`.jpeg` - **Maximum file size:** 2 MB > **Info — Note** > > The invitee cannot Proceed until all required supporting documents are uploaded. #### V4 Workflow 1. After reviewing the document, click the **Proceed** button. 2. Sign in using the OTP triggered to your email/SMS. 3. Click on the document name to upload the corresponding file. 4. Once the upload is complete, click **Proceed** to continue the signing journey. - **Allowed file types:** `.png`,`.pdf` - **Maximum file size:** 2 MB > **Info — Note** > > The invitee cannot Proceed until all required supporting documents are uploaded. ## Access Supporting Document #### For Sender The sender can access the supporting documents that the invitee uploads from the document details page. 1. In the document section, go to the **Sent** or **Completed** section. 2. Click on the document name to open the **Detail View**. 3. Click on the **Three Dots (⋮)** and select the **Supporting Documents** option. 4. A dialog box will appear, displaying the uploaded supporting documents for each invitee. 5. Click on a document to view or download it. #### V4 Workflow The sender can access the supporting documents that the invitee uploads from the document details page. 1. In the document section, go to the **Sent** or **Completed** section. 2. Click on the document name to open the **Detail View**. 3. Click on the **paperclip icon (📎)** on an invitee to open the supporting documents for that particular invitee. 4. A box appears, displaying the uploaded supporting documents for the invitee. #### For Invitee In the signing journey, invitees can access the uploaded supporting documents by following these steps: 1. Click the **Invitees** icon in the top-left corner. 2. A dialog box will open, showing the invitee(s) and their associated supporting documents. 3. Expand the **View Supporting Docs** dropdown to see the list of uploaded documents. #### V4 Workflow In the signing journey, invitees can access the uploaded supporting documents by following these steps: 1. Click the **Invitees** icon in the top-left corner. 2. A dialog box will open, showing the invitee(s) and their associated supporting documents. 3. Expand the **View Supporting Docs** dropdown to see the list of uploaded documents. --- URL: https://knowledge.leegality.com/document-execution/leegality-features/invitee-level/other-features/additional-consent # Additional consent terms Enabling the feature “ Set additional consent terms” will help in adding custom consent which will be added in the signing journey along with the default Leegality consent which can contain further Specific consent requirements to be agreed upon. ## Use Additional Consent #### V3 Workflow 1. On the **Invitee Card**, click **Invitee Level Options**. 2. Enable **Set additional consent terms**. 3. In the **Custom consent** field, enter the consent term. 4. Click **Save** to confirm the configuration. #### Workflow Creation 1. On the **Invitee Card**, click **More Options**. 2. Enable **Custom Consent**. 3. In the **Custom consent** field, enter the consent term. 4. Click **Save** to confirm the configuration. The workflow runner cannot disable this if enabled by the workflow creator, and vice versa. #### V4 Workflow 1. On the **Invite** stage, select the invitee card. 2. In the right panel, open the **Settings** tab and go to **Consent and Validity Controls**. 3. Enter the custom consent terms to show alongside the default consent. #### Workflow Creation 1. On the **Invite** stage, select the invitee card. 2. In the right panel, open the **Settings** tab and go to **Consent and Validity Controls**. 3. Enter the custom consent terms to show alongside the default consent. **Note:** Whether the workflow runner can modify this setting depends on the [field properties](https://knowledge.leegality.com/document-execution/workflows/v4/setup-configuration/field-properties) set by the workflow creator. > **Info — Note** > > Both Leegality's default consent and any custom consent must be agreed to before proceeding with the document signing. > **Info — Note** > > The custom consent field has a character limit of 1000. ## Signing Journey 1. Open the signing link sent via email, SMS, or WhatsApp. 2. Review the document and click **Proceed**. 3. Choose your preferred signature type and click **Proceed**. 4. Provide consent for the **default** and **additional terms**. 5. Click **Sign Document** to finalize the signing process. --- URL: https://knowledge.leegality.com/document-execution/leegality-features/invitee-level/other-features/reject-to-sign # Reject to Sign This feature allows the signer to reject the document while viewing the document for signing. ## Activate Invitee Rejection #### V3 Workflow 1. On the **Invitee Card**, click **Invitee Level Options** (labelled **More Options** in a workflow). 2. Enable **Allow signer to reject document in signing journey**. 3. *(Optional)* Enable **Enforce message collection in case of rejection** to require the signer to provide a mandatory reason for rejecting the document. 4. Click **Save** to confirm the configuration. **Note:** Within a reusable workflow, the workflow runner cannot disable this if enabled by the creator, and vice versa. #### V4 Workflow 1. On the **Invite** stage, select the invitee card. 2. In the right panel, open the **Settings** tab and go to **Manage Invitee Interactions**. 3. Enable **Allow rejection of doc(s)** to let the invitee reject signing the document(s). **Note:** Within a reusable workflow, whether the workflow runner can modify this setting depends on the [field properties](https://knowledge.leegality.com/document-execution/workflows/v4/setup-configuration/field-properties) set by the workflow creator. > **Info — Note** > > Invitee rejection option cannot be enabled for automated sign and Nesl sign > **Info — Note** > > The invitee rejection option works with CC, reviewer, and group invitee feature. ## Invitee Rejection Journey #### V3 Workflow 1. Open the signing link received via email, SMS, or WhatsApp. 2. Review the document and if you do not want to sign the document click **Reject**. 3. Authenticate using the OTP. 4. After entering the OTP, click **Proceed to Rejection**. 5. Provide the reason for rejection and click **Reject Document**. The document is now rejected. > **Info — Note** > > Once the document is rejected by the signer, the signing link would not be accessible and Signer receives an email. > **Info — Note** > > Sender of the document receives the email once the document is rejected by the signer #### V4 Workflow 1. Open the signing link received via email, SMS, or WhatsApp. 2. Review the document and if you do not want to sign the document click **Reject**. 3. Authenticate using the OTP. 4. After entering the OTP, click **Proceed to Rejection**. 5. Provide the reason for rejection and click **Reject Document**. The document is now rejected. > **Info — Note** > > Once the document is rejected by the signer, the signing link would not be accessible and Signer receives an email. > **Info — Note** > > Sender of the document receives the email once the document is rejected by the signer ## Re-Inviting an Invitee Who Rejected to Sign 1. Click **Documents** on the top bar. 2. Go to the **Sent** folder on the left navigation panel. 3. [Find the document](https://knowledge.leegality.com/document-execution/manage-documents/find-documents) containing the invitee who rejected to sign the document. 4. In the **Invitee List**, you can see all active including one who rejected to sign. > The invitee's status will be `Unsigned` and `Rejected`. 5. Click **Re-Invite**, optionally add a message, and confirm to send the invitation. The signer will receive the signing invitation again via email or phone. --- URL: https://knowledge.leegality.com/document-execution/leegality-features/invitee-level/other-features/mask-contact-details # Mask Contact Details Mask Contact Details is a feature designed to protect the contact details of invitees (signers and reviewers). When enabled, this feature ensures that an invitee cannot view the contact details (name, phone number, and email address) of any invitee during and after the signing journey. This option helps maintain privacy and security by preventing the exposure of contact details to unauthorized parties. ## Masking Method The Mask Contact Details feature partially obscures invitees' contact information by replacing some characters with asterisks (\*). For example: | | Unmasked | Masked | | :---- | :---- | :---- | | **Phone** | 9876543210 | 9\*7\*5\*3\*1\* | | **Email** | abhishek@gmail.com | a\*\*\*\*\*\*\*@gmail.com | | **Name** | Abhishek Sharma | Ab\*\*\*\*\*\* Sh\*\*\*\* | ## Use Contact Details Masking #### V3 Workflow 1. On the **Invitee Card**, click **Invitee Level Options** (labelled **More Options** in a workflow). 2. Enable **Mask the contact details from this Invitee**. 3. Click **Save** to confirm the configuration. **Note:** Within a reusable workflow, the workflow runner cannot disable this if enabled by the creator, and vice versa. #### V4 Workflow 1. On the **Invite** stage, select the invitee card. 2. In the right panel, open the **Settings** tab and go to **Security Options**. 3. Enable **Mask contact details** — contact details of other invitees will be masked from this invitee. **Note:** Within a reusable workflow, whether the workflow runner can modify this setting depends on the [field properties](https://knowledge.leegality.com/document-execution/workflows/v4/setup-configuration/field-properties) set by the workflow creator. ## Signing Journey - Mask Contact Details In the Invitee List, names, emails, and phone numbers will be partially hidden, with some characters replaced by asterisks (*). #### What Invitees See in the Audit Trail (When Masking is Enabled) Only invitees for whom the Mask Contact Details option was enabled will receive an audit trail where the contact details of other invitees are protected. All invitees’ names, email addresses, and phone numbers will be masked. If an invitee has signed the document using Aadhaar eSign, their Name and street address will be masked from the Certificate Details. #### Details Page When Contact Masking Is Enabled When contact masking is enabled, invitee names, email addresses, and phone numbers are hidden from the document details screen. The masking applies across the following sections: * **Invitee cards** (including individual details) * **Activity log** panel on the right * **Supporting Documents** and **Reference Attachments** section * **CC** (Carbon Copy) section --- URL: https://knowledge.leegality.com/document-execution/leegality-features/invitee-level/payment-collect # Payment Collect Leegality Payment Collect is a feature that will allow Leegality users to collect payments within the signing journey from their invitees. This happens through a payment gateway which needs to be linked with the client’s bank account. ## Activate Payment Collect #### New Document Journey 1. On the **Invitee Card**, click **Invitee Level Options**. 2. Enable **Collect Payment**. 3. In the **Enter Amount to be deducted** field, enter the amount you want to be collected from the invitee. *(**Note:** The amount range is Rs 10 to Rs 1,00,000)* 4. *(Optional)* You can also add a message which will be shown to the invitee before they initiate payment. 5. Click **Save** to confirm the configuration. #### Workflow Creation 1. On the **Invitee Card**, click **More Options**. 2. Enable **Collect Payment** and configure the following options: - **Amount to be collected from invitee:** - Leave blank to allow the workflow runner to input the amount. - Enter a value to fix the amount to be collected from the invitee. - **Enforce Payment Collection:** - Enable to make payment mandatory for eSigning/Reviewing. - Disable to allow the workflow runner to skip configuring payment collection. - **Set Maximum Amount:** Specify the maximum payment amount allowed. - **Set Minimum Amount:** Specify the minimum payment amount allowed. - **Add custom message for payment page:** Add a message to display to the invitee before they initiate payment. 3. Click **Save** to confirm the configuration. The workflow runner cannot disable this if enabled by the workflow creator, and vice versa. > **Info — Note** > > Payment Collect is available for **Signer** and **Reviewer** invitee types. This feature does not work for **Group invitee** and **CC** invitee types. --- ## Sending a Document via Workflow There are two ways to run the workflow. ### Running a Workflow via Dashboard 1. First let’s also cover a scenario where the workflow runner has to enter an amount while running the workflow. 2. If Enforce Payment Collection is turned on while configuring a workflow, the user will have to enter an amount to be collected. 3. If maximum and minimum amount isn’t entered, then by default the minimum value is Rs. 10 and the maximum value is Rs. 1,00,000. ### Sending a document(s) via Excel Upload If you are not familiar with using Leegality’s excel upload functionality, use this Guide to learn more about Sending a document(s) using Excel Upload - Running a Workflow - Via Excel Upload 1. After configuring a workflow, an excel template for the same can be downloaded from the dashboard 2. In case an amount to be collected is preconfigured in a workflow for a particular invitee, any new amount entered in the excel file will be ignored by Leegality and the value set at the time of configuring the workflow will be used. In this case, the value under the header ‘Invitee(0).amount’ can be left blank. 3. If Enforce Payment Collection is turned on while configuring a workflow and the amount to be collected isn’t preconfigured, the user will have to enter a value for the column. `Invitee.amount` (for that particular invitee). 4. Excel Upload won’t work in the following situations- if the amount to be paid entered in the excel spreadsheet is more than the maximum amount configured or less than the minimum amount configured for that invitee in the workflow. ## Signing Journey 1. You as an invitee will receive a signing link to the document. 2. You can preview the document they will be eSigning/ reviewing. 3. Before eSigning/ reviewing, you will have to complete payment (amount as set by the sender). 4. Click on the ‘Pay Online’ button as shown below- 5. Enter mobile number and email address and click on ‘Proceed’. 6. Select the mode of payment and proceed to pay. 7. After a successful payment, you can proceed to eSigning/ reviewing the document. Details of the payment will be sent to the payer and the sender. The payment gateway and bank may also send separate notifications. 8. Complete the signing journey within 5 days of payment, else payment will be reversed. Payment reversal is notified via email- 9. Payment reversal takes time and funds typically will hit the bank account of the payer in 7 to 12 business days. 10. After a reversal, if the signing journey is attempted again - then the signer will have to pay again (since the previous amount was reversed) ## Payment Status of Invitees - Details Page 1. The sender can check the status of payment on Document Details page. 2. Click on the **View Payment Logs** icon. 3. The dialog box shows the date of payment by the invitee, the payment ID, amount paid and status of payment. ### Status Meaning - **Authorized:** Payment has been completed by the signer, but the sign/review itself is not completed. Funds have been deducted from the payer’s bank account but have not yet been earmarked for deposit in the recipient’s bank account. - **Capture:** Payment as well as eSigning/ reviewing has been completed. The amount is earmarked for depositing into the recipient's bank account. Note that funds take some time to reach the recipient’s bank account. To know how settlement works, visit https://razorpay.com/settlement/ ## Payment Logs - **Payment Authorised:** This log is created when the payment is made by the invitee but the document is not signed by the invitee. > **Info — Note** > > Payment will be reversed if the document is not signed. - **Payment Captured:** This log is created when the payment is made by the invitee and also document is signed by the invitee. - **Payment Refunded:** This log is created when the payment is refunded to the invitee. ## Refund scenarios Paid amount is refunded if the signing/ reviewing journey is not completed within 5 days of the payment, including by way of expiry of the documentation. --- URL: https://knowledge.leegality.com/document-execution/leegality-features/invitee-level/local-language # Local Language Local Language support allows invitee to complete the signing or reviewing process in their native language. Languages being provided in Local Language Support- - Hindi - English - Marathi - Gujarati - Bengali - Telugu - Tamil - Kannada - Malayalam - Odia - Punjabi --- ## Use Local Language #### V3 Workflow 1. On the **Invitee Card**, click on the **Language** icon. 2. A side modal will appear with the following options: - **Allow Signers to Select Language:** Choose this to allow signers to choose their preferred local language before starting the signing journey. - **Set a Default Language:** Choose this to set a default language for the invitee. - The selected language will appear during the signing journey. - **Choose While Running Workflow:** If this option is selected (only available in a workflow), the sender must choose a language for the invitee each time the workflow is run. - **Note:** Even if a default language is set, the signer can change it using the language switch button during the signing process. 3. Click **Save** to confirm the configuration. **Note:** Within a reusable workflow, the workflow runner cannot disable this if enabled by the creator, and vice versa. #### V4 Workflow 1. On the **Invite** stage, select the invitee card. 2. In the right panel, open the **Settings** tab and go to **Manage Invitee Interactions**. 3. Open **Local Language Settings** and choose one of the two options: - **Allow Signers to Select Language:** A language select screen is shown as the first step for the signer. - **Set a Default Language:** The signing journey starts in the default language you set for the signer. **Note:** Within a reusable workflow, whether the workflow runner can modify this setting depends on the [field properties](https://knowledge.leegality.com/document-execution/workflows/v4/setup-configuration/field-properties) set by the workflow creator. ## Signing Journey #### V3 Workflow 1. **Allow Signers to Select Language:** If the sender has configured “Allow Signers to Select Language” while sending the document, the signer will get the option to select their local language. 2. **Set a Default Language:** If the sender has configured “Set a Default Language” while sending the document, the signer will not get the option to select a language instead the signing journey will start with the default language selected by the sender. > **Info — Note** > > The selected language can be changed during the signing journey by clicking on the regional language icon. Once everyone has signed the document, the audit trail will have the consent in the selected language. #### V4 Workflow 1. **Allow Signers to Select Language:** If the sender has configured “Allow Signers to Select Language” while sending the document, the signer will get the option to select their local language. 2. **Set a Default Language:** If the sender has configured “Set a Default Language” while sending the document, the signer will not get the option to select a language instead the signing journey will start with the default language selected by the sender. > **Info — Note** > > The selected language can be changed during the signing journey by clicking on the regional language icon. Once everyone has signed the document, the audit trail will have the consent in the selected language. --- URL: https://knowledge.leegality.com/document-execution/leegality-features/signature-coordinate/coordinate-picker # Coordinate Picker Coordinate Picker is an API-only functionality that is supported only through the 2.1 API., This functionality allows you to configure signature coordinates (placement) on a document without logging into the Leegality dashboard or passing coordinates in the API call. When using our 2.1 API to create eSign requests, you can customise the placement of signatures on the document in two ways: - You can pass the eSign coordinates in the appearances array of the payload. This approach requires you to calculate the x-y coordinates for all signatures on your application and pass the values in the API payload. - Alternatively, you can leverage our pre-built screens for placing signatures, which allow an easy to use, drag and drop interface. The pre-built screens can be opened inside your app using our Web/Android/iOS SDKs. To use this flow, you need to pass the “coordinate_picker” parameter as TRUE in the 2.1 API payload. When you pass the “coordinate_picker” parameter as TRUE, you will receive a Coordinate Picker URL in response. This URL can be used to set signature placements. The functionalities of our pre-built signature placement screens are set out below: Note for developers: If you wish to receive the signURLs generated after setting coordinates for managing the signURLs inside your application, you should also pass a webhook URL in the “coordinate-picker_webhook” parameter of the 2.1 API payload. ## Signature Placement Process 1. When you open the Coordinate Picker URL, you will be shown a preview of the document on which you can place the signature positions. , Scroll down to the end of the document and wait for all the pages of the document to load > **Info — Note** > > The document is in the “Draft” stage at this point in the journey. In case no coordinates were configured before triggering the coordinate picker URL, the default coordinates will appear on the document for each invitee. In case, Custom coordinates were configured in the API call, those will appear in the document 2. Click on the “Click and Drop Signature Box” button to initiate the signature placement module Your cursor will now change into the Leegality logo when hovered on the document 3. Click anywhere on the document to place a signature box 4. You can select which signature belongs to which signer by selecting the desired signer from the dropdown in the signature box 5. You also have the option to copy a signature placement across all pages of the document by pressing the following button - In case Leegality’s “Dynamic Stamping” feature was used to create the document (i.e. there are multiple papers attached to the document - only 1 paper will be visible for the signature placement process and any signature coordinate placed on that page will be replicated across all the stamp papers. Note 1: If the “All” option is selected when placing the signature coordinate on the stamp paper it will be replicated across all pages of the document, whereas if the signature is simply placed on the stamp paper without explicitly replicating it on “All” pages it will only appear on the stamp paper attached. Note -2: Coordinates for stamp papers and the document function independently unless the “All” option is selected in signature placement options which will replicate the concerned signature placement across all pages 6. In case you want to delete the new coordinates set by you or clear the already configured custom coordinates, simply click on the “Delete Custom Coordinates” Button 7. Clicking on the “Delete Custom Coordinates” Button will delete any newly configured (set by you) and/or existing custom coordinates (set via API) 8. Once you are done configuring the coordinates, click on the “Send Document” button >> Confirm that you want to send the document. > **Info — Note** > > In case any of the invitees do not have “Custom Coordinates” configured, Leegality will automatically place their signatures on the “Bottom-Left corner” (default placement) of every page --- URL: https://knowledge.leegality.com/document-execution/esign-type/aadhaar/maximum-signing-attempts # Maximum Aadhaar Signing Attempts Maximum Aadhaar Signing Attempts is a invitee-level feature that allows senders to limit how many times a signer can attempt to complete the Aadhaar eSign process. When enabled, senders can define the maximum number of additional attempts a signer receives beyond their initial signing attempt. This prevents indefinite retry loops and provides clarity on when a document needs to be reactivated. ## Understanding signing attempts A signing attempt is counted when a signer actively cancels the signing process on the ESP (eSign Service Provider) page by clicking the "Cancel" button. ### What counts as a failed attempt - Clicking "Cancel" on the ESP page ### What does NOT count as a failed attempt - Closing the browser tab - Refreshing the page ## Configuring maximum signing attempts To enable this feature: 1. Navigate to the invitee-level options when creating or configuring a document 2. Enable **Define maximum signing attempts allowed (only for Aadhaar eSign)** 3. Enter the number of additional attempts beyond the initial attempt (e.g., entering "1" gives the signer 2 total attempts) > **Info — Total attempts calculation** > > Total attempts = 1 (initial attempt) + number entered in the field > > For example, if you enter "1", the signer gets 2 total attempts. > **Info — If disabled** > > If this option is disabled, the signer gets unlimited signing attempts until the document expires. ## What happens when attempts are exhausted After all attempts are exhausted, the following occurs: ### For the signer The signer is redirected to the Leegality page with the following message: > **Warning — Error occurred** > > Retry attempt exhausted. The signer cannot attempt to sign the document again until it is reactivated by the sender. ### For the sender On the Leegality Dashboard, the document and invitee status changes: - **Invitee status**: Expired, Active, and Unsigned - **Document status**: Expired - **Document location**: Appears in the Expired and Failed folder - **Available action**: Re-activate document option ## Reactivating a document after exhausted attempts To allow the signer another opportunity to sign: 1. Navigate to the document details page from the Expired and Failed folder 2. Click the **Re-activate** option 3. Set a new expiry date for the document 4. Save the changes Once reactivated, the signer will receive one additional attempt to complete the signing process. --- URL: https://knowledge.leegality.com/document-execution/esign-type/aadhaar/prioritise-aadhaar-for-invitee # Prioritise Aadhaar for Invitee This section provides instructions for prioritizing the Aadhaar eSign option over other eSign methods for an invitee during the document signing process. By prioritizing Aadhaar eSign, you ensure that it is presented as the first signing option to the user, even if you have enabled multiple other eSign methods for the document. This configuration provides flexibility by offering the user various choices while directing them to your organization's preferred method first. #### V3 Workflow Use the following steps to configure Aadhaar eSign priority when initiating a new document. 1. While initiating a document, go to the **Invitee level options**. 2. Toggle on **Prioritise Aadhaar for Invitee**. - If enabled, the invitee will see the Aadhaar eSign options first. Other selected eSign options are displayed only after the configured Aadhaar eSign attempts are exhausted. 3. Toggle on **Order Level Retry Count** (Optional) - Enable this setting to define a specific display order for the different Aadhaar verification subtypes (such as OTP, Biometric, Face Auth or Iris scan). - When enabled, retries are counted collectively for all subtypes with the same Order number. The system proceeds to the next Order priority only after maximum attempts for the current Order group are exhausted. 4. Set the number of **retry attempts** for each subtype. This is the maximum number of attempts an invitee has for a specific subtype after the initial unsuccessful attempt. 5. Set the **Order** for each subtype to specify the priority in which it should appear to the invitee. 6. Click **Save**. #### Workflow Creation Use the following steps to configure Aadhaar eSign priority within a workflow configuration. **Prerequisite:** Before you begin, enable Aadhaar under Signature type. 1. While initiating a document, go to the **More Options**. 2. Toggle on **Prioritise Aadhaar for Invitee**. - If enabled, the invitee will see the Aadhaar eSign options first. Other selected eSign options are displayed only after the configured Aadhaar eSign attempts are exhausted. 3. Toggle on **Order Level Retry Count** (Optional) - Enable this setting to define a specific display order for the different Aadhaar verification subtypes (such as OTP, Biometric, Face Auth or Iris scan). - When multiple subtypes are arranged in a specific order, The system will only proceed to the next Order priority group after the invitee has exhausted the maximum retry attempts set for the preceding subtype. - If a specific order is not configured, the OTP method is displayed first by default. > **Info — NOTE** > > The Order level retry count is fixed and cannot be changed while running the workflow. To make changes you need to edit the workflow. 4. Set the number of **retry attempts** for each subtype. This is the maximum number of attempts an invitee has for a specific subtype after the initial unsuccessful attempt. > **Info — Retry limit** > > The retry limit must be between 0 and 5. > - A limit of 0 grants the User only the original attempt. > - A limit between 1 and 5 allows the User the original attempt plus the configured number of additional retries. 5. Set the **Order** for each subtype to specify the priority in which it should appear to the invitee. 6. Click **Save**. #### V4 Workflow Use the following steps to configure Aadhaar eSign priority in the v4 editor. **Prerequisite:** Before you begin, enable Aadhaar eSign for the invitee under **eSign Types**. 1. On the **Invite** stage, select the invitee card. 2. In the right panel, open the **Settings** tab and go to **eSign Prioritisation**. 3. Toggle on **Prioritise Aadhaar for Invitee**. - If enabled, the invitee will see the Aadhaar eSign options first. Other selected eSign options are displayed only after the configured Aadhaar eSign attempts are exhausted. #### Workflow Creation 1. On the **Invite** stage, select the invitee card. 2. In the right panel, open the **Settings** tab and go to **eSign Prioritisation**. 3. Toggle on **Prioritise Aadhaar for Invitee**. - If enabled, the invitee will see the Aadhaar eSign options first. Other selected eSign options are displayed only after the configured Aadhaar eSign attempts are exhausted. Whether the workflow runner can modify this setting depends on the [field properties](https://knowledge.leegality.com/document-execution/workflows/v4/setup-configuration/field-properties) set by the workflow creator. > **Info — NOTE** > > eSign Prioritisation works for **Aadhaar eSign** only. ## How Prioritization Affects the Signing Journey When Aadhaar eSign prioritization is enabled, the invitee's signing experience is structured to present Aadhaar verification methods first, before any other eSign options become available. This section explains how the signing flow changes with prioritization enabled. ### Standard Signing Flow vs. Prioritized Flow **Without Prioritization:** When multiple eSign methods are enabled (such as Aadhaar OTP, DSC, Quick Sign), the invitee can freely choose any available option to sign the document immediately upon reaching the signing page. **With Prioritization Enabled:** The invitee must first attempt signing using the Aadhaar eSign methods in the configured order and exhaust the allowed retry attempts before other eSign options become visible. ### Invitee Signing Experience When an invitee receives a document with Aadhaar prioritization enabled, the signing journey follows this flow: 1. The invitee receives the invitation via email, SMS, or WhatsApp and clicks the signing link. 2. After previewing the document and clicking **Proceed**, they are presented with the available Aadhaar eSign methods. 3. The Aadhaar verification subtypes (OTP, Biometric, Face Auth, or Iris) appear in the order configured by the sender. 4. The invitee selects an available Aadhaar method and proceeds with the verification. ### How Retry Attempts Work The retry attempt configuration determines how many times an invitee can attempt each Aadhaar verification subtype: - **Initial Attempt:** The invitee makes their first signing attempt with the chosen Aadhaar method. - **Retry Attempts:** If the verification fails (e.g., incorrect OTP, biometric mismatch, face authentication failure), the invitee can retry based on the configured retry limit (0-5 additional attempts). - **Exhausted Attempts:** Once all retry attempts for a subtype are exhausted, the system proceeds according to your configuration: - If other Aadhaar subtypes are available in the next order group, those options appear next. - If all Aadhaar retry attempts are exhausted, other eSign methods (if enabled) become available. ### Order Level Retry Count Behavior When **Order Level Retry Count** is enabled, the retry attempts are counted collectively for all Aadhaar subtypes that share the same order number: - **Collective Retry Count:** The system counts retry attempts collectively across all subtypes in that order number. - **Progression:** The system only moves to the next order priority after the maximum retry attempts for any subtype within the current order group are exhausted. ### When Other eSign Methods Become Available If you have enabled multiple eSign types (e.g., Aadhaar, DSC, Quick Sign) and have prioritized Aadhaar: 1. The invitee initially sees only Aadhaar eSign options in the configured order. 2. They must exhaust all configured Aadhaar retry attempts across all order groups. 3. Only after all Aadhaar attempts are exhausted do the other eSign methods (DSC, Quick Sign, etc.) become visible and selectable. This ensures your preferred verification method (Aadhaar) is attempted first while still providing alternative signing options if needed. > **Info — NOTE** > > The invitee can still complete the signing process even if Aadhaar verification fails, as long as you have configured alternative eSign methods. --- URL: https://knowledge.leegality.com/document-execution/esign-type/aadhaar/esp-auto-switch # ESP Auto Switch ESP Auto Switch is an intelligent backend feature that automatically switches between Aadhaar eSign Service Providers (ESPs) based on real-time performance monitoring. This ensures signers are always routed to the best-performing ESP, eliminating customer drop-offs due to ESP downtime and maintaining business continuity without manual intervention. ### Key Benefits - **Automatic ESP prioritisation** based on real-time success rates - **Multiple backup ESPs** for maximum reliability - **Reduced turnaround time** for transactions ### The Problem: ESP Downtime #### What is ESP Downtime? ESP downtime occurs when an eSign Service Provider experiences technical issues, outages, or performance degradation that prevents users from completing their eSign transactions. This can happen due to: - Server maintenance or upgrades - Technical failures or system crashes - Network connectivity issues - High traffic loads exceeding capacity - Third-party service dependencies ### How ESP Auto Switch Works ESP Auto Switch operates as an intelligent backend system that continuously monitors ESP performance and automatically adjusts routing priorities to ensure optimal signing success rates. #### Continuous Monitoring Leegality continuously monitors the health and performance of all connected ESPs: - **Check frequency**: Every 10 minutes - **Success rate tracking**: Real-time monitoring against predefined thresholds - **Automatic evaluation**: Compares performance across all available ESPs - **Smart prioritisation**: Automatically adjusts ESP priority order when performance drops #### Intelligent Routing Logic The system uses different routing strategies for OTP and Biometric authentication: ##### OTP-Based Authentication - Auto-switching applies to all OTP-based transactions - ESP priority adjusts automatically based on success rate monitoring - Organisations with custom ESP configurations need to manage priorities manually ##### Biometric Authentication (Fingerprint) - Auto-switching extends to biometric (fingerprint) flows - **Device-based routing**: ESP selection considers device compatibility with ESPs - Example: If a device supports only NSDL and CDSL, the signer is routed accordingly, skipping incompatible ESPs like Verasys #### NSDL as Super Priority NSDL (Protean) is set as the default first-priority ESP due to its consistently high success rate: - **Maintains priority** as long as success rate remains above 40% - **Automatically de-prioritized** if success rate falls below 40% - **Regains priority** automatically once performance is restored above the threshold ### Signing Experience ESP Auto Switch operates primarily in the background, making the process seamless for signers while ensuring they always interact with the best-performing ESP. #### For the Signer When a signer clicks on the eSign link: 1. **Automatic routing**: The signer is automatically directed to the ESP webpage that is performing best at that moment. 2. **Streamlined process**: The signer sees no indication of auto-switching—they simply land on the ESP authentication page. 3. **Standard signing flow**: The signer proceeds with OTP or biometric authentication as usual. #### If Authentication Fails If a signer encounters an error during the authentication process: 1. The signer needs to **start the signing journey again** by clicking the eSign link. 2. On the next attempt, the system routes them to the **next best-performing ESP** in the priority order. > **Tip — For Signers** > > If you encounter an error during signing, simply click on the eSign link again to retry. The system will automatically route you to an alternative ESP to help ensure successful completion. --- ### Frequently Asked Questions #### 1. Why is my ESP (E-Sign Service Provider) auto-switching not happening? If your ESP is not automatically switching during a low-success period, it is likely due to one of the following configuration settings: **Potential Causes for Auto-Switch Failure:** * **Manual Priority Configuration:** If your organisation has a **Manual ESP Order** configured, it takes precedence over the global auto-switch logic. * *Example:* If you have manually set CDSL as P1 and NSDL as P2, the system will **always** attempt CDSL first for every invitee, even if CDSL’s success rate is currently low. The performance-based "Auto-switch" will not trigger because the manual rule is being enforced. * **Single ESP Setup:** The system requires at least two providers to perform a switch. * *Example:* If your organisation has only one ESP configured (e.g., only NSDL), the invitee will land on that same ESP every time. Since there is no secondary provider available, a switch cannot occur regardless of the ESP's status. * **First-Attempt Logic:** The auto-switch system functions as a performance-based rerouting. * *Note:* Even with auto-switching enabled, the system will still attempt your primary (P1) provider on the first try. It cannot bypass a hard-coded manual sequence for the initial landing unless that sequence is removed from your settings. **How to Resolve:** If you are experiencing issues with ESP switching, you can take the following steps depending on your needs: * **To Enable Performance-Based Switching:** If you want the system to automatically choose the best-performing provider, you must request to have **Performance-Based Auto-Switching** enabled for your organisation. * **To Monitor Downtime:** If you prefer to stay with your current configuration, you can wait for your primary ESP to recover. You can monitor real-time service status at any time here: [**Leegality Aadhaar Tracker**](https://www.leegality.com/aadhaar-tracker). * **To Change Your Configuration:** Since ESP priority and switching logic are managed at the system level, please contact [support@leegality.com](mailto:support@leegality.com). Our team can: * Provide details on your organisation's specific ESP configuration. * Update your ESP priority order. * Transition your account from a Manual Priority to an Auto-Switching setup. --- URL: https://knowledge.leegality.com/document-execution/esign-type/doc-signer-certificate # Doc Signer Organizational Document Signer Certificate or Doc Signer is a Digital Certificate which is procured in the name of the organization, and is used to indicate organizational approval of a document. Such a Certificate can be procured from providers such as SafeScrypt. The organization will have to install Leegality’s utility on their server and place the procured Certificate along with it. Leegality’s application will allow you to set a Signature level ID and Password, and program the API to automatically digitally sign the document before or after the a signatory or similar Authenticates it. ## Setting up Document Signer Certificate (DSC) To set up a Document Signer Certificate for your account: 1. Click on the **Settings ⚙️** icon in the top right corner. 2. From the left panel, go to **Settings > eSignature & Seal.** 3. In Document Signer Certificate, click on **Setup**. 4. Enter the **eSign Name**. It can be anything. 5. Choose where you want to store the Document Signer Certificate: | Hosting Option | What You Need to Do | Key Considerations | | :--- | :--- | :--- | | 🖥️ **Host on Your Server** | 1. Provide a publicly accessible **Profile Access URL**. 2. **Whitelist Leegality's IP addresses** for secure access (we will provide these). 3. Follow the instructions to [**download and install the Leegality Doc Signer Utility**](https://gitlab.com/leegality-public/docsigner) on your server. | Choose this if you have the technical infrastructure and prefer to manage the certificate hosting in-house. | | ✨ **Host on Leegality's Server** _(Recommended)_ | 1. Upload your certificate (`.pfx` file). 2. Enter the password for the `.pfx` file. | This is the simplest, hassle-free option. Leegality manages all the technical infrastructure, so you can get started right away without any setup. | 6. Provide the **Email Address(es)** for receiving certificate expiry notifications. Leegality sends expiry reminder emails to users 30 days, 15 days, and 1 day before their Doc Signer expires, giving them sufficient time to update or replace it. Only if you are hosting on Leegality server. 7. Click **Save** to complete the setup. ## Sending Journey #### V3 Workflow The Document Signer Certificate is used to sign documents on behalf of the organization. It is mainly intended for users within the organization and is primarily used in automated signature processes. 1. Hover over the **Signature Type** dropdown. 2. Enable **Automated Sign**. 3. Use **Choose Automated Sign profile** drop to select the signer's automated eSign profile. > **Tip** > > Use the eSign ID and Name to identify the profile. 4. Enter the password and click **Save**. > **Tip — Can multiple users share the same Doc Signer?** > > A single Doc Signer certificate can be shared across multiple Leegality users. Each user must configure it independently in their own account using the steps above. #### Workflow Creation 1. Hover over the **Signature Type** dropdown. 2. Enable **Automated Sign**. 3. Use **Choose Automated Sign profile** drop to select the signer's automated eSign profile. > **Tip** > > Use the eSign ID and Name to identify the profile. 4. Enter the password and click **Save**. > **Tip — Can multiple users share the same Doc Signer?** > > A single Doc Signer certificate can be shared across multiple Leegality users. Each user must configure it independently in their own account using the steps above. #### V4 Workflow To enable Doc Signer Certificate for an invitee in a V4 workflow: 1. In the **Invite** stage, select the invitee and expand the **eSign Types** section. 2. Toggle on **Doc Signer Certificate**. #### Workflow Creation To enable Doc Signer Certificate for an invitee in a V4 workflow: 1. In the **Invite** stage, select the invitee and expand the **eSign Types** section. 2. Toggle on **Doc Signer Certificate**. ## Signing Journey When the invitation for an automated signer is activated, the document will be signed automatically within a few seconds. > **Info — Note** > > Leegality will be logging the Sender's Public IP from which the Document Request was created - for both Dashboard and API use cases in the Audit Trail for Doc Signer. --- URL: https://knowledge.leegality.com/document-execution/esign-type/dsc-token # DSC Token A USB token-based DSC (containing the Digital Signature Certificate), can be for eSigning the document. In Leegality, you can use DSC Token to sign multiple documents in bulk. ## Use DSC Token in Sending Journey #### V3 Workflow 1. Hover over the **Signature Type** dropdown. 2. Enable **DSC**. 3. In the right panel, toggle on **Verify details with Certificate Details** (Optional). Fields to enable are; * Verify Name * Smart Name Verification * PIN Code * State Toggle on the adjacent switch to Enable any of the fields listed above. > **Info — NOTE** > > Enabling a variable automatically makes the verification mandatory for that field. 4. Click **Save**. > **Info — INFO** > > **Smart Name Verification Threshold**: The Smart Name Verification Threshold must be configured on your account prior to enabling **Smart Name Verification** in the sending journey. This threshold is configured in the main Settings page, under **Department** > **eSignature**. #### Workflow Creation 1. Hover over the **Signature Type** dropdown. 2. Enable **DSC**. 3. In the right panel, toggle on **Verify details with Certificate Details** (Optional). Fields to enable are; * Verify Name * Smart Name Verification * PIN Code * State Toggle on the adjacent switch to Enable any of the fields listed above. > **Info — NOTE** > > Enabling a variable automatically makes the verification mandatory for that field. 4. Click **Save**. > **Info — INFO** > > **Smart Name Verification Threshold**: The Smart Name Verification Threshold must be configured on your account prior to enabling **Smart Name Verification** in the sending journey. This threshold is configured in the main Settings page, under **Department** > **eSignature**. #### V4 Workflow To enable DSC Token for an invitee in a V4 workflow: 1. In the **Invite** stage, select the invitee and expand the **eSign Types** section. 2. Toggle on **DSC Token**. #### Workflow Creation To enable DSC Token for an invitee in a V4 workflow: 1. In the **Invite** stage, select the invitee and expand the **eSign Types** section. 2. Toggle on **DSC Token**. ## Signing Journey ### Prerequisites 1. Download and install the Leegality DSC Utility on your computer. **Download link:** https://gitlab.leegality.com/leegality-public/dsc-utility/raw/master/leegality-dsc-client-setup.exe?inline=false This is also available for download in the signing journey. 2. Anyone of the following ports should be available for use by Leegality's DSC utility: 8009, 9800, 2048, 3900. 3. Java run-time environment (JRE) 1.7 or above to be installed on the local machine. Recommended: JRE 1.8 4. The token driver should be installed and running as administrator You can download the same from here - https://app1.leegality.com/resources 5. Leegality's DSC Utility will support signing from the following Tokens, irrespective of the Certifying Authority (Indian or Foreign) has issued the same: Epass2003, Safenet, Aladdin, Watchdata, Trustkey, Mtoken, Moser Baer > **Info — Note** > > DSC Token signing is limited to PC only. ### Sign a single document using DSC 1. After opening the signing link and clicking on **Proceed**, run the Leegality DSC utility. 2. Once the signing page recognizes the utility. 3. Once the signer has successfully input the DSC Token and the requisite utilities and drivers are running, a pop-up appears highlighting the certificates contained in the token. Select the relevant certificate and click **OK**. > **Info — Note** > > If both the signature certificate and encryption certificate appear, choose a signature type certificate. 4. Once the signer selects the certificate, the utility recognizes your DSC certificate details. After successful detection of the certificate, click **Proceed**. 5. Check the consent box and click **Sign Document**. 6. After clicking the sign button, a pop-up asking for the DSC-Token PIN appears. Enter the token PIN and click **Login**. 7. Upon correct input of the PIN/Password, the document will be signed. ### Bulk Sign using DSC Token Within the Leegality account, you can use the DSC Token to bulk sign the multiple documents (up to 500) in one go. 1. Go to the **Documents** section using the top bar. 2. Select **Received** from the left panel. 3. Click **Activate Bulk Sign** button. 4. Select **DSC Token** as the bulk signing option. 5. All the documents available to sign with DSC Token will appear in the list. 6. Use the checkbox to select documents that you want to sign. 7. Click on the **Sign** button. > **Info — note** > > Leegality DSC Token must be installed and DSC Token must be properly connected to the computer. 8. Check the consent box. 9. Click on the **Sign** button. 10. Choose the certificate for signing the document and click **Select**. 11. Verify the signature details and click **Sign**. 12. Enter the **User PIN** of the DSC Token and click **Login**. If the entered User PIN is correct, the signing process will begin immediately. Based on the total number of documents the process may take up to few seconds. --- URL: https://knowledge.leegality.com/document-execution/esign-type/virtual-sign/virtual-signature # Virtual Signature A Virtual Signature is a secure, valid and legally binding method of entering into agreements in India., By setting up a Virtual Signature in the Account you can use this directly while self-signing or can automate this authentication during a document flow. This is an electronic authentication mechanism powered by a ‘One Time Password’ verification of the Email or Phone Number. This is a reflection of the user’s consent and intention to approve the contents of an electronic document. This approval appears on the document by way of a user-generated virtual sign or by the user choosing a template mark, along with the Leegality generated time-stamp. Choose these for your agreements with Merchants, Employees, Users and Business Partners. The virtual sign saved while setting up the virtual sign will automatically show up as a pre-filled sign in the draw box when a Leegality user is signing the document. ## Setting up Virtual Sign in Leegality By setting up a Virtual Signature in your account, you can also use for automated signing of documents. To set up a Virtual Signature for your account: 1. Click on the **Settings ⚙️** icon in the top right corner. 2. From the left panel, go to **Settings > eSignature & Seal.** 3. In the Virtual Sign section, click on the **Setup**. A side menu will appear on your screen with three options: - **Draw:** Draw your signature on the screen and save it. - **Choose a pre-built virtual sign:** Select a pre-built virtual signature from the available options. - **Upload a photo of your signature:** Upload an image of your hand-drawn signature. (Supported image formats are .jpeg, .jpg, and .png) 4. Select your preferred option and click **Save**. ## Sending Journey #### V3 Workflow 1. On the invite page 2. Hover over Signature type dropdown 3. Enable **Virtual Sign** 4. Click **Save**. > **Info** > > Learn how to [**enable and use Virtual Sign for automated signing.**](https://knowledge.leegality.com/document-execution/esign-type/automated-esign.md) #### Workflow Creation 1. On the invite page 2. Hover over Signature type dropdown 3. Enable **Virtual Sign** 4. Click **Save**. > **Info** > > Learn how to [**enable and use Virtual Sign for automated signing.**](https://knowledge.leegality.com/document-execution/esign-type/automated-esign.md) #### V4 Workflow To enable Virtual eSign for an invitee in a V4 workflow: 1. In the **Invite** stage, select the invitee and expand the **eSign Types** section. 2. Toggle on **Virtual eSign**. 3. Check whichever options you want to allow the invitee to use: - **Allow invitee to draw signature** - **Allow invitee to choose computer-generated signature** - **Allow invitee to affix fingerprint image** - **Allow Sign Upload** You can enable any combination of these options for the invitee. #### Workflow Creation To enable Virtual eSign for an invitee in a V4 workflow: 1. In the **Invite** stage, select the invitee and expand the **eSign Types** section. 2. Toggle on **Virtual eSign**. 3. Check whichever options you want to allow the invitee to use: - **Allow invitee to draw signature** - **Allow invitee to choose computer-generated signature** - **Allow invitee to affix fingerprint image** - **Allow Sign Upload** You can enable any combination of these options for the invitee. ## Signing Journey Access your email or phone (per the invitation details) and click **Sign** (email) or the signing link (text message) to begin. You'll be redirected to the Leegality eSign Gateway, where you can view the full document. 1. Preview the document and click **Invitees** to view other parties and download the latest version. 2. Enter the OTP received on your email or phone, then click **Proceed**. > **Info — OTP via Call** > > If the invitee's phone number is linked, they can receive the OTP via a phone call. The **Resend via Call** button will appear on the OTP screen 30 seconds after the first code is sent. 3. Select the virtual sign type: - **Draw** Choose **Draw**, sign using your mouse or finger, and click **Proceed**. Use **Full screen** to enlarge the signature pad or **Clear** to erase input. - **Select** Click **Select** to choose a computer-generated signature, then click **Proceed**. - **Physical Signature** Choose **Upload** to either: - Upload an image from your device, or - Capture an image using your camera (sign on white paper). Leegality will extract the signature from the image. > **Info — Guidelines for quick approval** > > - Accepted formats: PNG, JPEG, JPG, HEIC > - Ensure proper lighting; avoid shadows > - File size must not exceed 5MB > - Use plain white paper with blue/black ink Click **upload/drag & drop** to select a saved image, or click **Capture** to take a new photo. After uploading, rotate and crop the image as needed, then click **Proceed**. You'll then be given three options for the uploaded signature. **Note:** If the uploaded signature is unsatisfactory, click **Try fixing it** to repeat the process. 4. After clicking **Proceed**, check the consent box and click **Sign Document** to sign. --- URL: https://knowledge.leegality.com/document-execution/esign-type/virtual-sign/fingerprint-capture # Fingerprint Capture - Virtual Sign Affix fingerprint type is the third subtype of Leegality’s Virtual Signature type that allows for users to sign using their fingerprint via a registered biometric device connected to a Windows PC or Android Mobile phone. ## Sending Journey 1. On the invite page 2. Hover over Signature type dropdown 3. Enable **Virtual Sign** 4. Click gear icon and enable **Allow invitee to affix fingerprint image**. ## Signing Journey ### Prerequisites - Fingerprint capture device - **Mantra MFS500** biometric device for mobile application signing journey - **Mantra MFS100 and MFS500** biometric device for web-based and mobile application signing journey - Leegality Helper app > **Caution** > > - Mantra has **discontinued support for the MFS100 AAR** for mobile applications. As a result, MFS100 devices are no longer supported for Virtual Fingerprint flows in the Leegality Helper App. > **Info — Note** > > Fingerprint Virtual Sign is not supported for Mac OS or iOS. ### Signing Journey 1. On the signature page, depending on the activated virtual sign types, select **Affix Fingerprint** or proceed directly to the fingerprint capture page. 2. When you reach the fingerprint capture page, Leegality detects whether the biometric device is connected. 3. If the device is detected, press **Capture Fingerprint**. 4. Based on the fingerprint capture result, one of the following screens appears: - If the capture is unsuccessful, retry the fingerprint capture. - If the capture is successful, you can either: - Click **Proceed**, or - Delete and re-capture the fingerprint. 5. After clicking **Proceed**, check the consent box and click **Sign Document**. The document will be successfully signed. > **Info — Note** > > The signature appearance includes an image of the captured fingerprint. --- URL: https://knowledge.leegality.com/document-execution/esign-type/quick-sign # Quick Sign 'Quick Sign' is a fast eSigning method with a three-click process, no OTP verification, and no third-party integrations. It prioritizes speed and simplicity, ideal for situations where additional security features are not required. ## Setting up Quick Sign in Leegality To Set up Quick Sign for your account: 1. Click on the **Settings ⚙️** icon in the top right corner. 2. From the left panel, go to **Settings > eSignature & Seal.** 3. In the Quick Sign section, click on the **Setup**. A side menu will appear on your screen with three options: - **Draw:** Draw your signature on the screen. - **Choose a pre-built virtual sign:** Select a pre-built signature from the available options. - **Upload a photo of your signature:** Upload an image of your hand-drawn signature. (Supported image formats are .jpeg, .jpg, and .png) 4. Select your preferred option and click **Save**. ## Sending Journey #### V3 Workflow 1. On the invite page 2. Hover over Signature type dropdown 3. Enable **Quick Sign** 4. Click **Save**. > **Info** > > Learn how to [**enable and use Quick Sign for automated signing.**](https://knowledge.leegality.com/document-execution/esign-type/automated-esign.md) #### Workflow Creation 1. On the invite page 2. Hover over Signature type dropdown 3. Enable **Quick Sign** 4. Click **Save**. > **Info** > > Learn how to [**enable and use Quick Sign for automated signing.**](https://knowledge.leegality.com/document-execution/esign-type/automated-esign.md) #### V4 Workflow To enable Quick Sign for an invitee in a V4 workflow: 1. In the **Invite** stage, select the invitee and expand the **eSign Types** section. 2. Toggle on **Quick eSign**. 3. Optionally enable any of the following options: - **Allow invitee to draw signature** - **Allow invitee to choose computer-generated signature** - **Allow invitee to affix fingerprint image** #### Workflow Creation To enable Quick Sign for an invitee in a V4 workflow: 1. In the **Invite** stage, select the invitee and expand the **eSign Types** section. 2. Toggle on **Quick eSign**. 3. Optionally enable any of the following options: - **Allow invitee to draw signature** - **Allow invitee to choose computer-generated signature** - **Allow invitee to affix fingerprint image** ## Signing Journey 1. Open the invite received by email/SMS/whatsapp. Click on ‘Sign’ 2. View the document. Click on ‘Proceed’ to sign the document. 3. Select the type of signature and then click on ‘Proceed’ 4. Provide consent and click on ‘Sign Document’ and the document will be signed > **Info — Note** > > In the signing journey, the audit trail shows the name of the signer. It does not consist of the email or phone number of the signer. --- URL: https://knowledge.leegality.com/document-execution/esign-type/visual-sign # Visual Sign Impression Visual Sign Impression is a new eSign type that offers a non-digital signature without timestamps. Unlike traditional digital signatures, Visual Sign Impression captures an image of a hand-drawn signature, computer-generated signature, uploaded signature, or fingerprint image and affixs it to the document. This feature is designed to address specific use cases where timestamped digital signatures are not suitable. ## Setting Up Visual Sign in Leegality 1. Click on the **Settings ⚙️** icon in the top right corner. 2. From the left panel, go to **Settings > eSignature & Seal.** 3. In the Visual Sign section, click on the **Setup**. A side menu will appear on your screen with three options: - **Draw:** Draw your signature on the screen. - **Choose a pre-built virtual sign:** Select a pre-built signature from the available options. - **Upload a photo of your signature:** Upload an image of your hand-drawn signature. (Supported image formats are .jpeg, .jpg, and .png) 4. Select your preferred option and click **Save**. ## Sending Journey #### V3 Workflow > **Warning** > > Do not upload previously digitally signed documents for Visual Sign Impression. Existing signatures will be invalidated once a document is signed using Visual Sign. 1. Select the **Visual Sign** option under the **Signature Type** dropdown. 2. Allow invitee to: - Draw signature - Choose computer-generated signature - Affix fingerprint image - Upload physical signature 3. Click **Save** > **Info — Important Note** > > - Other eSign types cannot be selected with Visual Sign Impression for an invitee. Selecting Visual Sign will automatically toggle off other eSign types and vice versa. > - Visual Sign invitees must be added before any other eSign types. > - Only reviewers can be added before the Visual Sign invitees. > - NeSL is not supported with Visual Sign. > - Signing orders for documents containing Visual and Automated Visual signs will always be enforced. #### Workflow Creation 1. Select the **Visual Sign** option under the **Signature Type** dropdown. 2. Allow invitee to: - Draw signature - Choose computer-generated signature - Affix fingerprint image - Upload physical signature 3. Click **Save** > **Info — Important Note** > > - Other eSign types cannot be selected with Visual Sign Impression for an invitee. Selecting Visual Sign will automatically toggle off other eSign types and vice versa. > - Visual Sign invitees must be added before any other eSign types. > - Only reviewers can be added before the Visual Sign invitees. > - NeSL is not supported with Visual Sign. > - Signing orders for documents containing Visual and Automated Visual signs will always be enforced. #### V4 Workflow To enable Visual Sign for an invitee in a V4 workflow: 1. In the **Invite** stage, select the invitee and expand the **eSign Types** section. 2. Toggle on **Visual Sign**. 3. Check whichever options you want to allow the invitee to use: - **Allow invitee to draw signature** - **Allow invitee to choose computer-generated signature** - **Allow invitee to affix fingerprint image** - **Allow Sign Upload** You can enable any combination of these options for the invitee. #### Workflow Creation To enable Visual Sign for an invitee in a V4 workflow: 1. In the **Invite** stage, select the invitee and expand the **eSign Types** section. 2. Toggle on **Visual Sign**. 3. Check whichever options you want to allow the invitee to use: - **Allow invitee to draw signature** - **Allow invitee to choose computer-generated signature** - **Allow invitee to affix fingerprint image** - **Allow Sign Upload** You can enable any combination of these options for the invitee. ## Signing Journey The signed document will only show the signature appearance. Details like Leegality Document ID and timestamps will not be shown. In the audit trail, only the signature type will be shown. > **Info — Note** > > PDF readers will not detect Visual Sign Impression as a digital signature. --- URL: https://knowledge.leegality.com/document-execution/esign-type/automated-esign # Automated eSign This feature allows you to automatically sign the documents using Virtual Sign, Quick Sign and Doc Signer Certificate without manual intervention. Before proceeding, ensure that your eSign for which you want to automated sign is already set up in your account. ## Account-Level Configuration To Set Up automated sign in your account: 1. Click on the **Settings ⚙️** icon in the top right corner. 2. From the left panel, go to **Settings > eSignature & Seal.** 3. For the desired eSign type, click on the **edit** icon on the right side. 4. Toggle the **Automated Sign** option to enable it. 5. Check the consent box to agree to the terms of using Automated Sign. 6. Set a password. (this password must be provided by the sender to enable Automated Sign for an invitee). > **Info** > > Automated Sign can be enabled for *Virtual Sign, Quick Sign and Document Signer Certificate*. ## Sending Journey #### V3 Workflow 1. Hover over the **Signature Type** dropdown. 2. Enable **Automated Sign**. 3. Use **Choose Automated Sign profile** drop to select the signer's automated eSign profile. > **Tip** > > Use the eSign ID and Name to identify the profile. 4. Enter the password and click **Save**. #### Workflow Creation 1. Hover over the **Signature Type** dropdown. 2. Enable **Automated Sign**. 3. Use **Choose Automated Sign profile** drop to select the signer's automated eSign profile. > **Tip** > > Use the eSign ID and Name to identify the profile. 4. Enter the password and click **Save**. #### V4 Workflow To enable Automated eSign for an invitee in a V4 workflow: 1. In the **Invite** stage, select the invitee and expand the **eSign Types** section. 2. Toggle on **Automated eSign**. 3. Fill in the following details: - **Choose Automated Sign Profile** — select the signer's automated eSign profile. - **Password** (required) — enter the profile password. #### Workflow Creation To enable Automated eSign for an invitee in a V4 workflow: 1. In the **Invite** stage, select the invitee and expand the **eSign Types** section. 2. Toggle on **Automated eSign**. 3. Fill in the following details: - **Choose Automated Sign Profile** — select the signer's automated eSign profile. - **Password** (required) — enter the profile password. > **Info — Note** > > Automated Sign cannot be used for Group Signing. ## Signing Journey When the invitation for an automated signer is activated, the document will be signed automatically within a few seconds. The automated signer can be positioned anywhere in the signing order. > **Info — Note** > > For an Automated Sign invitee, the signing link does not need to be opened. Signing happens automatically in the background, and the link has no other function — clicking or opening it (including in a desktop browser) will not trigger or affect the signing process. > **Tip — Example** > > Consider a document with two signers where the second signer is automated and a signing order is enforced. Once the first invitee signs the document, the automated signer's invitation is activated. Within a few seconds, the automated signer completes the signing process, and the document is signed. ### Manual Retry of Automated Signature In some cases, an automated signature may be delayed or fail due to technical issues. When this happens, you can manually retry the automated signing process without waiting for the system to attempt it again. #### How to Retry 1. Navigate to **Documents > Received** or **Documents > Action Required**. 2. Open the document details page for the relevant document. 3. Click the **Retry Automated Sign** button to re-initiate the automated signing process instantly. #### Availability The manual retry option is available for all active automated eSign invitations that have not yet been completed. > **Info — Supported eSign Types** > > The retry option is available for **Virtual Sign, Visual Sign, Quick Sign, and Document Signer Certificate**. > **Info — Legacy UI** > > The automated retry option is only available in the **Legacy UI**. --- URL: https://knowledge.leegality.com/document-execution/integrations/salesforce/overview # Leegality for Salesforce Leegality for Salesforce is an AppExchange managed package that brings Leegality Document Execution directly into your Salesforce org. Your teams can send documents for eSigning, track signing status, and download signed documents and audit trails — all from the Salesforce records they already work on, without switching to the Leegality dashboard. ## What you can do - **Import and link Leegality workflows** to Salesforce objects, mapping document, stamp, and invitee details to Salesforce fields. - **Send documents for eSigning** from any record using a Sender Modal placed on the record page. - **Track documents** in real time — status, invitee details, and activity — from within Salesforce. - **Act on documents** — resend notifications, sign, complete, preview, and download documents, audit trails, and attachments. - **Manage everything centrally** on the All Documents page, with role-based visibility for admins and senders. ## How the integration works The managed package communicates with Leegality through three mechanisms: 1. **Named Credentials** — Salesforce makes secure API calls to the Leegality gateway (sandbox or production) using Named Credentials that store your Leegality Client ID and Client Secret. See [Installation & Setup](https://knowledge.leegality.com/document-execution/integrations/salesforce/installation-and-setup). 2. **OAuth authorization** — each admin and sender connects their own Leegality account by signing in from Salesforce. See [Connect & Authorize](https://knowledge.leegality.com/document-execution/integrations/salesforce/connect-and-authorize). 3. **Webhook + scheduled sync** — Leegality pushes document status updates to a webhook endpoint hosted on a Salesforce public site, and a scheduled Apex job keeps document and invitee details up to date. See [Administration](https://knowledge.leegality.com/document-execution/integrations/salesforce/administration). ## User roles The package defines two roles through permission sets: | Role | Permission set | What they do | | --- | --- | --- | | **Admin** | Leegality Admin User | Installs and configures the package, connects environments, imports and links workflows, manages users, and oversees all documents in the org. | | **Sender** | Leegality Sender User | Sends documents for eSigning from mapped records and manages the documents they have created. | ## Environments The package supports two Leegality environments: - **Sandbox** (`sandbox-gateway.leegality.com`) — for testing. Install the package in a Salesforce Developer or Sandbox org and connect it to Leegality Sandbox to explore features without affecting live data. - **Production** (`api-gateway.leegality.com`) — for live usage with real documents and signers. > **Tip** > > Always validate your configuration end-to-end in sandbox before setting up production. ## Prerequisites Before you begin, make sure you have: - Salesforce **System Administrator** access to install and configure the package. - A **Leegality account** with workflows configured in the environment you plan to connect. - Your Leegality **Client ID and Client Secret** for each environment (sandbox and/or production). These are provided by Leegality — contact your Leegality account manager if you don't have them. ## Setup at a glance An admin sets up the integration once, in this order: 1. [Install the managed package and configure credentials](https://knowledge.leegality.com/document-execution/integrations/salesforce/installation-and-setup) 2. [Assign permission sets to admins and senders](https://knowledge.leegality.com/document-execution/integrations/salesforce/installation-and-setup#step-3-assign-leegality-permission-sets) 3. [Connect and authorize with a Leegality environment](https://knowledge.leegality.com/document-execution/integrations/salesforce/connect-and-authorize) 4. [Import and link workflows to Salesforce objects](https://knowledge.leegality.com/document-execution/integrations/salesforce/workflow-management) 5. [Add the Sender Modal to record pages](https://knowledge.leegality.com/document-execution/integrations/salesforce/send-documents#add-the-sender-modal-to-a-record-page) 6. [Configure the webhook for status updates](https://knowledge.leegality.com/document-execution/integrations/salesforce/administration#webhook-configuration) After setup, senders simply authorize once and start [sending documents](https://knowledge.leegality.com/document-execution/integrations/salesforce/send-documents). --- URL: https://knowledge.leegality.com/document-execution/integrations/salesforce/installation-and-setup # Installation & Setup This page walks a Salesforce administrator through the one-time setup: installing the managed package, configuring credentials, and assigning permission sets. Complete the steps in order. > **Info — Before you start** > > Keep your Leegality **Client ID** and **Client Secret** handy for each environment you plan to connect. These are provided by Leegality — contact your Leegality account manager if you don't have them. > > Your **redirect URI** must already be registered against your Client ID at Leegality, pointing at your Salesforce org: > > ``` > https:///apex/LeegalityforSF__LG_AuthPage > ``` > > Production Client IDs are issued per customer, so the redirect URI requires your Salesforce org domain at the time credentials are created. Confirm this with your Leegality account manager when requesting credentials. ## Step 1: Install the managed package 1. Log in to your Salesforce org as a System Administrator. 2. Open the installation page for the Leegality managed package. 3. Choose **Install for Admins Only**. 4. Check the box **I acknowledge that I'm installing a Non-Salesforce Application that is not authorized for distribution as part of Salesforce's AppExchange Partner Program**. 5. Click **Install**. You are taken to the third-party access approval step. 6. All third-party access options are selected by default. Review them and check **Yes, grant access to these third-party websites**. 7. Click **Continue** to complete the installation. ## Step 2: Configure credentials The package calls Leegality APIs through Salesforce **Named Credentials**. You'll create an External Credential (which stores the Client ID and Secret), a Named Credential (which points to the Leegality gateway URL), and a permission set that lets users access the credential. Set up the environments you need — sandbox for testing, production for live use. The steps are identical; only the names, URLs, and credential values differ. ### 2.1 Create External Credentials 1. Click on the Gear icon (⚙️) on the top right corner to open **Setup Menu**. 2. Click **Setup** and a new tab will open. 3. Search for **Named Credentials**, and open it. 4. Click the **External Credentials** tab, then click **New**. 5. Based on the environment, enter: - For **sandbox** environment - **Label:** `LEEGALITY_SANDBOX_EC` - **Name:** `LEEGALITY_SANDBOX_EC` - For the **production** environment - **Label:** `LEEGALITY_PRODUCTION_EC` - **Name:** `LEEGALITY_PRODUCTION_EC` 6. **Authentication Protocol:** Basic Authentication 7. Click **Save**. > **Info — Separate environment-specific configuration** > > You need to add separate external credentials for Sandbox and Production environment. ### 2.2 Add Principals to the External Credentials 1. Open the External Credential (`LEEGALITY_SANDBOX_EC` or `LEEGALITY_PRODUCTION_EC`). 2. Scroll to the **Principals** section and click **New**. 3. Enter: - **Parameter Name:** Add an appropriate name e.g. `LeegalityCredentials` - **Sequence Number:** `1` - **Identity Type:** Named Principal 4. Click **Save**. 5. Click **Edit** on the principal you just created. 6. Enter your Leegality credentials in the built-in fields: | Field | Value | | --- | --- | | **Username** | Your Leegality Client ID for this environment | | **Password** | Your Leegality Client Secret for this environment | 7. Click **Save**. > **Caution** > > Use the **sandbox** Client ID/Secret in `LEEGALITY_SANDBOX_EC` and the **production** Client ID/Secret in `LEEGALITY_PRODUCTION_EC`. Mixing them up will cause authorization failures. > **Caution — Common mistakes** > > - **Do not swap Username and Password.** The Client ID goes in Username, the Client Secret goes in Password. > - **Delete leftover custom parameters.** If you previously configured `client_id` and `client_secret` as custom Authentication Parameters (from an earlier version), remove them. The built-in Username/Password fields replace them entirely. ### 2.3 Create Named Credentials 1. Go to **Setup → Named Credentials → Named Credentials** tab and click **New**. 2. Enter the values for your environment — use the **Production** column for production and the **Sandbox** column for sandbox: | Field | Production value | Sandbox value | | --- | --- | --- | | **Label** | `LEEGALITY_PRODUCTION` | `LEEGALITY_SANDBOX` | | **Name** | `LEEGALITY_PRODUCTION` | `LEEGALITY_SANDBOX` | | **URL** | `https://api-gateway.leegality.com` | `https://sandbox-gateway.leegality.com` | | **Enabled for Callouts** | ✅ Checked | ✅ Checked | | **External Credential** | `LEEGALITY_PRODUCTION_EC` | `LEEGALITY_SANDBOX_EC` | | **Generate Authorization Header** | ✅ Checked | ✅ Checked | | **Allow Formulas in HTTP Header** | ❌ Unchecked | ❌ Unchecked | | **Allow Formulas in HTTP Body** | ❌ Unchecked | ❌ Unchecked | | **Allowed Namespaces for Callouts** | `LeegalityforSF` | `LeegalityforSF` | 3. Click **Save**. 4. To set up both environments, click **New** again and repeat with the other column's values. > **Caution** > > Create the credentials with the **exact names shown above**. The package references them by name — a typo results in an "Unauthorized endpoint" error later. ### 2.4 Grant credential access to users Users need access to the External Credential principals before they can use the integration. **Create the permission set:** 1. Go to **Setup**, search for **Permission Sets**, and open it. 2. Click **New** and enter: - **Label:** `Leegality External Credential Access` - **API Name:** `Leegality_External_Credential_Access` 3. Click **Save**. 4. In the new permission set, click **External Credential Principal Access → Edit**. 5. Move the following to **Enabled External Credential Principals**: - `LEEGALITY_SANDBOX_EC - LeegalityCredentials` - `LEEGALITY_PRODUCTION_EC - LeegalityCredentials` 6. Click **Save**. **Assign it:** 1. Go to **Setup → Permission Sets** and open **Leegality External Credential Access**. 2. Click **Manage Assignments → Add Assignment**. 3. Select every user who will use Leegality (admins and senders), then click **Assign**. ### 2.5 Enter Client ID and redirect URL on custom metadata records After installing the package, two custom metadata records are available — one for each environment. You must enter your **Client ID** and **redirect URL** on both records before authorization will work. 1. Go to **Setup**, search for **Custom Metadata Types**, and open it. 2. Find **Leegality environment** and click **Manage Records**. 3. Open the record for the environment you are configuring and click **Edit**. 4. Enter: | Field | Value | | --- | --- | | **Client ID** | Your Leegality Client ID for this environment | | **Redirect URL** | `https:///apex/LeegalityforSF__LG_AuthPage` | 5. Click **Save**. 6. Repeat for the other environment's record. > **Info** > > This step must be completed before [verifying the credential setup](#26-verify-the-credential-setup). The verification step requires a successful login, which depends on these values being present in the metadata records. ### 2.6 Verify the credential setup Confirm the credentials work by signing in to a Leegality environment from the app. A successful OAuth login means the External and Named Credentials are configured correctly. 1. Click the **App Launcher** (9-dot grid icon, top left), search for *Leegality*, and select **Leegality for Salesforce** to open the app. 2. Go to the **Authorization** tab. 3. Click **Connect New Account** and select your environment (Production / Sandbox). 4. Complete the OAuth flow. If authorization fails, the error message is usually `invalid_client`. See [Troubleshooting](https://knowledge.leegality.com/document-execution/integrations/salesforce/troubleshooting#invalid_client-error-during-authorization) for how to resolve it. ## Step 3: Assign Leegality permission sets The package ships with two permission sets that define what users can do inside the app. ### Make a user an Admin Assign the **Leegality Admin User** permission set to every System Admin (or any user who will link workflows and manage the integration): 1. Go to **Setup → Users** and select the user. 2. Under **Permission Set Assignments**, click **Edit Assignments**. 3. Select the **Leegality Admin User** permission set. 4. Click **Save**. ### Make a user a Sender 1. Open the **Leegality for Salesforce** app and go to the **User Management** tab. 2. Select **Permission Set** and choose **Leegality Sender User**. 3. Click **Manage Assignment → Add Assignment**. 4. Select the user(s) you want to add as senders and confirm. > **Info — note** > > You can also manage both permission sets later from the app's **User Management** tab — see [Administration](https://knowledge.leegality.com/document-execution/integrations/salesforce/administration#user-management). ## Next step With installation and permissions in place, [connect and authorize with a Leegality environment](https://knowledge.leegality.com/document-execution/integrations/salesforce/connect-and-authorize). --- URL: https://knowledge.leegality.com/document-execution/integrations/salesforce/connect-and-authorize # Connect & Authorize Every user — admin or sender — connects their own Leegality account from within Salesforce before they can use the integration. This page covers how each role connects to each environment, and how environment redirection behaves. ## Admin authorization ### Connect as an admin 1. Log in to Salesforce with a user that has the **Leegality Admin User** permission set. 2. From the **App Launcher** (9-dot grid icon, top left), open the **Leegality for Salesforce** app, go to the **Authorization** tab, and click **Connect New Account**. 3. Choose the environment: - **Login with Sandbox** — connects to Leegality Sandbox. - **Login with App 1** — connects to Leegality Production. 4. A new tab tabs with the Leegality sign-in page. Enter your Leegality username and password — or sign in with OTP or SSO if enabled for your profile — and click **Sign In**. 5. You are redirected back to Salesforce with a message confirming successful authorization. ### Disconnect as an admin 1. Go to the **Authorization** tab. 2. Click **Disconnect**. 3. A message confirms that you are disconnected and can no longer use Leegality services. ## Sender authorization > **Info — Precondition** > > Senders need the **Leegality Sender User** permission set in Salesforce and valid Leegality credentials. The record they connect from must belong to an object with the Sender Modal on its page — see [Send Documents](https://knowledge.leegality.com/document-execution/integrations/salesforce/send-documents#add-the-sender-modal-to-a-record-page). 1. Navigate to any record of a mapped object (standard or custom). 2. In the **Leegality Workflows** section, click **Login to Leegality**. 3. If prompted, choose the environment (**Login with Sandbox** or **Login with App 1**). In many cases the environment is selected automatically — see [How environment redirection works](#how-environment-redirection-works). 4. A new tab opens with the Leegality sign-in page. Enter your credentials and click **Sign In**. 5. You are redirected back to the Salesforce record, and the record detail page shows a visual indication of the connection. ## How environment redirection works Which environment a sender lands in depends on what the org's admins are connected to: | Admin state | What the sender sees | | --- | --- | | One active admin, connected to an environment | Sender is automatically redirected to that same environment. | | Admin not connected to any environment | Sender is shown both environment options and chooses. | | Multiple active admins connected to **different** environments | Sender is shown both environment options and chooses. | | Multiple active admins connected to the **same** environment | Sender is automatically redirected to that shared environment. | Additional behavior to be aware of: - If a sender signs out and continues **without refreshing the page**, both environment options are shown — the system can't determine the admin's environment until the page reloads. - Admins and senders only see **workflows linked to the environment they are currently connected to**. An admin connected to Sandbox sees Sandbox workflows. - The **All Documents** table also follows the connected environment — an admin connected to Production sees documents initiated by production workflows, and vice versa. ## Authorization errors If you see an **`invalid_client`** error during authorization, the client secret configured in Salesforce is no longer valid. See [Troubleshooting](https://knowledge.leegality.com/document-execution/integrations/salesforce/troubleshooting#invalid_client-error-during-authorization) for the fix. ## Next step Once connected, admins can [import and link workflows](https://knowledge.leegality.com/document-execution/integrations/salesforce/workflow-management). --- URL: https://knowledge.leegality.com/document-execution/integrations/salesforce/workflow-management # Workflow Management Admins bring Leegality workflows into Salesforce in two steps: **import** the workflow list from Leegality, then **link** each workflow to a Salesforce object by mapping its fields across a series of stages. Once linked and activated, a workflow becomes available to senders on that object's records. ## Import workflows from Leegality 1. As an admin, open the **Workflow Management** tab. 2. Click **Import Workflow**. 3. A confirmation appears on success, and the imported workflows are listed under the Workflow Management tab. > **Info — note** > > The workflow list is fetched when you visit the tab. If workflows change in Leegality, revisit the **Workflow Management** tab to fetch the latest details. > **Caution — Which workflows appear** > > Workflows with the **NeSL** invitee signing type, and workflows unpublished in Leegality, are filtered out and won't appear in Salesforce. ## Link a workflow Linking maps a workflow to a Salesforce object across six stages — object, document, template, PDF, and invitee mapping, followed by review and activation. Work through them in order. > **Tip — Pause anytime** > > You can pause linking at any stage. Unfinished workflows keep a **Draft** status with your progress stored — see [Draft workflows](#draft-workflows) for how drafts behave across admins. ### Object Mapping Map the source objects whose records will feed the workflow information like document name, invitee details, and so on. If no suitable object exists, create one in Salesforce before linking. 1. Open the **Workflow Management** tab. 2. Click **Link Workflow** next to the workflow. 3. Use the **Select Source Object** dropdown to choose the data source — the Salesforce object whose records will feed the workflow. 4. Optionally, select additional source object(s) that are in relation with the primary source object, such as Account and Contacts. 5. Click **Next**. ### Document Details Mapping Map the document details to object fields that will feed the document and stamp details. If you leave a field unmapped, the person sending the document can enter any value in that field. - **Document Name** — the name the document is saved and identified by in Leegality and Salesforce. - **Internal Reference Number** — your own reference number for tracking the document internally. - **Revenue Stamp Series** — must be a valid revenue stamp series with stamps in it. For example: `06`. - **Revenue Stamp Quantity** — the number of stamps you want to affix. Must be a whole number, e.g. `4`. - **Series Group** — the stamp series group to draw the stamp from. - **Series Value** — the denomination (value) of the stamp to be affixed. - **Stamp Series** — the specific stamp series used to stamp the document. > **Info** > > When a field value is predefined at the Leegality workflow level, it cannot be mapped to a Salesforce field. Click **Save and Proceed**. ### Template Fields Mapping This stage is conditionally available — it appears only if the workflow uses a template. For PDF-only workflows, this stage does not appear. If your template has fields, they are fetched from Leegality. You can map template fields to Salesforce fields and provide values. - Fields like Radio Button, Dropdown (single-selection), Checkbox (multi-select), and Image cannot be mapped to any Salesforce field. - Required fields must be either mapped to an object's field or given a value at this stage before proceeding. - If you leave an optional field unmapped or empty, the person sending the document can enter any value in that field. Click **Save and Proceed**. ### PDF Files Mapping You can upload multiple PDFs if allowed by the workflow creator. You can also leave this empty, in which case the person sending the document can upload the PDFs. Click **Add PDF File** to upload a PDF from your system. > **Info** > > **Upload limit:** 10 files. > **Maximum total size:** up to 15 MB combined for all PDFs. Click **Save and Proceed**. ### Invitee Details Mapping Map the invitee details. For each invitee, map the name, phone, and email address. If left unmapped, the person using the workflow to send the document can enter any value. Click **Save and Proceed**. ### Review and Activate Workflow Review the complete mapping on the **Activate Workflow** page. Use **Edit** to change a mapping, or go **Back** to return to a previous stage. #### Automatic upload of documents to Files Admins can configure a workflow to automatically upload the signed document and/or the Audit Trail to the Salesforce **Files** section once the process is complete. This removes the need to manually download and re-upload documents. 1. Enable the **Enable automatic upload of document(s) to Files** toggle (off by default). 2. After enabling, two more toggles appear (both on by default): - **Upload latest version of document** — the latest signed version is uploaded to Files, replacing any previously uploaded version. - **Upload Audit Trail after completion** — the Audit Trail is uploaded once the document is fully signed by all parties. > **Caution** > > If the selected object does not support Salesforce Files, a warning appears: *"'Files' is NOT linked with this object."* You can still save the configuration, but documents will not be stored in Files until the object is properly configured. When everything looks correct, click **Activate**. The workflow's status changes to **Linked** and it becomes available to senders on the mapped object's records. **How it works:** - When the document is sent, an initial copy is saved to the Files section automatically. - As the document progresses, the latest signed version replaces the previous version, and on completion the Audit Trail is added — based on your configuration. ## Give edit permission to the sender By default, senders send documents with the details mapped by the admin. To let senders edit details before sending: 1. Go to the **Workflow Management** tab. 2. Find the workflow and click its **toggle** to grant edit permission to the sender. ## Re-link a workflow Re-link a workflow when its mapping needs to change: 1. Open the **Workflow Management** tab. 2. Find the linked workflow and click **Relink**. 3. Work through the mapping stages again — **Object Mapping**, **Document Details**, **Template Fields**, **PDF Files**, and **Invitee Details** — clicking **Next** or **Save and Proceed** at each stage. 4. On the **Activate Workflow** page, review the summary and click **Activate** to re-link (or **Edit** to keep adjusting). > **Caution** > > Re-link cautiously to avoid disrupting in-flight processes. Verify all details thoroughly before activating. ## Draft workflows When a workflow's linking is paused mid-way: - All other admins can see the workflow, but it remains **unlinked**. - Other admins can work on the same workflow — but they **cannot see drafts** that another user has edited and saved. - Once linking completes, the workflow moves to the linked section and becomes visible to all admin users. ## Next step With workflows linked, [add the Sender Modal and start sending documents](https://knowledge.leegality.com/document-execution/integrations/salesforce/send-documents). --- URL: https://knowledge.leegality.com/document-execution/integrations/salesforce/send-documents # Send Documents Senders send documents for eSigning directly from Salesforce records using the **Leegality Sender Modal** — a component an admin places on the record page. This page covers adding the modal, sending documents, and every action available on a sent document. ## Add the Sender Modal to a record page > **Info — Add Leegality Component** > > Admin need to add the Leegality component is the desired object once. 1. Open a record of the object where you want the Sender Modal, click the **gear icon** (top right), and select **Edit Page**. 2. In the components panel on the left, search for **Leegality** — the Sender Modal component appears labeled **Leegality**. 3. Drag and drop the component into the layout. 4. Click **Save**, then **Activate**, and assign the page as the **Org Default**. 5. Test the setup — open a record and confirm the modal appears as expected. ## Send a document for eSigning 1. Navigate to a record of the object where the Sender Modal is added. 2. Make sure you're [authorized](https://knowledge.leegality.com/document-execution/integrations/salesforce/connect-and-authorize#sender-authorization) — complete the login flow first if not. 3. Click **Trigger New Workflow** and select the workflow you want to send from the list of available workflows. 4. View — or edit, if the admin has [granted edit permission](https://knowledge.leegality.com/document-execution/integrations/salesforce/workflow-management#give-edit-permission-to-the-sender) — the document, template, and PDF details. 5. View or edit the invitee details. 6. Review everything on the preview page. 7. Click **Send Document**. The invitees receive notifications to eSign the document. > **Note** > > Before sending, ensure all necessary fields are filled correctly to avoid errors during the process. After sending, a modal appears with **OK, Got It!** and **View Details**. Click **View Details** to see the Document ID, Document Name, Status, and Activity Date, plus invitee details at the bottom. Close the modal with the ✕ button at the top right. - **Preview** — opens the document for review. Use the **download** icon (top right) to save it, or **✕** to close. - **Details** — opens a modal with the document's full details. - **Complete** — marks the document as completed manually. A copy of the completed document, along with the audit trail, is sent to the signer(s). - **Download Document / Download Audit Trail** — downloads the file to your device. - **Attachments** — opens a modal listing all attachments. Click **Download Link** next to an attachment to download it. ## Latest version in the Files section The latest version of a sent document is available in the **Files** section of the record. As invitees sign, this version is kept up to date. Once all invitees have signed, the fully signed document and its audit trail also appear in the **Files** section. > **Note** > > This applies only when the workflow is configured to upload documents to Files — see [Automatic upload of documents to Files](https://knowledge.leegality.com/document-execution/integrations/salesforce/workflow-management#automatic-upload-of-documents-to-files). ## Work with invitees The **Invitee Details** section of a document offers three actions: - **Details** — opens a pop-up with the invitee's name, email, invitation date, sign date, and signature. - **Resend Notification** — sends the invitee a fresh notification immediately. - **Sign** — redirects you to the signing page. Click **Proceed** and follow the steps to sign the document. ## Next step Admins can track every document in the org from the [All Documents](https://knowledge.leegality.com/document-execution/integrations/salesforce/all-documents) page. --- URL: https://knowledge.leegality.com/document-execution/integrations/salesforce/all-documents # All Documents The **All Documents** page is the central place to view and manage documents in Salesforce. What you see depends on your role: - **Admin** — a comprehensive view of all documents created in the organization, regardless of sender (excluding drafts and received documents of others). - **Sender** — only the documents you have created, keeping your view focused on your own work. > **Note** > > The page shows documents for the environment you're connected to. An admin connected to Production sees documents initiated by production workflows — see [How environment redirection works](https://knowledge.leegality.com/document-execution/integrations/salesforce/connect-and-authorize#how-environment-redirection-works). ## Find documents - **Filter by status** — use the status filters at the top of the page. Admins see filtered results across all documents; senders see only their own. - **Search** — use the search bar (top left) with a **Document ID** or **Document Name**. - **Filter by date range** — use the date range selector (top right) to view documents from a specific period. - **Filter by type** — click **Filter By** (top right) and choose **PDF** or **Template**. - **Paginate** — use **Next** / **Previous** at the bottom, or click a page number to jump directly. ## Document actions Click the **⋮ (three dots)** button next to a document to access its options: Preview, Details, Complete, Download Document, Download Audit Trail, Attachments, and Share. - **Preview** — opens the document in a modal. Use the download icon (top right) to save it, or ✕ to close. - **Details** — opens comprehensive information about the document. - **Download Document / Download Audit Trail** — downloads the file to your device. - **Attachments** — opens a modal where you can view and download the available attachments. ## Available actions by document status Which actions appear depends on the document's current status and your role and permissions: | Action | Sent | Completed | Received | Draft | Expired | | --- | :-: | :-: | :-: | :-: | :-: | | Preview | ✅ | ✅ | ✅ | ❌ | ✅ | | Edit | — | — | — | ✅ | — | | Complete | ✅ | — | — | — | — | | Details | ✅ | ✅ | ✅ | ✅ | ✅ | | Download Document | ✅ | ✅ | ✅ | ❌ | ✅ | | Download Audit Trail | — | ✅ | — | — | — | | Attachments | ✅ | ✅ | ✅ | ✅ | ✅ | ### Notes on draft documents - **Preview and Download** are not operational in the draft state — both become available once the document has been fully sent. - **Visibility** — draft documents are only visible to the admin or sender who created them, not to other admins or senders. --- URL: https://knowledge.leegality.com/document-execution/integrations/salesforce/administration # Administration Ongoing admin tasks: managing who can use Leegality in your org, and configuring the webhook that keeps document statuses in sync. ## User management The app's **User Management** tab gives admins a shortcut to the two Leegality permission sets without going through Salesforce Setup. ### Assign admin permissions 1. In the **Leegality for Salesforce** app, open the **User Management** tab. You are redirected to the **Permission Sets** page. 2. Find and click **Leegality Admin User Permission Set**. 3. Click **Manage Assignment**, then **Add Assignment**. 4. Choose the users to assign and click **Save**. ### Assign sender permissions 1. Open the **User Management** tab. You are redirected to the **Permission Sets** page. 2. Find and click **Leegality Sender User Permission Set**. 3. Click **Manage Assignment**, then **Add Assignment**. 4. Choose the users to assign and click **Save**. > **Note** > > Users also need the **Leegality External Credential Access** permission set to call Leegality APIs — see [Installation & Setup](https://knowledge.leegality.com/document-execution/integrations/salesforce/installation-and-setup#24-grant-credential-access-to-users). ## Webhook configuration Leegality pushes document status updates into Salesforce through a webhook endpoint hosted on a Salesforce **public site**. Set it up as follows: 1. From your Salesforce home page, click the **Setup** gear icon (top right). 2. In the Quick Find box, type **Sites** and open the Sites setup page. 3. Click **New** to create a new public site. 4. Fill in the required information — Site Label, Site Name, and Site Contact — and save. 5. Locate the new site in the list and click its name to open the site details. 6. Click **Public Access Settings**. 7. Under Public Access Settings, click **View Users** to see the users associated with the site. 8. Assign the **Leegality Webhook Permission Set** to the site's Guest User: open the user, click **Edit Assignments** under Permission Set Assignments, and add the permission set. 9. In Leegality (the webhook provider), set the webhook endpoint to: ``` https://{siteurl}/services/apexrest/LeegalityforSF/leegality/webhook/2.5/document ``` replacing `{siteurl}` with the URL of the public site you created. > **Info — Guest User permissions** > > Creating a site automatically generates a **Guest User**. This user must have **both** the **Leegality Webhook Permission Set** and the **Leegality External Credential Access** permission set for webhook and credential handling to work. ## Timezone configuration Dates and times in the integration are affected by three different timezone settings: - **Organization timezone** — the Apex job that updates document and invitee details runs on the organization's timezone setting. - **Current user timezone** — the Invitation Date and the date filters on All Documents follow the timezone of the current Salesforce user. - **Guest/site user timezone** — the webhook operates on the guest user's timezone setting. To ensure accurate date and time display, set the timezone to **Indian Standard Time (IST)** for the organization, all Salesforce users, and the site's guest user. This is necessary because the Leegality API responds in GMT, which Salesforce converts to IST based on these settings. See [Troubleshooting](https://knowledge.leegality.com/document-execution/integrations/salesforce/troubleshooting#dates-or-times-look-wrong) if you're seeing incorrect dates. --- URL: https://knowledge.leegality.com/document-execution/integrations/salesforce/troubleshooting # Troubleshooting Common issues with the Leegality for Salesforce integration and how to resolve them. ## Credential setup errors | Error | Resolution | | --- | --- | | "Unauthorized endpoint" | Verify the Named Credentials are created with the exact names shown in [Installation & Setup](https://knowledge.leegality.com/document-execution/integrations/salesforce/installation-and-setup#23-create-named-credentials). | | "No credentials found" | Ensure the **Leegality External Credential Access** permission set is assigned to the user. | | "Invalid client credentials" | Verify `client_id` and `client_secret` are correctly entered in the External Credential principal — and that sandbox/production values aren't mixed up. | ## `invalid_client` error during authorization If you encounter an `invalid_client` error while [authorizing](https://knowledge.leegality.com/document-execution/integrations/salesforce/connect-and-authorize), the client secret configured in Salesforce is invalid. Contact Leegality for assistance and request a new client secret for your environment — a **Sandbox client secret** for sandbox, or a **Production client secret** for production. Once you receive the new client secret, apply it: 1. Go to **Setup**, search for **Translate** in the Quick Find box, and **enable** the Translation feature. 2. Go back to **Setup** and search for **Custom Labels**. 3. Locate the two labels **`sandbox_client_secret`** and **`production_client_secret`**, and open the one matching your environment. 4. Click **New Local Translations (Override)**. 5. In the **Language** dropdown, select **English**. 6. Enter the new secret key from Leegality in the **Translation Text** field. 7. Save the changes. The correct client secret is now applied for your environment, resolving the error. ## Dates or times look wrong Document dates, invitation dates, or date filters showing unexpected values are almost always a timezone mismatch. The Leegality API responds in **GMT**, and Salesforce converts it based on three separate settings: | Setting | What it affects | | --- | --- | | Organization timezone | The Apex job that updates document and invitee details | | Current user's timezone | Invitation Date and date filters on the All Documents page | | Guest (site) user's timezone | Webhook processing | **Resolution:** set the timezone to **Indian Standard Time (IST)** in all three places — the organization settings, each Salesforce user, and the public site's guest user. See [Administration](https://knowledge.leegality.com/document-execution/integrations/salesforce/administration#timezone-configuration) for context. ## Workflows missing from Salesforce - **NESL and unpublished workflows are filtered out by design** — workflows with the NESL invitee signing type, or workflows unpublished in Leegality, won't appear. - The list is fetched when you visit the **Workflow Management** tab — revisit the tab to fetch the latest workflows from Leegality. - A maximum of **99 workflows** can be fetched from Leegality. ## Sending fails or the workflow errors out - Check that no **mandatory field** is left blank — an error message is displayed if one is. - Keep payloads under the **6 MB limit** — larger payloads cause failures in the workflow process. ## Status updates not arriving If document statuses aren't updating in Salesforce, verify the [webhook configuration](https://knowledge.leegality.com/document-execution/integrations/salesforce/administration#webhook-configuration) — in particular, that the site's **Guest User** has both the **Leegality Webhook Permission Set** and the **Leegality External Credential Access** permission set assigned. --- URL: https://knowledge.leegality.com/document-execution/security-compliance # Security, Compliance, and Certifications At Leegality, we prioritize the integrity of your digital transactions. As an authorized Application Service Provider (ASP), we operate under the legal framework of the Information Technology Act, 2000, holding formal authorizations from Esign Service Providers (ESPs). To ensure your data and our platform operations remain resilient against evolving threats, we maintain a robust suite of globally recognized certifications and attestations. ## Core Security & Privacy Certifications Leegality employs industry-standard controls and governance practices to protect customer data. Our commitment is supported by the following internationally recognized standards and attestation: | Certification | Focus Area | Impact on You | | :---- | :---- | :---- | | **ISO 27001:2022** | Information Security (ISMS) | Ensures a comprehensive system is in place to identify, manage, and mitigate security risks through continuous monitoring. | | **ISO 27017** | Cloud Security | Validates that our cloud-hosted environment follows strict protocols for secure administration, data segregation, and access management. | | **ISO 27018** | PII Protection | Confirms specialized privacy controls are in place to handle Personally Identifiable Information (PII) securely within our cloud environment. | ## Operational Excellence & Trust Beyond data security, we focus on the reliability and effectiveness of our business operations. The goal is to ensure operational resilience and service continuity, keeping your business running even during disruptive events or incidents. - **SOC 2 Type II Attestation:** An independent, third-party validation of our internal controls. Unlike a basic point-in-time check, a Type II report confirms that Leegality's controls regarding Security, Availability, and Confidentiality have operated effectively over an extended audit period. - **ISO 22301: Business Continuity (BCMS):** Resilience is a core pillar of our service. This certification demonstrates that Leegality maintains structured disaster recovery and business continuity processes. These certifications and attestation are not just badges; they represent our promise to provide a secure, legal, and uninterrupted digital documentation experience. By aligning to these global benchmarks, Leegality ensures that your sensitive business data is governed by the highest levels of international compliance. --- URL: https://knowledge.leegality.com/document-execution/validate-a-digital-signature # Validate a Digital Signature After a document has been signed, you can validate the digital signature in Adobe Acrobat to confirm that the signature is authentic and the document has not been modified since it was signed. This guide walks you through validating a signature by adding the signer's digital certificate to your list of trusted identities. ## How to Validate a Digital Signature in Adobe Acrobat ### Step 1: Open the Signature Panel First, open the document and access the signature details. 1. In Adobe Acrobat, open the PDF document containing the digital signature. 2. Click the **Signature Panel** button, which is often located in the blue ribbon at the top of the document or as an icon in the right-hand toolbar. > **Info — Check Initial Status** > > This is the step where you will see the initial, unverified status of the signature. It will likely be marked with a yellow warning triangle and the text **"Signature validity is unknown."** This is normal before you complete the validation process. ### Step 2: Begin the Trust Process Now, you will begin the process of telling Adobe to trust the signature. 1. In the Signature Panel on the left, right-click on the signature that has the "validity unknown" status. 2. Select **Show Signature Properties** from the context menu. 3. In the "Signature Properties" window, click the **Show Signer's Certificate** button. ### Step 3: Add to Trusted Certificates This is the most critical step, where you explicitly add the signer's identity to your trusted list. 1. In the "Certificate Viewer" window, navigate to the **Trust** tab. 2. Click the **Add to Trusted Certificates** button. Acknowledge the Adobe Acrobat pop-up by clicking **OK**. > **Info — What and Why: Adding to Trusted Certificates** > > **What it is:** This action takes the signer's digital ID (their certificate) and adds it to a special list within your Adobe software known as "Trusted Identities." > > **Why it's mandatory:** This is a crucial security step. You are manually confirming to the software that you trust the identity of the signer. This prevents Adobe from automatically trusting a potentially fraudulent signature and ensures that only the certificates you have personally vetted are considered valid. ### Step 4: Set Trust Permissions Specify what you want to trust this certificate for. 1. In the "Import Contact Settings" window, check the box next to **Certified documents**. This is the most important option for signature validation. 2. Click **OK** to confirm. 3. Click **OK** again to close the "Certificate Viewer." ### Step 5: Validate the Signature Finally, close the properties window and re-validate the signature. 1. Click **Validate Signature** at the bottom of the "Signature Properties" window. 2. A pop-up will show the validation results. You should now see the green checkmark. 3. Click **Close**. The signature in the document and in the Signature Panel will now display the green checkmark, confirming it is fully validated and trusted. ## Understanding Signature Details After validation, you will see a green checkmark. This is your confirmation. To see the specific digital signature certificate details such as Aadhaar-linked details, click on the now-valid signature. When you click on **Signature Properties** and **Show Signer's Certificate**, you can view an exhaustive list of details that provide comprehensive proof of the signature's authenticity. ### Signature Properties Details This window gives you information about the signature itself and its effect on the document. - **Signed by:** Displays the name of the person who signed the document. - **Signing Time:** Shows the exact date and time the signature was applied, based on the clock of the signer's computer or a trusted time-stamping authority. - **Reason:** The signer can state the purpose of their signature (e.g., "I approve this document," "I am the author of this document"). - **Signature Validity:** A summary that states if the signature is valid. After validation, this will say, "Signature is valid." - **Document Modification:** Confirms that "The document has not been modified since this signature was applied." - **Signer's Identity:** Confirms whether the signer's identity is valid and trusted. - **Certificate Source:** Tells you where the certificate came from (e.g., the Windows Certificate Store, a file). ### Signer's Certificate Details This window provides deep technical details about the digital ID used to create the signature, acting like a digital passport. - **Issued To:** The common name (CN) of the certificate holder (the signer). - **Issued By:** The name of the Certificate Authority (CA) that issued and verified the digital ID (e.g., CDSL, Protean, or Veraysys). - **Validity Period:** The "Valid from" and "to" dates, showing the time frame during which the certificate is considered active and trustworthy. - **Intended purposes:** Lists what the certificate is approved for. - **Serial Number:** A unique number assigned to the certificate by the issuing CA. - **Public Key:** The public portion of the signer's cryptographic key pair. --- URL: https://knowledge.leegality.com/document-execution/Glossary/glossary # Glossary 📖 This list explains terms you might see while using Leegality. It helps you understand the specific terminology and jargon with easy-to-follow definitions. ## Regulatories --- #### ASA (Authentication Service Agency) ASAs are agencies that have established secured leased line connectivity with the CIDR compliant with UIDAI's standards and specifications. ASAs offer their UIDAI-compliant network connectivity as a service to requesting entities (such as AUAs/KUAs) and transmit their authentication requests to CIDR. #### ASP (Application Service Provider) Application Service Provider (ASP) - an entity that provides front-end tools and services that allow signers to Aadhaar eSign documents. #### AUA (Authentication/Aadhar User Agency) Authentication User Agency (AUA) is an entity engaged in providing Aadhaar Enabled Services to Aadhaar number Holder, using the authentication as facilitated by the Authentication Service Agency (ASA). #### CA (Certifying Authorities) The Certifying Authorities (CAs) issue digital signature certificates for electronic authentication of users. Digital Signature Certificates (DSC) are issued by Certifying Authorities (CA) upon successful verification of the identity and address credentials of the applicant. #### CCA (Controller of Certifying Authorities) CCA provides license and regulates the working of Certifying Authorities. The CCA also maintains the Repository of Digital Certificates, which contains all the certificates issued to the CAs in the country. #### eGRAS Online Government Receipts Accounting System (e-GRAS) is an e-Governance Initiative of Government of Rajasthan. e-GRAS facilitates collection of tax/non tax revenue in both the mode online as well as manual. #### ESP (eSign Service Provider) eSign Service Provider (ESP) - the central entity that facilitates the Aadhaar eSign transaction between the signer, the UIDAI and the Certifying Authority. Under India’s regulatory framework - the eSign Service Provider or “ESP” must be owned and operated by a Certifying Authority. #### KUA (e-KYC User Agency) Acronym for KYC User Agency, the KUA fetches the KYC details from the UIDAI server. The KYC checks are carried out in the UIDAI server by collecting Aadhaar Number and OTP / Biometrics (Fingerprint / Iris / Face). #### NeSL NeSL is India’s first Information Utility and is registered with the Insolvency and Bankruptcy Board of India (IBBI). The primary role of NeSL is to serve as a repository of legal evidence holding the information pertaining to any debt/claim, as submitted by the financial or operational creditor and verified and authenticated by the parties to the debt. #### UIDAI UIDAI (Unique Identification Authority of India) is the government agency responsible for implementing and managing the Aadhaar program, which provides a unique 12-digit identification number to Indian residents based on biometric and demographic data. --- # Document Execution API URL: https://knowledge.leegality.com/document-execution/api/document-execution-api > Welcome to the Leegality Document Execution API documentation. This API lets you integrate Document Execution into your application. Use it to create signing requests, track document status, and retrieve signed documents and audit trails. Welcome to the Leegality Document Execution API documentation. This API lets you integrate Document Execution into your application. Use it to create signing requests, track document status, and retrieve signed documents and audit trails. ## What can you do with this API? - **Create eSigning requests** — Send documents for signing via based on pre-configured workflow. - **Track status** — Check the entire document status or specific invitee details. - **Retrieve signed documents** — Download the signed PDF and audit trail once all invitees have signed. - **Real-time updates** — Use Webhooks to receive real-time notifications on signing events. ## Environments | Environment | Dashboard | Base URL | |---|---|---| | Sandbox | https://sandbox-dashboard.leegality.com | `https://sandbox.leegality.com/api/` | | Production | https://dashboard.leegality.com | `https://app1.leegality.com/api/` | ## Testing with Postman A Postman Collection is available with pre-configured requests for common scenarios: [Download Postman Collection](https://drive.google.com/file/d/1EpJItMuIQPMFKgtmjHmjs7JKGqs3I4Dl/view) Import the collection into Postman and add your Auth Token to begin testing. ## Need Help? Reach out to [support@leegality.com](mailto:support@leegality.com) for any questions about your integration. You can also review our [Terms of Service](https://leegality.com/tnc).
Security Scheme Type: apiKey
Header parameter name: X-Auth-Token
--- URL: https://knowledge.leegality.com/document-execution/api/security/ip-whitelisting # IP Whitelisting IP whitelisting ensures secure communication between your infrastructure and Leegality by restricting network access to specific IP addresses. IP whitelisting works in two directions: 1. **Whitelisting Your IPs in Leegality**: Restrict which of your servers can make API calls to Leegality 2. **Whitelisting Leegality IPs in Your Infrastructure**: Allow Leegality to send webhooks and access your endpoints ## Whitelisting Your IPs in Leegality Dashboard Configure which IP addresses from your infrastructure can access Leegality APIs. #### Add Your Server IPs 1. Log in to your Leegality dashboard 2. Navigate to **Settings** > **API** 3. In **Whitelisted IPs** enter your server's public IP address 4. Click **+** to add the IP address. Repeat for all servers that need API access. > **Caution — Important** > > Once enabled, only API requests from whitelisted IPs will be accepted. Ensure all necessary server IPs are added before enabling. #### IP Address Format The Leegality dashboard accepts **valid IPv4 addresses only**. **Format**: `xxx.xxx.xxx.xxx` **Example**: ``` 203.0.113.10 ``` **To whitelist multiple servers**: Add each server's IP address separately by clicking the **+** button after each entry. ## Whitelisting Leegality IPs in Your Infrastructure If your infrastructure has IP-based firewall rules, whitelist these Leegality IPs to * Receive real-time webhook delivery * Automated SFTP transfers * Doc Signer (Only if hosted on your server) #### Production Environment IPs Whitelist these IPs for production integrations: ``` 15.207.242.28 3.6.114.195 3.7.137.254 ``` #### Sandbox Environment IPs Whitelist these IPs for sandbox/testing: ``` 65.2.154.131 ``` ### Disaster Recovery (DR) IPs Leegality operates a Disaster Recovery site for failover and redundancy. Traffic originates from these addresses when the DR site is active, so they must be whitelisted **in addition to** the production and sandbox IPs listed above. #### DR Production Environment IPs ``` 16.112.182.65 16.113.53.191 18.60.37.106 ``` #### DR Sandbox Environment IPs ``` 16.112.167.5 ``` > **Caution — Whitelist both primary and DR IPs** > > Both primary and DR IPs need to be whitelisted. ## IP Whitelisting Errors | Code | Message | Description | Solution | |------|---------|---------------------|----------| | `173` | `IP verification failed.` | The IP address making the API request is not in the authorized whitelist configured for your API token. | Add your public IPs in Leegality Dashboard via [**Settings → API → Whitelisted IPs**](https://knowledge.leegality.com/document-execution/settings/account-level/API/how-to-whitelist-ip). Ensure all server IPs are whitelisted before enabling the feature — once active, only whitelisted IPs can make call to Leegality APIs. | | — | `Please enter valid IPv4 address.` | The IP address entered in the dashboard is not a valid IPv4 format. | Use the format `xxx.xxx.xxx.xxx` (e.g. `203.0.113.10`). IPv6 addresses and incomplete values like `192.168.1` are not supported. | --- URL: https://knowledge.leegality.com/document-execution/api/security/domain-whitelisting # Domain Whitelisting Domain whitelisting ensures your infrastructure can access Leegality services and third-party eSign providers. ## Whitelisting Domains in Your Infrastructure If your organization uses firewalls, proxy servers, or content filters, whitelist these domains to ensure proper integration with Leegality. ### Required Domains for Production ``` *.leegality.com https://esign.egov.proteantech.in/nsdl-esp/authenticate/esign-doc/ https://esign.egov.proteantech.in https://api.leegality.com https://esign.cdslindia.com/ESign21Web/otp​ https://esign.verasys.in/esp/authpage ``` > **Info — Why Wildcard Domain?** > > Whitelisting `*.leegality.com` ensures all subdomains and microservices are accessible. Without this, you'll need to individually whitelist each subdomain and any new microservices deployed in the future. ### Required Domains for Sandbox ``` *.leegality.com https://pregw.esign.egov.proteantech.in​ https://api-sandbox.leegality.com https://esignuat.vsign.in/esp/authpage https://uatesign.cdslindia.com/ https://uatesign.cdslindia.com/ESign21Web/otp ``` ### Email Domain Whitelisting Whitelist these email addresses to receive notifications: - **Production**: `noreply@leegality.com` - **Sandbox**: `noreply-sandbox@leegality.com` Configure your email security gateway and spam filters to allow emails from these addresses. --- URL: https://knowledge.leegality.com/document-execution/api/security/payload-encryption # Payload Encryption Payload encryption adds an additional security layer to API requests, responses, and webhook notifications beyond standard HTTPS/TLS/SSL protocols. #### API Payload Encryption ### Pre-requisites Before enabling API payload encryption: 1. **Verify plan**: Contact Leegality customer support (support@leegality.com) to confirm your license supports API payload encryption. 2. **Key-Pair Exchange**: Exchange public keys with Leegality over secure email (bi-directional) - **Public Keys** - Leegality's public keys are shared with customers to download and use to encrypt API requests. - Customer-managed pubic keys are shared with Leegality to encrypt API responses. - **Private Keys** - Leegality's private keys are used to decrypt the API requests sent by the customer. - Customer-managed private keys are used to decrypt the API responses sent by Leegality. 3. **Specify User email IDs**: Provide the list of user email IDs that will make encrypted API calls. Leegality will map your public certificate to these user IDs ### How It Works Leegality uses **AES-256-CBC** to encrypt the payload content. The AES key and IV (Initialization Vector) used for encryption are bundled together into a 48-byte structure — 32 bytes for the AES key followed by 16 bytes for the IV. This bundle is called the **salt**, which is then RSA-encrypted with the recipient's public key before being sent alongside the payload. The encryption is built on a two-key system — each party holds a public key and a private key. Public keys are shared openly; private keys never leave their owner. | Direction | Encrypted with | Decrypted with | |-----------|---------------|----------------| | Your request → Leegality | Leegality's public key *(Leegality shared with you)* | Leegality's private key | | Leegality's response → You | Your public key *(You shared with Leegality)* | Your private key | ### Sending Encrypted Requests To send an encrypted request to a Leegality API, follow these steps: 1. Create the standard request payload as per API documentation 2. Generate a 256-bit AES key and IV (Initialization Vector) 3. Encrypt the request payload using the AES key (AES-256-CBC) and encode the result with Base64 format — this is the **`payload`** value 4. Combine AES key + IV into a 48-byte bundle (bytes 0–32 is AES key and bytes 32–48 is IV) 5. Encrypt the bundle with Leegality's public key using RSA and Base64 encode the result — this is the **`salt`** value 6. Send the request with the `content-encoding: encrypted` header and this body structure: ```bash curl --location 'https://app.leegality.com/api/v3.0/{endpoint}' \ --header 'X-Auth-Token: YOUR_API_TOKEN' \ --header 'Content-Type: application/json' \ --header 'content-encoding: encrypted' \ --data '{ "salt": "BASE64_ENCODED_ENCRYPTED_AES_KEY_AND_IV", "payload": "BASE64_ENCODED_ENCRYPTED_PAYLOAD" }' ``` ```mermaid flowchart LR A["Create request payload"] --> B["Generate 256-bit AES key + IV"] B --> C["Encrypt payload with AES key"] B --> D["Combine AES key + IV into 48-byte bundle"] C --> E["Base64 encode → payload value"] D --> F["Encrypt bundle with Leegality's public key"] F --> G["Base64 encode → salt value"] E --> H["Send request with content-encoding: encrypted"] G --> H ``` ### Decrypting API Responses When you send an encrypted request, Leegality's response is also encrypted — using your public key. You must decrypt it to read the response. Encrypted responses from Leegality have this structure: ```json { "salt": "BASE64_ENCODED_ENCRYPTED_AES_KEY_AND_IV", "payload": "BASE64_ENCODED_ENCRYPTED_RESPONSE" } ``` To decrypt: 1. Decrypt the salt using your organization's private key (RSA) 2. Extract AES key (bytes 0-31) and IV (bytes 32-47) from the decrypted salt 3. Decrypt the payload using the extracted AES key and IV (AES-256-CBC) 4. Parse the decrypted JSON response > **Info** > > HTTP status codes and error messages are NOT encrypted. Only the response payload is encrypted. ### Additional Resources A sample Java application for encryption, decryption, and related steps is available at the [Leegality Encryption Utility](https://gitlab.leegality.com/leegality-public/encryption-decryption-util) repository. #### Webhook Payload Encryption ### Pre-requisites Before enabling webhook payload encryption: 1. **Verify License**: Contact Leegality customer support to confirm your license supports webhook payload encryption 2. **Share Public Certificate**: Send your **RSA public key in PEM format** (file extension: `.cer.txt`) to Leegality over secure email. You retain the corresponding private key for decryption 3. **Receive Profile ID**: Leegality will configure your public certificate and provide a **Webhook Profile ID** 4. **Configure Profile ID**: Add the Webhook Profile ID against each invitee when sending documents > **Info** > > - If you configure both Payload Encryption and [Custom Webhook Headers](https://knowledge.leegality.com/document-execution/api/security/custom-webhook-headers), both are mapped to a single **Webhook Profile ID** — you don't need separate IDs > - An organisation can have multiple Profile IDs with different combinations > - Profile IDs are optional — if no Profile ID is passed, no encryption or custom headers are applied ### Configuring Webhook Profile ID **Via Dashboard**: 1. When creating or editing a workflow, navigate to invitee configuration 2. Go to **Invitee Level Options** for the invitee(s) who should receive encrypted webhooks 3. Under **Add custom URLs and webhooks** section 4. Enter the Webhook Profile ID in the **Webhook Profile ID** field **Via API**: Add `profileId` in the webhook object for each invitee when sending documents: ```json { "invitees": [ { "name": "John Doe", "email": "john@example.com", "webhook": { "profileId": "YOUR_WEBHOOK_PROFILE_ID", "url": "https://your-domain.com/webhook" } } ] } ``` > **Tip** > > Only invitees with a Profile ID configured will receive encrypted webhook payloads. Invitees without a Profile ID will receive standard (non-encrypted) webhooks. ### How It Works Leegality uses **AES-256-CBC** to encrypt webhook payloads. When a webhook is triggered for an invitee with a Profile ID configured: 1. Leegality generates a 256-bit AES key and IV (Initialization Vector) 2. Encrypts the webhook payload with the AES key — Base64 encoded, this is the **`payload`** value 3. Encrypts the AES key + IV bundle with your public key using RSA — Base64 encoded, this is the **`salt`** value 4. Sends the encrypted webhook to your endpoint: ```json { "salt": "BASE64_ENCODED_ENCRYPTED_AES_KEY_AND_IV", "payload": "BASE64_ENCODED_ENCRYPTED_WEBHOOK_PAYLOAD" } ``` ### Decrypting Webhook Payloads When your endpoint receives a webhook, the body will contain two fields — `salt` and `payload` — both Base64 encoded. To read the webhook content, you need to decrypt them using your private key: 1. Decrypt the `salt` using your private key (RSA) to obtain the 48-byte bundle 2. Extract the AES key (bytes 0–32) and IV (bytes 32–48) from the decrypted bundle 3. Decrypt the `payload` using the extracted AES key and IV (AES-256-CBC) 4. Parse the decrypted JSON and process the webhook content --- URL: https://knowledge.leegality.com/document-execution/api/security/custom-webhook-headers # Custom Webhook Headers When Leegality sends a webhook to your endpoint, your server needs a way to verify the request is genuinely coming from Leegality. Custom webhook headers let you define authentication parameters that Leegality includes in every webhook request — your server checks for these before processing the webhook. This supports a range of authentication methods, from basic username/password to bearer tokens and OAuth2.0. ### Types of Custom Webhook Headers Leegality supports two types of custom webhook headers: **Static Headers** - Fixed key-value pairs that remain unchanged for every webhook callback - Ideal for API keys, usernames, passwords, and fixed authentication tokens **Dynamic Headers** - Values fetched in real time from an API before each webhook call - Suitable for bearer tokens, OAuth2.0 tokens, or any value that refreshes periodically ## How It Works 1. You share your authentication requirements with Leegality support — for example, a static username and password, or an API endpoint Leegality should call to fetch a bearer token before each webhook 2. Leegality configures them on the backend and provides a **Webhook Profile ID** 3. For every webhook request sent to an invitee with the Profile ID attached, Leegality includes the configured headers 4. Your endpoint validates these headers to confirm the request is from Leegality before processing it ## Configuration #### Step 1: Prepare Header Information Email Leegality support at **support@leegality.com** with the following details: **For Static Headers:** Provide the key-value pairs to be added to the webhook headers. The key names depend on what your authentication system accepts — for example: | Key | Value | |-----|-------| | `username` | `xyz@abc.com` | | `password` | `sample_password` | **For Dynamic Headers:** Provide the details of the API that Leegality should call to fetch values before each webhook: - **API Endpoint / URL** - **Method Type** (GET, POST, etc.) - **Request parameters** — keys, values, and structure - **Response structure** — the JSON path of the value to extract (e.g., `$.resp_type.code.token`) Then provide the header mapping — the key name to use in the webhook header and the JSON path pointing to where Leegality should extract the value from the API response. Both the key name and the value source are defined by you: | Key | Source | |-----|--------| | `your-header-key` | `$.resp_type.code.token` *(extracted from API response (JSON) on each call)* | #### Step 2: Receive Webhook Profile ID Once Leegality configures your request, you will receive a **Webhook Profile ID**. You need to include this Profile ID with each invitee when sending documents — only invitations with the Profile ID attached will have the custom headers added to their webhook calls. #### Step 3: Configure Profile ID 1. When creating or editing a workflow, navigate to invitee configuration 2. Go to **Invitee Level Options** for the invitee(s) who should receive custom headers 3. Under **Add custom URLs and webhooks** section 4. Enter the Webhook Profile ID in the **Webhook Profile ID** field > **Tip — Authenticate Webhook Calls** > > When your endpoint receives a webhook from Leegality, validate the custom headers before processing the request. If the headers are missing or do not match your expected values, reject the request. This ensures only legitimate webhook calls from Leegality are processed. --- URL: https://knowledge.leegality.com/document-execution/api/security/mtls # Mutual TLS (mTLS) on Leegality Mutual TLS (mTLS) is a two-way authentication protocol. Unlike standard HTTPS, where only the server proves its identity, in mTLS, **both the server and the client present digital certificates** before any data exchange begins. In Leegality's context, this means: when Leegality sends a webhook to a client's server, both sides authenticate each other using certificates — ensuring the client's server only accepts callbacks from Leegality's verified identity. ## Why mTLS for Webhooks When Leegality completes a signing event, it sends an outbound HTTP POST call to the client's configured `webhookURL` or `errorWebhookURL`. By default, this call is made over standard HTTPS (TLS), which only authenticates the **server** (Leegality's side). However, clients who need to verify that incoming webhook calls genuinely originate from Leegality — and not from a third party — can enable **Mutual TLS (mTLS)**. mTLS extends standard TLS by requiring **both parties** to present and validate a certificate. This means: - Leegality proves its identity to the client's server (standard TLS). - Leegality also presents a **client certificate** when calling the client's webhook endpoint, which the client's server validates before accepting the request. Clients operate under strict frameworks — RBI IT & Cybersecurity, SEBI Cloud Application Framework, and internal WAF policies. These frameworks require that all inbound API callbacks (webhooks) be authenticated. mTLS is Leegality's primary mechanism to satisfy these requirements. ## How mTLS Works When Leegality sends an outbound webhook: 1. Leegality presents the mTLS certificate as its client identity in the TLS handshake 2. The client's server validates Leegality's certificate 3. The TLS handshake completes; the webhook payload is delivered **Key facts:** - Clients must trust the mTLS certificate in their keystore - Sandbox and Production are **separate configurations** — certificates must be installed and configured for each environment independently - The certificate is configured per **Webhook Profile ID** (a UUID), which is then mapped to an Org ID ## Implementation Methods ### Method 1: CSR Generated by Leegality 1. Leegality generates a CSR and shares it with the client 2. Client gets it signed by any CA (private or recognised) 3. Client shares signed certificate back with Leegality 4. Leegality converts to P12 and configures in a Webhook Profile ID 5. Webhook Profile ID shared with client ### Method 2: Certificate Procured by Leegality 1. Leegality procures a public signed certificate from a trusted CA 2. Converts it to P12 format 3. Configures it in a Webhook Profile ID 4. Shares the public certificate and Webhook Profile ID with the client ## Prerequisites Checklist **From the Customer:** - [ ] Org ID(s) requiring mTLS — Sandbox and Production separately - [ ] Webhook receiver URL (HTTPS endpoint) - [ ] Custom header requirements (header names and values) - [ ] Commercial approval (mTLS is a paid feature ) **From the Leegality:** - [ ] Webhook Profile ID created/identified for the Org ID - [ ] Certificate configured in the Webhook Profile - [ ] Custom headers added if required ## Certificate Renewal Certificate has **1-year validity**. Upon renewal: 1. Leegality renews the certificate 2. The renewed certificate must be **re-configured in every Webhook Profile ID** that uses it 3. The new public certificate must be **re-shared with all active mTLS clients** so they can update their keystores 4. Clients must install the new cert before the old one expires --- URL: https://knowledge.leegality.com/document-execution/api/v4-authentication # v4 Authentication (OAuth 2.0) The v4 Workflow APIs use the **OAuth 2.0 Authorization Code** flow. In short: your application sends the user to Leegality to sign in, receives an authorization **code**, exchanges that code for an **access token**, and then calls the v4 APIs with that token. ## How the flow works ```mermaid sequenceDiagram actor User as User participant App as Your application participant Auth as Leegality Authorization Server participant API as Leegality v4 API User->>App: 1. Clicks "Sign in with Leegality" App->>Auth: 2. Redirects the browser to /oauth2/authorize Auth-->>User: 3. Shows the Leegality login page User->>Auth: 4. Signs in and approves access Auth-->>App: 5. Redirects back to your app with ?code=… App->>Auth: 6. POST /oauth2/token (code + Client ID/Secret) Auth-->>App: 7. Returns an access token App->>API: 8. Calls the v4 API with the access token API-->>App: 9. Returns the data App-->>User: 10. Shows the result ``` ## Authorization endpoints All OAuth endpoints are served under the base URL `https://api-gateway.leegality.com/auth`. On sandbox, the base URL is `https://sandbox-gateway.leegality.com/auth`. ## Step 1 — Create an OAuth client Create an OAuth client in the dashboard. This gives you the **Client ID** and **Client Secret** your application uses to obtain access tokens. ![Access the UAM portal from the dashboard](https://knowledge.leegality.com/img/access_uam_panel.png) 1. Log in to the [Leegality dashboard](https://dashboard.leegality.com/sign-in). 2. Click the gear (settings) ⚙️ icon in the top-right corner. 3. In the left menu, go to **Settings → API**. 4. Click **Manage Access Token**. You're redirected to the UAM portal login page. 5. Log in to the UAM portal. 6. Open **OAuth Clients**. 7. Click **+ Create Client** and provide: - **Client Name** — any name to identify this client. - **Grant Type** — choose **Authorization Code**. - **Redirect URLs** — the URL(s) Leegality is allowed to send the user back to after they sign in (carrying the authorization code). The `redirect_uri` you send in Step 2 must **exactly match** one of these values. Add only URLs your application controls. - **Access Token Validity** — how long an access token stays valid, in seconds. - **Refresh Token Validity** — how long a refresh token stays valid, in seconds. 8. Click **Create Client**. The **Client ID** and **Client Secret** created successfully. > **Warning — Copy your Client Secret now** > > The Client Secret is shown only once. Copy and store both the Client ID and Client Secret before closing the window. ## Step 2 — Get an authorization code Redirect the user's browser to the authorization endpoint: > **Info — Sandbox Endpoint** > > `https://sandbox-gateway.leegality.com/auth/oauth2/authorize` Include the query parameters shown below: ``` GET https://api-gateway.leegality.com/auth/oauth2/authorize?response_type=code&client_id=&redirect_uri=&scope=*&state= ``` | Parameter | Required | Description | | --- | --- | --- | | `response_type` | Yes | Must be `code`. | | `client_id` | Yes | Your client's ID from Step 1. | | `redirect_uri` | Yes | Where to send the user after they sign in. Must **exactly match** a Redirect URL registered on the client. | | `scope` | Yes | The access being requested. Use `*`. | | `state` | Recommended | An opaque value your application generates. Leegality returns it unchanged, so you can confirm the response belongs to your request (protects against CSRF). Use a **different value for every authorization request**. | The user sees the Leegality login page, signs in, and approves access. Leegality then redirects the browser back to your `redirect_uri` with the authorization code appended: ``` ?code=&scope=*&state= ``` Your application reads the `code` value from the query string in its redirect handler. > **Warning — Use each code once** > > The authorization code is single-use and short-lived. Exchange it for a token immediately (Step 3) and **never retry the same code** — replaying a code invalidates the tokens issued from it. ## Step 3 — Exchange the code for an access token From your backend, exchange the code for an access token at the token endpoint. Authenticate with your Client ID and Secret using **HTTP Basic** auth. > **Info — Sandbox Endpoint** > > `https://sandbox-gateway.leegality.com/auth/oauth2/token` ```bash curl --location 'https://api-gateway.leegality.com/auth/oauth2/token' \ --header 'Authorization: Basic ' \ --header 'Content-Type: application/x-www-form-urlencoded' \ --data-urlencode 'grant_type=authorization_code' \ --data-urlencode 'code=' \ --data-urlencode 'redirect_uri=' ``` | Field | Where | Description | | --- | --- | --- | | Client ID + Secret | `Authorization: Basic` header | Base64-encode `client_id:client_secret`. Most HTTP clients build this header for you when you supply a username and password. Credentials must go **here**, not in the body. | | `grant_type` | Body | Must be `authorization_code`. | | `code` | Body | The authorization code from Step 2. | | `redirect_uri` | Body | The same value you used in Step 2. | A successful response returns the access token: ```json { "access_token": "eyJhbGciOiJSUzI1NiIsInR5cCI6ImF0K2p3dCJ9...", "token_type": "Bearer", "expires_in": 3600, "refresh_token": "eyJhbGciOiJSUzI1NiIsInR5cCI6InJ0K2p3dCJ9...", "scope": "*" } ``` The access token is valid for the number of seconds shown in `expires_in`. ## Step 4 — Call the v4 APIs Send the access token in the `Authorization` header (as a Bearer token) on every v4 API request: ```bash curl --location 'https://app1.leegality.com/api/v4/packs/search?max=3' \ --header 'Authorization: Bearer ' ``` When the token expires, use the refresh token to get a new one (Step 5) — no need to send the user through sign-in again. ## Step 5 — Refresh the access token When the access token expires, use the `refresh_token` from Step 3 to get a new one, without sending the user through sign-in again. Call the **same** token endpoint with `grant_type=refresh_token`. ```bash curl --location 'https://api-gateway.leegality.com/auth/oauth2/token' \ --header 'Authorization: Basic ' \ --header 'Content-Type: application/x-www-form-urlencoded' \ --data-urlencode 'grant_type=refresh_token' \ --data-urlencode 'refresh_token=' ``` | Field | Where | Description | | --- | --- | --- | | Client ID + Secret | `Authorization: Basic` header | Same as Step 3. | | `grant_type` | Body | Must be `refresh_token`. | | `refresh_token` | Body | The `refresh_token` from the Step 3 response. | The response has the same shape as Step 3, with a fresh `access_token`. ## Rules to know > **Note** > > - **Redirect URI must match exactly.** The `redirect_uri` in Steps 2 and 3 must be identical to a Redirect URL registered on the client — same scheme, host, and path. > - **Use `127.0.0.1`, not `localhost`.** `localhost` is rejected as a redirect host; use the loopback IP for local testing. > - **Client credentials go only in the `Authorization: Basic` header** at `/oauth2/token`. Sending them in the request body is rejected. > - **Authorization codes are single-use.** Never retry a code exchange — start the flow again to get a new code. --- URL: https://knowledge.leegality.com/document-execution/api/download-v4-api-payload # Download the v4 API payload The dashboard shows only a short form of the workflow ID (for example, `70843c25`). To get the full `workflowId` — and a ready-to-use request body — download the workflow's API payload from the dashboard. 1. In the dashboard, open **Workflows** from the left menu. 2. Select **V4 workflow**. 3. Find the workflow you want to use. 4. Click the **⋮** (three dots) on that workflow and select **Download API Payload**. ## What you get A JSON file containing the workflow's base request body, pre-filled with the details you need to get started. Use it as the starting point for your request payload when calling the [Send Pack for eSigning (Sync)](https://knowledge.leegality.com/document-execution/api/create-pack-sync) or [Send Pack for eSigning (Async)](https://knowledge.leegality.com/document-execution/api/create-pack) API. > **Info — Template grouped fields** > > If a template has grouped fields, pass only one value per group for `text`, `textarea`, and `number` field types in `templateFieldValues` — it will auto-populate every template form field in the same group. --- URL: https://knowledge.leegality.com/document-execution/api/upload-media # POST /v4/media/upload — Upload media :::info[Sandbox endpoint] **Authentication:** `X-Auth-Token` header required on every request. ## Request URL ``` POST https://app1.leegality.com/api/v4/media/upload ``` **Environments:** - Production: `https://app1.leegality.com/api/v4/media/upload` - Sandbox: `https://sandbox.leegality.com/api/v4/media/upload` --- ## Request Body **Content-Type:** `application/json` | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `fileName` | string | Yes | Name of the file you will upload, including its extension. | `loan-agreement.pdf` | | `mediaType` | string | Yes | The type of file being uploaded — what it will be used as in the pack. **Possible values:** - `SUB_DOCUMENT` - `STAMP_UPLOAD` - `REFERENCE_ATTACHMENTS` - `FACE_MATCH_REFERENCE` - `TEMPLATE_FILE_TYPE_FIELD` - `CUSTOM_FIELD_UPLOAD` Allowed: `SUB_DOCUMENT`, `STAMP_UPLOAD`, `REFERENCE_ATTACHMENTS`, `FACE_MATCH_REFERENCE`, `TEMPLATE_FILE_TYPE_FIELD`, `CUSTOM_FIELD_UPLOAD`. | `SUB_DOCUMENT` | ### Sample Request ```json { "fileName": "loan-agreement.pdf", "mediaType": "SUB_DOCUMENT" } ``` --- ## Responses ### 200 — Pre-signed upload URL generated. Upload your file to `data.presignedUrl` within 15 minutes, then use `data.mediaId` when creating a pack. | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `code` | string | No | Result code. `SUCCESS` when the pre-signed URL was generated. | `SUCCESS` | | `message` | string | No | Human-readable status message. | `Pre-signed URL generated` | | `data` | MediaUploadResponse | No | See **MediaUploadResponse** below. | — | #### MediaUploadResponse | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `mediaId` | string | No | Unique ID for the file. Use this value in any `file` field when creating a pack. | `550e8400-e29b-41d4-a716-446655440000` | | `presignedUrl` | string | No | Pre-signed URL to upload your file to. Valid for **15 minutes**. | `https://uploads.leegality.com/document-infrastructure/media/` | | `expiresAt` | string | No | When the pre-signed upload URL expires (15 minutes after it is generated). | `2026-08-21T10:45:00Z` | | `mediaRetentionExpiresAt` | string | No | How long the `mediaId` stays valid (1 day). You can use this `mediaId` when creating a pack until this time. | `2026-08-22T10:30:00Z` | ### Sample Response (200) ```json { "code": "SUCCESS", "message": "Pre-signed URL generated", "data": { "mediaId": "550e8400-e29b-41d4-a716-446655440000", "presignedUrl": "https://uploads.leegality.com/document-infrastructure/media/550e8400-e29b-41d4-a716-446655440000?X-Amz-Signature=…", "expiresAt": "2026-08-21T10:45:00Z", "mediaRetentionExpiresAt": "2026-08-22T10:30:00Z" } } ``` --- URL: https://knowledge.leegality.com/document-execution/api/create-pack-sync # POST /v4/pack/sync — Send Pack for eSigning (Sync) :::info[Sandbox endpoint] **Authentication:** `X-Auth-Token` header required on every request. ## Request URL ``` POST https://app1.leegality.com/api/v4/pack/sync ``` **Environments:** - Production: `https://app1.leegality.com/api/v4/pack/sync` - Sandbox: `https://sandbox.leegality.com/api/v4/pack/sync` --- ## Request Body **Content-Type:** `application/json` Request body for the synchronous send-pack API. Same structure as the async **Send Pack for eSigning (Async)** request, except each file is provided directly as **base64-encoded content** in a `file` field (instead of a pre-uploaded `mediaId`). | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `workflowId` | string | Yes | ID of the published Workflow to execute. The pack is created and sent according to this Workflow's configuration. The dashboard shows a short form of this ID (for example, `70843c25`); to get the full value, [download the workflow's API payload](https://knowledge.leegality.com/document-execution/api/download-v4-api-payload) from the dashboard. **Required.** | `70843c25-8d80-40ac-ab6b-edba12abd495` | | `pack` | object | Yes | Pack-level details: metadata, custom fields, and `signingOrder`. The pack is the top-level container for all primary documents sent together in one run. **Required.** See **pack** below. | — | | `documents` | array\ | Yes | Primary documents in the pack, each with its sub-documents, stamps, and attachments. Each primary document is signed independently. **Required.** See **documents** below. | — | | `invitees` | array\ | Yes | Configure invitee details. See **invitees** below. | — | | `cc` | array\ | No | CC recipients — a top-level sibling of `invitees`. CC recipients receive notifications but do not sign or review. See **cc** below. | — | | `coordinates` | array\ | No | Signature placement. **Optional** — the backend resolves placement from the workflow config when omitted. Each entry positions one invitee's signature appearance(s). See **coordinates** below. | — | #### pack Pack-level details: metadata, custom fields, and `signingOrder`. The pack is the top-level container for all primary documents sent together in one run. **Required.** | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `packName` | string | Yes | Display name for the pack, shown to invitees and in the dashboard. **Required.** - Max 255 characters. - Allowed characters: letters, digits, spaces, and `+ @ \| - : ( ) , _ . [ ] & /`. | `Home Loan Agreement - Rajesh Kumar` | | `packIrn` | string | No | Your Internal Reference Number for the pack (for compliance/reconciliation against your own records). | `IRN-2026-001234` | | `packUrn` | string | No | Your Unique Reference Number for the pack. Must be unique within your account — you can't create two packs with the same URN. | `21312313131` | | `packFolderId` | string | No | ID of the folder where you want to keep the pack. You'll find it in your Leegality Dashboard's Folder section on the left. | `K4wFolder` | | `deleteOnComplete` | boolean | No | Set to `true` to automatically delete the pack's documents from Leegality once the pack is completed. | `false` | | `sftpProfileId` | string | No | ID (UUID) of a pre-configured SFTP profile to which signed files are delivered on completion. | `07aba168-b55b-4889-bddf-9012fa853e61` | | `brandingProfileId` | string | No | ID of a branding profile that controls the look and feel (logo, colours) of the signing journey. | `branding-001` | | `lecf_loanId` | string | No | Custom field at pack level. `lecf_`-prefixed fields are available **only if the corresponding custom fields have been added to the Workflow** (they cannot be added at runtime). Example shown is a loan ID. | `LOAN-2026-5678` | | `lecf_branchCode` | string | No | Custom field at pack level. `lecf_`-prefixed fields are available **only if the corresponding custom fields have been added to the Workflow**. Example shown is a branch code. | `MUM-001` | | `signingOrder` | object | No | Signing-order settings. Must live **inside** `pack`. See **signingOrder** below. | — | ##### signingOrder Signing-order settings. Must live **inside** `pack`. | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `setSigningOrder` | boolean | Yes | Whether signing order is enforced. When `true`, level ordering (`level`) is enforced; when `false`, all invitees are active in parallel. **Required** within `signingOrder`. | `true` | | `preventChangesToSigningOrder` | boolean | No | Set to `true` to lock the signing order so it cannot be changed after sending (also blocks out-of-order activation). Default: `false`. | `false` | | `setAdvanceSigningOrder` | boolean | No | Set to `true` to enable advanced signing order. | `false` | #### documents | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `uuid` | string | Yes | Unique ID (UUID v4) for this document. Leegality generates it if the document is already configured in the workflow. If the workflow creator allows adding documents and you add one while sending, generate a new UUID v4 yourself. Other items refer to this document by `documentUuid`. | `711abfff-2057-48ac-909e-519f3f7415a4` | | `documentName` | string | Yes | Display name of the primary document. **Required.** | `Loan Agreement` | | `irn` | string | No | Document-level Internal Reference Number. | `DOC-IRN-001` | | `documentFolderId` | string | No | ID of the folder where you want to keep this document. You'll find it in your Leegality Dashboard's Folder section on the left. | `K4wKEBB` | | `subDocuments` | array\ | Yes | Sub-documents that make up this primary document. Each is an individual file (or a template) combined into the single primary document the invitee signs. **Required.** To leave a sub-document out of the pack, don't add its object to this array. See **subDocuments** below. | — | | `stamps` | object | No | Document-level stamp configuration (stamps applied at the primary-document scope). Turned on by the master `enableStamp` flag, with each subtype turned on by its own `enable…` flag. See **stamps** below. | — | | `referenceAttachment` | object | No | Reference attachments shown to invitees alongside the document for context (not signed). See **referenceAttachment** below. | — | | `lecf_documentCategory` | string | No | Custom field at document level. `lecf_`-prefixed fields are available **only if the corresponding custom fields have been added to the Workflow**. Example shown is a document category. | `CONTRACT` | ##### subDocuments | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `uuid` | string | Yes | Unique ID (UUID v4) for this sub-document. Leegality generates it if the sub-document is already configured in the workflow. If the workflow creator allows adding sub-documents and you add one while sending, generate a new UUID v4 yourself. Other items refer to this sub-document by `subDocumentUuid`. | `795df69d-12c9-4959-be9a-9a73a2e1dd30` | | `templateId` | string | No | ID of the template to use for this sub-document. **Required when the sub-document is a template** (instead of `mediaId`). | `tpl_mapping_abc123` | | `templateVersion` | string | No | Version of the template to use, for example `1.0`. Applies when the sub-document is a template. | `1.0` | | `allowFirstInviteeToFill` | boolean | No | Set to `true` to let the first invitee fill the template fields during signing instead of pre-filling them via the API. | `true` | | `templateFieldValues` | array\ | No | Values used to pre-fill the template's fields. Each entry is `{ fieldId, fieldValue, fieldName }`. Applies when the sub-document is a template. If a template has grouped fields, pass only one value per group for `text`, `textarea`, and `number` field types — it will auto-populate every template form field in the same group. See **templateFieldValues** below. | — | | `enableRevenueStamp` | boolean | No | Set to `true` to apply a revenue stamp (provide `revenueStamp`). When `false`, any `revenueStamp` sent in the request is ignored. When `true`, a valid `revenueStamp` is required. | `true` | | `revenueStamp` | object | No | Revenue stamp configuration. Active when `enableRevenueStamp = true`. Can be used together with `stampSeries` or `stampGroup`, but not with `stampUpload`. See **revenueStamp** below. | — | | `enableStampSeries` | boolean | No | Set to `true` to stamp from a stamp series (provide the `stampSeries` array). When `false`, any `stampSeries` sent in the request is ignored. When `true`, a valid `stampSeries` is required. | `true` | | `stampSeries` | array\ | No | Attach stamps from one or more stamp series. Active when `enableStampSeries = true`. Each entry takes a stamp series number (`stampSeriesId`) and how many stamps to use from it (`stampQuantities`). Works together with `stampGroup`, but not with `stampUpload`. See **stampSeries** below. | — | | `enableStampUpload` | boolean | No | Set to `true` to use an uploaded stamp paper (provide `stampUpload`). When `false`, any `stampUpload` sent in the request is ignored. When `true`, a valid `stampUpload` is required. | `true` | | `stampUpload` | object | No | Uploaded stamp-paper configuration. Active when `enableStampUpload = true`. Cannot be used with any other stamp type. When `stampUpload` is provided, `stampUploadedFile` and its `file` are required. See **stampUpload** below. | — | | `enableStampGroup` | boolean | No | Set to `true` to stamp from a stamp group (provide `stampGroup`). When `false`, any `stampGroup` sent in the request is ignored. When `true`, a valid `stampGroup` is required. | `true` | | `stampGroup` | object | No | eStamp from a stamp group. Active when `enableStampGroup = true`. Can be used together with `stampSeries`, but not with `stampUpload`. See **stampGroup** below. | — | | `file` | string | No | A media ID (from the [Upload media API](https://knowledge.leegality.com/document-execution/api/upload-media)) or the file's base64-encoded content. Allowed format: PDF. **Required for non-template sub-documents.** | `JVBERi0xLjQKJeLjz9MK…(base64-encoded file)` | ###### templateFieldValues | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `fieldId` | string | No | ID of the template field to fill. The server identifies the field by `fieldId`. | `f1a23456-78bc-4def-9012-3456789abcde` | | `fieldValue` | string | No | Value to insert into the template field. For a `file`-type field, pass a `mediaId` (from the [Upload media API](https://knowledge.leegality.com/document-execution/api/upload-media), uploaded with `mediaType: TEMPLATE_FILE_TYPE_FIELD`) or the file's base64-encoded content. | `Rajesh Kumar` | | `fieldName` | string | No | Human-readable field name. **Informational only** — the server identifies the field by `fieldId`; `fieldName` is not used for processing. | `borrower name` | ###### revenueStamp Revenue stamp configuration. Active when `enableRevenueStamp = true`. Can be used together with `stampSeries` or `stampGroup`, but not with `stampUpload`. | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `revenueStampQuantity` | integer | No | Number of revenue stamps to attach. | `1` | | `revenueStampId` | string | No | ID of the revenue stamp to use. | `10` | ###### stampSeries | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `uuid` | string | Yes | Unique ID (UUID v4) for this stamp-series entry. Leegality generates it if the stamp-series entry is already configured in the workflow. If the workflow creator allows adding stamp-series entries and you add one while sending, generate a new UUID v4 yourself. Required whenever a `stampSeries` entry is included. | `0a1b2c3d-4e5f-4abc-8def-0123456789ab` | | `stampSeriesId` | string | No | Stamp Series Number. | `01` | | `stampQuantities` | integer | No | Number of stamps you want to attach. | `1` | ###### stampUpload Uploaded stamp-paper configuration. Active when `enableStampUpload = true`. Cannot be used with any other stamp type. When `stampUpload` is provided, `stampUploadedFile` and its `file` are required. | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `stampUploadState` | string | No | State code the stamp paper was purchased in (for example, `PB`). | `PB` | | `stampUploadedFile` | object | No | The uploaded stamp-paper file. See **stampUploadedFile** below. | — | | `stampUploadDenomination` | integer | No | Face value (denomination) of the uploaded stamp paper. | `100` | | `stampUploadFirstPartyName` | string | No | First party name printed on the stamp paper. | `John Doe` | | `stampUploadSecondPartyName` | string | No | Second party name printed on the stamp paper. | `Jane Smith` | | `stampUploadSerialNumber` | string | No | Serial number of the uploaded stamp paper. | `123` | ###### stampUploadedFile The uploaded stamp-paper file. | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `file` | string | No | A media ID (from the [Upload media API](https://knowledge.leegality.com/document-execution/api/upload-media)) or the file's base64-encoded content. Allowed format: PDF. | `JVBERi0xLjQKJeLjz9MK…(base64-encoded file)` | ###### stampGroup eStamp from a stamp group. Active when `enableStampGroup = true`. Can be used together with `stampSeries`, but not with `stampUpload`. | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `stampGroupId` | string | No | ID of the stamp group to use. | `PB01` | | `stampGroupAmount` | integer | No | Stamp duty amount you want to attach. | `1` | ##### stamps Document-level stamp configuration (stamps applied at the primary-document scope). Turned on by the master `enableStamp` flag, with each subtype turned on by its own `enable…` flag. | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `enableStamp` | boolean | No | Set to `true` to enable stamping for this document; controls both document-level and sub-document-level stamps. A subtype is applied only when its own `enable…` flag is also `true` with valid config. A document can use **either** document-level stamping **or** sub-document-level stamping — both cannot be enabled together. When `false`, no stamps are applied to this document; any stamp config sent is ignored. When `true`, at least one stamp subtype must be enabled with valid config. | `true` | | `enableRevenueStamp` | boolean | No | Set to `true` to apply a revenue stamp (provide `revenueStamp`). When `false`, any `revenueStamp` sent in the request is ignored. When `true`, a valid `revenueStamp` is required. | `true` | | `revenueStamp` | object | No | Revenue stamp configuration. Active when `enableRevenueStamp = true`. Can be used together with `stampSeries` or `stampGroup`, but not with `stampUpload`. See **revenueStamp** below. | — | | `enableStampSeries` | boolean | No | Set to `true` to stamp from a stamp series (provide the `stampSeries` array). When `false`, any `stampSeries` sent in the request is ignored. When `true`, a valid `stampSeries` is required. | `true` | | `stampSeries` | array\ | No | Attach stamps from one or more stamp series. Active when `enableStampSeries = true`. Each entry takes a stamp series number (`stampSeriesId`) and how many stamps to use from it (`stampQuantities`). Works together with `stampGroup`, but not with `stampUpload`. See **stampSeries** below. | — | | `enableStampGroup` | boolean | No | Set to `true` to stamp from a stamp group (provide `stampGroup`). When `false`, any `stampGroup` sent in the request is ignored. When `true`, a valid `stampGroup` is required. | `true` | | `stampGroup` | object | No | eStamp from a stamp group. Active when `enableStampGroup = true`. Can be used together with `stampSeries`, but not with `stampUpload`. See **stampGroup** below. | — | | `enableStampUpload` | boolean | No | Set to `true` to use an uploaded stamp paper (provide `stampUpload`). When `false`, any `stampUpload` sent in the request is ignored. When `true`, a valid `stampUpload` is required. | `true` | | `stampUpload` | object | No | Uploaded stamp-paper configuration. Active when `enableStampUpload = true`. Cannot be used with any other stamp type. When `stampUpload` is provided, `stampUploadedFile` and its `file` are required. See **stampUpload** below. | — | ###### revenueStamp Revenue stamp configuration. Active when `enableRevenueStamp = true`. Can be used together with `stampSeries` or `stampGroup`, but not with `stampUpload`. | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `revenueStampQuantity` | integer | No | Number of revenue stamps to attach. | `1` | | `revenueStampId` | string | No | ID of the revenue stamp to use. | `10` | ###### stampSeries | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `uuid` | string | Yes | Unique ID (UUID v4) for this stamp-series entry. Leegality generates it if the stamp-series entry is already configured in the workflow. If the workflow creator allows adding stamp-series entries and you add one while sending, generate a new UUID v4 yourself. Required whenever a `stampSeries` entry is included. | `1a2b3c4d-5e6f-4a7b-8c9d-0e1f2a3b4c5e` | | `stampSeriesId` | string | No | Stamp Series Number. | `01` | | `stampQuantities` | integer | No | Number of stamps you want to attach. | `1` | ###### stampGroup eStamp from a stamp group. Active when `enableStampGroup = true`. Can be used together with `stampSeries`, but not with `stampUpload`. | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `stampGroupId` | string | No | ID of the stamp group to use. | `PB01` | | `stampGroupAmount` | integer | No | Stamp duty amount you want to attach. | `10` | ###### stampUpload Uploaded stamp-paper configuration. Active when `enableStampUpload = true`. Cannot be used with any other stamp type. When `stampUpload` is provided, `stampUploadedFile` and its `file` are required. | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `stampUploadSerialNumber` | string | No | Serial number of the uploaded stamp paper. | `SERIAL001` | | `stampUploadFirstPartyName` | string | No | First party name printed on the stamp paper. | `Alice` | | `stampUploadDenomination` | integer | No | Face value (denomination) of the uploaded stamp paper. | `100` | | `stampUploadedFile` | object | No | The uploaded stamp-paper file. See **stampUploadedFile** below. | — | | `stampUploadState` | string | No | State code the stamp paper was purchased in (for example, `PB`). | `PB` | | `stampUploadSecondPartyName` | string | No | Second party name printed on the stamp paper. | `Bob` | ###### stampUploadedFile The uploaded stamp-paper file. | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `file` | string | No | A media ID (from the [Upload media API](https://knowledge.leegality.com/document-execution/api/upload-media)) or the file's base64-encoded content. Allowed format: PDF. | `JVBERi0xLjQKJeLjz9MK…(base64-encoded file)` | ##### referenceAttachment Reference attachments shown to invitees alongside the document for context (not signed). | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `enableReferenceAttachment` | boolean | No | Set to `true` to attach reference files (provide `referenceAttachmentFiles`). When `false`, any `referenceAttachmentFiles` sent in the request is ignored. When `true`, a valid `referenceAttachmentFiles` is required. | `true` | | `referenceAttachmentFiles` | array\ | No | Files to attach for reference. Each entry is `{ uuid, mediaId, fileName }`. See **referenceAttachmentFiles** below. | — | ###### referenceAttachmentFiles | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `uuid` | string | Yes | Unique ID (UUID v4) for this reference attachment. Leegality generates it if the reference attachment is already configured in the workflow. If the workflow creator allows adding reference attachments and you add one while sending, generate a new UUID v4 yourself. | `23c96e97-813a-4a6c-9c37-e939f54d597d` | | `file` | string | Yes | A media ID (from the [Upload media API](https://knowledge.leegality.com/document-execution/api/upload-media)) or the file's base64-encoded content. Allowed formats: PDF, PNG, JPEG, JPG. | `JVBERi0xLjQKJeLjz9MK…(base64-encoded file)` | #### invitees | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `uuid` | string | Yes | Unique ID (UUID v4) for this invitee. Leegality generates it if the invitee is already configured in the workflow. If the workflow creator allows adding invitees and you add one while sending, generate a new UUID v4 yourself. Other items refer to this invitee by `inviteeUuid`. | `8bc21487-b200-4130-8240-a5f1715244dc` | | `type` | string | Yes | Type of invitee. One of `signer`, `reviewer`, `groupSigner`, `groupReviewer`. Only `signer` and `groupSigner` receive sign coordinates; reviewers and group reviewers never do. **Required.** | `signer` | | `level` | integer | Yes | Signing-order level (1 = first). Enforced only when `pack.signingOrder.setSigningOrder = true`; invitees at the same level act in parallel, and the next level unlocks when the current level is satisfied. **Required.** | `1` | | `groupName` | string | No | Name of the invitee group. **Required for `groupSigner` / `groupReviewer`**; leave empty for an individual invitee. | `` | | `groupThreshold` | integer | No | Minimum number of group members that must complete the action for the group's part to be satisfied. **Required for `groupSigner` / `groupReviewer`.** | `2` | | `inviteeDetails` | array\ | Yes | The person(s) for this invitee. A single entry for an individual; multiple entries for `groupSigner` / `groupReviewer`. **Required.** See **inviteeDetails** below. | — | | `inviteeSettings` | object | No | Per-person (invitee-level) settings: security, interaction options, notifications, contact book, certificate verification, and reviewer settings. These apply to the person regardless of which documents they sign. See **inviteeSettings** below. | — | | `combinations` | array\ | Yes | Document assignments for this invitee. Each combination assigns one or more documents (with a role) and defines the eSign/experience settings for that document group. Always an array, even for a single combination. **Required.** See **combinations** below. | — | | `lecf_customerId` | string | No | Custom field at invitee level. `lecf_`-prefixed fields are available **only if the corresponding custom fields have been added to the Workflow**. Example shown is a customer ID. | `CUST-8842` | ##### inviteeDetails | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `uuid` | string | Yes | Unique ID (UUID v4) for this recipient. Leegality generates it if the recipient is already configured in the workflow. If the workflow creator allows adding recipients and you add one while sending, generate a new UUID v4 yourself. | `1aa11111-1111-4111-8111-111111111111` | | `inviteeName` | string | Yes | Full name of the person. **Required.** | `Rajesh Kumar` | | `inviteeLabel` | string | No | A label for this invitee. | `borrower` | | `inviteeEmail` | string | No | Email address. **Required if email notifications are enabled.** | `rajesh@example.com` | | `inviteePhone` | string | No | The invitee's 10-digit phone number. **Required if SMS/WhatsApp notifications are enabled.** | `9820000001` | | `enableWhatsAppMandatoryNotifications` | boolean | No | Set to `true` to send mandatory notifications to this invitee over WhatsApp only. | `false` | | `lecf_employeeCode` | string | No | Custom field at the invitee-details (per-person) level. `lecf_`-prefixed fields are available **only if the corresponding custom fields have been added to the Workflow**. Example shown is an employee code. | `EMP-00921` | ##### inviteeSettings Per-person (invitee-level) settings: security, interaction options, notifications, contact book, certificate verification, and reviewer settings. These apply to the person regardless of which documents they sign. | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `securityOptions` | object | No | Security controls applied to the invitee: authentication, GPS, face capture/match, OTP download link, and contact masking. See **securityOptions** below. | — | | `manageInviteInteractions` | object | No | How the invitee interacts with the signing journey: supporting documents, base/redirect URLs, rejection, custom message, and local language. See **manageInviteInteractions** below. | — | | `notifications` | object | No | Notification channel preferences for this invitee. See **notifications** below. | — | | `contactBook` | object | No | Whether to save this invitee to your account's contact book. See **contactBook** below. | — | | `certificateVerification` | object | No | Certificate-verification config performed against the invitee: Aadhaar, cloud-DSC, and DSC checks. Each enabled check must match for the signature to be accepted. See **certificateVerification** below. | — | | `reviewer` | object | No | Settings that apply when the invitee is a reviewer. See **reviewer** below. | — | ###### securityOptions Security controls applied to the invitee: authentication, GPS, face capture/match, OTP download link, and contact masking. | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `oneFactorAuthentication` | boolean | No | Set to `true` to require single-factor authentication before the invitee can access the document. | `false` | | `twoFactorAuthentication` | boolean | No | Set to `true` to require two-factor authentication before the invitee can access the document. | `true` | | `gps` | object | No | Configure geofencing details. See **gps** below. | — | | `faceCapture` | object | No | Configure face capture and liveliness details. See **faceCapture** below. | — | | `docDownloadLinkWithOtp` | boolean | No | Set to `true` to protect the signed-document download link with an OTP. | `false` | | `maskContactDetails` | boolean | No | Set to `true` to mask the invitee's contact details. | `false` | ###### gps Configure geofencing details. | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `enabled` | boolean | No | Set to `true` to capture the signer's location during signing. When `false`, leave the other `gps` fields empty. | `true` | | `accuracyBasedRestriction` | boolean | No | Set to `true` to block signing when the device's location accuracy is worse than `accuracyThreshold`. | `true` | | `accuracyThreshold` | integer | No | Maximum acceptable location-accuracy value (metres). Applies when `accuracyBasedRestriction` is `true`. | `12` | | `locationBasedRestriction` | boolean | No | Set to `true` to restrict signing to within `permissibleRadius` of the point defined by `latitude`/`longitude`. | `true` | | `latitude` | number | No | Latitude of the allowed signing location. Applies when `locationBasedRestriction` / `enableLatLngRadius` is `true`. | `23.34` | | `longitude` | number | No | Longitude of the allowed signing location. Applies when `locationBasedRestriction` / `enableLatLngRadius` is `true`. | `72.88` | | `permissibleRadius` | integer | No | Radius (metres) around the allowed location within which signing is permitted. | `100` | | `restrictToIndia` | boolean | No | Set to `true` to allow signing only from within India. | `true` | | `enableLatLngRadius` | boolean | No | Set to `true` to enable the latitude/longitude/radius restriction. | `true` | ###### faceCapture Configure face capture and liveliness details. | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `enabled` | boolean | No | Set to `true` to enable face capture in the signing journey. When `false`, leave all other `faceCapture` fields empty. | `true` | | `liveliness` | boolean | No | Set to `true` to require a liveliness check during face capture. | `true` | | `match` | boolean | No | Set to `true` to match the captured face against the reference image(s) in `faceMatch`. | `true` | | `faceMatchRetryAttempts` | integer | No | Number of retry attempts allowed for the face-match check (set at the `faceCapture` level). | `2` | | `faceMatch` | array\ | No | Reference image(s) the captured face is matched against. Each entry carries its own `uuid` and a nested `faceMatchImage`. See **faceMatch** below. | — | | `livelinessRetryAttempts` | integer | No | Number of retry attempts allowed for the smart liveliness check. | `3` | ###### faceMatch | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `uuid` | string | Yes | Unique ID (UUID v4) for this face-match entry. Leegality generates it if the face-match entry is already configured in the workflow. If the workflow creator allows adding face-match entries and you add one while sending, generate a new UUID v4 yourself. This is the face-match entry's own ID, not the image's `mediaId`. | `3a333333-3333-4333-8333-333333333333` | | `faceMatchImage` | object | No | The reference face image the rule matches against. | — | ###### manageInviteInteractions How the invitee interacts with the signing journey: supporting documents, base/redirect URLs, rejection, custom message, and local language. | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `enableSupportingDocs` | boolean | No | Set to `true` to require supporting documents (provide `supportingDocumentConfig`). When `false`, any `supportingDocumentConfig` sent in the request is ignored. When `true`, a valid `supportingDocumentConfig` is required. | `true` | | `supportingDocumentConfig` | object | No | Supporting documents the invitee must upload. Active when `enableSupportingDocs = true`. See **supportingDocumentConfig** below. | — | | `baseUrl` | string | No | Base URL for the signing journey. | `https://client.example.com/sign` | | `redirectUrl` | string | No | URL the invitee is redirected to after completing signing. | `https://client.example.com/sign/complete` | | `enableRejection` | boolean | No | Set to `true` to allow the invitee to reject the document. | `true` | | `enforceRejectionMessage` | boolean | No | Set to `true` to require the invitee to enter a message when rejecting. Send it only alongside `enableRejection` set to `true`. | `false` | | `enableCustomMessage` | boolean | No | Set to `true` to show a custom message (provide `customMessageInput`). When `false`, any `customMessageInput` sent in the request is ignored. When `true`, a valid `customMessageInput` is required. | `true` | | `customMessageInput` | string | No | Custom message shown to the invitee. Active when `enableCustomMessage = true`. | `Please review and sign the loan agreement.` | | `enableLocalLanguage` | boolean | No | Set to `true` to offer the signing journey in a local language (provide `languageDefaultVsSignerSelect` and `localLanguageChooseDefault`). When `false`, the `languageDefaultVsSignerSelect` and `localLanguageChooseDefault` values sent are ignored. When `true`, `languageDefaultVsSignerSelect` and `localLanguageChooseDefault` are required. | `true` | | `languageDefaultVsSignerSelect` | string | No | Whether the language is fixed by you (`default`) or chosen by the signer (`signer-select`). Present when `enableLocalLanguage = true`. | `default` | | `localLanguageChooseDefault` | string | No | Default local-language code (for example, `hi`) when `languageDefaultVsSignerSelect = default`. | `hi` | ###### supportingDocumentConfig Supporting documents the invitee must upload. Active when `enableSupportingDocs = true`. | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `supportingDocuments` | array\ | No | List of supporting documents requested. Each entry is `{ uuid, supportingDocName, supportingDocFormat, supportingDocSize }`. See **supportingDocuments** below. | — | | `allowViewingSupportingDocs` | boolean | No | Set to `true` to let the pack's other invitees view the supporting documents this invitee uploads. Applies when you request supporting documents from this invitee. | `true` | ###### supportingDocuments | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `uuid` | string | Yes | Unique ID (UUID v4) for this supporting-document requirement. Leegality generates it if the supporting-document requirement is already configured in the workflow. If the workflow creator allows adding supporting-document requirements and you add one while sending, generate a new UUID v4 yourself. | `2a222222-2222-4222-8222-222222222222` | | `supportingDocName` | string | No | Name of the supporting document requested (for example, `ID Proof`). | `ID Proof` | | `supportingDocFormat` | string | No | Allowed file format for the supporting document (for example, `PDF`). | `PDF` | | `supportingDocSize` | integer | No | Declared size of the supporting document (bytes). | `2048` | ###### notifications Notification channel preferences for this invitee. | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `enableSmsNotifications` | boolean | No | Set to `true` to send SMS notifications to the invitee. | `true` | | `enableEmailNotifications` | boolean | No | Set to `true` to send email notifications to the invitee. | `true` | | `enableWhatsAppNotifications` | boolean | No | Set to `true` to send WhatsApp notifications to the invitee. | `false` | ###### contactBook Whether to save this invitee to your account's contact book. | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `addInviteeToContactBook` | boolean | No | Set to `true` to add the invitee to the [contact book](https://knowledge.leegality.com/document-execution/contact-book) for reuse. | `true` | | `inviteeLabel` | string | No | Label to tag the contact with (for example, `borrower`). | `borrower` | ###### certificateVerification Certificate-verification config performed against the invitee: Aadhaar, cloud-DSC, and DSC checks. Each enabled check must match for the signature to be accepted. | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `aadhaarVerifyCertificateDetails` | array\ | No | Aadhaar eSign certificate details verification. Each object maps to an invitee by index position. An object is always present for each invitee even if all verification fields are non-editable — in that case, only `uuid` is included. See **aadhaarVerifyCertificateDetails** below. | — | | `cloudDscVerifyCertificateDetails` | array\ | No | Cloud DSC (Cloud Digital Signature Certificate) details verification. See **cloudDscVerifyCertificateDetails** below. | — | | `dscVerifyCertificateDetails` | array\ | No | DSC (Digital Signature Certificate) details verification. Each object maps to an invitee by index position. An object is always present for each invitee even if all verification fields are non-editable — in that case, only `uuid` is included. See **dscVerifyCertificateDetails** below. | — | ###### aadhaarVerifyCertificateDetails | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `uuid` | string | No | Unique identifier for this certificate verification object. Always present, even when all other fields are non-editable. | `a1b2c3d4-5678-4abc-9def-012345678901` | | `aadhaarVerifyName` | boolean | No | Set to `true` to verify the signer's name against the Aadhaar record. | `false` | | `aadhaarSmartNameVerify` | boolean | No | Set to `true` to allow AI-based Smart name verification. | `false` | | `aadhaarVerifyYob` | string | No | Enter the year of birth that will be verified against the Aadhaar record (for example, `1997`). | `1997` | | `aadhaarVerifyState` | string | No | Enter the state that will be verified against the Aadhaar record. | `bihar` | | `aadhaarVerifyTitle` | string | No | Enter the last 4 digits of the signer's Aadhaar number that will be verified. | `3046` | | `aadhaarVerifyPincode` | integer | No | Enter the 6-digit pincode that will be verified against the Aadhaar record. | `845446` | | `aadhaarVerifyGender` | string | No | Enter the gender that will be verified against the Aadhaar record (`M` or `F`). | `M` | ###### cloudDscVerifyCertificateDetails | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `cloudDscVerifyName` | boolean | No | Set to `true` to verify the signer's name against the cloud DSC. | `true` | | `cloudDscSmartNameVerify` | boolean | No | Set to `true` to allow AI-based Smart name verification. | `false` | | `cloudDscVerifyState` | string | No | Enter the state that will be verified against the cloud DSC. | `Maharashtra` | | `cloudDscVerifyPincode` | integer | No | Enter the pincode that will be verified against the cloud DSC. | `400001` | ###### dscVerifyCertificateDetails | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `uuid` | string | No | Unique identifier for this certificate verification object. Always present, even when all other fields are non-editable. | `b2c3d4e5-6789-4abc-8def-123456789012` | | `dscVerifyName` | boolean | No | Set to `true` to verify the signer's name against the DSC. | `false` | | `dscSmartNameVerify` | boolean | No | Set to `true` to allow AI-based Smart name verification. | `false` | | `dscVerifyPincode` | integer | No | Enter the pincode that will be verified against the DSC. | `845449` | | `dscVerifyState` | string | No | Enter the state that will be verified against the DSC. | `bihar` | ###### reviewer Settings that apply when the invitee is a reviewer. | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `enableAuditTrail` | boolean | No | Set to `true` to include the reviewer's actions in the audit trail. | `true` | | `enableOtpForReview` | boolean | No | Set to `true` to require the reviewer to enter an OTP before reviewing. | `false` | ##### combinations | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `uuid` | string | Yes | Unique ID (UUID v4) for this combination. Leegality generates it if the combination is already configured in the workflow. If the workflow creator allows adding combinations and you add one while sending, generate a new UUID v4 yourself. Other items refer to this combination by `combinationUuid`. | `29bdb6fd-99a9-4501-b74b-d482d7ad5062` | | `assignedDocuments` | array\ | Yes | Documents assigned to the invitee in this combination. **Required.** See **assignedDocuments** below. | — | | `combinationSettings` | object | Yes | Per-combination (document-group scope) settings: eSign types, prioritisation, appearance, webhooks, consent, expiry, and payment. **Required.** See **combinationSettings** below. | — | ###### assignedDocuments | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `uuid` | string | Yes | Unique ID (UUID v4) for this assigned-document entry. Leegality generates it if the assigned-document entry is already configured in the workflow. If the workflow creator allows adding assigned-document entries and you add one while sending, generate a new UUID v4 yourself. | `cd7c1c46-af20-4452-9f6c-ca507705a8b9` | | `documentUuid` | string | Yes | Reference to a document. Must match the `uuid` of a document (`documents[]`) included in this same request. **Required.** | `711abfff-2057-48ac-909e-519f3f7415a4` | | `role` | string | Yes | Role the invitee plays on the assigned document. One of `signer`, `reviewer`. **Required.** | `signer` | ###### combinationSettings Per-combination (document-group scope) settings: eSign types, prioritisation, appearance, webhooks, consent, expiry, and payment. **Required.** | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `esignTypes` | object | No | Available eSign methods for this combination. Each type has its own `enable…` flag; a type is active only when that flag is `true`. **Required.** See **esignTypes** below. | — | | `eSignPrioritisation` | object | No | Priority order and retry policy across eSign methods, so signing can fall back from one method to the next. See **eSignPrioritisation** below. | — | | `signatureAppearance` | object | No | How the signature block looks on the document. See **signatureAppearance** below. | — | | `webhooks` | object | No | Per-combination webhook configuration. Omitting `webhooks` means no webhooks fire for this combination. See **webhooks** below. | — | | `customConsent` | object | No | Custom consent settings. See **customConsent** below. | — | | `expiry` | object | No | Invitation expiry settings. See **expiry** below. | — | | `paymentCollect` | object | No | Payment collection settings. Active when `enablePaymentCollect = true`. See **paymentCollect** below. | — | ###### esignTypes Available eSign methods for this combination. Each type has its own `enable…` flag; a type is active only when that flag is `true`. **Required.** | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `aadharEsign` | object | No | Aadhaar-based eSign. See **aadharEsign** below. | — | | `automatedEsign` | object | No | Automated (system) eSign using a pre-configured signing profile. See **automatedEsign** below. | — | | `quickSign` | object | No | Quick eSign (electronic signature, without PKI). See **quickSign** below. | — | | `visualSign` | object | No | Visual eSign (electronic signature with a visible appearance). See **visualSign** below. | — | | `virtualEsign` | object | No | Virtual eSign. See **virtualEsign** below. | — | | `dscToken` | object | No | DSC token-based signing (hardware Digital Signature Certificate). See **dscToken** below. | — | | `docSign` | object | No | DocSigner-based signing. See **docSign** below. | — | | `cloudDsc` | object | No | Cloud DSC-based signing. See **cloudDsc** below. | — | ###### aadharEsign Aadhaar-based eSign. | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `aadharEsignEnabled` | boolean | No | Set to `true` to allow Aadhaar eSign, then configure `aadhaarEsignConfig`. When `false`, any `aadhaarEsignConfig` sent in the request is ignored. When `true`, a valid `aadhaarEsignConfig` is required. | `true` | | `aadhaarEsignConfig` | object | No | Aadhaar eSign options. | — | ###### automatedEsign Automated (system) eSign using a pre-configured signing profile. | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `enableAutomatedSign` | boolean | No | Set to `true` to allow automated signing, then configure `automatedSignConfig`. When `false`, any `automatedSignConfig` sent in the request is ignored. When `true`, a valid `automatedSignConfig` is required. | `true` | | `automatedSignConfig` | object | No | Automated signing options. | — | ###### quickSign Quick eSign (electronic signature, without PKI). | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `enableQuickSign` | boolean | No | Set to `true` to allow Quick eSign, then configure `quickSignConfig`. When `false`, any `quickSignConfig` sent in the request is ignored. When `true`, a valid `quickSignConfig` is required. | `true` | | `quickSignConfig` | object | No | Quick eSign options. | — | ###### visualSign Visual eSign (electronic signature with a visible appearance). | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `enableVisualSign` | boolean | No | Set to `true` to allow Visual eSign, then configure `visualSignConfig`. When `false`, any `visualSignConfig` sent in the request is ignored. When `true`, a valid `visualSignConfig` is required. | `true` | | `visualSignConfig` | object | No | Visual eSign options. | — | ###### virtualEsign Virtual eSign. | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `virtualEsignEnabled` | boolean | No | Set to `true` to allow Virtual eSign, then configure `virtualEsignConfig`. When `false`, any `virtualEsignConfig` sent in the request is ignored. When `true`, a valid `virtualEsignConfig` is required. | `true` | | `virtualEsignConfig` | object | No | Virtual eSign options. | — | ###### dscToken DSC token-based signing (hardware Digital Signature Certificate). | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `enableDscToken` | boolean | No | Set to `true` to allow signing with a DSC token. | `true` | ###### docSign DocSigner-based signing. | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `enableDocSigner` | boolean | No | Set to `true` to allow signing via DocSigner. | `true` | ###### cloudDsc Cloud DSC-based signing. | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `enableCloudDsc` | boolean | No | Set to `true` to allow signing with a cloud DSC. | `true` | ###### eSignPrioritisation Priority order and retry policy across eSign methods, so signing can fall back from one method to the next. | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `orderLevelRetryCount` | boolean | No | Set to `true` to apply retry counts at the priority-order level (shared across priority types). | `true` | | `enableAadhaarPriority` | boolean | No | Functional toggle that drives whether Aadhaar-priority logic runs at sign time. When `true`, configure `aadhaarPriorityConfig`. When `false`, any `aadhaarPriorityConfig` sent in the request is ignored. When `true`, a valid `aadhaarPriorityConfig` is required. | `true` | | `aadhaarPriorityConfig` | object | No | Retry attempts and ordering for each Aadhaar authentication mode. See **aadhaarPriorityConfig** below. | — | ###### aadhaarPriorityConfig Retry attempts and ordering for each Aadhaar authentication mode. | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `prioritisationOtpRetryAttempts` | integer | No | Retry attempts allowed for Aadhaar OTP. | `1` | | `prioritisationOtpOrder` | integer | No | Priority-order position of Aadhaar OTP. | `2` | | `prioritisationBioRetryAttempts` | integer | No | Retry attempts allowed for Aadhaar biometric. | `1` | | `prioritisationBioOrder` | integer | No | Priority-order position of Aadhaar biometric. | `4` | | `prioritisationIrisRetryAttempts` | integer | No | Retry attempts allowed for Aadhaar iris. | `1` | | `prioritisationIrisOrder` | integer | No | Priority-order position of Aadhaar iris. | `4` | | `prioritisationFaceAuthRetryAttempts` | integer | No | Retry attempts allowed for Aadhaar face authentication. | `2` | | `prioritisationFaceAuthOrder` | integer | No | Priority-order position of Aadhaar face authentication. | `3` | ###### signatureAppearance How the signature block looks on the document. | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `allowEditingNameInSigningJourney` | boolean | No | Set to `true` to let the signer edit the name shown in their signature during signing. | `false` | | `displayNameInSignatureAppearances` | boolean | No | Set to `true` to display the signer's name in the signature appearance. | `true` | | `requireOrgSeal` | boolean | No | Set to `true` to include an organisation seal in the signature appearance. | `true` | | `orgNameInSeal` | string | No | Organisation name printed on the seal. | `Acme Corp` | | `orgSealType` | string | No | Type of organisation seal to use (for example, `CUSTOM`). | `CUSTOM` | ###### webhooks Per-combination webhook configuration. Omitting `webhooks` means no webhooks fire for this combination. | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `successWebhook` | string | No | The URL Leegality calls when the event completes successfully. | `https://integrator.example.com/webhooks/leegality/success` | | `errorWebhook` | string | No | The URL Leegality calls when an error occurs. | `https://integrator.example.com/webhooks/leegality/error` | | `webhookProfileId` | string | No | References a configured webhook profile (auth credentials, headers, retry policy). The profile does not carry the destination URL. | `8b9bfa84-3982-4ffe-a5b9-16a403eca7a1` | | `webhookVersion` | string | No | Webhook payload version. **Possible values:** - `VERSION_2.3` - `VERSION_2.5` - `VERSION_4.0` Required whenever `successWebhook` or `errorWebhook` is configured. Allowed: `VERSION_2.3`, `VERSION_2.5`, `VERSION_4.0`. | `VERSION_4.0` | ###### customConsent Custom consent settings. | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `enableCustomConsent` | boolean | No | Set to `true` to show a custom consent to the invitee (provide `customConsentInput`). | `true` | | `consentAutoCheck` | boolean | No | Set to `true` to pre-check the consent checkbox for the invitee. | `true` | | `customConsentAutoCheck` | boolean | No | Set to `true` to pre-check the custom consent checkbox for the invitee. | `true` | | `customConsentInput` | string | No | Custom consent text shown to the invitee. Active when `enableCustomConsent = true`. | `null` | ###### expiry Invitation expiry settings. | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `enableExpiry` | boolean | No | Set to `true` to expire the invitation after a set number of days (provide `expiry`). When `false`, any `expiry` sent in the request is ignored. When `true`, a valid `expiry` is required. | `true` | | `expiry` | integer | No | When the invitation expires. Applies when `enableExpiry` is `true`. **Possible values:** - `-1` — 45 minutes - `0` — same day - `1` to `365` — that many days (`1` = next day, end of day) | `30` | ###### paymentCollect Payment collection settings. Active when `enablePaymentCollect = true`. | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `enablePaymentCollect` | boolean | No | Set to `true` to collect a payment before signing (fill in the fields below). When `false`, the payment fields are ignored. | `true` | | `paymentProfile` | string | No | ID of the payment profile used to collect the payment. | `23931d8d-9edb-4895-adee-e296dcba07c9` | | `paymentAmount` | integer | No | Amount to collect from the invitee. | `500` | | `customMessagePaymentPage` | string | No | Custom message shown on the payment page. Send it only alongside `paymentAmount`. | `Stamp duty payment required.` | #### cc | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `uuid` | string | Yes | Unique ID (UUID v4) for this CC recipient. Leegality generates it if the CC recipient is already configured in the workflow. If the workflow creator allows adding CC recipients and you add one while sending, generate a new UUID v4 yourself. | `4a444444-4444-4444-8444-444444444444` | | `name` | string | Yes | CC recipient name. **Required.** | `CC Person` | | `email` | string | Yes | CC recipient email. **Required.** | `cc@g.com` | | `invitationNotifications` | boolean | No | Set to `true` to notify the CC recipient when invitations are sent. | `true` | | `signingNotifications` | boolean | No | Set to `true` to notify the CC recipient each time an invitee signs. | `true` | | `completionNotifications` | boolean | No | Set to `true` to notify the CC recipient when the pack is completed. | `true` | | `failureNotifications` | boolean | No | Set to `true` to notify the CC recipient if the pack fails. | `true` | | `sendInvitationUrl` | boolean | No | Set to `true` to include the signing/invitation URL in notifications to the CC recipient. | `true` | | `shareDocAuditTrail` | boolean | No | Set to `true` to share the document audit trail with the CC recipient on completion. | `true` | | `recordAuditTrail` | boolean | No | Set to `true` to record the CC recipient's notifications in the audit trail. | `true` | | `addInviteeToContactBook` | boolean | No | Set to `true` to save the CC invitee in Leegality's [contact book](https://knowledge.leegality.com/document-execution/contact-book) for reuse. | `true` | #### coordinates | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `uuid` | string | Yes | Unique ID (UUID v4) for this coordinate. Leegality generates it if the coordinate is already configured in the workflow. If the workflow creator allows adding coordinates and you add one while sending, generate a new UUID v4 yourself. | `5c047eb0-aa4d-4e68-8ef7-617b8ec2e87d` | | `inviteeUuid` | string | Yes | The invitee whose signature this entry places. Must match the `uuid` of an invitee (`invitees[]`) included in this same request. **Required.** | `8bc21487-b200-4130-8240-a5f1715244dc` | | `appearances` | array\ | Yes | Individual signature placements for the invitee across documents and pages. **Required.** See **appearances** below. | — | | `groupSigningSlot` | integer | No | Threshold-signing slot for a group signer (`groupSigner`). **Required when `groupThreshold > 1`** (valid range `1..groupThreshold`); when the threshold is `1` it is optional (must be `1` if sent). Reviewers and group reviewers never receive coordinates. Slots are claimed in signing order, not bound to a specific member. | `1` | ##### appearances | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `uuid` | string | Yes | Unique ID (UUID v4) for this signature appearance. Leegality generates it if the signature appearance is already configured in the workflow. If the workflow creator allows adding signature appearances and you add one while sending, generate a new UUID v4 yourself. | `c39d44b6-6135-4279-a4b6-2bc53dce2fdc` | | `documentUuid` | string | Yes | The document this appearance is placed on. Must match the `uuid` of a document (`documents[]`) included in this same request. **Required.** | `711abfff-2057-48ac-909e-519f3f7415a4` | | `subDocumentUuid` | string | Yes | The sub-document this appearance is placed on. Must match the `uuid` of a sub-document (`documents[].subDocuments[]`) included in this same request. **Required.** | `795df69d-12c9-4959-be9a-9a73a2e1dd30` | | `combinationUuid` | string | Yes | The combination this appearance belongs to. Must match the `uuid` of a combination (`invitees[].combinations[]`) included in this same request. An invitee can have multiple combinations over the same document, so it can't be inferred automatically. | `29bdb6fd-99a9-4501-b74b-d482d7ad5062` | | `pageNo` | string | Yes | Page number on which to place the appearance (1-indexed, as a string). **Required.** | `1` | | `rect` | object | Yes | Placement rectangle `{ x1Axis, y1Axis, x2Axis, y2Axis }` (coordinates as strings). **Required.** See **rect** below. | — | | `type` | string | Yes | Placement type. **Required.** **Possible values:** - `FULL_DOC` - `SUB_DOC` - `CUSTOM` - `DEFAULT` Allowed: `FULL_DOC`, `SUB_DOC`, `CUSTOM`, `DEFAULT`. | `FULL_DOC` | | `subDocumentType` | string | No | The sub-document's type. Pass the value that matches the sub-document: **Possible values:** - `PDF` — for a PDF - `STAMP` — for a stamp - `TEMPLATE` — for a template Allowed: `PDF`, `STAMP`, `TEMPLATE`. | `PDF` | ###### rect Placement rectangle `{ x1Axis, y1Axis, x2Axis, y2Axis }` (coordinates as strings). **Required.** | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `x1Axis` | string | Yes | X coordinate of the rectangle's first corner (string). | `350` | | `y1Axis` | string | Yes | Y coordinate of the rectangle's first corner (string). | `680` | | `x2Axis` | string | Yes | X coordinate of the rectangle's opposite corner (string). | `550` | | `y2Axis` | string | Yes | Y coordinate of the rectangle's opposite corner (string). | `720` | ### Sample Request ```json { "workflowId": "70843c25-8d80-40ac-ab6b-edba12abd495", "pack": { "packName": "Home Loan Agreement - Rajesh Kumar", "packIrn": "IRN-2026-001234", "packUrn": "21312313131", "packFolderId": "K4wFolder", "deleteOnComplete": false, "sftpProfileId": "07aba168-b55b-4889-bddf-9012fa853e61", "brandingProfileId": "branding-001", "lecf_loanId": "LOAN-2026-5678", "lecf_branchCode": "MUM-001", "signingOrder": { "setSigningOrder": true, "preventChangesToSigningOrder": false, "setAdvanceSigningOrder": false } }, "documents": [ { "uuid": "711abfff-2057-48ac-909e-519f3f7415a4", "documentName": "Loan Agreement", "irn": "DOC-IRN-001", "documentFolderId": "K4wKEBB", "subDocuments": [ { "uuid": "795df69d-12c9-4959-be9a-9a73a2e1dd30", "templateId": "tpl_mapping_abc123", "templateVersion": "1.0", "allowFirstInviteeToFill": true, "templateFieldValues": [ { "fieldId": "f1a23456-78bc-4def-9012-3456789abcde", "fieldValue": "Rajesh Kumar", "fieldName": "borrower name" } ], "enableRevenueStamp": true, "revenueStamp": { "revenueStampQuantity": 1, "revenueStampId": "10" }, "enableStampSeries": true, "stampSeries": [ { "uuid": "0a1b2c3d-4e5f-4abc-8def-0123456789ab", "stampSeriesId": "01", "stampQuantities": 1 } ], "enableStampUpload": true, "stampUpload": { "stampUploadState": "PB", "stampUploadedFile": { "file": "JVBERi0xLjQKJeLjz9MK…(base64-encoded file)" }, "stampUploadDenomination": 100, "stampUploadFirstPartyName": "John Doe", "stampUploadSecondPartyName": "Jane Smith", "stampUploadSerialNumber": "123" }, "enableStampGroup": true, "stampGroup": { "stampGroupId": "PB01", "stampGroupAmount": 1 }, "file": "JVBERi0xLjQKJeLjz9MK…(base64-encoded file)" } ], "stamps": { "enableStamp": true, "enableRevenueStamp": true, "revenueStamp": { "revenueStampQuantity": 1, "revenueStampId": "10" }, "enableStampSeries": true, "stampSeries": [ { "uuid": "1a2b3c4d-5e6f-4a7b-8c9d-0e1f2a3b4c5e", "stampSeriesId": "01", "stampQuantities": 1 } ], "enableStampGroup": true, "stampGroup": { "stampGroupId": "PB01", "stampGroupAmount": 10 }, "enableStampUpload": true, "stampUpload": { "stampUploadSerialNumber": "SERIAL001", "stampUploadFirstPartyName": "Alice", "stampUploadDenomination": 100, "stampUploadedFile": { "file": "JVBERi0xLjQKJeLjz9MK…(base64-encoded file)" }, "stampUploadState": "PB", "stampUploadSecondPartyName": "Bob" } }, "referenceAttachment": { "enableReferenceAttachment": true, "referenceAttachmentFiles": [ { "uuid": "23c96e97-813a-4a6c-9c37-e939f54d597d", "file": "JVBERi0xLjQKJeLjz9MK…(base64-encoded file)" } ] }, "lecf_documentCategory": "CONTRACT" } ], "invitees": [ { "uuid": "8bc21487-b200-4130-8240-a5f1715244dc", "type": "signer", "level": 1, "groupName": "", "groupThreshold": 2, "inviteeDetails": [ { "uuid": "1aa11111-1111-4111-8111-111111111111", "inviteeName": "Rajesh Kumar", "inviteeLabel": "borrower", "inviteeEmail": "rajesh@example.com", "inviteePhone": "9820000001", "enableWhatsAppMandatoryNotifications": false, "lecf_employeeCode": "EMP-00921" } ], "inviteeSettings": { "securityOptions": { "oneFactorAuthentication": false, "twoFactorAuthentication": true, "gps": { "enabled": true, "accuracyBasedRestriction": true, "accuracyThreshold": 12, "locationBasedRestriction": true, "latitude": 23.34, "longitude": 72.88, "permissibleRadius": 100, "restrictToIndia": true, "enableLatLngRadius": true }, "faceCapture": { "enabled": true, "liveliness": true, "match": true, "faceMatchRetryAttempts": 2, "faceMatch": [ { "uuid": "3a333333-3333-4333-8333-333333333333", "faceMatchImage": { "file": "JVBERi0xLjQKJeLjz9MK…(base64-encoded file)" } } ], "livelinessRetryAttempts": 3 }, "docDownloadLinkWithOtp": false, "maskContactDetails": false }, "manageInviteInteractions": { "enableSupportingDocs": true, "supportingDocumentConfig": { "supportingDocuments": [ { "uuid": "2a222222-2222-4222-8222-222222222222", "supportingDocName": "ID Proof", "supportingDocFormat": "PDF", "supportingDocSize": 2048 } ], "allowViewingSupportingDocs": true }, "baseUrl": "https://client.example.com/sign", "redirectUrl": "https://client.example.com/sign/complete", "enableRejection": true, "enforceRejectionMessage": false, "enableCustomMessage": true, "customMessageInput": "Please review and sign the loan agreement.", "enableLocalLanguage": true, "languageDefaultVsSignerSelect": "default", "localLanguageChooseDefault": "hi" }, "notifications": { "enableSmsNotifications": true, "enableEmailNotifications": true, "enableWhatsAppNotifications": false }, "contactBook": { "addInviteeToContactBook": true, "inviteeLabel": "borrower" }, "certificateVerification": { "aadhaarVerifyCertificateDetails": [ { "uuid": "a1b2c3d4-5678-4abc-9def-012345678901", "aadhaarVerifyName": false, "aadhaarSmartNameVerify": false, "aadhaarVerifyYob": "1997", "aadhaarVerifyState": "bihar", "aadhaarVerifyTitle": "3046", "aadhaarVerifyPincode": 845446, "aadhaarVerifyGender": "M" } ], "cloudDscVerifyCertificateDetails": [ { "cloudDscVerifyName": true, "cloudDscSmartNameVerify": false, "cloudDscVerifyState": "Maharashtra", "cloudDscVerifyPincode": 400001 } ], "dscVerifyCertificateDetails": [ { "uuid": "b2c3d4e5-6789-4abc-8def-123456789012", "dscVerifyName": false, "dscSmartNameVerify": false, "dscVerifyPincode": 845449, "dscVerifyState": "bihar" } ] }, "reviewer": { "enableAuditTrail": true, "enableOtpForReview": false } }, "combinations": [ { "uuid": "29bdb6fd-99a9-4501-b74b-d482d7ad5062", "assignedDocuments": [ { "uuid": "cd7c1c46-af20-4452-9f6c-ca507705a8b9", "documentUuid": "711abfff-2057-48ac-909e-519f3f7415a4", "role": "signer" } ], "combinationSettings": { "esignTypes": { "aadharEsign": { "aadharEsignEnabled": true, "aadhaarEsignConfig": { "aadhaarOtp": true, "aadhaarBio": false, "aadhaarIris": false, "aadhaarFace": false, "aadhaarSetMaxRetryAttempts": true, "aadhaarMaxRetryAttempts": 3 } }, "automatedEsign": { "enableAutomatedSign": true, "automatedSignConfig": { "automatedSignProfile": "auto-profile-001", "automatedSignPassword": "secret" } }, "quickSign": { "enableQuickSign": true, "quickSignConfig": { "quickSignDraw": true, "quickSignAutoGenerate": true, "quickSignFingerprint": false } }, "visualSign": { "enableVisualSign": true, "visualSignConfig": { "visualSignDraw": true, "visualSignAutoGenerate": true, "visualSignFingerprint": false, "visualSignUpload": true } }, "virtualEsign": { "virtualEsignEnabled": true, "virtualEsignConfig": { "virtualDrawSignature": true, "virtualSelect": true, "virtualFingerprint": false, "virtualSignUpload": false } }, "dscToken": { "enableDscToken": true }, "docSign": { "enableDocSigner": true }, "cloudDsc": { "enableCloudDsc": true } }, "eSignPrioritisation": { "orderLevelRetryCount": true, "enableAadhaarPriority": true, "aadhaarPriorityConfig": { "prioritisationOtpRetryAttempts": 1, "prioritisationOtpOrder": 2, "prioritisationBioRetryAttempts": 1, "prioritisationBioOrder": 4, "prioritisationIrisRetryAttempts": 1, "prioritisationIrisOrder": 4, "prioritisationFaceAuthRetryAttempts": 2, "prioritisationFaceAuthOrder": 3 } }, "signatureAppearance": { "allowEditingNameInSigningJourney": false, "displayNameInSignatureAppearances": true, "requireOrgSeal": true, "orgNameInSeal": "Acme Corp", "orgSealType": "CUSTOM" }, "webhooks": { "successWebhook": "https://integrator.example.com/webhooks/leegality/success", "errorWebhook": "https://integrator.example.com/webhooks/leegality/error", "webhookProfileId": "8b9bfa84-3982-4ffe-a5b9-16a403eca7a1", "webhookVersion": "VERSION_4.0" }, "customConsent": { "enableCustomConsent": true, "consentAutoCheck": true, "customConsentAutoCheck": true, "customConsentInput": null }, "expiry": { "enableExpiry": true, "expiry": 30 }, "paymentCollect": { "enablePaymentCollect": true, "paymentProfile": "23931d8d-9edb-4895-adee-e296dcba07c9", "paymentAmount": 500, "customMessagePaymentPage": "Stamp duty payment required." } } } ], "lecf_customerId": "CUST-8842" } ], "cc": [ { "uuid": "4a444444-4444-4444-8444-444444444444", "name": "CC Person", "email": "cc@g.com", "invitationNotifications": true, "signingNotifications": true, "completionNotifications": true, "failureNotifications": true, "sendInvitationUrl": true, "shareDocAuditTrail": true, "recordAuditTrail": true, "addInviteeToContactBook": true } ], "coordinates": [ { "uuid": "5c047eb0-aa4d-4e68-8ef7-617b8ec2e87d", "inviteeUuid": "8bc21487-b200-4130-8240-a5f1715244dc", "appearances": [ { "uuid": "c39d44b6-6135-4279-a4b6-2bc53dce2fdc", "documentUuid": "711abfff-2057-48ac-909e-519f3f7415a4", "subDocumentUuid": "795df69d-12c9-4959-be9a-9a73a2e1dd30", "combinationUuid": "29bdb6fd-99a9-4501-b74b-d482d7ad5062", "pageNo": "1", "rect": { "x1Axis": "350", "y1Axis": "680", "x2Axis": "550", "y2Axis": "720" }, "type": "FULL_DOC", "subDocumentType": "PDF" } ], "groupSigningSlot": 1 } ] } ``` --- ## Responses ### 201 — Pack created and sent. Returns the created pack with its documents, invitations, and sign URLs. | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `code` | string | No | Result code. `SUCCESS` when the pack was created. | `SUCCESS` | | `message` | string | No | Human-readable status message. | `Pack created` | | `data` | object | No | See **data** below. | — | #### data | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `workflowRunContextId` | string | No | Unique ID for this submission. Use it with **Check Pack Details** to view the pack. | `b7c4f1e2-9a0d-4c3b-8f11-2a5d6e7f8a90` | | `pack` | object | No | The created pack. See **pack** below. | — | | `documents` | array\ | No | The documents in the pack. See **documents** below. | — | | `invitations` | array\ | No | The invitee groups on the pack. See **invitations** below. | — | | `cc` | array\ | No | CC recipients on the pack. See **cc** below. | — | ##### pack The created pack. | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `packId` | string | No | Unique ID of the pack. | `PK-90211` | | `packIrn` | string | No | Your Internal Reference Number for the pack. | `IRN-1001` | | `packUrn` | string | No | Your Unique Reference Number for the pack. | `URN-1001` | | `packName` | string | No | Display name of the pack. | `Loan Agreement Pack` | ##### documents | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `documentId` | string | No | Unique ID of the document. | `DOC-45120` | | `documentName` | string | No | Display name of the document. | `Loan Agreement` | | `irn` | string | No | Your Internal Reference Number for the document. | `DOC-IRN-1` | ##### invitations | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `uuid` | string | No | ID of the invitee group. | `c2b2f8d0-0000-4000-8000-000000000001` | | `groupName` | string | No | Name of the invitee group. | `Borrower` | | `groupThreshold` | integer | No | Minimum members required to complete the group's action. | `1` | | `type` | string | No | Type of invitee (e.g. `SIGNER`, `REVIEWER`). | `SIGNER` | | `level` | integer | No | Signing-order level (1 = first). | `1` | | `inviteeDetails` | array\ | No | The person(s) in this invitee group. See **inviteeDetails** below. | — | ###### inviteeDetails | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `uuid` | string | No | ID of this person. | `c2b2f8d0-0000-4000-8000-000000000011` | | `inviteeName` | string | No | Full name of the invitee. | `Asha Rao` | | `inviteeEmail` | string | No | Email address of the invitee. | `asha@example.com` | | `inviteePhone` | string | No | Mobile number of the invitee. | `9800000000` | | `invitationUrl` | string | No | The invitee's sign URL. | `https:///sign/xxxxxxxx` | ##### cc | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `uuid` | string | No | ID of this CC entry. | `d3c3f8d0-0000-4000-8000-000000000001` | | `name` | string | No | CC recipient name. | `Ops Desk` | | `email` | string | No | CC recipient email. | `ops@example.com` | ### Sample Response (201) ```json { "code": "SUCCESS", "message": "Pack created", "data": { "workflowRunContextId": "b7c4f1e2-9a0d-4c3b-8f11-2a5d6e7f8a90", "pack": { "packId": "PK-90211", "packIrn": "IRN-1001", "packUrn": "URN-1001", "packName": "Loan Agreement Pack" }, "documents": [ { "documentId": "DOC-45120", "documentName": "Loan Agreement", "irn": "DOC-IRN-1" } ], "invitations": [ { "uuid": "c2b2f8d0-0000-4000-8000-000000000001", "groupName": "Borrower", "groupThreshold": 1, "type": "SIGNER", "level": 1, "inviteeDetails": [ { "uuid": "c2b2f8d0-0000-4000-8000-000000000011", "inviteeName": "Asha Rao", "inviteeEmail": "asha@example.com", "inviteePhone": "9800000000", "invitationUrl": "https:///sign/xxxxxxxx" } ] } ], "cc": [ { "uuid": "d3c3f8d0-0000-4000-8000-000000000001", "name": "Ops Desk", "email": "ops@example.com" } ] } } ``` --- URL: https://knowledge.leegality.com/document-execution/api/create-pack # POST /v4/pack — Send Pack for eSigning (Async) :::info[Sandbox endpoint] **Authentication:** `X-Auth-Token` header required on every request. ## Request URL ``` POST https://app1.leegality.com/api/v4/pack ``` **Environments:** - Production: `https://app1.leegality.com/api/v4/pack` - Sandbox: `https://sandbox.leegality.com/api/v4/pack` --- ## Request Body **Content-Type:** `application/json` | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `workflowId` | string | Yes | ID of the published Workflow to execute. The pack is created and sent according to this Workflow's configuration. The dashboard shows a short form of this ID (for example, `70843c25`); to get the full value, [download the workflow's API payload](https://knowledge.leegality.com/document-execution/api/download-v4-api-payload) from the dashboard. **Required.** | `70843c25-8d80-40ac-ab6b-edba12abd495` | | `pack` | object | Yes | Pack-level details: metadata, custom fields, and `signingOrder`. The pack is the top-level container for all primary documents sent together in one run. **Required.** See **pack** below. | — | | `documents` | array\ | Yes | Primary documents in the pack, each with its sub-documents, stamps, and attachments. Each primary document is signed independently. **Required.** See **documents** below. | — | | `invitees` | array\ | Yes | Configure invitee details. See **invitees** below. | — | | `cc` | array\ | No | CC recipients — a top-level sibling of `invitees`. CC recipients receive notifications but do not sign or review. See **cc** below. | — | | `coordinates` | array\ | No | Signature placement. **Optional** — the backend resolves placement from the workflow config when omitted. Each entry positions one invitee's signature appearance(s). See **coordinates** below. | — | #### pack Pack-level details: metadata, custom fields, and `signingOrder`. The pack is the top-level container for all primary documents sent together in one run. **Required.** | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `packName` | string | Yes | Display name for the pack, shown to invitees and in the dashboard. **Required.** - Max 255 characters. - Allowed characters: letters, digits, spaces, and `+ @ \| - : ( ) , _ . [ ] & /`. | `Home Loan Agreement - Rajesh Kumar` | | `packIrn` | string | No | Your Internal Reference Number for the pack (for compliance/reconciliation against your own records). | `IRN-2026-001234` | | `packUrn` | string | No | Your Unique Reference Number for the pack. Must be unique within your account — you can't create two packs with the same URN. | `21312313131` | | `packFolderId` | string | No | ID of the folder where you want to keep the pack. You'll find it in your Leegality Dashboard's Folder section on the left. | `K4wFolder` | | `deleteOnComplete` | boolean | No | Set to `true` to automatically delete the pack's documents from Leegality once the pack is completed. | `false` | | `sftpProfileId` | string | No | ID (UUID) of a pre-configured SFTP profile to which signed files are delivered on completion. | `07aba168-b55b-4889-bddf-9012fa853e61` | | `brandingProfileId` | string | No | ID of a branding profile that controls the look and feel (logo, colours) of the signing journey. | `branding-001` | | `lecf_loanId` | string | No | Custom field at pack level. `lecf_`-prefixed fields are available **only if the corresponding custom fields have been added to the Workflow** (they cannot be added at runtime). Example shown is a loan ID. | `LOAN-2026-5678` | | `lecf_branchCode` | string | No | Custom field at pack level. `lecf_`-prefixed fields are available **only if the corresponding custom fields have been added to the Workflow**. Example shown is a branch code. | `MUM-001` | | `signingOrder` | object | No | Signing-order settings. Must live **inside** `pack`. See **signingOrder** below. | — | ##### signingOrder Signing-order settings. Must live **inside** `pack`. | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `setSigningOrder` | boolean | Yes | Whether signing order is enforced. When `true`, level ordering (`level`) is enforced; when `false`, all invitees are active in parallel. **Required** within `signingOrder`. | `true` | | `preventChangesToSigningOrder` | boolean | No | Set to `true` to lock the signing order so it cannot be changed after sending (also blocks out-of-order activation). Default: `false`. | `false` | | `setAdvanceSigningOrder` | boolean | No | Set to `true` to enable advanced signing order. | `false` | #### documents | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `uuid` | string | Yes | Unique ID (UUID v4) for this document. Leegality generates it if the document is already configured in the workflow. If the workflow creator allows adding documents and you add one while sending, generate a new UUID v4 yourself. Other items refer to this document by `documentUuid`. | `711abfff-2057-48ac-909e-519f3f7415a4` | | `documentName` | string | Yes | Display name of the primary document. **Required.** | `Loan Agreement` | | `irn` | string | No | Document-level Internal Reference Number. | `DOC-IRN-001` | | `documentFolderId` | string | No | ID of the folder where you want to keep this document. You'll find it in your Leegality Dashboard's Folder section on the left. | `K4wKEBB` | | `subDocuments` | array\ | Yes | Sub-documents that make up this primary document. Each is an individual file (or a template) combined into the single primary document the invitee signs. **Required.** To leave a sub-document out of the pack, don't add its object to this array. See **subDocuments** below. | — | | `stamps` | object | No | Document-level stamp configuration (stamps applied at the primary-document scope). Turned on by the master `enableStamp` flag, with each subtype turned on by its own `enable…` flag. See **stamps** below. | — | | `referenceAttachment` | object | No | Reference attachments shown to invitees alongside the document for context (not signed). See **referenceAttachment** below. | — | | `lecf_documentCategory` | string | No | Custom field at document level. `lecf_`-prefixed fields are available **only if the corresponding custom fields have been added to the Workflow**. Example shown is a document category. | `CONTRACT` | ##### subDocuments | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `uuid` | string | Yes | Unique ID (UUID v4) for this sub-document. Leegality generates it if the sub-document is already configured in the workflow. If the workflow creator allows adding sub-documents and you add one while sending, generate a new UUID v4 yourself. Other items refer to this sub-document by `subDocumentUuid`. | `795df69d-12c9-4959-be9a-9a73a2e1dd30` | | `templateId` | string | No | ID of the template to use for this sub-document. **Required when the sub-document is a template** (instead of `mediaId`). | `tpl_mapping_abc123` | | `templateVersion` | string | No | Version of the template to use, for example `1.0`. Applies when the sub-document is a template. | `1.0` | | `allowFirstInviteeToFill` | boolean | No | Set to `true` to let the first invitee fill the template fields during signing instead of pre-filling them via the API. | `true` | | `templateFieldValues` | array\ | No | Values used to pre-fill the template's fields. Each entry is `{ fieldId, fieldValue, fieldName }`. Applies when the sub-document is a template. If a template has grouped fields, pass only one value per group for `text`, `textarea`, and `number` field types — it will auto-populate every template form field in the same group. See **templateFieldValues** below. | — | | `enableRevenueStamp` | boolean | No | Set to `true` to apply a revenue stamp (provide `revenueStamp`). When `false`, any `revenueStamp` sent in the request is ignored. When `true`, a valid `revenueStamp` is required. | `true` | | `revenueStamp` | object | No | Revenue stamp configuration. Active when `enableRevenueStamp = true`. Can be used together with `stampSeries` or `stampGroup`, but not with `stampUpload`. See **revenueStamp** below. | — | | `enableStampSeries` | boolean | No | Set to `true` to stamp from a stamp series (provide the `stampSeries` array). When `false`, any `stampSeries` sent in the request is ignored. When `true`, a valid `stampSeries` is required. | `true` | | `stampSeries` | array\ | No | Attach stamps from one or more stamp series. Active when `enableStampSeries = true`. Each entry takes a stamp series number (`stampSeriesId`) and how many stamps to use from it (`stampQuantities`). Works together with `stampGroup`, but not with `stampUpload`. See **stampSeries** below. | — | | `enableStampUpload` | boolean | No | Set to `true` to use an uploaded stamp paper (provide `stampUpload`). When `false`, any `stampUpload` sent in the request is ignored. When `true`, a valid `stampUpload` is required. | `true` | | `stampUpload` | object | No | Uploaded stamp-paper configuration. Active when `enableStampUpload = true`. Cannot be used with any other stamp type. When `stampUpload` is provided, `stampUploadedFile` and its `file` are required. See **stampUpload** below. | — | | `enableStampGroup` | boolean | No | Set to `true` to stamp from a stamp group (provide `stampGroup`). When `false`, any `stampGroup` sent in the request is ignored. When `true`, a valid `stampGroup` is required. | `true` | | `stampGroup` | object | No | eStamp from a stamp group. Active when `enableStampGroup = true`. Can be used together with `stampSeries`, but not with `stampUpload`. See **stampGroup** below. | — | | `file` | string | No | A media ID (from the [Upload media API](https://knowledge.leegality.com/document-execution/api/upload-media)) or the file's base64-encoded content. Allowed format: PDF. **Required for non-template sub-documents.** | `95ded759-0b03-4c6b-91bd-45f049893972` | ###### templateFieldValues | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `fieldId` | string | No | ID of the template field to fill. The server identifies the field by `fieldId`. | `f1a23456-78bc-4def-9012-3456789abcde` | | `fieldValue` | string | No | Value to insert into the template field. For a `file`-type field, pass a `mediaId` (from the [Upload media API](https://knowledge.leegality.com/document-execution/api/upload-media), uploaded with `mediaType: TEMPLATE_FILE_TYPE_FIELD`). | `Rajesh Kumar` | | `fieldName` | string | No | Human-readable field name. **Informational only** — the server identifies the field by `fieldId`; `fieldName` is not used for processing. | `borrower name` | ###### revenueStamp Revenue stamp configuration. Active when `enableRevenueStamp = true`. Can be used together with `stampSeries` or `stampGroup`, but not with `stampUpload`. | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `revenueStampQuantity` | integer | No | Number of revenue stamps to attach. | `1` | | `revenueStampId` | string | No | ID of the revenue stamp to use. | `10` | ###### stampSeries | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `uuid` | string | Yes | Unique ID (UUID v4) for this stamp-series entry. Leegality generates it if the stamp-series entry is already configured in the workflow. If the workflow creator allows adding stamp-series entries and you add one while sending, generate a new UUID v4 yourself. Required whenever a `stampSeries` entry is included. | `0a1b2c3d-4e5f-4abc-8def-0123456789ab` | | `stampSeriesId` | string | No | Stamp Series Number. | `01` | | `stampQuantities` | integer | No | Number of stamps you want to attach. | `1` | ###### stampUpload Uploaded stamp-paper configuration. Active when `enableStampUpload = true`. Cannot be used with any other stamp type. When `stampUpload` is provided, `stampUploadedFile` and its `file` are required. | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `stampUploadState` | string | No | State code the stamp paper was purchased in (for example, `PB`). | `PB` | | `stampUploadedFile` | object | No | The uploaded stamp-paper file. See **stampUploadedFile** below. | — | | `stampUploadDenomination` | integer | No | Face value (denomination) of the uploaded stamp paper. | `100` | | `stampUploadFirstPartyName` | string | No | First party name printed on the stamp paper. | `John Doe` | | `stampUploadSecondPartyName` | string | No | Second party name printed on the stamp paper. | `Jane Smith` | | `stampUploadSerialNumber` | string | No | Serial number of the uploaded stamp paper. | `123` | ###### stampUploadedFile The uploaded stamp-paper file. | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `file` | string | No | A media ID (from the [Upload media API](https://knowledge.leegality.com/document-execution/api/upload-media)) or the file's base64-encoded content. Allowed format: PDF. | `f8cb424a-9580-4d84-8817-31f9d7887c0e` | ###### stampGroup eStamp from a stamp group. Active when `enableStampGroup = true`. Can be used together with `stampSeries`, but not with `stampUpload`. | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `stampGroupId` | string | No | ID of the stamp group to use. | `PB01` | | `stampGroupAmount` | integer | No | Stamp duty amount you want to attach. | `1` | ##### stamps Document-level stamp configuration (stamps applied at the primary-document scope). Turned on by the master `enableStamp` flag, with each subtype turned on by its own `enable…` flag. | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `enableStamp` | boolean | No | Set to `true` to enable stamping for this document; controls both document-level and sub-document-level stamps. A subtype is applied only when its own `enable…` flag is also `true` with valid config. A document can use **either** document-level stamping **or** sub-document-level stamping — both cannot be enabled together. When `false`, no stamps are applied to this document; any stamp config sent is ignored. When `true`, at least one stamp subtype must be enabled with valid config. | `true` | | `enableRevenueStamp` | boolean | No | Set to `true` to apply a revenue stamp (provide `revenueStamp`). When `false`, any `revenueStamp` sent in the request is ignored. When `true`, a valid `revenueStamp` is required. | `true` | | `revenueStamp` | object | No | Revenue stamp configuration. Active when `enableRevenueStamp = true`. Can be used together with `stampSeries` or `stampGroup`, but not with `stampUpload`. See **revenueStamp** below. | — | | `enableStampSeries` | boolean | No | Set to `true` to stamp from a stamp series (provide the `stampSeries` array). When `false`, any `stampSeries` sent in the request is ignored. When `true`, a valid `stampSeries` is required. | `true` | | `stampSeries` | array\ | No | Attach stamps from one or more stamp series. Active when `enableStampSeries = true`. Each entry takes a stamp series number (`stampSeriesId`) and how many stamps to use from it (`stampQuantities`). Works together with `stampGroup`, but not with `stampUpload`. See **stampSeries** below. | — | | `enableStampGroup` | boolean | No | Set to `true` to stamp from a stamp group (provide `stampGroup`). When `false`, any `stampGroup` sent in the request is ignored. When `true`, a valid `stampGroup` is required. | `true` | | `stampGroup` | object | No | eStamp from a stamp group. Active when `enableStampGroup = true`. Can be used together with `stampSeries`, but not with `stampUpload`. See **stampGroup** below. | — | | `enableStampUpload` | boolean | No | Set to `true` to use an uploaded stamp paper (provide `stampUpload`). When `false`, any `stampUpload` sent in the request is ignored. When `true`, a valid `stampUpload` is required. | `true` | | `stampUpload` | object | No | Uploaded stamp-paper configuration. Active when `enableStampUpload = true`. Cannot be used with any other stamp type. When `stampUpload` is provided, `stampUploadedFile` and its `file` are required. See **stampUpload** below. | — | ###### revenueStamp Revenue stamp configuration. Active when `enableRevenueStamp = true`. Can be used together with `stampSeries` or `stampGroup`, but not with `stampUpload`. | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `revenueStampQuantity` | integer | No | Number of revenue stamps to attach. | `1` | | `revenueStampId` | string | No | ID of the revenue stamp to use. | `10` | ###### stampSeries | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `uuid` | string | Yes | Unique ID (UUID v4) for this stamp-series entry. Leegality generates it if the stamp-series entry is already configured in the workflow. If the workflow creator allows adding stamp-series entries and you add one while sending, generate a new UUID v4 yourself. Required whenever a `stampSeries` entry is included. | `1a2b3c4d-5e6f-4a7b-8c9d-0e1f2a3b4c5e` | | `stampSeriesId` | string | No | Stamp Series Number. | `01` | | `stampQuantities` | integer | No | Number of stamps you want to attach. | `1` | ###### stampGroup eStamp from a stamp group. Active when `enableStampGroup = true`. Can be used together with `stampSeries`, but not with `stampUpload`. | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `stampGroupId` | string | No | ID of the stamp group to use. | `PB01` | | `stampGroupAmount` | integer | No | Stamp duty amount you want to attach. | `10` | ###### stampUpload Uploaded stamp-paper configuration. Active when `enableStampUpload = true`. Cannot be used with any other stamp type. When `stampUpload` is provided, `stampUploadedFile` and its `file` are required. | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `stampUploadSerialNumber` | string | No | Serial number of the uploaded stamp paper. | `SERIAL001` | | `stampUploadFirstPartyName` | string | No | First party name printed on the stamp paper. | `Alice` | | `stampUploadDenomination` | integer | No | Face value (denomination) of the uploaded stamp paper. | `100` | | `stampUploadedFile` | object | No | The uploaded stamp-paper file. See **stampUploadedFile** below. | — | | `stampUploadState` | string | No | State code the stamp paper was purchased in (for example, `PB`). | `PB` | | `stampUploadSecondPartyName` | string | No | Second party name printed on the stamp paper. | `Bob` | ###### stampUploadedFile The uploaded stamp-paper file. | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `file` | string | No | A media ID (from the [Upload media API](https://knowledge.leegality.com/document-execution/api/upload-media)) or the file's base64-encoded content. Allowed format: PDF. | `f8cb424a-9580-4d84-8817-31f9d7887c0e` | ##### referenceAttachment Reference attachments shown to invitees alongside the document for context (not signed). | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `enableReferenceAttachment` | boolean | No | Set to `true` to attach reference files (provide `referenceAttachmentFiles`). When `false`, any `referenceAttachmentFiles` sent in the request is ignored. When `true`, a valid `referenceAttachmentFiles` is required. | `true` | | `referenceAttachmentFiles` | array\ | No | Files to attach for reference. Each entry is `{ uuid, mediaId, fileName }`. See **referenceAttachmentFiles** below. | — | ###### referenceAttachmentFiles | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `uuid` | string | Yes | Unique ID (UUID v4) for this reference attachment. Leegality generates it if the reference attachment is already configured in the workflow. If the workflow creator allows adding reference attachments and you add one while sending, generate a new UUID v4 yourself. | `23c96e97-813a-4a6c-9c37-e939f54d597d` | | `file` | string | Yes | A media ID (from the [Upload media API](https://knowledge.leegality.com/document-execution/api/upload-media)) or the file's base64-encoded content. Allowed formats: PDF, PNG, JPEG, JPG. | `739fa0b6-91fb-4c98-944c-cb74e7dfe400` | #### invitees | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `uuid` | string | Yes | Unique ID (UUID v4) for this invitee. Leegality generates it if the invitee is already configured in the workflow. If the workflow creator allows adding invitees and you add one while sending, generate a new UUID v4 yourself. Other items refer to this invitee by `inviteeUuid`. | `8bc21487-b200-4130-8240-a5f1715244dc` | | `type` | string | Yes | Type of invitee. One of `signer`, `reviewer`, `groupSigner`, `groupReviewer`. Only `signer` and `groupSigner` receive sign coordinates; reviewers and group reviewers never do. **Required.** | `signer` | | `level` | integer | Yes | Signing-order level (1 = first). Enforced only when `pack.signingOrder.setSigningOrder = true`; invitees at the same level act in parallel, and the next level unlocks when the current level is satisfied. **Required.** | `1` | | `groupName` | string | No | Name of the invitee group. **Required for `groupSigner` / `groupReviewer`**; leave empty for an individual invitee. | `` | | `groupThreshold` | integer | No | Minimum number of group members that must complete the action for the group's part to be satisfied. **Required for `groupSigner` / `groupReviewer`.** | `2` | | `inviteeDetails` | array\ | Yes | The person(s) for this invitee. A single entry for an individual; multiple entries for `groupSigner` / `groupReviewer`. **Required.** See **inviteeDetails** below. | — | | `inviteeSettings` | object | No | Per-person (invitee-level) settings: security, interaction options, notifications, contact book, certificate verification, and reviewer settings. These apply to the person regardless of which documents they sign. See **inviteeSettings** below. | — | | `combinations` | array\ | Yes | Document assignments for this invitee. Each combination assigns one or more documents (with a role) and defines the eSign/experience settings for that document group. Always an array, even for a single combination. **Required.** See **combinations** below. | — | | `lecf_customerId` | string | No | Custom field at invitee level. `lecf_`-prefixed fields are available **only if the corresponding custom fields have been added to the Workflow**. Example shown is a customer ID. | `CUST-8842` | ##### inviteeDetails | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `uuid` | string | Yes | Unique ID (UUID v4) for this recipient. Leegality generates it if the recipient is already configured in the workflow. If the workflow creator allows adding recipients and you add one while sending, generate a new UUID v4 yourself. | `1aa11111-1111-4111-8111-111111111111` | | `inviteeName` | string | Yes | Full name of the person. **Required.** | `Rajesh Kumar` | | `inviteeLabel` | string | No | A label for this invitee. | `borrower` | | `inviteeEmail` | string | No | Email address. **Required if email notifications are enabled.** | `rajesh@example.com` | | `inviteePhone` | string | No | The invitee's 10-digit phone number. **Required if SMS/WhatsApp notifications are enabled.** | `9820000001` | | `enableWhatsAppMandatoryNotifications` | boolean | No | Set to `true` to send mandatory notifications to this invitee over WhatsApp only. | `false` | | `lecf_employeeCode` | string | No | Custom field at the invitee-details (per-person) level. `lecf_`-prefixed fields are available **only if the corresponding custom fields have been added to the Workflow**. Example shown is an employee code. | `EMP-00921` | ##### inviteeSettings Per-person (invitee-level) settings: security, interaction options, notifications, contact book, certificate verification, and reviewer settings. These apply to the person regardless of which documents they sign. | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `securityOptions` | object | No | Security controls applied to the invitee: authentication, GPS, face capture/match, OTP download link, and contact masking. See **securityOptions** below. | — | | `manageInviteInteractions` | object | No | How the invitee interacts with the signing journey: supporting documents, base/redirect URLs, rejection, custom message, and local language. See **manageInviteInteractions** below. | — | | `notifications` | object | No | Notification channel preferences for this invitee. See **notifications** below. | — | | `contactBook` | object | No | Whether to save this invitee to your account's contact book. See **contactBook** below. | — | | `certificateVerification` | object | No | Certificate-verification config performed against the invitee: Aadhaar, cloud-DSC, and DSC checks. Each enabled check must match for the signature to be accepted. See **certificateVerification** below. | — | | `reviewer` | object | No | Settings that apply when the invitee is a reviewer. See **reviewer** below. | — | ###### securityOptions Security controls applied to the invitee: authentication, GPS, face capture/match, OTP download link, and contact masking. | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `oneFactorAuthentication` | boolean | No | Set to `true` to require single-factor authentication before the invitee can access the document. | `false` | | `twoFactorAuthentication` | boolean | No | Set to `true` to require two-factor authentication before the invitee can access the document. | `true` | | `gps` | object | No | Configure geofencing details. See **gps** below. | — | | `faceCapture` | object | No | Configure face capture and liveliness details. See **faceCapture** below. | — | | `docDownloadLinkWithOtp` | boolean | No | Set to `true` to protect the signed-document download link with an OTP. | `false` | | `maskContactDetails` | boolean | No | Set to `true` to mask the invitee's contact details. | `false` | ###### gps Configure geofencing details. | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `enabled` | boolean | No | Set to `true` to capture the signer's location during signing. When `false`, leave the other `gps` fields empty. | `true` | | `accuracyBasedRestriction` | boolean | No | Set to `true` to block signing when the device's location accuracy is worse than `accuracyThreshold`. | `true` | | `accuracyThreshold` | integer | No | Maximum acceptable location-accuracy value (metres). Applies when `accuracyBasedRestriction` is `true`. | `12` | | `locationBasedRestriction` | boolean | No | Set to `true` to restrict signing to within `permissibleRadius` of the point defined by `latitude`/`longitude`. | `true` | | `latitude` | number | No | Latitude of the allowed signing location. Applies when `locationBasedRestriction` / `enableLatLngRadius` is `true`. | `23.34` | | `longitude` | number | No | Longitude of the allowed signing location. Applies when `locationBasedRestriction` / `enableLatLngRadius` is `true`. | `72.88` | | `permissibleRadius` | integer | No | Radius (metres) around the allowed location within which signing is permitted. | `100` | | `restrictToIndia` | boolean | No | Set to `true` to allow signing only from within India. | `true` | | `enableLatLngRadius` | boolean | No | Set to `true` to enable the latitude/longitude/radius restriction. | `true` | ###### faceCapture Configure face capture and liveliness details. | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `enabled` | boolean | No | Set to `true` to enable face capture in the signing journey. When `false`, leave all other `faceCapture` fields empty. | `true` | | `liveliness` | boolean | No | Set to `true` to require a liveliness check during face capture. | `true` | | `match` | boolean | No | Set to `true` to match the captured face against the reference image(s) in `faceMatch`. | `true` | | `faceMatchRetryAttempts` | integer | No | Number of retry attempts allowed for the face-match check (set at the `faceCapture` level). | `2` | | `faceMatch` | array\ | No | Reference image(s) the captured face is matched against. Each entry carries its own `uuid` and a nested `faceMatchImage`. See **faceMatch** below. | — | | `livelinessRetryAttempts` | integer | No | Number of retry attempts allowed for the smart liveliness check. | `3` | ###### faceMatch | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `uuid` | string | Yes | Unique ID (UUID v4) for this face-match entry. Leegality generates it if the face-match entry is already configured in the workflow. If the workflow creator allows adding face-match entries and you add one while sending, generate a new UUID v4 yourself. This is the face-match entry's own ID, not the image's `mediaId`. | `3a333333-3333-4333-8333-333333333333` | | `faceMatchImage` | object | No | The reference face image the rule matches against. | — | ###### manageInviteInteractions How the invitee interacts with the signing journey: supporting documents, base/redirect URLs, rejection, custom message, and local language. | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `enableSupportingDocs` | boolean | No | Set to `true` to require supporting documents (provide `supportingDocumentConfig`). When `false`, any `supportingDocumentConfig` sent in the request is ignored. When `true`, a valid `supportingDocumentConfig` is required. | `true` | | `supportingDocumentConfig` | object | No | Supporting documents the invitee must upload. Active when `enableSupportingDocs = true`. See **supportingDocumentConfig** below. | — | | `baseUrl` | string | No | Base URL for the signing journey. | `https://client.example.com/sign` | | `redirectUrl` | string | No | URL the invitee is redirected to after completing signing. | `https://client.example.com/sign/complete` | | `enableRejection` | boolean | No | Set to `true` to allow the invitee to reject the document. | `true` | | `enforceRejectionMessage` | boolean | No | Set to `true` to require the invitee to enter a message when rejecting. Send it only alongside `enableRejection` set to `true`. | `false` | | `enableCustomMessage` | boolean | No | Set to `true` to show a custom message (provide `customMessageInput`). When `false`, any `customMessageInput` sent in the request is ignored. When `true`, a valid `customMessageInput` is required. | `true` | | `customMessageInput` | string | No | Custom message shown to the invitee. Active when `enableCustomMessage = true`. | `Please review and sign the loan agreement.` | | `enableLocalLanguage` | boolean | No | Set to `true` to offer the signing journey in a local language (provide `languageDefaultVsSignerSelect` and `localLanguageChooseDefault`). When `false`, the `languageDefaultVsSignerSelect` and `localLanguageChooseDefault` values sent are ignored. When `true`, `languageDefaultVsSignerSelect` and `localLanguageChooseDefault` are required. | `true` | | `languageDefaultVsSignerSelect` | string | No | Whether the language is fixed by you (`default`) or chosen by the signer (`signer-select`). Present when `enableLocalLanguage = true`. | `default` | | `localLanguageChooseDefault` | string | No | Default local-language code (for example, `hi`) when `languageDefaultVsSignerSelect = default`. | `hi` | ###### supportingDocumentConfig Supporting documents the invitee must upload. Active when `enableSupportingDocs = true`. | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `supportingDocuments` | array\ | No | List of supporting documents requested. Each entry is `{ uuid, supportingDocName, supportingDocFormat, supportingDocSize }`. See **supportingDocuments** below. | — | | `allowViewingSupportingDocs` | boolean | No | Set to `true` to let the pack's other invitees view the supporting documents this invitee uploads. Applies when you request supporting documents from this invitee. | `true` | ###### supportingDocuments | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `uuid` | string | Yes | Unique ID (UUID v4) for this supporting-document requirement. Leegality generates it if the supporting-document requirement is already configured in the workflow. If the workflow creator allows adding supporting-document requirements and you add one while sending, generate a new UUID v4 yourself. | `2a222222-2222-4222-8222-222222222222` | | `supportingDocName` | string | No | Name of the supporting document requested (for example, `ID Proof`). | `ID Proof` | | `supportingDocFormat` | string | No | Allowed file format for the supporting document (for example, `PDF`). | `PDF` | | `supportingDocSize` | integer | No | Declared size of the supporting document (bytes). | `2048` | ###### notifications Notification channel preferences for this invitee. | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `enableSmsNotifications` | boolean | No | Set to `true` to send SMS notifications to the invitee. | `true` | | `enableEmailNotifications` | boolean | No | Set to `true` to send email notifications to the invitee. | `true` | | `enableWhatsAppNotifications` | boolean | No | Set to `true` to send WhatsApp notifications to the invitee. | `false` | ###### contactBook Whether to save this invitee to your account's contact book. | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `addInviteeToContactBook` | boolean | No | Set to `true` to add the invitee to the [contact book](https://knowledge.leegality.com/document-execution/contact-book) for reuse. | `true` | | `inviteeLabel` | string | No | Label to tag the contact with (for example, `borrower`). | `borrower` | ###### certificateVerification Certificate-verification config performed against the invitee: Aadhaar, cloud-DSC, and DSC checks. Each enabled check must match for the signature to be accepted. | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `aadhaarVerifyCertificateDetails` | array\ | No | Aadhaar eSign certificate details verification. Each object maps to an invitee by index position. An object is always present for each invitee even if all verification fields are non-editable — in that case, only `uuid` is included. See **aadhaarVerifyCertificateDetails** below. | — | | `cloudDscVerifyCertificateDetails` | array\ | No | Cloud DSC (Cloud Digital Signature Certificate) details verification. See **cloudDscVerifyCertificateDetails** below. | — | | `dscVerifyCertificateDetails` | array\ | No | DSC (Digital Signature Certificate) details verification. Each object maps to an invitee by index position. An object is always present for each invitee even if all verification fields are non-editable — in that case, only `uuid` is included. See **dscVerifyCertificateDetails** below. | — | ###### aadhaarVerifyCertificateDetails | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `uuid` | string | No | Unique identifier for this certificate verification object. Always present, even when all other fields are non-editable. | `a1b2c3d4-5678-4abc-9def-012345678901` | | `aadhaarVerifyName` | boolean | No | Set to `true` to verify the signer's name against the Aadhaar record. | `false` | | `aadhaarSmartNameVerify` | boolean | No | Set to `true` to allow AI-based Smart name verification. | `false` | | `aadhaarVerifyYob` | string | No | Enter the year of birth that will be verified against the Aadhaar record (for example, `1997`). | `1997` | | `aadhaarVerifyState` | string | No | Enter the state that will be verified against the Aadhaar record. | `bihar` | | `aadhaarVerifyTitle` | string | No | Enter the last 4 digits of the signer's Aadhaar number that will be verified. | `3046` | | `aadhaarVerifyPincode` | integer | No | Enter the 6-digit pincode that will be verified against the Aadhaar record. | `845446` | | `aadhaarVerifyGender` | string | No | Enter the gender that will be verified against the Aadhaar record (`M` or `F`). | `M` | ###### cloudDscVerifyCertificateDetails | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `cloudDscVerifyName` | boolean | No | Set to `true` to verify the signer's name against the cloud DSC. | `true` | | `cloudDscSmartNameVerify` | boolean | No | Set to `true` to allow AI-based Smart name verification. | `false` | | `cloudDscVerifyState` | string | No | Enter the state that will be verified against the cloud DSC. | `Maharashtra` | | `cloudDscVerifyPincode` | integer | No | Enter the pincode that will be verified against the cloud DSC. | `400001` | ###### dscVerifyCertificateDetails | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `uuid` | string | No | Unique identifier for this certificate verification object. Always present, even when all other fields are non-editable. | `b2c3d4e5-6789-4abc-8def-123456789012` | | `dscVerifyName` | boolean | No | Set to `true` to verify the signer's name against the DSC. | `false` | | `dscSmartNameVerify` | boolean | No | Set to `true` to allow AI-based Smart name verification. | `false` | | `dscVerifyPincode` | integer | No | Enter the pincode that will be verified against the DSC. | `845449` | | `dscVerifyState` | string | No | Enter the state that will be verified against the DSC. | `bihar` | ###### reviewer Settings that apply when the invitee is a reviewer. | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `enableAuditTrail` | boolean | No | Set to `true` to include the reviewer's actions in the audit trail. | `true` | | `enableOtpForReview` | boolean | No | Set to `true` to require the reviewer to enter an OTP before reviewing. | `false` | ##### combinations | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `uuid` | string | Yes | Unique ID (UUID v4) for this combination. Leegality generates it if the combination is already configured in the workflow. If the workflow creator allows adding combinations and you add one while sending, generate a new UUID v4 yourself. Other items refer to this combination by `combinationUuid`. | `29bdb6fd-99a9-4501-b74b-d482d7ad5062` | | `assignedDocuments` | array\ | Yes | Documents assigned to the invitee in this combination. **Required.** See **assignedDocuments** below. | — | | `combinationSettings` | object | Yes | Per-combination (document-group scope) settings: eSign types, prioritisation, appearance, webhooks, consent, expiry, and payment. **Required.** See **combinationSettings** below. | — | ###### assignedDocuments | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `uuid` | string | Yes | Unique ID (UUID v4) for this assigned-document entry. Leegality generates it if the assigned-document entry is already configured in the workflow. If the workflow creator allows adding assigned-document entries and you add one while sending, generate a new UUID v4 yourself. | `cd7c1c46-af20-4452-9f6c-ca507705a8b9` | | `documentUuid` | string | Yes | Reference to a document. Must match the `uuid` of a document (`documents[]`) included in this same request. **Required.** | `711abfff-2057-48ac-909e-519f3f7415a4` | | `role` | string | Yes | Role the invitee plays on the assigned document. One of `signer`, `reviewer`. **Required.** | `signer` | ###### combinationSettings Per-combination (document-group scope) settings: eSign types, prioritisation, appearance, webhooks, consent, expiry, and payment. **Required.** | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `esignTypes` | object | No | Available eSign methods for this combination. Each type has its own `enable…` flag; a type is active only when that flag is `true`. **Required.** See **esignTypes** below. | — | | `eSignPrioritisation` | object | No | Priority order and retry policy across eSign methods, so signing can fall back from one method to the next. See **eSignPrioritisation** below. | — | | `signatureAppearance` | object | No | How the signature block looks on the document. See **signatureAppearance** below. | — | | `webhooks` | object | No | Per-combination webhook configuration. Omitting `webhooks` means no webhooks fire for this combination. See **webhooks** below. | — | | `customConsent` | object | No | Custom consent settings. See **customConsent** below. | — | | `expiry` | object | No | Invitation expiry settings. See **expiry** below. | — | | `paymentCollect` | object | No | Payment collection settings. Active when `enablePaymentCollect = true`. See **paymentCollect** below. | — | ###### esignTypes Available eSign methods for this combination. Each type has its own `enable…` flag; a type is active only when that flag is `true`. **Required.** | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `aadharEsign` | object | No | Aadhaar-based eSign. See **aadharEsign** below. | — | | `automatedEsign` | object | No | Automated (system) eSign using a pre-configured signing profile. See **automatedEsign** below. | — | | `quickSign` | object | No | Quick eSign (electronic signature, without PKI). See **quickSign** below. | — | | `visualSign` | object | No | Visual eSign (electronic signature with a visible appearance). See **visualSign** below. | — | | `virtualEsign` | object | No | Virtual eSign. See **virtualEsign** below. | — | | `dscToken` | object | No | DSC token-based signing (hardware Digital Signature Certificate). See **dscToken** below. | — | | `docSign` | object | No | DocSigner-based signing. See **docSign** below. | — | | `cloudDsc` | object | No | Cloud DSC-based signing. See **cloudDsc** below. | — | ###### aadharEsign Aadhaar-based eSign. | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `aadharEsignEnabled` | boolean | No | Set to `true` to allow Aadhaar eSign, then configure `aadhaarEsignConfig`. When `false`, any `aadhaarEsignConfig` sent in the request is ignored. When `true`, a valid `aadhaarEsignConfig` is required. | `true` | | `aadhaarEsignConfig` | object | No | Aadhaar eSign options. | — | ###### automatedEsign Automated (system) eSign using a pre-configured signing profile. | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `enableAutomatedSign` | boolean | No | Set to `true` to allow automated signing, then configure `automatedSignConfig`. When `false`, any `automatedSignConfig` sent in the request is ignored. When `true`, a valid `automatedSignConfig` is required. | `true` | | `automatedSignConfig` | object | No | Automated signing options. | — | ###### quickSign Quick eSign (electronic signature, without PKI). | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `enableQuickSign` | boolean | No | Set to `true` to allow Quick eSign, then configure `quickSignConfig`. When `false`, any `quickSignConfig` sent in the request is ignored. When `true`, a valid `quickSignConfig` is required. | `true` | | `quickSignConfig` | object | No | Quick eSign options. | — | ###### visualSign Visual eSign (electronic signature with a visible appearance). | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `enableVisualSign` | boolean | No | Set to `true` to allow Visual eSign, then configure `visualSignConfig`. When `false`, any `visualSignConfig` sent in the request is ignored. When `true`, a valid `visualSignConfig` is required. | `true` | | `visualSignConfig` | object | No | Visual eSign options. | — | ###### virtualEsign Virtual eSign. | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `virtualEsignEnabled` | boolean | No | Set to `true` to allow Virtual eSign, then configure `virtualEsignConfig`. When `false`, any `virtualEsignConfig` sent in the request is ignored. When `true`, a valid `virtualEsignConfig` is required. | `true` | | `virtualEsignConfig` | object | No | Virtual eSign options. | — | ###### dscToken DSC token-based signing (hardware Digital Signature Certificate). | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `enableDscToken` | boolean | No | Set to `true` to allow signing with a DSC token. | `true` | ###### docSign DocSigner-based signing. | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `enableDocSigner` | boolean | No | Set to `true` to allow signing via DocSigner. | `true` | ###### cloudDsc Cloud DSC-based signing. | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `enableCloudDsc` | boolean | No | Set to `true` to allow signing with a cloud DSC. | `true` | ###### eSignPrioritisation Priority order and retry policy across eSign methods, so signing can fall back from one method to the next. | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `orderLevelRetryCount` | boolean | No | Set to `true` to apply retry counts at the priority-order level (shared across priority types). | `true` | | `enableAadhaarPriority` | boolean | No | Functional toggle that drives whether Aadhaar-priority logic runs at sign time. When `true`, configure `aadhaarPriorityConfig`. When `false`, any `aadhaarPriorityConfig` sent in the request is ignored. When `true`, a valid `aadhaarPriorityConfig` is required. | `true` | | `aadhaarPriorityConfig` | object | No | Retry attempts and ordering for each Aadhaar authentication mode. See **aadhaarPriorityConfig** below. | — | ###### aadhaarPriorityConfig Retry attempts and ordering for each Aadhaar authentication mode. | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `prioritisationOtpRetryAttempts` | integer | No | Retry attempts allowed for Aadhaar OTP. | `1` | | `prioritisationOtpOrder` | integer | No | Priority-order position of Aadhaar OTP. | `2` | | `prioritisationBioRetryAttempts` | integer | No | Retry attempts allowed for Aadhaar biometric. | `1` | | `prioritisationBioOrder` | integer | No | Priority-order position of Aadhaar biometric. | `4` | | `prioritisationIrisRetryAttempts` | integer | No | Retry attempts allowed for Aadhaar iris. | `1` | | `prioritisationIrisOrder` | integer | No | Priority-order position of Aadhaar iris. | `4` | | `prioritisationFaceAuthRetryAttempts` | integer | No | Retry attempts allowed for Aadhaar face authentication. | `2` | | `prioritisationFaceAuthOrder` | integer | No | Priority-order position of Aadhaar face authentication. | `3` | ###### signatureAppearance How the signature block looks on the document. | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `allowEditingNameInSigningJourney` | boolean | No | Set to `true` to let the signer edit the name shown in their signature during signing. | `false` | | `displayNameInSignatureAppearances` | boolean | No | Set to `true` to display the signer's name in the signature appearance. | `true` | | `requireOrgSeal` | boolean | No | Set to `true` to include an organisation seal in the signature appearance. | `true` | | `orgNameInSeal` | string | No | Organisation name printed on the seal. | `Acme Corp` | | `orgSealType` | string | No | Type of organisation seal to use (for example, `CUSTOM`). | `CUSTOM` | ###### webhooks Per-combination webhook configuration. Omitting `webhooks` means no webhooks fire for this combination. | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `successWebhook` | string | No | The URL Leegality calls when the event completes successfully. | `https://integrator.example.com/webhooks/leegality/success` | | `errorWebhook` | string | No | The URL Leegality calls when an error occurs. | `https://integrator.example.com/webhooks/leegality/error` | | `webhookProfileId` | string | No | References a configured webhook profile (auth credentials, headers, retry policy). The profile does not carry the destination URL. | `8b9bfa84-3982-4ffe-a5b9-16a403eca7a1` | | `webhookVersion` | string | No | Webhook payload version. **Possible values:** - `VERSION_2.3` - `VERSION_2.5` - `VERSION_4.0` Required whenever `successWebhook` or `errorWebhook` is configured. Allowed: `VERSION_2.3`, `VERSION_2.5`, `VERSION_4.0`. | `VERSION_4.0` | ###### customConsent Custom consent settings. | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `enableCustomConsent` | boolean | No | Set to `true` to show a custom consent to the invitee (provide `customConsentInput`). | `true` | | `consentAutoCheck` | boolean | No | Set to `true` to pre-check the consent checkbox for the invitee. | `true` | | `customConsentAutoCheck` | boolean | No | Set to `true` to pre-check the custom consent checkbox for the invitee. | `true` | | `customConsentInput` | string | No | Custom consent text shown to the invitee. Active when `enableCustomConsent = true`. | `null` | ###### expiry Invitation expiry settings. | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `enableExpiry` | boolean | No | Set to `true` to expire the invitation after a set number of days (provide `expiry`). When `false`, any `expiry` sent in the request is ignored. When `true`, a valid `expiry` is required. | `true` | | `expiry` | integer | No | When the invitation expires. Applies when `enableExpiry` is `true`. **Possible values:** - `-1` — 45 minutes - `0` — same day - `1` to `365` — that many days (`1` = next day, end of day) | `30` | ###### paymentCollect Payment collection settings. Active when `enablePaymentCollect = true`. | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `enablePaymentCollect` | boolean | No | Set to `true` to collect a payment before signing (fill in the fields below). When `false`, the payment fields are ignored. | `true` | | `paymentProfile` | string | No | ID of the payment profile used to collect the payment. | `23931d8d-9edb-4895-adee-e296dcba07c9` | | `paymentAmount` | integer | No | Amount to collect from the invitee. | `500` | | `customMessagePaymentPage` | string | No | Custom message shown on the payment page. Send it only alongside `paymentAmount`. | `Stamp duty payment required.` | #### cc | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `uuid` | string | Yes | Unique ID (UUID v4) for this CC recipient. Leegality generates it if the CC recipient is already configured in the workflow. If the workflow creator allows adding CC recipients and you add one while sending, generate a new UUID v4 yourself. | `4a444444-4444-4444-8444-444444444444` | | `name` | string | Yes | CC recipient name. **Required.** | `CC Person` | | `email` | string | Yes | CC recipient email. **Required.** | `cc@g.com` | | `invitationNotifications` | boolean | No | Set to `true` to notify the CC recipient when invitations are sent. | `true` | | `signingNotifications` | boolean | No | Set to `true` to notify the CC recipient each time an invitee signs. | `true` | | `completionNotifications` | boolean | No | Set to `true` to notify the CC recipient when the pack is completed. | `true` | | `failureNotifications` | boolean | No | Set to `true` to notify the CC recipient if the pack fails. | `true` | | `sendInvitationUrl` | boolean | No | Set to `true` to include the signing/invitation URL in notifications to the CC recipient. | `true` | | `shareDocAuditTrail` | boolean | No | Set to `true` to share the document audit trail with the CC recipient on completion. | `true` | | `recordAuditTrail` | boolean | No | Set to `true` to record the CC recipient's notifications in the audit trail. | `true` | | `addInviteeToContactBook` | boolean | No | Set to `true` to save the CC invitee in Leegality's [contact book](https://knowledge.leegality.com/document-execution/contact-book) for reuse. | `true` | #### coordinates | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `uuid` | string | Yes | Unique ID (UUID v4) for this coordinate. Leegality generates it if the coordinate is already configured in the workflow. If the workflow creator allows adding coordinates and you add one while sending, generate a new UUID v4 yourself. | `5c047eb0-aa4d-4e68-8ef7-617b8ec2e87d` | | `inviteeUuid` | string | Yes | The invitee whose signature this entry places. Must match the `uuid` of an invitee (`invitees[]`) included in this same request. **Required.** | `8bc21487-b200-4130-8240-a5f1715244dc` | | `appearances` | array\ | Yes | Individual signature placements for the invitee across documents and pages. **Required.** See **appearances** below. | — | | `groupSigningSlot` | integer | No | Threshold-signing slot for a group signer (`groupSigner`). **Required when `groupThreshold > 1`** (valid range `1..groupThreshold`); when the threshold is `1` it is optional (must be `1` if sent). Reviewers and group reviewers never receive coordinates. Slots are claimed in signing order, not bound to a specific member. | `1` | ##### appearances | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `uuid` | string | Yes | Unique ID (UUID v4) for this signature appearance. Leegality generates it if the signature appearance is already configured in the workflow. If the workflow creator allows adding signature appearances and you add one while sending, generate a new UUID v4 yourself. | `c39d44b6-6135-4279-a4b6-2bc53dce2fdc` | | `documentUuid` | string | Yes | The document this appearance is placed on. Must match the `uuid` of a document (`documents[]`) included in this same request. **Required.** | `711abfff-2057-48ac-909e-519f3f7415a4` | | `subDocumentUuid` | string | Yes | The sub-document this appearance is placed on. Must match the `uuid` of a sub-document (`documents[].subDocuments[]`) included in this same request. **Required.** | `795df69d-12c9-4959-be9a-9a73a2e1dd30` | | `combinationUuid` | string | Yes | The combination this appearance belongs to. Must match the `uuid` of a combination (`invitees[].combinations[]`) included in this same request. An invitee can have multiple combinations over the same document, so it can't be inferred automatically. | `29bdb6fd-99a9-4501-b74b-d482d7ad5062` | | `pageNo` | string | Yes | Page number on which to place the appearance (1-indexed, as a string). **Required.** | `1` | | `rect` | object | Yes | Placement rectangle `{ x1Axis, y1Axis, x2Axis, y2Axis }` (coordinates as strings). **Required.** See **rect** below. | — | | `type` | string | Yes | Placement type. **Required.** **Possible values:** - `FULL_DOC` - `SUB_DOC` - `CUSTOM` - `DEFAULT` Allowed: `FULL_DOC`, `SUB_DOC`, `CUSTOM`, `DEFAULT`. | `FULL_DOC` | | `subDocumentType` | string | No | The sub-document's type. Pass the value that matches the sub-document: **Possible values:** - `PDF` — for a PDF - `STAMP` — for a stamp - `TEMPLATE` — for a template Allowed: `PDF`, `STAMP`, `TEMPLATE`. | `PDF` | ###### rect Placement rectangle `{ x1Axis, y1Axis, x2Axis, y2Axis }` (coordinates as strings). **Required.** | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `x1Axis` | string | Yes | X coordinate of the rectangle's first corner (string). | `350` | | `y1Axis` | string | Yes | Y coordinate of the rectangle's first corner (string). | `680` | | `x2Axis` | string | Yes | X coordinate of the rectangle's opposite corner (string). | `550` | | `y2Axis` | string | Yes | Y coordinate of the rectangle's opposite corner (string). | `720` | ### Sample Request ```json { "workflowId": "70843c25-8d80-40ac-ab6b-edba12abd495", "pack": { "packName": "Home Loan Agreement - Rajesh Kumar", "packIrn": "IRN-2026-001234", "packUrn": "21312313131", "packFolderId": "K4wFolder", "deleteOnComplete": false, "sftpProfileId": "07aba168-b55b-4889-bddf-9012fa853e61", "brandingProfileId": "branding-001", "lecf_loanId": "LOAN-2026-5678", "lecf_branchCode": "MUM-001", "signingOrder": { "setSigningOrder": true, "preventChangesToSigningOrder": false, "setAdvanceSigningOrder": false } }, "documents": [ { "uuid": "711abfff-2057-48ac-909e-519f3f7415a4", "documentName": "Loan Agreement", "irn": "DOC-IRN-001", "documentFolderId": "K4wKEBB", "subDocuments": [ { "uuid": "795df69d-12c9-4959-be9a-9a73a2e1dd30", "templateId": "tpl_mapping_abc123", "templateVersion": "1.0", "allowFirstInviteeToFill": true, "templateFieldValues": [ { "fieldId": "f1a23456-78bc-4def-9012-3456789abcde", "fieldValue": "Rajesh Kumar", "fieldName": "borrower name" } ], "enableRevenueStamp": true, "revenueStamp": { "revenueStampQuantity": 1, "revenueStampId": "10" }, "enableStampSeries": true, "stampSeries": [ { "uuid": "0a1b2c3d-4e5f-4abc-8def-0123456789ab", "stampSeriesId": "01", "stampQuantities": 1 } ], "enableStampUpload": true, "stampUpload": { "stampUploadState": "PB", "stampUploadedFile": { "file": "f8cb424a-9580-4d84-8817-31f9d7887c0e" }, "stampUploadDenomination": 100, "stampUploadFirstPartyName": "John Doe", "stampUploadSecondPartyName": "Jane Smith", "stampUploadSerialNumber": "123" }, "enableStampGroup": true, "stampGroup": { "stampGroupId": "PB01", "stampGroupAmount": 1 }, "file": "95ded759-0b03-4c6b-91bd-45f049893972" } ], "stamps": { "enableStamp": true, "enableRevenueStamp": true, "revenueStamp": { "revenueStampQuantity": 1, "revenueStampId": "10" }, "enableStampSeries": true, "stampSeries": [ { "uuid": "1a2b3c4d-5e6f-4a7b-8c9d-0e1f2a3b4c5e", "stampSeriesId": "01", "stampQuantities": 1 } ], "enableStampGroup": true, "stampGroup": { "stampGroupId": "PB01", "stampGroupAmount": 10 }, "enableStampUpload": true, "stampUpload": { "stampUploadSerialNumber": "SERIAL001", "stampUploadFirstPartyName": "Alice", "stampUploadDenomination": 100, "stampUploadedFile": { "file": "f8cb424a-9580-4d84-8817-31f9d7887c0e" }, "stampUploadState": "PB", "stampUploadSecondPartyName": "Bob" } }, "referenceAttachment": { "enableReferenceAttachment": true, "referenceAttachmentFiles": [ { "uuid": "23c96e97-813a-4a6c-9c37-e939f54d597d", "file": "739fa0b6-91fb-4c98-944c-cb74e7dfe400" } ] }, "lecf_documentCategory": "CONTRACT" } ], "invitees": [ { "uuid": "8bc21487-b200-4130-8240-a5f1715244dc", "type": "signer", "level": 1, "groupName": "", "groupThreshold": 2, "inviteeDetails": [ { "uuid": "1aa11111-1111-4111-8111-111111111111", "inviteeName": "Rajesh Kumar", "inviteeLabel": "borrower", "inviteeEmail": "rajesh@example.com", "inviteePhone": "9820000001", "enableWhatsAppMandatoryNotifications": false, "lecf_employeeCode": "EMP-00921" } ], "inviteeSettings": { "securityOptions": { "oneFactorAuthentication": false, "twoFactorAuthentication": true, "gps": { "enabled": true, "accuracyBasedRestriction": true, "accuracyThreshold": 12, "locationBasedRestriction": true, "latitude": 23.34, "longitude": 72.88, "permissibleRadius": 100, "restrictToIndia": true, "enableLatLngRadius": true }, "faceCapture": { "enabled": true, "liveliness": true, "match": true, "faceMatchRetryAttempts": 2, "faceMatch": [ { "uuid": "3a333333-3333-4333-8333-333333333333", "faceMatchImage": { "file": "7e82aa31-16b9-4699-a94a-af12d5d3488c" } } ], "livelinessRetryAttempts": 3 }, "docDownloadLinkWithOtp": false, "maskContactDetails": false }, "manageInviteInteractions": { "enableSupportingDocs": true, "supportingDocumentConfig": { "supportingDocuments": [ { "uuid": "2a222222-2222-4222-8222-222222222222", "supportingDocName": "ID Proof", "supportingDocFormat": "PDF", "supportingDocSize": 2048 } ], "allowViewingSupportingDocs": true }, "baseUrl": "https://client.example.com/sign", "redirectUrl": "https://client.example.com/sign/complete", "enableRejection": true, "enforceRejectionMessage": false, "enableCustomMessage": true, "customMessageInput": "Please review and sign the loan agreement.", "enableLocalLanguage": true, "languageDefaultVsSignerSelect": "default", "localLanguageChooseDefault": "hi" }, "notifications": { "enableSmsNotifications": true, "enableEmailNotifications": true, "enableWhatsAppNotifications": false }, "contactBook": { "addInviteeToContactBook": true, "inviteeLabel": "borrower" }, "certificateVerification": { "aadhaarVerifyCertificateDetails": [ { "uuid": "a1b2c3d4-5678-4abc-9def-012345678901", "aadhaarVerifyName": false, "aadhaarSmartNameVerify": false, "aadhaarVerifyYob": "1997", "aadhaarVerifyState": "bihar", "aadhaarVerifyTitle": "3046", "aadhaarVerifyPincode": 845446, "aadhaarVerifyGender": "M" } ], "cloudDscVerifyCertificateDetails": [ { "cloudDscVerifyName": true, "cloudDscSmartNameVerify": false, "cloudDscVerifyState": "Maharashtra", "cloudDscVerifyPincode": 400001 } ], "dscVerifyCertificateDetails": [ { "uuid": "b2c3d4e5-6789-4abc-8def-123456789012", "dscVerifyName": false, "dscSmartNameVerify": false, "dscVerifyPincode": 845449, "dscVerifyState": "bihar" } ] }, "reviewer": { "enableAuditTrail": true, "enableOtpForReview": false } }, "combinations": [ { "uuid": "29bdb6fd-99a9-4501-b74b-d482d7ad5062", "assignedDocuments": [ { "uuid": "cd7c1c46-af20-4452-9f6c-ca507705a8b9", "documentUuid": "711abfff-2057-48ac-909e-519f3f7415a4", "role": "signer" } ], "combinationSettings": { "esignTypes": { "aadharEsign": { "aadharEsignEnabled": true, "aadhaarEsignConfig": { "aadhaarOtp": true, "aadhaarBio": false, "aadhaarIris": false, "aadhaarFace": false, "aadhaarSetMaxRetryAttempts": true, "aadhaarMaxRetryAttempts": 3 } }, "automatedEsign": { "enableAutomatedSign": true, "automatedSignConfig": { "automatedSignProfile": "auto-profile-001", "automatedSignPassword": "secret" } }, "quickSign": { "enableQuickSign": true, "quickSignConfig": { "quickSignDraw": true, "quickSignAutoGenerate": true, "quickSignFingerprint": false } }, "visualSign": { "enableVisualSign": true, "visualSignConfig": { "visualSignDraw": true, "visualSignAutoGenerate": true, "visualSignFingerprint": false, "visualSignUpload": true } }, "virtualEsign": { "virtualEsignEnabled": true, "virtualEsignConfig": { "virtualDrawSignature": true, "virtualSelect": true, "virtualFingerprint": false, "virtualSignUpload": false } }, "dscToken": { "enableDscToken": true }, "docSign": { "enableDocSigner": true }, "cloudDsc": { "enableCloudDsc": true } }, "eSignPrioritisation": { "orderLevelRetryCount": true, "enableAadhaarPriority": true, "aadhaarPriorityConfig": { "prioritisationOtpRetryAttempts": 1, "prioritisationOtpOrder": 2, "prioritisationBioRetryAttempts": 1, "prioritisationBioOrder": 4, "prioritisationIrisRetryAttempts": 1, "prioritisationIrisOrder": 4, "prioritisationFaceAuthRetryAttempts": 2, "prioritisationFaceAuthOrder": 3 } }, "signatureAppearance": { "allowEditingNameInSigningJourney": false, "displayNameInSignatureAppearances": true, "requireOrgSeal": true, "orgNameInSeal": "Acme Corp", "orgSealType": "CUSTOM" }, "webhooks": { "successWebhook": "https://integrator.example.com/webhooks/leegality/success", "errorWebhook": "https://integrator.example.com/webhooks/leegality/error", "webhookProfileId": "8b9bfa84-3982-4ffe-a5b9-16a403eca7a1", "webhookVersion": "VERSION_4.0" }, "customConsent": { "enableCustomConsent": true, "consentAutoCheck": true, "customConsentAutoCheck": true, "customConsentInput": null }, "expiry": { "enableExpiry": true, "expiry": 30 }, "paymentCollect": { "enablePaymentCollect": true, "paymentProfile": "23931d8d-9edb-4895-adee-e296dcba07c9", "paymentAmount": 500, "customMessagePaymentPage": "Stamp duty payment required." } } } ], "lecf_customerId": "CUST-8842" } ], "cc": [ { "uuid": "4a444444-4444-4444-8444-444444444444", "name": "CC Person", "email": "cc@g.com", "invitationNotifications": true, "signingNotifications": true, "completionNotifications": true, "failureNotifications": true, "sendInvitationUrl": true, "shareDocAuditTrail": true, "recordAuditTrail": true, "addInviteeToContactBook": true } ], "coordinates": [ { "uuid": "5c047eb0-aa4d-4e68-8ef7-617b8ec2e87d", "inviteeUuid": "8bc21487-b200-4130-8240-a5f1715244dc", "appearances": [ { "uuid": "c39d44b6-6135-4279-a4b6-2bc53dce2fdc", "documentUuid": "711abfff-2057-48ac-909e-519f3f7415a4", "subDocumentUuid": "795df69d-12c9-4959-be9a-9a73a2e1dd30", "combinationUuid": "29bdb6fd-99a9-4501-b74b-d482d7ad5062", "pageNo": "1", "rect": { "x1Axis": "350", "y1Axis": "680", "x2Axis": "550", "y2Axis": "720" }, "type": "FULL_DOC", "subDocumentType": "PDF" } ], "groupSigningSlot": 1 } ] } ``` --- ## Responses ### 202 — Request accepted for asynchronous processing. The pack is validated synchronously; if it passes, document generation and notifications happen in the background. | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `code` | string | No | Result code for the submission. `SUCCESS` means the request was accepted for processing. | `SUCCESS` | | `message` | string | No | Human-readable status message. | `Pack Creation Submitted` | | `data` | object | No | See **data** below. | — | #### data | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `workflowRunContextId` | string | No | Unique ID for this submission. Use it with the **Check request status** API to check the workflow's status, and with **Check Pack Details** to view the created pack. | `a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6` | | `requestStatus` | string | No | Processing status. Starts as `PROCESSING`; poll the status API until it becomes `COMPLETED`, `FAILED`, or `VALIDATION_FAILED`. | `PROCESSING` | ### Sample Response (202) ```json { "code": "SUCCESS", "message": "Pack Creation Submitted", "data": { "workflowRunContextId": "a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6", "requestStatus": "PROCESSING" } } ``` --- URL: https://knowledge.leegality.com/document-execution/api/check-request-status # GET /v4/request/{workflowRunContextId}/status — Check request status :::info[Sandbox endpoint] **Authentication:** `X-Auth-Token` header required on every request. ## Request URL ``` GET https://app1.leegality.com/api/v4/request/{workflowRunContextId}/status ``` **Environments:** - Production: `https://app1.leegality.com/api/v4/request/{workflowRunContextId}/status` - Sandbox: `https://sandbox.leegality.com/api/v4/request/{workflowRunContextId}/status` --- ## Parameters | Name | In | Required | Type | Description | Example | |------|----|----------|------|-------------|---------| | `workflowRunContextId` | path | Yes | string | Type: Path parameter Unique identifier of the request. You get this value in the response of the **[Send Pack for eSigning (Async)](https://knowledge.leegality.com/document-execution/api/create-pack)** API. | — | --- ## Responses ### 200 — Request status retrieved successfully. | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `code` | string | No | Result code. | `SUCCESS` | | `message` | string | No | Human-readable status message. | `Status fetched` | | `data` | PackRequestStatusResponse | No | See **PackRequestStatusResponse** below. | — | #### PackRequestStatusResponse | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `requestStatus` | string | No | The processing status of the request. **Possible values:** - `PROCESSING` - `COMPLETED` - `FAILED` - `VALIDATION_FAILED` Allowed: `PROCESSING`, `COMPLETED`, `FAILED`, `VALIDATION_FAILED`. | `FAILED` | | `failureReason` | string | No | Reason for failure. Present when `requestStatus` is `FAILED` or `VALIDATION_FAILED`; `null` otherwise. | `Duplicate URN not allowed. Urn: 123, Resource Level: DOCUMEN` | ### Sample Response (200) ```json { "code": "SUCCESS", "message": "Status fetched", "data": { "requestStatus": "FAILED", "failureReason": "Duplicate URN not allowed. Urn: 123, Resource Level: DOCUMENT_PACK" } } ``` --- URL: https://knowledge.leegality.com/document-execution/api/check-pack-details # GET /v4/packs — Check Pack Details :::info[Sandbox endpoint] **Authentication:** `X-Auth-Token` header required on every request. ## Request URL ``` GET https://app1.leegality.com/api/v4/packs?packId={packId}&packUrn={packUrn}&workflowRunContextId={workflowRunContextId}&payloadForPackEdit={payloadForPackEdit}&workflowDetails={workflowDetails}&account={account}&sender={sender}&packFolder={packFolder}&sftp={sftp}&deleteOnComplete={deleteOnComplete}&signingOrder={signingOrder}&customFields={customFields}&cc={cc}&coordinates={coordinates}&documentFolder={documentFolder}&file={file}&auditTrail={auditTrail}&referenceAttachments={referenceAttachments}&scheduledDeletionDate={scheduledDeletionDate}&stampDetails={stampDetails}&subDocuments={subDocuments}&subDocuments_template={subDocuments_template}&combinationResponse={combinationResponse}&combinationResponse_supportingDocuments={combinationResponse_supportingDocuments}&combinationResponse_verificationResult={combinationResponse_verificationResult}&combinationResponse_verificationResult_cloudDscVerifyCertificateDetails={combinationResponse_verificationResult_cloudDscVerifyCertificateDetails}&combinationResponse_verificationResult_dscVerifyCertificateDetails={combinationResponse_verificationResult_dscVerifyCertificateDetails}&combinationResponse_verificationResult_faceMatch={combinationResponse_verificationResult_faceMatch}&combinationResponse_verificationResult_smartUserLiveliness={combinationResponse_verificationResult_smartUserLiveliness}&combinationConfig={combinationConfig}&combinationConfig_combinationSettings={combinationConfig_combinationSettings}&combinationConfig_combinationSettings_eSignPrioritisation={combinationConfig_combinationSettings_eSignPrioritisation}&combinationConfig_combinationSettings_signatureAppearance={combinationConfig_combinationSettings_signatureAppearance}&combinationConfig_combinationSettings_customConsent={combinationConfig_combinationSettings_customConsent}&combinationConfig_combinationSettings_webhooks={combinationConfig_combinationSettings_webhooks}&combinationConfig_combinationSettings_paymentCollect={combinationConfig_combinationSettings_paymentCollect}&combinationConfig_combinationSettings_reviewerConfig={combinationConfig_combinationSettings_reviewerConfig}&inviteeSettings={inviteeSettings}&inviteeSettings_securityOptions={inviteeSettings_securityOptions}&inviteeSettings_securityOptions_gps={inviteeSettings_securityOptions_gps}&inviteeSettings_securityOptions_faceCapture={inviteeSettings_securityOptions_faceCapture}&inviteeSettings_securityOptions_docDownloadLinkWithOtp={inviteeSettings_securityOptions_docDownloadLinkWithOtp}&inviteeSettings_securityOptions_maskContactDetails={inviteeSettings_securityOptions_maskContactDetails}&inviteeSettings_manageInviteInteractions={inviteeSettings_manageInviteInteractions}&inviteeSettings_manageInviteInteractions_supportingDocumentConfig={inviteeSettings_manageInviteInteractions_supportingDocumentConfig}&inviteeSettings_manageInviteInteractions_language={inviteeSettings_manageInviteInteractions_language}&inviteeSettings_certificateVerification={inviteeSettings_certificateVerification}&inviteeSettings_certificateVerification_cloudDscVerifyCertificateDetails={inviteeSettings_certificateVerification_cloudDscVerifyCertificateDetails}&inviteeSettings_certificateVerification_dscVerifyCertificateDetails={inviteeSettings_certificateVerification_dscVerifyCertificateDetails} ``` **Environments:** - Production: `https://app1.leegality.com/api/v4/packs` - Sandbox: `https://sandbox.leegality.com/api/v4/packs` --- ## Parameters | Name | In | Required | Type | Description | Example | |------|----|----------|------|-------------|---------| | `packId` | query | No | string | Provide exactly one of `packId`, `urn`, or `workflowRunContextId` to select the pack. The Leegality pack ID (ULID) returned when the pack was created. | — | | `packUrn` | query | No | string | Provide exactly one of `packId`, `packUrn`, or `workflowRunContextId` to select the pack. Your Unique Reference Number (URN) set on the pack at creation time. | — | | `workflowRunContextId` | query | No | string | Provide exactly one of `packId`, `urn`, or `workflowRunContextId` to select the pack. The workflow run context ID returned by the Send Pack for eSigning (Async) API. | — | | `payloadForPackEdit` | query | No | boolean | Master switch — set to `true` to include **every** section below at once (auto-enables all the other flags). | — | | `workflowDetails` | query | No | boolean | Set to `true` to include the `workflow` object on the pack (currently the workflow `name`). | — | | `account` | query | No | boolean | Set to `true` to include the `account` object on the pack — organisation `id`, `name`, department `label`, and `brandName`. | — | | `sender` | query | No | boolean | Set to `true` to include the `sender` object on the pack (`username` and `name`). | — | | `packFolder` | query | No | boolean | Set to `true` to include the `packFolder` object (folder `id` and `name`). | — | | `sftp` | query | No | boolean | Set to `true` to include the SFTP configuration (`enabled` flag and `profileId`). | — | | `deleteOnComplete` | query | No | boolean | Set to `true` to include the `deleteOnComplete` flag on the pack. | — | | `signingOrder` | query | No | boolean | Set to `true` to include the signing-order configuration (`setSigningOrder`, `preventChangesToSigningOrder`). | — | | `customFields` | query | No | boolean | Set to `true` to include Legal Entity Custom Fields (`lecf_*`). This single flag populates custom fields wherever they exist — on the pack, on each document (e.g. `lecf_documentCategory`), and on each invitation/invitee (e.g. `lecf_groupRegion`, `lecf_customerId`). | — | | `cc` | query | No | boolean | Set to `true` to include the top-level `cc` array — carbon-copy recipients and their notification settings. | — | | `coordinates` | query | No | boolean | Set to `true` to include the top-level `coordinates` array — signature appearance coordinates per invitee. | — | | `documentFolder` | query | No | boolean | Set to `true` to include each document's folder (`documentFolderId` and `documentFolderName`). | — | | `file` | query | No | boolean | Set to `true` to include the signed document download URL (`file`) on each document. | — | | `auditTrail` | query | No | boolean | Set to `true` to include the audit trail download URL (`auditTrail`). Returned only for documents whose `status` is `COMPLETED`. | — | | `referenceAttachments` | query | No | boolean | Set to `true` to include the `referenceAttachments` uploaded alongside each document. | — | | `scheduledDeletionDate` | query | No | boolean | Set to `true` to include the `scheduledDeletionDate` for each document. | — | | `stampDetails` | query | No | boolean | Set to `true` to include stamp details (revenue stamp, stamp series, stamp group, and stamp upload) on the document and its sub-documents. | — | | `subDocuments` | query | No | boolean | Set to `true` to include the `subDocuments` array on each document. Note: sub-documents are also returned automatically when `template` or `stampDetails` is enabled. | — | | `subDocuments_template` | query | No | boolean | Set to `true` to include template details on each sub-document (`template`: `id`, `name`, `version`, `allowFirstInviteeToFill`, `templateFieldValues`). Only takes effect when `subDocuments` is also `true`. | — | | `combinationResponse` | query | No | boolean | Set to `true` to include the `combinationResponse` array on each invitee — execution results per signing combination (assigned documents, signature options used, sign time). | — | | `combinationResponse_supportingDocuments` | query | No | boolean | Set to `true` to include `supportingDocuments` submitted by the invitee during signing. Requires all ancestor flags (`combinationResponse`) to also be `true`; otherwise it has no effect. | — | | `combinationResponse_verificationResult` | query | No | boolean | Set to `true` to include the `verificationResult` for each signed document (Aadhaar certificate details, smart-name match, verification status). Requires all ancestor flags (`combinationResponse`) to also be `true`; otherwise it has no effect. | — | | `combinationResponse_verificationResult_cloudDscVerifyCertificateDetails` | query | No | boolean | Set to `true` to include Cloud DSC certificate verification details within the verification result. Requires all ancestor flags (`combinationResponse`, `combinationResponse_verificationResult`) to also be `true`; otherwise it has no effect. | — | | `combinationResponse_verificationResult_dscVerifyCertificateDetails` | query | No | boolean | Set to `true` to include DSC certificate verification details within the verification result. Requires all ancestor flags (`combinationResponse`, `combinationResponse_verificationResult`) to also be `true`; otherwise it has no effect. | — | | `combinationResponse_verificationResult_faceMatch` | query | No | boolean | Set to `true` to include face-match verification results within the verification result. Requires all ancestor flags (`combinationResponse`, `combinationResponse_verificationResult`) to also be `true`; otherwise it has no effect. | — | | `combinationResponse_verificationResult_smartUserLiveliness` | query | No | boolean | Set to `true` to include smart user liveliness verification results within the verification result. Requires all ancestor flags (`combinationResponse`, `combinationResponse_verificationResult`) to also be `true`; otherwise it has no effect. | — | | `combinationConfig` | query | No | boolean | Set to `true` to include the combination configuration (`combinationsConfigInfo`) for the invitee group — combinations, their assigned documents, and expiry. | — | | `combinationConfig_combinationSettings` | query | No | boolean | Set to `true` to include the `combinationSettings` for each combination (enabled eSign types and expiry). Requires all ancestor flags (`combinationConfig`) to also be `true`; otherwise it has no effect. | — | | `combinationConfig_combinationSettings_eSignPrioritisation` | query | No | boolean | Set to `true` to include the eSign prioritisation configuration. Requires all ancestor flags (`combinationConfig`, `combinationConfig_combinationSettings`) to also be `true`; otherwise it has no effect. | — | | `combinationConfig_combinationSettings_signatureAppearance` | query | No | boolean | Set to `true` to include the signature appearance configuration (name display, org seal). Requires all ancestor flags (`combinationConfig`, `combinationConfig_combinationSettings`) to also be `true`; otherwise it has no effect. | — | | `combinationConfig_combinationSettings_customConsent` | query | No | boolean | Set to `true` to include the custom consent configuration. Requires all ancestor flags (`combinationConfig`, `combinationConfig_combinationSettings`) to also be `true`; otherwise it has no effect. | — | | `combinationConfig_combinationSettings_webhooks` | query | No | boolean | Set to `true` to include the webhook configuration (success/error URLs, profile id, version). Requires all ancestor flags (`combinationConfig`, `combinationConfig_combinationSettings`) to also be `true`; otherwise it has no effect. | — | | `combinationConfig_combinationSettings_paymentCollect` | query | No | boolean | Set to `true` to include the payment collection configuration. Requires all ancestor flags (`combinationConfig`, `combinationConfig_combinationSettings`) to also be `true`; otherwise it has no effect. | — | | `combinationConfig_combinationSettings_reviewerConfig` | query | No | boolean | Set to `true` to include the reviewer configuration (`recordReviewerResponse`, `requireOtpToReview`). Requires all ancestor flags (`combinationConfig`, `combinationConfig_combinationSettings`) to also be `true`; otherwise it has no effect. | — | | `inviteeSettings` | query | No | boolean | Set to `true` to include `inviteeSettings`, starting with notification preferences (email, SMS, WhatsApp). | — | | `inviteeSettings_securityOptions` | query | No | boolean | Set to `true` to include the invitee `securityOptions` (authentication factors). Requires all ancestor flags (`inviteeSettings`) to also be `true`; otherwise it has no effect. | — | | `inviteeSettings_securityOptions_gps` | query | No | boolean | Set to `true` to include GPS restriction settings. Requires all ancestor flags (`inviteeSettings`, `inviteeSettings_securityOptions`) to also be `true`; otherwise it has no effect. | — | | `inviteeSettings_securityOptions_faceCapture` | query | No | boolean | Set to `true` to include face capture / liveliness settings. Requires all ancestor flags (`inviteeSettings`, `inviteeSettings_securityOptions`) to also be `true`; otherwise it has no effect. | — | | `inviteeSettings_securityOptions_docDownloadLinkWithOtp` | query | No | boolean | Set to `true` to include the `docDownloadLinkWithOtp` flag. Requires all ancestor flags (`inviteeSettings`, `inviteeSettings_securityOptions`) to also be `true`; otherwise it has no effect. | — | | `inviteeSettings_securityOptions_maskContactDetails` | query | No | boolean | Set to `true` to include the `maskContactDetails` flag. Requires all ancestor flags (`inviteeSettings`, `inviteeSettings_securityOptions`) to also be `true`; otherwise it has no effect. | — | | `inviteeSettings_manageInviteInteractions` | query | No | boolean | Set to `true` to include invite interaction settings (base/redirect URLs, rejection, custom message, local language). Requires all ancestor flags (`inviteeSettings`) to also be `true`; otherwise it has no effect. | — | | `inviteeSettings_manageInviteInteractions_supportingDocumentConfig` | query | No | boolean | Set to `true` to include the supporting-document request configuration. Requires all ancestor flags (`inviteeSettings`, `inviteeSettings_manageInviteInteractions`) to also be `true`; otherwise it has no effect. | — | | `inviteeSettings_manageInviteInteractions_language` | query | No | boolean | Set to `true` to include the invitee's regional-language settings (`language`). Only takes effect when `inviteeSettings_manageInviteInteractions` is also `true`. | — | | `inviteeSettings_certificateVerification` | query | No | boolean | Set to `true` to include the certificate verification configuration bound to each recipient via `inviteeDetailsUuid`, with bare `verify*` keys. Requires all ancestor flags (`inviteeSettings`) to also be `true`; otherwise it has no effect. | — | | `inviteeSettings_certificateVerification_cloudDscVerifyCertificateDetails` | query | No | boolean | Set to `true` to include Cloud DSC certificate verification entries. Requires all ancestor flags (`inviteeSettings`, `inviteeSettings_certificateVerification`) to also be `true`; otherwise it has no effect. | — | | `inviteeSettings_certificateVerification_dscVerifyCertificateDetails` | query | No | boolean | Set to `true` to include DSC certificate verification entries. Requires all ancestor flags (`inviteeSettings`, `inviteeSettings_certificateVerification`) to also be `true`; otherwise it has no effect. | — | --- ## Responses ### 200 — Pack details. | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `data` | DocumentDetailsResponse | No | The pack payload (returned under `data`). By default it carries `pack`, `documents`, and `invitations` with their base fields; every other field is opt-in via the query flags. Send `payloadForPackEdit=true` to include everything. See **DocumentDetailsResponse** below. | — | #### DocumentDetailsResponse The pack payload (returned under `data`). By default it carries `pack`, `documents`, and `invitations` with their base fields; every other field is opt-in via the query flags. Send `payloadForPackEdit=true` to include everything. | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `pack` | object | Yes | Top-line pack details. Always present. See **pack** below. | — | | `documents` | array\ | Yes | The documents in the pack. Always present. See **documents** below. | — | | `coordinates` | array\ | No | Signature placements, grouped per invitee. Present only when `coordinates=true`. See **coordinates** below. | — | | `invitations` | array\ | Yes | The invitee groups on the pack. Always present (empty for DRAFT packs). See **invitations** below. | — | | `cc` | array\ | No | CC recipients on the pack. Present only when `cc=true`. See **cc** below. | — | ##### pack Top-line pack details. Always present. | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `packId` | string | No | Unique ID of the pack. | `01KZ8JV4Z7T3EZWMXGF3RNAYR5` | | `workflowId` | string | No | ID of the workflow the pack was created from. `null` for packs not tied to a workflow. | `a6295beb-650f-4dc0-81b4-df8e8faf2b7e` | | `status` | string | No | Current status of the pack. - `DRAFT` — Created but not yet sent. - `SENT` — Sent to invitees; signing is in progress. - `COMPLETED` — All required signing is done. - `EXPIRED` — The pack expired before it was completed. Allowed: `DRAFT`, `SENT`, `EXPIRED`, `COMPLETED`. | `COMPLETED` | | `createdAt` | string | No | When the pack was created (ISO 8601). | `2026-08-05T09:07:33Z` | | `completedAt` | string | No | When the pack was completed (ISO 8601). `null` until the pack completes. | `2026-08-05T09:12:00Z` | | `packName` | string | No | Display name of the pack. | `Home Loan Agreement` | | `packIrn` | string | No | Your Internal Reference Number for the pack. `null` if not set. | `IRN-2026-001234` | | `packUrn` | string | No | Your Unique Reference Number for the pack. `null` if not set. | `CLIENT-REF-001` | | `workflowRunContextId` | string | No | ID of the workflow run that produced this pack. | `8babd0af-a418-486e-b1cd-eb717fe97c35` | | `workflow` | object | No | Workflow details. Present only when `workflowDetails=true`. See **workflow** below. | — | | `account` | object | No | Account details. Present only when `account=true`. See **account** below. | — | | `sender` | object | No | The user who sent the pack. Present only when `sender=true`. See **sender** below. | — | | `packFolder` | object | No | The folder the pack is filed under. Present only when `packFolder=true` and a folder exists. See **packFolder** below. | — | | `sftp` | object | No | SFTP delivery configuration. Present only when `sftp=true`. See **sftp** below. | — | | `deleteOnComplete` | boolean | No | Whether the pack's documents are auto-deleted on completion. Present only when `deleteOnComplete=true`. | `false` | | `signingOrder` | object | No | Signing-order settings. Present only when `signingOrder=true`. See **signingOrder** below. | — | ###### workflow Workflow details. Present only when `workflowDetails=true`. | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `name` | string | No | Name of the workflow. | `Home Loan Workflow` | ###### account Account details. Present only when `account=true`. | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `id` | string | No | Account ID. | `acc_12345` | | `name` | string | No | Account name. | `Acme Corp` | | `label` | string | No | Account label (organisation subdomain). | `acme` | | `brandName` | string | No | Brand name shown to signers. `null` if not set. | `Acme` | ###### sender The user who sent the pack. Present only when `sender=true`. | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `username` | string | No | Sender's username (usually their email). | `ops@acme.com` | | `name` | string | No | Sender's display name. | `Operations Team` | ###### packFolder The folder the pack is filed under. Present only when `packFolder=true` and a folder exists. | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `id` | string | No | Folder ID. | `6Ucvh0i` | | `name` | string | No | Folder name. | `V3` | ###### sftp SFTP delivery configuration. Present only when `sftp=true`. | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `enabled` | boolean | No | Whether SFTP delivery is enabled for this pack. | `true` | | `profileId` | string | No | ID of the SFTP profile used. `null` when none is set. | `sftp_9012` | ###### signingOrder Signing-order settings. Present only when `signingOrder=true`. | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `signingOrderType` | string | No | How signing order is applied. - `OFF` — All invitees can sign in parallel. - `ON` — Invitees sign in a strict sequence. - `ADVANCED` — Mixed — some invitees are parallel, some sequential. Allowed: `OFF`, `ON`, `ADVANCED`. | `ON` | | `preventChangesToSigningOrder` | boolean | No | Whether the signing order is locked. `null` when not set. | `false` | ##### documents | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `documentId` | string | No | Unique ID of the document. | `01KZ8JV503BJMY8QHCDS86DAR4` | | `documentName` | string | No | Display name of the document. | `Loan Agreement` | | `irn` | string | No | Your Internal Reference Number for the document. `null` if not set. | `DOC-IRN-001` | | `status` | string | No | Current status of the document. - `DRAFT` — The document is in draft state. - `SENT` — The document still has invitees who need to sign or review it. - `PACK_PENDING_COMPLETION` — Signing is done; the pack is finalising. - `COMPLETED` — Fully signed and complete. Allowed: `DRAFT`, `SENT`, `PACK_PENDING_COMPLETION`, `COMPLETED`. | `COMPLETED` | | `documentFolderId` | string | No | ID of the document's folder. Present only when `documentFolder=true`. | `uvwmVVk` | | `documentFolderName` | string | No | Name of the document's folder. Present only when `documentFolder=true`. | `testing` | | `file` | string | No | Download link for the document at its current signing stage. Present only when `file=true`. `null` if the preview could not be generated. | `https://downloads.leegality.com/export/…` | | `auditTrail` | string | No | Download link for the audit trail. Present only when `auditTrail=true` and the document is `COMPLETED`. | `https://downloads.leegality.com/export/…` | | `referenceAttachments` | array\ | No | Reference attachments on the document. Present only when `referenceAttachments=true`. See **referenceAttachments** below. | — | | `scheduledDeletionDate` | string | No | When the document is scheduled to be deleted (ISO 8601). Present only when `scheduledDeletionDate=true`. | `2026-09-01T00:00:00Z` | | `stamps` | array\ | No | Stamp details for the document. Present only when `stampDetails=true` and the document has stamps. One entry per document. See **stamps** below. | — | | `subDocuments` | array\ | No | Sub-documents that make up this document. Present only when `subDocuments=true`. See **subDocuments** below. | — | ###### referenceAttachments | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `file` | string | No | Download link for the attachment. | `https://downloads.leegality.com/export/…` | | `name` | string | No | Attachment name. | `reference-document` | | `type` | string | No | Attachment file type. | `PDF` | ###### stamps | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `documentUuid` | string | No | The document's runner UUID. | `95f24138-03e7-4669-a3dd-0588a8d007a0` | | `subDocumentUuid` | string | No | Always `null` — the stamp belongs to the document, not a sub-document. | — | | `stampState` | string | No | State the stamps were drawn from. | `Karnataka` | | `totalStampDutyAmount` | number | No | Total stamp duty across the affixed stamps (sum of their denominations). `null` when nothing is affixed. | `200` | | `stampsAffixed` | array\ | No | The stamps physically affixed to this document. See **stampsAffixed** below. | — | | `revenueStamp` | object | No | Revenue-stamp config. `null`/empty in this release (no v4 stamp-config source yet). See **revenueStamp** below. | — | | `stampSeries` | array\ | No | Always empty in this release (no v4 source yet). | — | | `stampUpload` | object | No | Uploaded-stamp config. `null`/empty in this release. See **stampUpload** below. | — | | `stampGroup` | object | No | Stamp-group config. `null`/empty in this release. See **stampGroup** below. | — | ###### stampsAffixed | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `series` | string | No | Stamp series the stamp came from. | `01` | | `amount` | string | No | Denomination of the stamp. | `100.0` | | `serialNumber` | string | No | Serial number of the affixed stamp. | `IN-DL1234567890` | | `associatedDocumentId` | string | No | ID of the stamp document that landed here. | `XR701AC977` | ###### revenueStamp Revenue-stamp config. `null`/empty in this release (no v4 stamp-config source yet). | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `revenueStampQuantity` | integer | No | Number of revenue stamps. | — | | `revenueStampId` | string | No | Revenue stamp ID. | — | ###### stampUpload Uploaded-stamp config. `null`/empty in this release. | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `stampUploadSerialNumber` | string | No | Serial number. | — | | `stampUploadFirstPartyName` | string | No | First party name. | — | | `stampUploadDenomination` | string | No | Denomination. | — | | `stampUploadedFile` | object | No | The uploaded stamp file. See **stampUploadedFile** below. | — | | `stampUploadState` | string | No | State. | — | | `stampUploadSecondPartyName` | string | No | Second party name. | — | ###### stampUploadedFile The uploaded stamp file. | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `mediaId` | string | No | Media ID of the uploaded file. | — | ###### stampGroup Stamp-group config. `null`/empty in this release. | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `stampGroupId` | string | No | Stamp group ID. | — | | `stampGroupAmount` | string | No | Stamp group amount. | — | | `maximumValuePermitted` | string | No | Always `null` in v4. | — | ###### subDocuments | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `uuid` | string | No | Sub-document UUID. | `795df69d-12c9-4959-be9a-9a73a2e1dd30` | | `mediaId` | string | No | Media ID of the sub-document's file. | `95ded759-0b03-4c6b-91bd-45f049893972` | | `subDocumentType` | string | No | Media type of the sub-document. - `PDF` — A PDF file. - `STAMP` — A stamp page. - `HTML_TEMPLATE` — An HTML template. - `PDF_TEMPLATE` — A PDF template. - `DOCX_TEMPLATE` — A Word (DOCX) template. Allowed: `PDF`, `STAMP`, `HTML_TEMPLATE`, `PDF_TEMPLATE`, `DOCX_TEMPLATE`. | `PDF` | | `template` | object | No | Template details. Present only when `subDocuments_template=true`. All fields are `null` (and `templateFieldValues` empty) for non-template sub-documents. See **template** below. | — | ###### template Template details. Present only when `subDocuments_template=true`. All fields are `null` (and `templateFieldValues` empty) for non-template sub-documents. | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `id` | string | No | Template ID. | `tpl_mapping_abc123` | | `name` | string | No | Template display name. | `Loan Template` | | `version` | string | No | Template version pinned at pack creation. | `1` | | `allowFirstInviteeToFill` | boolean | No | Whether the first invitee fills the template fields during signing. | `true` | | `templateFieldValues` | array\ | No | The template's field values. See **templateFieldValues** below. | — | ###### templateFieldValues | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `id` | string | No | Field ID. | `f1a23456-78bc-4def-9012-3456789abcde` | | `name` | string | No | Field name. | `borrower name` | | `fieldType` | string | No | Type of the template field. - `text` — Single-line text. - `textarea` — Multi-line text. - `number` — A numeric value. - `checkbox` — A checkbox (true/false). - `radio` — A single choice from options. - `select` — A dropdown — single choice. - `multi-select` — A dropdown — multiple choices; the value is a JSON array string. - `file` — A file upload; the value is a mediaId. | `text` | | `value` | string | No | Field value. For `file`, the mediaId; for `multi-select`, a JSON array string. | `Rajesh Kumar` | | `isFilledBySender` | boolean | No | Whether the sender filled this field (read-only to the signer). | `true` | ##### coordinates | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `inviteeUuid` | string | No | ID of the invitee these placements belong to. | `8bc21487-b200-4130-8240-a5f1715244dc` | | `appearances` | array\ | No | The individual signature placements. See **appearances** below. | — | ###### appearances | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `documentUuid` | string | No | Runner UUID of the document. | `711abfff-2057-48ac-909e-519f3f7415a4` | | `subDocumentUuid` | string | No | Runner UUID of the sub-document. | `795df69d-12c9-4959-be9a-9a73a2e1dd30` | | `combinationUuid` | string | No | ID of the combination. | `29bdb6fd-99a9-4501-b74b-d482d7ad5062` | | `pageNo` | string | No | Page number. | `1` | | `rect` | object | No | Placement rectangle. See **rect** below. | — | ###### rect Placement rectangle. | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `x1Axis` | string | No | X of the first corner. | `350` | | `y1Axis` | string | No | Y of the first corner. | `680` | | `x2Axis` | string | No | X of the opposite corner. | `550` | | `y2Axis` | string | No | Y of the opposite corner. | `720` | ##### invitations | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `uuid` | string | No | ID of the invitee group. | `1342a359-2364-4e0a-9b21-6f3a2c1d4e5f` | | `groupName` | string | No | Name of the invitee group. `null` for an individual invitee. | `Borrower` | | `inviteeGroupThreshold` | integer | No | Minimum members required to complete the group's action. | `1` | | `inviteeType` | string | No | Type of invitee. - `signer` — Signs the document(s). - `reviewer` — Reviews and approves or rejects; does not sign. - `groupSigner` — A group where a threshold of members sign. - `groupReviewer` — A group where a threshold of members review. Allowed: `signer`, `reviewer`, `groupSigner`, `groupReviewer`. | `signer` | | `inviteeSigningLevel` | integer | No | Signing-order level (1 = first). | `1` | | `activationStatus` | string | No | Whether the invitation is active in the signing order. - `ACTIVE` — Currently actionable by the invitee. - `INACTIVE` — Waiting for its turn in the signing order. - `COMPLETE` — The invitee has finished their part. Allowed: `ACTIVE`, `INACTIVE`, `COMPLETE`. | `COMPLETE` | | `inviteeDetails` | array\ | No | The person(s) in this invitee group. See **inviteeDetails** below. | — | | `combinationsConfigInfo` | array\ | No | The invitee group's combinations. Present only when `combinationConfig=true`. See **combinationsConfigInfo** below. | — | | `inviteeSettings` | object | No | Per-invitee settings. Present only when `inviteeSettings=true`. `notifications` is always included; the other blocks each need their own flag. See **inviteeSettings** below. | — | ###### inviteeDetails | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `uuid` | string | No | ID of this person. | `1aa11111-1111-4111-8111-111111111111` | | `inviteeName` | string | No | Full name of the invitee. | `Rajesh Kumar` | | `inviteeEmail` | string | No | Email address. `null` if not set. | `rajesh@example.com` | | `inviteeNumber` | string | No | Mobile number. `null` if not set. | `9820000001` | | `enableWhatsAppMandatoryNotifications` | boolean | No | Whether WhatsApp notification is mandatory for this person. `null` when no notification config exists. | `true` | | `invitationUrl` | string | No | The invitee's sign URL. `null` before the invitation is sent. | `https://app1.leegality.com/sign/abc123` | | `invitationStatus` | object | No | The invitee's current invitation status. See **invitationStatus** below. | — | | `combinationResponse` | array\ | No | The invitee's response per assigned document. Present only when `combinationResponse=true`. See **combinationResponse** below. | — | ###### invitationStatus The invitee's current invitation status. | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `status` | string | No | The invitee's invitation status. - `PENDING` — Not yet acted on. - `SIGNED` — The invitee signed. - `EXPIRED` — The invitation expired. - `SIGNER_REJECTED` — The signer rejected the document. - `REVIEWER_APPROVED` — The reviewer approved the document. - `REVIEWER_REJECTED` — The reviewer rejected the document. Allowed: `PENDING`, `SIGNED`, `EXPIRED`, `REVIEWER_REJECTED`, `REVIEWER_APPROVED`, `SIGNER_REJECTED`. | `SIGNED` | | `failureReason` | string | No | Reason for failure, if any. `null` otherwise. | — | ###### combinationResponse | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `combinationConfigUuid` | string | No | ID of the combination this response belongs to. | `29bdb6fd-99a9-4501-b74b-d482d7ad5062` | | `assignedDocuments` | array\ | No | The documents assigned to this invitee in this combination. See **assignedDocuments** below. | — | | `supportingDocuments` | array\ | No | Supporting documents required of this invitee. Present only when `combinationResponse_supportingDocuments=true`. One entry per required document. See **supportingDocuments** below. | — | ###### assignedDocuments | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `documentUuid` | string | No | Runner UUID of the assigned document. | `711abfff-2057-48ac-909e-519f3f7415a4` | | `documentId` | string | No | Document ID of the assigned document. | `01KZ8JV503BJMY8QHCDS86DAR4` | | `rejectionMessage` | string | No | The invitee's rejection message for this document. `null` when not rejected. | — | | `status` | string | No | Signing status of this document for this invitee. - `PENDING` — Not yet acted on. - `SIGNED` — The invitee signed. - `REVIEWER_APPROVED` — The reviewer approved. - `REVIEWER_REJECTED` — The reviewer rejected. - `SIGNER_REJECTED` — The signer rejected. - `EXPIRED` — The invitation expired. Allowed: `PENDING`, `SIGNED`, `REVIEWER_APPROVED`, `REVIEWER_REJECTED`, `SIGNER_REJECTED`, `EXPIRED`. | `SIGNED` | | `signTime` | string | No | When the invitee signed this document (ISO 8601). `null` until signed. | `2026-08-05T09:11:20Z` | | `signatureOptionsUsed` | object | No | The signature type the invitee used. | — | | `verificationResult` | object | No | Verification outcome for this assigned document — the result of the checks configured in the invitee's `certificateVerification`. Present only when `combinationResponse_verificationResult=true`, and only on the **first** assigned document of each combination; every other assigned document omits it. `dscVerifyCertificateDetails` and `cloudDscVerifyCertificateDetails` mirror the sender's verify config, so they are present regardless of signing. The remaining fields populate only after the invitee signs: `aadhaarVerifyCertificateDetails` (values from the signer's Aadhaar certificate), `faceMatch`, `smartUserLiveliness`, `smartNamePercentage` and `smartNameThreshold` (the smart-name match score and its passing threshold), and `verificationFailed`. | — | ###### supportingDocuments | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `name` | string | No | Name of the required document. | `Aadhaar supporting doc` | | `file` | string | No | Download link for the submitted document. `null` if nothing has been submitted yet. | `https://downloads.leegality.com/export/…` | | `type` | string | No | Required file format. | `PDF` | ###### combinationsConfigInfo | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `uuid` | string | No | Combination ID. | `29bdb6fd-99a9-4501-b74b-d482d7ad5062` | | `expiryDate` | string | No | When this combination expires (ISO 8601). `null` if not set. | `2026-08-25T10:30:00Z` | | `assignedDocuments` | array\ | No | Documents assigned in this combination. See **assignedDocuments** below. | — | | `combinationSettings` | object | No | Combination settings. Present only when `combinationConfig_combinationSettings=true`. `esignTypes` is always present; the other blocks each need their own flag. See **combinationSettings** below. | — | ###### assignedDocuments | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `uuid` | string | No | Runner UUID of the assigned document. | `711abfff-2057-48ac-909e-519f3f7415a4` | | `documentId` | string | No | Document ID. | `01KZ8JV503BJMY8QHCDS86DAR4` | | `role` | string | No | The invitee's role on this document. - `signer` — Signs the document. - `reviewer` — Reviews the document. Allowed: `signer`, `reviewer`. | `signer` | ###### combinationSettings Combination settings. Present only when `combinationConfig_combinationSettings=true`. `esignTypes` is always present; the other blocks each need their own flag. | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `esignTypes` | object | No | The eSign methods enabled for this combination. Each method present is an object of its options. See **esignTypes** below. | — | | `eSignPrioritisation` | object | No | eSign priority and retry policy. Present only when `combinationConfig_combinationSettings_eSignPrioritisation=true`. See **eSignPrioritisation** below. | — | | `signatureAppearance` | object | No | Signature appearance settings. Present only when `combinationConfig_combinationSettings_signatureAppearance=true`. See **signatureAppearance** below. | — | | `webhooks` | object | No | Webhook settings. Present only when `combinationConfig_combinationSettings_webhooks=true`. See **webhooks** below. | — | | `customConsent` | object | No | Custom consent settings. Present only when `combinationConfig_combinationSettings_customConsent=true`. See **customConsent** below. | — | | `paymentCollect` | object | No | Payment collection config and outcome. Present only when `combinationConfig_combinationSettings_paymentCollect=true`. `null` when no payment is configured. See **paymentCollect** below. | — | | `reviewerConfig` | object | No | Reviewer settings. Present only when `combinationConfig_combinationSettings_reviewerConfig=true`. Group type is not consulted — when the flag is on, the key is present for signer groups too (and may be `null`); when off, it is omitted entirely. See **reviewerConfig** below. | — | ###### esignTypes The eSign methods enabled for this combination. Each method present is an object of its options. | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `virtualSign` | object | No | Virtual eSign options (shown as an example; other methods follow the same pattern). | — | ###### eSignPrioritisation eSign priority and retry policy. Present only when `combinationConfig_combinationSettings_eSignPrioritisation=true`. | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `orderLevelRetryCount` | boolean | No | Whether retry counts apply at the priority-order level. | `false` | | `enableAadhaarPriority` | boolean | No | Whether Aadhaar prioritisation is enabled. | `false` | | `aadhaarPriorityConfig` | object | No | Per-mode retry/order settings. Values are `null` when unconfigured. | — | ###### signatureAppearance Signature appearance settings. Present only when `combinationConfig_combinationSettings_signatureAppearance=true`. | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `allowEditingNameInSigningJourney` | boolean | No | Whether the signer can edit their name during signing. | `true` | | `displayNameInSignatureAppearances` | boolean | No | Whether the signer's name appears in the signature. | `false` | | `requireOrgSeal` | boolean | No | Whether an organisation seal is required. | `false` | | `orgNameInSeal` | string | No | Organisation name printed on the seal. `null` if not set. | — | | `orgSealType` | string | No | Type of organisation seal. `null` if not set. | — | ###### webhooks Webhook settings. Present only when `combinationConfig_combinationSettings_webhooks=true`. | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `successWebhook` | string | No | URL called on success. `null` if not set. | — | | `errorWebhook` | string | No | URL called on error. `null` if not set. | — | | `webhookProfileId` | string | No | ID of the webhook profile used. `null` if not set. | — | | `webhookVersion` | string | No | Webhook payload version. `null` if not set. | — | ###### customConsent Custom consent settings. Present only when `combinationConfig_combinationSettings_customConsent=true`. | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `customConsentInput` | string | No | Custom consent text shown to the invitee. `null` if not set. | — | ###### paymentCollect Payment collection config and outcome. Present only when `combinationConfig_combinationSettings_paymentCollect=true`. `null` when no payment is configured. | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `paymentProfile` | string | No | ID of the payment profile. | `23931d8d-9edb-4895-adee-e296dcba07c9` | | `paymentAmount` | integer | No | Amount to collect. | `500` | | `customMessagePaymentPage` | string | No | Custom message on the payment page. | `Stamp duty payment required.` | | `status` | string | No | Payment status. - `paid` — The payment was completed (the gateway's paid status). - `notPaid` — A payment transaction exists but has not been paid. - `null` — The payment-service lookup failed. | `notPaid` | | `paymentId` | string | No | Payment transaction ID. `null` until paid. | — | | `eventDate` | string | No | When the payment was made (ISO 8601). `null` unless paid. | — | ###### reviewerConfig Reviewer settings. Present only when `combinationConfig_combinationSettings_reviewerConfig=true`. Group type is not consulted — when the flag is on, the key is present for signer groups too (and may be `null`); when off, it is omitted entirely. | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `recordReviewerResponse` | boolean | No | Whether the reviewer's response is recorded. | `true` | | `requireOtpToReview` | boolean | No | Whether an OTP is required to review. | `false` | ###### inviteeSettings Per-invitee settings. Present only when `inviteeSettings=true`. `notifications` is always included; the other blocks each need their own flag. | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `notifications` | object | No | Notification channel settings. See **notifications** below. | — | | `securityOptions` | object | No | Security settings. Present only when `inviteeSettings_securityOptions=true`. See **securityOptions** below. | — | | `manageInviteInteractions` | object | No | Interaction settings. Present only when `inviteeSettings_manageInviteInteractions=true`. See **manageInviteInteractions** below. | — | | `certificateVerification` | object | No | The certificate-verification settings the sender configured for this invitee (**input**). Present only when `inviteeSettings_certificateVerification=true`. The verification **outcome** is returned separately in each combination's `assignedDocuments[].verificationResult`. See **certificateVerification** below. | — | ###### notifications Notification channel settings. | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `enableEmailNotifications` | boolean | No | Whether email notifications are enabled. | `true` | | `enableSmsNotifications` | boolean | No | Whether SMS notifications are enabled. | `true` | | `enableWhatsappNotifications` | boolean | No | Whether WhatsApp notifications are enabled for this invitee. | `true` | ###### securityOptions Security settings. Present only when `inviteeSettings_securityOptions=true`. | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `oneFactorAuthentication` | boolean | No | Whether single-factor authentication is required. | `false` | | `twoFactorAuthentication` | boolean | No | Whether two-factor authentication is required. | `false` | | `gps` | object | No | Location settings. Present only when `inviteeSettings_securityOptions_gps=true`. See **gps** below. | — | | `faceCapture` | object | No | Face capture / match settings. Present only when `inviteeSettings_securityOptions_faceCapture=true`. See **faceCapture** below. | — | | `docDownloadLinkWithOtp` | boolean | No | Whether the signed-document link is OTP-protected. | `false` | | `maskContactDetails` | boolean | No | Whether the invitee's contact details are masked. | `false` | ###### gps Location settings. Present only when `inviteeSettings_securityOptions_gps=true`. | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `enabled` | boolean | No | Whether location capture is enabled. | `false` | | `accuracyBasedRestriction` | boolean | No | Whether signing is blocked below an accuracy threshold. | `false` | | `accuracyThreshold` | integer | No | Accuracy threshold in metres. | `0` | | `locationBasedRestriction` | boolean | No | Whether signing is restricted to a location radius. | `false` | | `latitude` | number | No | Latitude of the allowed location. | `0` | | `longitude` | number | No | Longitude of the allowed location. | `0` | | `permissibleRadius` | integer | No | Allowed radius in metres. | `0` | | `restrictToIndia` | boolean | No | Whether signing is restricted to within India. | `false` | ###### faceCapture Face capture / match settings. Present only when `inviteeSettings_securityOptions_faceCapture=true`. | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `enabled` | boolean | No | Whether face capture is enabled. | `false` | | `smartUserLiveliness` | boolean | No | Whether smart liveliness is enabled. | `false` | | `smartUserLivelinessRetryAttempts` | integer | No | Liveliness retry attempts. | `0` | | `match` | boolean | No | Whether face match is enabled. | `false` | | `faceMatch` | array\ | No | Reference images the captured face is matched against. | — | ###### manageInviteInteractions Interaction settings. Present only when `inviteeSettings_manageInviteInteractions=true`. | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `baseUrl` | string | No | Base URL for the signing journey. `null` if not set. | — | | `redirectUrl` | string | No | Redirect URL after signing. `null` if not set. | — | | `enableRejection` | boolean | No | Whether the invitee can reject. | `false` | | `enforceRejectionMessage` | boolean | No | Whether a rejection message is required. | `false` | | `customMessageInput` | string | No | Custom message shown to the invitee. `null` if not set. | `Please review and sign.` | | `supportingDocumentConfig` | object | No | Supporting-document requirements. Present only when `inviteeSettings_manageInviteInteractions_supportingDocumentConfig=true`. See **supportingDocumentConfig** below. | — | | `language` | object | No | Regional-language settings. Present only when `inviteeSettings_manageInviteInteractions_language=true`. See **language** below. | — | ###### supportingDocumentConfig Supporting-document requirements. Present only when `inviteeSettings_manageInviteInteractions_supportingDocumentConfig=true`. | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `supportingDocuments` | array\ | No | The documents the invitee is asked to upload. | — | | `allowViewingSupportingDocs` | boolean | No | Whether other invitees can view the uploaded documents. | `false` | ###### language Regional-language settings. Present only when `inviteeSettings_manageInviteInteractions_language=true`. | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `enableLanguage` | boolean | No | Whether a local language is offered. | `false` | | `defaultLanguage` | boolean | No | Whether a default language is set. | `false` | | `defaultLanguageSelect` | string | No | The default language code. `null` if not set. | — | ###### certificateVerification The certificate-verification settings the sender configured for this invitee (**input**). Present only when `inviteeSettings_certificateVerification=true`. The verification **outcome** is returned separately in each combination's `assignedDocuments[].verificationResult`. | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `aadhaarVerifyCertificateDetails` | array\ | No | Aadhaar verification rules configured for the invitee. | — | | `cloudDscVerifyCertificateDetails` | array\ | No | Cloud DSC verification rules. Present only when `inviteeSettings_certificateVerification_cloudDscVerifyCertificateDetails=true`. | — | | `dscVerifyCertificateDetails` | array\ | No | DSC verification rules. Present only when `inviteeSettings_certificateVerification_dscVerifyCertificateDetails=true`. | — | ##### cc | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `uuid` | string | No | Unique ID of the CC recipient. | `a1b2c3d4-5678-4abc-9def-012345678901` | | `name` | string | No | Name of the CC recipient. | `Rajesh Kumar` | | `email` | string | No | Email address of the CC recipient. | `rajesh@example.com` | | `invitationNotification` | boolean | No | Whether the CC recipient receives the invitation notification. | `true` | | `signingNotification` | boolean | No | Whether the CC recipient receives signing notifications. | `true` | | `completionNotification` | boolean | No | Whether the CC recipient receives the completion notification. | `true` | | `failureNotification` | boolean | No | Whether the CC recipient receives failure notifications. | `true` | | `sendInvitationUrl` | boolean | No | Whether the invitation URL is shared with the CC recipient. | `true` | | `shareDocAuditTrail` | boolean | No | Whether the document audit trail is shared with the CC recipient. | `false` | | `enforceOneFactorAuthentication` | boolean | No | Whether one-factor authentication is enforced for the CC recipient. | `false` | | `recordAuditTrail` | boolean | No | Whether the CC recipient's activity is recorded in the audit trail. | `true` | ### 400 — The request was rejected. Possible errors: - `LE_ERR_AP_002` — no identifier supplied (send exactly one of `packId`, `urn`, `workflowRunContextId`) - `LE_ERR_AP_003` — more than one identifier supplied - `LE_ERR_AP_024` — unknown or removed query parameter | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `code` | string | No | Top-level error code (matches the first entry in `errors`). | `LE_ERR_AP_007` | | `traceId` | string | No | Trace identifier for the request, or `null`. | `null` | | `errors` | array\ | No | One or more errors describing why the request failed. See **errors** below. | — | #### errors | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `message` | string | No | Human-readable error message. | `max must be >= 1` | | `path` | string | No | Request path that produced the error. | `/api/v4/packs/search` | | `code` | string | No | Error code. | `LE_ERR_AP_007` | ### 401 — Authentication failed. - `LE_ERR_AP_080` — missing or invalid authentication token | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `code` | string | No | Top-level error code (matches the first entry in `errors`). | `LE_ERR_AP_007` | | `traceId` | string | No | Trace identifier for the request, or `null`. | `null` | | `errors` | array\ | No | One or more errors describing why the request failed. See **errors** below. | — | #### errors | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `message` | string | No | Human-readable error message. | `max must be >= 1` | | `path` | string | No | Request path that produced the error. | `/api/v4/packs/search` | | `code` | string | No | Error code. | `LE_ERR_AP_007` | ### 403 — Access denied. - `LE_ERR_AP_081` — your account is not permitted to read this pack - `LE_ERR_AP_084` — your IP address is not whitelisted | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `code` | string | No | Top-level error code (matches the first entry in `errors`). | `LE_ERR_AP_007` | | `traceId` | string | No | Trace identifier for the request, or `null`. | `null` | | `errors` | array\ | No | One or more errors describing why the request failed. See **errors** below. | — | #### errors | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `message` | string | No | Human-readable error message. | `max must be >= 1` | | `path` | string | No | Request path that produced the error. | `/api/v4/packs/search` | | `code` | string | No | Error code. | `LE_ERR_AP_007` | ### 404 — Not found. - `LE_ERR_AP_004` — pack not found (also returned when the pack belongs to another account) | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `code` | string | No | Top-level error code (matches the first entry in `errors`). | `LE_ERR_AP_007` | | `traceId` | string | No | Trace identifier for the request, or `null`. | `null` | | `errors` | array\ | No | One or more errors describing why the request failed. See **errors** below. | — | #### errors | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `message` | string | No | Human-readable error message. | `max must be >= 1` | | `path` | string | No | Request path that produced the error. | `/api/v4/packs/search` | | `code` | string | No | Error code. | `LE_ERR_AP_007` | ### 500 — An unexpected error occurred while processing the request. | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `code` | string | No | Top-level error code (matches the first entry in `errors`). | `LE_ERR_AP_007` | | `traceId` | string | No | Trace identifier for the request, or `null`. | `null` | | `errors` | array\ | No | One or more errors describing why the request failed. See **errors** below. | — | #### errors | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `message` | string | No | Human-readable error message. | `max must be >= 1` | | `path` | string | No | Request path that produced the error. | `/api/v4/packs/search` | | `code` | string | No | Error code. | `LE_ERR_AP_007` | ### Sample Response (200) ```json { "data": { "pack": { "packId": "01KZ8JV4Z7T3EZWMXGF3RNAYR5", "workflowId": "a6295beb-650f-4dc0-81b4-df8e8faf2b7e", "status": "COMPLETED", "createdAt": "2026-08-05T09:07:33Z", "completedAt": "2026-08-05T09:12:00Z", "packName": "Home Loan Agreement", "packIrn": "IRN-2026-001234", "packUrn": "CLIENT-REF-001", "workflowRunContextId": "8babd0af-a418-486e-b1cd-eb717fe97c35", "workflow": { "name": "Home Loan Workflow" }, "account": { "id": "acc_12345", "name": "Acme Corp", "label": "acme", "brandName": "Acme" }, "sender": { "username": "ops@acme.com", "name": "Operations Team" }, "packFolder": { "id": "6Ucvh0i", "name": "V3" }, "sftp": { "enabled": true, "profileId": "sftp_9012" }, "deleteOnComplete": false, "signingOrder": { "signingOrderType": "ON", "preventChangesToSigningOrder": false } }, "documents": [ { "documentId": "01KZ8JV503BJMY8QHCDS86DAR4", "documentName": "Loan Agreement", "irn": "DOC-IRN-001", "status": "COMPLETED", "documentFolderId": "uvwmVVk", "documentFolderName": "testing", "file": "https://downloads.leegality.com/export/…", "auditTrail": "https://downloads.leegality.com/export/…", "referenceAttachments": [ { "file": "https://downloads.leegality.com/export/…", "name": "reference-document", "type": "PDF" } ], "scheduledDeletionDate": "2026-09-01T00:00:00Z", "stamps": [ { "documentUuid": "95f24138-03e7-4669-a3dd-0588a8d007a0", "subDocumentUuid": "string", "stampState": "Karnataka", "totalStampDutyAmount": 200, "stampsAffixed": [ { "series": "01", "amount": "100.0", "serialNumber": "IN-DL1234567890", "associatedDocumentId": "XR701AC977" } ], "revenueStamp": { "revenueStampQuantity": 0, "revenueStampId": "string" }, "stampSeries": [ {} ], "stampUpload": { "stampUploadSerialNumber": "string", "stampUploadFirstPartyName": "string", "stampUploadDenomination": "string", "stampUploadedFile": { "mediaId": "string" }, "stampUploadState": "string", "stampUploadSecondPartyName": "string" }, "stampGroup": { "stampGroupId": "string", "stampGroupAmount": "string", "maximumValuePermitted": "string" } } ], "subDocuments": [ { "uuid": "795df69d-12c9-4959-be9a-9a73a2e1dd30", "mediaId": "95ded759-0b03-4c6b-91bd-45f049893972", "subDocumentType": "PDF", "template": { "id": "tpl_mapping_abc123", "name": "Loan Template", "version": "1", "allowFirstInviteeToFill": true, "templateFieldValues": [ { "id": "f1a23456-78bc-4def-9012-3456789abcde", "name": "borrower name", "fieldType": "text", "value": "Rajesh Kumar", "isFilledBySender": true } ] } } ] } ], "coordinates": [ { "inviteeUuid": "8bc21487-b200-4130-8240-a5f1715244dc", "appearances": [ { "documentUuid": "711abfff-2057-48ac-909e-519f3f7415a4", "subDocumentUuid": "795df69d-12c9-4959-be9a-9a73a2e1dd30", "combinationUuid": "29bdb6fd-99a9-4501-b74b-d482d7ad5062", "pageNo": "1", "rect": { "x1Axis": "350", "y1Axis": "680", "x2Axis": "550", "y2Axis": "720" } } ] } ], "invitations": [ { "uuid": "1342a359-2364-4e0a-9b21-6f3a2c1d4e5f", "groupName": "Borrower", "inviteeGroupThreshold": 1, "inviteeType": "signer", "inviteeSigningLevel": 1, "activationStatus": "COMPLETE", "inviteeDetails": [ { "uuid": "1aa11111-1111-4111-8111-111111111111", "inviteeName": "Rajesh Kumar", "inviteeEmail": "rajesh@example.com", "inviteeNumber": "9820000001", "enableWhatsAppMandatoryNotifications": true, "invitationUrl": "https://app1.leegality.com/sign/abc123", "invitationStatus": { "status": "SIGNED", "failureReason": "string" }, "combinationResponse": [ { "combinationConfigUuid": "29bdb6fd-99a9-4501-b74b-d482d7ad5062", "assignedDocuments": [ { "documentUuid": "711abfff-2057-48ac-909e-519f3f7415a4", "documentId": "01KZ8JV503BJMY8QHCDS86DAR4", "rejectionMessage": "string", "status": "SIGNED", "signTime": "2026-08-05T09:11:20Z", "signatureOptionsUsed": { "signatureType": "AADHAAR", "signatureSubType": "OTP" }, "verificationResult": { "aadhaarVerifyCertificateDetails": { "name": "Rajesh Kumar", "yob": "1990", "gender": "M", "title": "string", "pincode": "560001", "state": "Karnataka", "uid": "XXXXXXXX1234" }, "verificationFailed": false, "smartNamePercentage": 92.5, "smartNameThreshold": 80, "cloudDscVerifyCertificateDetails": { "verifyName": false, "verifySmartName": false, "verifyYob": "string", "verifyTitle": "string", "verifyState": "string", "verifyPincode": "string", "verifyGender": "string" }, "dscVerifyCertificateDetails": { "verifyName": false, "verifyState": "string", "verifyPincode": "string" }, "faceMatch": { "percentage": 87.3, "success": true, "acceptancePercentage": 70, "error": "string", "attemptsLeft": 0 }, "smartUserLiveliness": { "percentage": 95, "success": true, "acceptancePercentage": 80, "attemptsLeft": 0 } } } ], "supportingDocuments": [ { "name": "Aadhaar supporting doc", "file": "https://downloads.leegality.com/export/…", "type": "PDF" } ] } ] } ], "combinationsConfigInfo": [ { "uuid": "29bdb6fd-99a9-4501-b74b-d482d7ad5062", "expiryDate": "2026-08-25T10:30:00Z", "assignedDocuments": [ { "uuid": "711abfff-2057-48ac-909e-519f3f7415a4", "documentId": "01KZ8JV503BJMY8QHCDS86DAR4", "role": "signer" } ], "combinationSettings": { "esignTypes": { "virtualSign": { "enableAffixFingerprint": true, "enableChoose": true, "enableDraw": true, "enablePhysicalSignature": true, "id": "8678413c-3597-41bb-a529-7928d02ff72d" } }, "eSignPrioritisation": { "orderLevelRetryCount": false, "enableAadhaarPriority": false, "aadhaarPriorityConfig": { "prioritisationOtpRetryAttempts": 0, "prioritisationOtpOrder": 0, "prioritisationBioRetryAttempts": 0, "prioritisationBioOrder": 0, "prioritisationIrisRetryAttempts": 0, "prioritisationIrisOrder": 0, "prioritisationFaceAuthRetryAttempts": 0, "prioritisationFaceAuthOrder": 0 } }, "signatureAppearance": { "allowEditingNameInSigningJourney": true, "displayNameInSignatureAppearances": false, "requireOrgSeal": false, "orgNameInSeal": "string", "orgSealType": "string" }, "webhooks": { "successWebhook": "string", "errorWebhook": "string", "webhookProfileId": "string", "webhookVersion": "string" }, "customConsent": { "customConsentInput": "string" }, "paymentCollect": { "paymentProfile": "23931d8d-9edb-4895-adee-e296dcba07c9", "paymentAmount": 500, "customMessagePaymentPage": "Stamp duty payment required.", "status": "notPaid", "paymentId": "string", "eventDate": "string" }, "reviewerConfig": { "recordReviewerResponse": true, "requireOtpToReview": false } } } ], "inviteeSettings": { "notifications": { "enableEmailNotifications": true, "enableSmsNotifications": true, "enableWhatsappNotifications": true }, "securityOptions": { "oneFactorAuthentication": false, "twoFactorAuthentication": false, "gps": { "enabled": false, "accuracyBasedRestriction": false, "accuracyThreshold": 0, "locationBasedRestriction": false, "latitude": 0, "longitude": 0, "permissibleRadius": 0, "restrictToIndia": false }, "faceCapture": { "enabled": false, "smartUserLiveliness": false, "smartUserLivelinessRetryAttempts": 0, "match": false, "faceMatch": [ { "faceMatchImage": { "mediaId": "string" }, "faceMatchRetryAttempts": 0 } ] }, "docDownloadLinkWithOtp": false, "maskContactDetails": false }, "manageInviteInteractions": { "baseUrl": "string", "redirectUrl": "string", "enableRejection": false, "enforceRejectionMessage": false, "customMessageInput": "Please review and sign.", "supportingDocumentConfig": { "supportingDocuments": [ { "uuid": "1c94a8a9-c75e-49c4-83e0-3870a6880b40", "supportingDocName": "Aadhaar supporting doc", "supportingDocFormat": "PDF" } ], "allowViewingSupportingDocs": false }, "language": { "enableLanguage": false, "defaultLanguage": false, "defaultLanguageSelect": "string" } }, "certificateVerification": { "aadhaarVerifyCertificateDetails": [ {} ], "cloudDscVerifyCertificateDetails": [ {} ], "dscVerifyCertificateDetails": [ {} ] } } } ], "cc": [ { "uuid": "a1b2c3d4-5678-4abc-9def-012345678901", "name": "Rajesh Kumar", "email": "rajesh@example.com", "invitationNotification": true, "signingNotification": true, "completionNotification": true, "failureNotification": true, "sendInvitationUrl": true, "shareDocAuditTrail": false, "enforceOneFactorAuthentication": false, "recordAuditTrail": true } ] } } ``` --- URL: https://knowledge.leegality.com/document-execution/api/reactivate-invitation # POST /v4/packs/invitations/reactivate — Reactivate invitation :::info[Sandbox endpoint] **Authentication:** `X-Auth-Token` header required on every request. ## Request URL ``` POST https://app1.leegality.com/api/v4/packs/invitations/reactivate ``` **Environments:** - Production: `https://app1.leegality.com/api/v4/packs/invitations/reactivate` - Sandbox: `https://sandbox.leegality.com/api/v4/packs/invitations/reactivate` --- ## Request Body **Content-Type:** `application/json` | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `signUrl` | string | Yes | The invitation's sign URL — the per-person signing link for the invitee you want to reactivate. **Required.** | `https://app1.leegality.com/sign/abc123` | | `expiryDays` | integer | No | New validity for the reactivated invitation, in days. Default `10`. Allowed range `-1` to `365`: `-1` = 45 minutes, `0` = same day, `1`–`365` = that many days. `0` bypasses the range check and is always accepted. This applies to every expired combination for the invitation. | `15` | ### Sample Request ```json { "signUrl": "https://app1.leegality.com/sign/abc123", "expiryDays": 15 } ``` --- ## Responses ### 200 — Invitation reactivated. **Error codes** The request is rejected if any of the following applies: | Scenario | Result | | --- | --- | | `signUrl` missing, empty, or null | `LE_ERR_AP_055` | | `signUrl` invalid or does not resolve | `LE_ERR_AP_016` | | `expiryDays` above the maximum (365) | `LE_ERR_AP_065` | | `expiryDays` below the minimum (-1) | Validation error | | Non-empty `combinations` array (not supported — use top-level `expiryDays`) | `LE_ERR_AP_020` | | Invitation not expired (active), already signed, or rejected | Error | | Expired JWT (401) | `LE_ERR_AP_080` | | Missing auth token (403) | `LE_ERR_AP_081` | | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `data` | object | No | Response payload. See **data** below. | — | #### data Response payload. | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `packId` | string | No | ID of the pack the invitation belongs to. | `01M0CSD4TJSD14R35SSG0VGNTD` | | `signUrl` | string | No | The invitation's sign URL. | `https://app1.leegality.com/sign/1813c566-ab07-4088-b217-27bf` | | `reactivationStatus` | string | No | Reactivation result. Always `REACTIVATED`. Allowed: `REACTIVATED`. | `REACTIVATED` | ### Sample Response (200) ```json { "data": { "packId": "01M0CSD4TJSD14R35SSG0VGNTD", "signUrl": "https://app1.leegality.com/sign/1813c566-ab07-4088-b217-27bfe4c2a009", "reactivationStatus": "REACTIVATED" } } ``` --- URL: https://knowledge.leegality.com/document-execution/api/activate-pack-invitation # POST /v4/packs/invitations/activate — Activate invitation :::info[Sandbox endpoint] **Authentication:** `X-Auth-Token` header required on every request. ## Request URL ``` POST https://app1.leegality.com/api/v4/packs/invitations/activate ``` **Environments:** - Production: `https://app1.leegality.com/api/v4/packs/invitations/activate` - Sandbox: `https://sandbox.leegality.com/api/v4/packs/invitations/activate` --- ## Request Body **Content-Type:** `application/json` | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `signUrl` | string | Yes | The invitation's sign URL — the per-person signing link for the invitee to activate. **Required.** | `https://app1.leegality.com/sign/abc123` | ### Sample Request ```json { "signUrl": "https://app1.leegality.com/sign/abc123" } ``` --- ## Responses ### 200 — Invitation activated. Returns all invitations that were activated (the requested one plus any group siblings). **Error codes** The request is rejected if any of the following applies: | Scenario | Result | | --- | --- | | `signUrl` missing, empty, null, an array, or invalid JSON body | 400 `LE_ERR_AP_057` | | `signUrl` invalid, not found, or from a different tenant | 404 `LE_ERR_AP_016` | | Invitation already active | `INVITATION_ALREADY_ACTIVE` | | Invitation already signed | `INVITATION_SIGNED` | | Invitation rejected | `INVITATION_REJECTED` | | Invitation completed | `INVITATION_COMPLETED` | | `preventChangesToSigningOrder` is `true` for the pack | `SIGNING_ORDER_LOCKED` | | Expired JWT | 401 `LE_ERR_AP_080` | | Missing auth token | 403 Access Denied | | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `data` | object | No | Response payload. See **data** below. | — | #### data Response payload. | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `activatedInvitations` | array\ | No | All invitations that were activated — the requested one plus any siblings in the same invitee group. See **activatedInvitations** below. | — | ##### activatedInvitations | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `signUrl` | string | No | The activated invitation's sign URL. | `https://app1.leegality.com/sign/abc123` | | `status` | string | No | New status of the invitation (`ACTIVE`). | `ACTIVE` | | `activatedAt` | string | No | Activation timestamp (ISO 8601). | `2026-02-10T12:00:00Z` | | `notificationSent` | boolean | No | Whether a notification was sent to this invitee. | `true` | ### Sample Response (200) ```json { "data": { "activatedInvitations": [ { "signUrl": "https://app1.leegality.com/sign/abc123", "status": "ACTIVE", "activatedAt": "2026-02-10T12:00:00Z", "notificationSent": true } ] } } ``` --- URL: https://knowledge.leegality.com/document-execution/api/resend-pack-notification # POST /v4/packs/notifications — Resend notification :::info[Sandbox endpoint] **Authentication:** `X-Auth-Token` header required on every request. ## Request URL ``` POST https://app1.leegality.com/api/v4/packs/notifications ``` **Environments:** - Production: `https://app1.leegality.com/api/v4/packs/notifications` - Sandbox: `https://sandbox.leegality.com/api/v4/packs/notifications` --- ## Request Body **Content-Type:** `application/json` | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `signUrl` | string | Yes | Sign URL of the invitee to notify — the invitation URL from [Check Pack Details](https://knowledge.leegality.com/document-execution/api/check-pack-details) (`invitations[].inviteeDetails[].invitationUrl`). | `https://app1.leegality.com/sign/a1b2c3d4-e5f6-7890-abcd-ef12` | ### Sample Request ```json { "signUrl": "https://app1.leegality.com/sign/a1b2c3d4-e5f6-7890-abcd-ef1234567890" } ``` --- ## Responses ### 200 — Notification resent. **Error codes** The request is rejected if any of the following applies: | Scenario | Error code | | --- | --- | | No invitation found for this `signUrl` | `LE_ERR_AP_016` | | Invitation has expired | `LE_ERR_AP_025` | | Invitee has already signed | `LE_ERR_AP_026` | | Invitee has rejected | `LE_ERR_AP_027` | | Missing or malformed body / blank `signUrl` | `LE_ERR_AP_056` | | Expired token (401) | `LE_ERR_AP_080` | | Missing token (403) | `LE_ERR_AP_081` | | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `data` | object | No | Response payload. See **data** below. | — | #### data Response payload. | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `signUrl` | string | No | The invitee's sign URL that was notified. | `https://app1.leegality.com/sign/a1b2c3d4-e5f6-7890-abcd-ef12` | | `notificationStatus` | string | No | Result of the resend. Always `SENT` on success. Allowed: `SENT`. | `SENT` | ### Sample Response (200) ```json { "data": { "signUrl": "https://app1.leegality.com/sign/a1b2c3d4-e5f6-7890-abcd-ef1234567890", "notificationStatus": "SENT" } } ``` --- URL: https://knowledge.leegality.com/document-execution/api/complete-document # POST /v4/packs/documents/complete — Complete document :::info[Sandbox endpoint] **Authentication:** `X-Auth-Token` header required on every request. ## Request URL ``` POST https://app1.leegality.com/api/v4/packs/documents/complete ``` **Environments:** - Production: `https://app1.leegality.com/api/v4/packs/documents/complete` - Sandbox: `https://sandbox.leegality.com/api/v4/packs/documents/complete` --- ## Request Body **Content-Type:** `application/json` | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `documentId` | string | Yes | The document's ID — the ULID that identifies the document (from the pack's document details). **Required.** | `01KTXKANAE8DHKQYNJTXSDJKG5` | ### Sample Request ```json { "documentId": "01KTXKANAE8DHKQYNJTXSDJKG5" } ``` --- ## Responses ### 200 — Document marked as complete. Returns the document and pack status. **Error codes** The request is rejected if any of the following applies: | Scenario | Result | | --- | --- | | `documentId` missing, empty, null, an array, an object, or invalid JSON body | 400 `LE_ERR_AP_058` | | `documentId` not found, or not a valid document ULID | 404 `LE_ERR_AP_001` | | Document already completed | 409 `DOCUMENT_ALREADY_COMPLETED` | | Document still has active or pending invitations | 409 `ACTIVE_INVITATIONS_EXIST` | | Expired JWT | 401 `LE_ERR_AP_080` | | Missing auth token | 403 Access Denied | | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `data` | object | No | Response payload. See **data** below. | — | #### data Response payload. | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `packId` | string | No | Pack identifier. | `pack_xyz789` | | `documentId` | string | No | The ULID of the completed document. | `01HN8Z2K7M9P4Q5R6S7T8U9V0` | | `documentStatus` | string | No | Document status after this call. The usual value is `PACK_PENDING_COMPLETION` — the document is marked pending, and the pack moves to `COMPLETED` only once every document in it has finished. **Possible values:** - `UNSIGNED` - `PARTIALLY_SIGNED` - `PACK_PENDING_COMPLETION` - `COMPLETED` Allowed: `UNSIGNED`, `PARTIALLY_SIGNED`, `PACK_PENDING_COMPLETION`, `COMPLETED`. | `PACK_PENDING_COMPLETION` | | `completionType` | string | No | How the document was completed. Always `MANUAL` for this endpoint. | `MANUAL` | | `packStatus` | string | No | Current pack status — `COMPLETED` if all documents are now complete, otherwise `SENT`. | `SENT` | | `packCompletedAt` | string | No | Pack completion timestamp (ISO 8601) if this action completed the pack; otherwise `null`. | `null` | ### Sample Response (200) ```json { "data": { "packId": "pack_xyz789", "documentId": "01HN8Z2K7M9P4Q5R6S7T8U9V0", "documentStatus": "PACK_PENDING_COMPLETION", "completionType": "MANUAL", "packStatus": "SENT", "packCompletedAt": null } } ``` --- URL: https://knowledge.leegality.com/document-execution/api/download-files # GET /v4/packs/download — Download files :::info[Sandbox endpoint] **Authentication:** `X-Auth-Token` header required on every request. ## Request URL ``` GET https://app1.leegality.com/api/v4/packs/download?downloadType={downloadType}&documentId={documentId}&signUrl={signUrl}&index={index}&mode={mode} ``` **Environments:** - Production: `https://app1.leegality.com/api/v4/packs/download` - Sandbox: `https://sandbox.leegality.com/api/v4/packs/download` --- ## Parameters | Name | In | Required | Type | Description | Example | |------|----|----------|------|-------------|---------| | `downloadType` | query | Yes | string | The type of file to download. One of `DOCUMENT`, `AUDIT_TRAIL`, `ATTACHMENT`, `SUPPORTING_DOCUMENT`. Only one per call. | — | | `documentId` | query | No | string | The document's ULID. **Required for `DOCUMENT`, `AUDIT_TRAIL`, and `ATTACHMENT`.** Sending it with `SUPPORTING_DOCUMENT` is a validation error. | — | | `signUrl` | query | No | string | The invitee's sign URL. **Required for `SUPPORTING_DOCUMENT`.** Sending it with a document-family `downloadType` is a validation error. | — | | `index` | query | No | integer | 0-indexed position of the file to fetch. Defaults to `0`. Required for `ATTACHMENT` and `SUPPORTING_DOCUMENT`. | — | | `mode` | query | No | string | Set to `stream` to receive the raw file directly. If omitted, the response format follows your account configuration. | — | --- ## Responses ### 200 — Returns the requested file. Depending on your account setup (or the `mode` parameter), you get one of two things: - A JSON response with a temporary download link (`data.url`) that expires shortly (`data.expiresAt`). - The file itself, sent back directly (for example, a PDF). Check the `Content-Type` response header to tell which one you received. | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `data` | object | No | See **data** below. | — | #### data | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `url` | string | No | Temporary link to download the file. Expires shortly. | `https://sandbox-downloads.leegality.com/export/…?Expires=…&S` | | `expiresAt` | string | No | When the download link expires (ISO 8601). | `2026-08-19T09:23:40.297Z` | ### 400 — The request was rejected. Possible errors: - `LE_ERR_AP_043` — `downloadType` is missing - `LE_ERR_AP_044` — `downloadType` is not a supported value - `LE_ERR_AP_029` — `documentId` is missing (for `DOCUMENT`, `AUDIT_TRAIL`, or `ATTACHMENT`) - `LE_ERR_AP_045` — `signUrl` is missing (for `SUPPORTING_DOCUMENT`) - `LE_ERR_AP_046` — `index` is a negative number - `LE_ERR_AP_062` — `index` is not a whole number - `LE_ERR_AP_024` — the document isn't fully signed yet, so its audit trail can't be downloaded | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `code` | string | No | Top-level error code (matches the first entry in `errors`). | `LE_ERR_AP_007` | | `traceId` | string | No | Trace identifier for the request, or `null`. | `null` | | `errors` | array\ | No | One or more errors describing why the request failed. See **errors** below. | — | #### errors | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `message` | string | No | Human-readable error message. | `max must be >= 1` | | `path` | string | No | Request path that produced the error. | `/api/v4/packs/search` | | `code` | string | No | Error code. | `LE_ERR_AP_007` | ### 401 — Authentication failed. - `LE_ERR_AP_080` — missing or invalid authentication token | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `code` | string | No | Top-level error code (matches the first entry in `errors`). | `LE_ERR_AP_007` | | `traceId` | string | No | Trace identifier for the request, or `null`. | `null` | | `errors` | array\ | No | One or more errors describing why the request failed. See **errors** below. | — | #### errors | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `message` | string | No | Human-readable error message. | `max must be >= 1` | | `path` | string | No | Request path that produced the error. | `/api/v4/packs/search` | | `code` | string | No | Error code. | `LE_ERR_AP_007` | ### 404 — Not found. - `LE_ERR_AP_001` — no document matches the `documentId` - `LE_ERR_AP_047` — the requested file isn't available (for example, there's no attachment at that `index`) | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `code` | string | No | Top-level error code (matches the first entry in `errors`). | `LE_ERR_AP_007` | | `traceId` | string | No | Trace identifier for the request, or `null`. | `null` | | `errors` | array\ | No | One or more errors describing why the request failed. See **errors** below. | — | #### errors | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `message` | string | No | Human-readable error message. | `max must be >= 1` | | `path` | string | No | Request path that produced the error. | `/api/v4/packs/search` | | `code` | string | No | Error code. | `LE_ERR_AP_007` | ### Sample Response (200) ```json { "data": { "url": "https://sandbox-downloads.leegality.com/export/…?Expires=…&Signature=…&Key-Pair-Id=…", "expiresAt": "2026-08-19T09:23:40.297Z" } } ``` --- URL: https://knowledge.leegality.com/document-execution/api/search-packs # GET /v4/packs/search — Search packs :::info[Sandbox endpoint] **Authentication:** `X-Auth-Token` header required on every request. ## Request URL ``` GET https://app1.leegality.com/api/v4/packs/search?q={q}&status={status}&workflowId={workflowId}&irn={irn}&max={max}&offset={offset}&sortBy={sortBy}&sortOrder={sortOrder} ``` **Environments:** - Production: `https://app1.leegality.com/api/v4/packs/search` - Sandbox: `https://sandbox.leegality.com/api/v4/packs/search` --- ## Parameters | Name | In | Required | Type | Description | Example | |------|----|----------|------|-------------|---------| | `q` | query | No | string | Free-text search across packs. | — | | `status` | query | No | string | Filter by pack status. | — | | `workflowId` | query | No | string | Filter by the workflow the packs were created from (workflow ID). An unknown value simply returns no records. | — | | `irn` | query | No | string | Exact match on the pack's IRN (does not search document IRNs). | — | | `max` | query | No | integer | Page size. Default `20`, minimum `1`, maximum `40`. | — | | `offset` | query | No | integer | Number of results to skip (pagination). Default `0`. `offset` + `max` cannot exceed 1,000 unless a `status` filter is set. | — | | `sortBy` | query | No | string | Field to sort by. | — | | `sortOrder` | query | No | string | Sort direction. Default `desc`. | — | --- ## Responses ### 200 — A page of packs matching the search — the records for this page plus pagination totals. | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `data` | object | No | See **data** below. | — | | `pagination` | object | No | Paging information for the result set. See **pagination** below. | — | #### data | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `records` | array\ | No | The page of matching packs. See **records** below. | — | ##### records | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `packId` | string | No | Pack identifier (ULID). | `01KZ8JV4Z7T3EZWMXGF3RNAYR5` | | `packName` | string | No | Display name of the pack. | `Pack Test` | | `irn` | string | No | Your Internal Reference Number for the pack, or `null` if not set. | `packirn` | | `workflowId` | string | No | ID of the workflow the pack was created from, or `null`. | `a6295beb-650f-4dc0-81b4-df8e8faf2b7e` | | `workflowRunContextId` | string | No | ID of the workflow run that produced this pack. Use it with **Check request status** and **Check Pack Details**. | `8babd0af-a418-486e-b1cd-eb717fe97c35` | | `status` | string | No | Current status of the pack. | `SENT` | | `documentCount` | integer | No | Number of documents in the pack. | `1` | | `createdAt` | string | No | When the pack was created (ISO 8601). | `2026-08-05T09:07:33Z` | | `updatedAt` | string | No | When the pack was last updated (ISO 8601). | `2026-08-05T09:09:07Z` | #### pagination Paging information for the result set. | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `pageNumber` | integer | No | Current page number (1-based). | `1` | | `pageSize` | integer | No | Number of records per page (matches `max`). | `3` | | `totalRecords` | integer | No | Total number of packs matching the query. | `96` | | `totalPages` | integer | No | Total number of pages available. | `32` | ### 400 — The request was rejected. Possible errors: - `LE_ERR_AP_007` — `max` must be >= 1 - `LE_ERR_AP_066` — `max` must be <= 40 - `LE_ERR_AP_061` — invalid query parameter (for example, a non-integer `max` or `offset`) - `LE_ERR_AP_067` — `offset` must be a non-negative integer - `LE_ERR_AP_011` — `offset` + `max` cannot exceed 1,000 without a `status` filter - `LE_ERR_AP_009` — `sortBy` must be one of: `createdAt`, `updatedAt` - `LE_ERR_AP_010` — `sortOrder` must be `asc` or `desc` - `LE_ERR_AP_013` — `status` must be one of: `DRAFT`, `SENT`, `EXPIRED`, `COMPLETED` | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `code` | string | No | Top-level error code (matches the first entry in `errors`). | `LE_ERR_AP_007` | | `traceId` | string | No | Trace identifier for the request, or `null`. | `null` | | `errors` | array\ | No | One or more errors describing why the request failed. See **errors** below. | — | #### errors | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `message` | string | No | Human-readable error message. | `max must be >= 1` | | `path` | string | No | Request path that produced the error. | `/api/v4/packs/search` | | `code` | string | No | Error code. | `LE_ERR_AP_007` | ### 401 — Authentication failed. - `LE_ERR_AP_080` — missing or invalid authentication token | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `code` | string | No | Top-level error code (matches the first entry in `errors`). | `LE_ERR_AP_007` | | `traceId` | string | No | Trace identifier for the request, or `null`. | `null` | | `errors` | array\ | No | One or more errors describing why the request failed. See **errors** below. | — | #### errors | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `message` | string | No | Human-readable error message. | `max must be >= 1` | | `path` | string | No | Request path that produced the error. | `/api/v4/packs/search` | | `code` | string | No | Error code. | `LE_ERR_AP_007` | ### Sample Response (200) ```json { "data": { "records": [ { "packId": "01KZ8JV4Z7T3EZWMXGF3RNAYR5", "packName": "Pack Test", "irn": "packirn", "workflowId": "a6295beb-650f-4dc0-81b4-df8e8faf2b7e", "workflowRunContextId": "8babd0af-a418-486e-b1cd-eb717fe97c35", "status": "SENT", "documentCount": 1, "createdAt": "2026-08-05T09:07:33Z", "updatedAt": "2026-08-05T09:09:07Z" } ] }, "pagination": { "pageNumber": 1, "pageSize": 3, "totalRecords": 96, "totalPages": 32 } } ``` --- URL: https://knowledge.leegality.com/document-execution/api/delete-pack # DELETE /v4/packs/{workflowRunContextId} — Delete pack :::info[Sandbox endpoint] **Authentication:** `X-Auth-Token` header required on every request. ## Request URL ``` DELETE https://app1.leegality.com/api/v4/packs/{workflowRunContextId} ``` **Environments:** - Production: `https://app1.leegality.com/api/v4/packs/{workflowRunContextId}` - Sandbox: `https://sandbox.leegality.com/api/v4/packs/{workflowRunContextId}` --- ## Parameters | Name | In | Required | Type | Description | Example | |------|----|----------|------|-------------|---------| | `workflowRunContextId` | path | Yes | string | Type: Path parameter The pack's `workflowRunContextId` — the UUID returned when the pack was created. This is **not** the `packId`. | — | --- ## Responses ### 200 — Pack deleted successfully. **Error codes** The request is rejected if any of the following applies: | Scenario | Status | Error code | | --- | --- | --- | | Missing or blank ID in the URL | 400 | `LE_ERR_AP_063` | | Pack not found, or belongs to a different organisation | 404 | `LE_ERR_AP_004` | | Expired token | 401 | `LE_ERR_AP_080` | | Missing token | 403 | `LE_ERR_AP_081` | | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `code` | string | No | Success code. | `LE_SUC_AP_000` | | `message` | string | No | Human-readable result message. | `Pack deleted successfully` | | `data` | object | No | Empty object. See **data** below. | `[object Object]` | #### data Empty object. | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| ### Sample Response (200) ```json { "code": "LE_SUC_AP_000", "message": "Pack deleted successfully", "data": {} } ``` --- URL: https://knowledge.leegality.com/document-execution/api/webhooks-v4/webhook-v4-introduction # Webhooks 4.0 When you send a pack for eSigning using the v4 Document Execution API, webhooks can notify you the moment an invitee completes or fails a signing action — they sign, approve, reject, or fail signature verification — without you having to poll the [Check Pack Details](https://knowledge.leegality.com/document-execution/api/check-pack-details) API. Leegality sends a JSON payload to the URL you configured on the pack, containing the event type, the pack, document, group and invitee involved, and their current status. The payload does not include the signed document or audit trail — use [Check Pack Details](https://knowledge.leegality.com/document-execution/api/check-pack-details) and the document-fetch endpoints to retrieve those once you've received the webhook. ## What's new in 4.0 Webhook 4.0 replaces the per-event payloads of earlier versions with a single, predictable shape: - **One flat envelope for every outcome.** Success and failure, signers and reviewers — every event uses the same key set and the same nesting. Nothing is renamed or restructured between events, so you write one parser. - **Two discriminators.** `webhookType` tells you which route delivered the event; `eventType` tells you what happened. You branch your handling on `eventType`. - **Pack-aware.** The payload carries the `pack`, `document`, `invitationGroup` and `invitee` the event belongs to, so you can reconcile directly against the v4 object model. - **Every key is always present.** A value that does not apply is sent as JSON `null`, never omitted. ## How it works 1. You configure a success URL, an error URL, or both — along with the payload version — on the combination when you create the pack. 2. A pack is sent using that configuration. 3. When an invitee completes or fails an action on a document, Leegality POSTs a JSON payload to the matching URL: success events to the success URL, failure events to the error URL. 4. Your server processes the payload and returns any 2XX response to acknowledge it. ## Requirements for your endpoint - Must be **publicly accessible** over HTTPS. - Must accept **POST** requests with `Content-Type: application/json`. - Must return **any 2XX** status code (for example, 200, 201, or 202) to acknowledge the request. ## Configuring Webhook 4.0 Webhook configuration is set **per combination** when you create the pack, under `combinations[].combinationSettings.webhooks`. It has four fields: - `successWebhook` — the URL that receives success events. - `errorWebhook` — the URL that receives failure events. - `webhookVersion` — the payload version; set this to the 4.0 value to receive Webhook 4.0 payloads. - `webhookProfileId` — optional; the UUID of a pre-configured webhook profile that applies transport-level security (custom headers, OAuth2, or mTLS) to the delivery. Configure the `webhooks` object as part of the [Send Pack for eSigning](https://knowledge.leegality.com/document-execution/api/create-pack) request — see that page for the full request schema and the accepted `webhookVersion` values. ## Next steps - [Event Types](https://knowledge.leegality.com/document-execution/api/webhooks-v4/webhook-v4-event-types) — the seven events and how each is routed. Each event's own page documents its exact payload. --- URL: https://knowledge.leegality.com/document-execution/api/webhooks-v4/webhook-v4-event-types # Webhook 4.0 Event Types Every Webhook 4.0 payload carries two discriminators: `webhookType`, which tells you the route that delivered the event, and `eventType`, which tells you what actually happened. **Branch your handling on `eventType`, not on the route.** ## The two discriminators - **`webhookType`** — the delivery route. `SUCCESS` events are delivered to `successWebhook`; `FAILED` events are delivered to `errorWebhook`. - **`eventType`** — what happened. Always present and never null on either route. This is the field you branch on. ## Success events Delivered to `successWebhook` (`webhookType: SUCCESS`). - [Signed](https://knowledge.leegality.com/document-execution/api/webhook-signed) — a signer completed a signature on the document. - [Signed but Verification Failed](https://knowledge.leegality.com/document-execution/api/webhook-signed-verification-failed) — a signer completed a signature but one or more certificate verification checks failed. Fires when Certificate Verification is set to "Accept but respond with result"; `messages[]` lists the mismatches. - [Reviewer Approved](https://knowledge.leegality.com/document-execution/api/webhook-reviewer-approved) — a reviewer approved the document. - [Reviewer Rejected](https://knowledge.leegality.com/document-execution/api/webhook-reviewer-rejected) — a reviewer rejected the document (`rejectionReason` set). Note this still arrives on the success URL. ## Failure events Delivered to `errorWebhook` (`webhookType: FAILED`). - [Signer Rejected](https://knowledge.leegality.com/document-execution/api/webhook-signer-rejected) — a signer rejected the invitation. - [Verification Failed](https://knowledge.leegality.com/document-execution/api/webhook-verification-failed) — a recorded verification failure (certificate details, signature, face match, face verification, or liveliness) was found; `messages[]` is populated. - [Aadhaar Retry Exhausted](https://knowledge.leegality.com/document-execution/api/webhook-aadhaar-retry-exhausted) — the invitee exhausted the permitted Aadhaar eSign retry attempts; `messages[]` is populated. - [Invitation Timeout](https://knowledge.leegality.com/document-execution/api/webhook-invitation-timeout) — the invitation expired with no failure recorded against it. --- URL: https://knowledge.leegality.com/document-execution/api/webhook-signed # WEBHOOK /your-webhook-endpoint/v4/signed — Signer Signed Fires when a signer completes a signature on the document. Delivered to `successWebhook`. **Authentication:** `X-Auth-Token` header required on every request. ## Request URL ``` WEBHOOK https://app1.leegality.com/api/your-webhook-endpoint/v4/signed ``` **Environments:** - Production: `https://app1.leegality.com/api/your-webhook-endpoint/v4/signed` - Sandbox: `https://sandbox.leegality.com/api/your-webhook-endpoint/v4/signed` --- ## Request Body **Content-Type:** `application/json` The Webhook 4.0 envelope for the **Signer Signed** event, delivered on the success route when a signer completes a signature. Every top-level key is always present; a value that does not apply to this event is sent as JSON null (the `mac` key is absent entirely when no account salt is configured). Branch your handling on `eventType`, which is always `SIGNED` here. | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `webhookType` | string | No | The delivery route the event was sent on. Always `SUCCESS` for this event. `SUCCESS` events are delivered to your `successWebhook` endpoint. Allowed: `SUCCESS`. | `SUCCESS` | | `eventType` | string | No | What happened. Always `SIGNED` for this event, which fires when a signer completes a signature. Branch your handling on this field. Allowed: `SIGNED`. | `SIGNED` | | `rejectionReason` | string | No | No rejection occurs when signing. Not applicable for the Signer Signed event. | `null` | | `combinationUuid` | string | No | The UUID of the combination this event belongs to, as supplied on the pack-create request. Webhook 4.0 carries no separate combination object — use this identifier to correlate the event with the combination you configured. | `c1d2e3f4-5678-4abc-9def-012345678903` | | `workflowRunContextId` | string | No | The pack-run identifier returned when the pack was created. It is shared by every event fired for that pack, so you can group all events belonging to a single pack run. | `wrc_abc123` | | `timestamp` | string | No | The time the event occurred, formatted as `dd-MM-yyyy HH:mm:ss`. The string carries no timezone marker. | `30-06-2026 18:53:16` | | `pack` | object | No | The pack the event belongs to. See **pack** below. | — | | `document` | object | No | The document the event is about. A separate event is fired for each document–combination mapping the invitee acted on. See **document** below. | — | | `invitationGroup` | object | No | The signer or reviewer group the invitee belongs to. See **invitationGroup** below. | — | | `invitee` | object | No | The invitee who acted or was affected. See **invitee** below. | — | | `messages` | array\ | No | No error messages on success. Not applicable for the Signer Signed event. See **messages** below. | `` | | `mac` | string | No | Hex-encoded HMAC-SHA1 of `document.documentId`, keyed by your account salt. This key is absent entirely (not null) when no salt is configured. | `a3f5b9c8d2e1f0a9b8c7d6e5f4a3b2c1d0e9f8a7` | #### pack The pack the event belongs to. | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `packId` | string | No | The pack identifier. Use it with the Check pack details endpoint to retrieve the current pack, documents and audit trail. | `pack_abc123xyz` | | `packStatus` | string | No | Live pack state at the time the event was built. This is persisted state, not the event outcome — a failure event can carry a terminal pack state such as `EXPIRED`. **Possible values:** - `SENT` - `EXPIRED` - `COMPLETED` Allowed: `SENT`, `EXPIRED`, `COMPLETED`. | `SENT` | | `packIrn` | string | No | Leegality's pack IRN, the platform-generated reference for the pack. | `PIRN-2026-001234` | | `packUrn` | string | No | The client-supplied reference for the pack. Reconcile events against your own systems on this field. | `CLIENT-URN-001` | #### document The document the event is about. A separate event is fired for each document–combination mapping the invitee acted on. | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `uuid` | string | No | The document UUID assigned at pack create. | `d1e2f3a4-5678-4abc-9def-012345678902` | | `documentId` | string | No | The document handle used by the document-fetch endpoints. `mac`, when present, is computed over this value. | `01HN8Z2K7M9P4Q5R6S7T8U9V0` | | `documentStatus` | string | No | Live document state. This is persisted state, not the event outcome. `PACK_PENDING_COMPLETION` means this document is fully executed but the pack is waiting on other documents; a failed or rejected document remains `SENT`. **Possible values:** - `SENT` - `PACK_PENDING_COMPLETION` - `COMPLETED` Allowed: `SENT`, `PACK_PENDING_COMPLETION`, `COMPLETED`. | `PACK_PENDING_COMPLETION` | | `irn` | string | No | The document IRN. | `IRN-2026-001234` | | `signatureType` | string | No | The signature method the signer used to complete the signature. **Possible values:** - `AADHAAR` - `VIRTUAL_SIGN` - `QUICK_SIGN` - `VISUAL_SIGN` - `DSC` - `DOC_SIGNER` - `AUTOMATED_SIGN` - `AUTOMATED_VIRTUAL_SIGN` - `AUTOMATED_VISUAL_SIGN` - `AUTOMATED_DOC_SIGN` Allowed: `AADHAAR`, `VIRTUAL_SIGN`, `QUICK_SIGN`, `VISUAL_SIGN`, `DSC`, `DOC_SIGNER`, `AUTOMATED_SIGN`, `AUTOMATED_VIRTUAL_SIGN`, `AUTOMATED_VISUAL_SIGN`, `AUTOMATED_DOC_SIGN`, `null`. | `AADHAAR` | #### invitationGroup The signer or reviewer group the invitee belongs to. | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `uuid` | string | No | The group UUID. | `f7b8c9d0-1234-4abc-8def-567890123456` | | `groupName` | string | No | The group's display name. | `Borrowers` | | `groupStatus` | string | No | Live group state. This is persisted state, not the event outcome — a failure event can carry `groupStatus: COMPLETED` (for example, when a threshold group has already met its minimum). **Possible values:** - `INACTIVE` - `ACTIVE` - `COMPLETED` Allowed: `INACTIVE`, `ACTIVE`, `COMPLETED`. | `COMPLETED` | | `type` | string | No | The group role. For this event the invitee is a signer, so this is typically `SIGNER` or `GROUP_SIGNER` (`GROUP_*` indicates a threshold group). **Possible values:** - `SIGNER` - `REVIEWER` - `GROUP_SIGNER` - `GROUP_REVIEWER` Allowed: `SIGNER`, `REVIEWER`, `GROUP_SIGNER`, `GROUP_REVIEWER`. | `SIGNER` | #### invitee The invitee who acted or was affected. | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `uuid` | string | No | The invitee UUID. | `a1b2c3d4-5678-4abc-9def-012345678901` | | `inviteeName` | string | No | The invitee's name. | `Rajesh Kumar` | | `inviteeEmail` | string | No | The invitee's email address. | `rajesh@example.com` | | `inviteePhone` | string | No | The invitee's 10-digit mobile number. | `9820000001` | | `invitationStatus` | string | No | Live invitation state. Always `SIGNED` for the Signer Signed event. Allowed: `SIGNED`. | `SIGNED` | #### messages | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `errorCode` | string | No | An error code. | — | | `errorMessage` | string | No | Human-readable message text. | — | ### Sample Request ```json { "webhookType": "SUCCESS", "eventType": "SIGNED", "rejectionReason": null, "combinationUuid": "c1d2e3f4-5678-4abc-9def-012345678903", "workflowRunContextId": "wrc_abc123", "timestamp": "30-06-2026 18:53:16", "pack": { "packId": "pack_abc123xyz", "packStatus": "SENT", "packIrn": "PIRN-2026-001234", "packUrn": "CLIENT-URN-001" }, "document": { "uuid": "d1e2f3a4-5678-4abc-9def-012345678902", "documentId": "01HN8Z2K7M9P4Q5R6S7T8U9V0", "documentStatus": "PACK_PENDING_COMPLETION", "irn": "IRN-2026-001234", "signatureType": "AADHAAR" }, "invitationGroup": { "uuid": "f7b8c9d0-1234-4abc-8def-567890123456", "groupName": "Borrowers", "groupStatus": "COMPLETED", "type": "SIGNER" }, "invitee": { "uuid": "a1b2c3d4-5678-4abc-9def-012345678901", "inviteeName": "Rajesh Kumar", "inviteeEmail": "rajesh@example.com", "inviteePhone": "9820000001", "invitationStatus": "SIGNED" }, "messages": [], "mac": "a3f5b9c8d2e1f0a9b8c7d6e5f4a3b2c1d0e9f8a7" } ``` --- ## Responses ### 2XX — Return any 2XX status code (200, 201, or 202) to acknowledge receipt. No specific response body is required. Any 2XX status code is accepted. --- URL: https://knowledge.leegality.com/document-execution/api/webhook-signed-verification-failed # WEBHOOK /your-webhook-endpoint/v4/signed-verification-failed — Signed but Verification Failed Fired on the **success** route when a signer completes a signature but one or more certificate verification checks (name, YOB, title, state, gender, pincode) failed. The signer was able to sign because the organisation's Certificate Verification setting is set to **Accept but respond with result** under [Settings > Department > eSignature Settings](https://knowledge.leegality.com/document-execution/settings/Department/esignature-settings). The `messages` array lists every verification mismatch. **Authentication:** `X-Auth-Token` header required on every request. ## Request URL ``` WEBHOOK https://app1.leegality.com/api/your-webhook-endpoint/v4/signed-verification-failed ``` **Environments:** - Production: `https://app1.leegality.com/api/your-webhook-endpoint/v4/signed-verification-failed` - Sandbox: `https://sandbox.leegality.com/api/your-webhook-endpoint/v4/signed-verification-failed` --- ## Request Body **Content-Type:** `application/json` The Webhook 4.0 envelope for the **Signed but Verification Failed** event, delivered on the success route when a signer completes a signature even though one or more certificate verification checks failed. This happens when the organisation's Certificate Verification setting is set to "Accept but respond with result" under Settings > Department > eSignature Settings. The `messages` array contains the verification failures — branch your handling on this field to distinguish a clean signature from one with verification mismatches. `eventType` is always `SIGNED` and `webhookType` is always `SUCCESS`. | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `webhookType` | string | No | The delivery route the event was sent on. Always `SUCCESS` for this event. `SUCCESS` events are delivered to your `successWebhook` endpoint. Allowed: `SUCCESS`. | `SUCCESS` | | `eventType` | string | No | What happened. Always `SIGNED` for this event — the signer completed the signature despite verification failures. Branch your handling on the `messages` array to detect verification mismatches. Allowed: `SIGNED`. | `SIGNED` | | `rejectionReason` | string | No | No rejection occurs when signing. Not applicable for this event. | `null` | | `combinationUuid` | string | No | The UUID of the combination this event belongs to, as supplied on the pack-create request. Webhook 4.0 carries no separate combination object — use this identifier to correlate the event with the combination you configured. | `c1d2e3f4-5678-4abc-9def-012345678903` | | `workflowRunContextId` | string | No | The pack-run identifier returned when the pack was created. It is shared by every event fired for that pack, so you can group all events belonging to a single pack run. | `wrc_abc123` | | `timestamp` | string | No | The time the event occurred, formatted as `dd-MM-yyyy HH:mm:ss`. The string carries no timezone marker. | `30-06-2026 18:53:16` | | `pack` | object | No | The pack the event belongs to. See **pack** below. | — | | `document` | object | No | The document the event is about. A separate event is fired for each document–combination mapping the invitee acted on. See **document** below. | — | | `invitationGroup` | object | No | The signer or reviewer group the invitee belongs to. See **invitationGroup** below. | — | | `invitee` | object | No | The invitee who acted or was affected. See **invitee** below. | — | | `messages` | array\ | No | Verification failures detected during signing. Each object represents a check that did not pass. The signer was still able to sign because the Certificate Verification setting is set to "Accept but respond with result". See **messages** below. | `[object Object],[object Object],[object Object],[object Obje` | | `mac` | string | No | Hex-encoded HMAC-SHA1 of `document.documentId`, keyed by your account salt. This key is absent entirely (not null) when no salt is configured. | `a3f5b9c8d2e1f0a9b8c7d6e5f4a3b2c1d0e9f8a7` | #### pack The pack the event belongs to. | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `packId` | string | No | The pack identifier. Use it with the Check pack details endpoint to retrieve the current pack, documents and audit trail. | `pack_abc123xyz` | | `packStatus` | string | No | Live pack state at the time the event was built. This is persisted state, not the event outcome — a failure event can carry a terminal pack state such as `EXPIRED`. **Possible values:** - `SENT` - `EXPIRED` - `COMPLETED` Allowed: `SENT`, `EXPIRED`, `COMPLETED`. | `SENT` | | `packIrn` | string | No | Leegality's pack IRN, the platform-generated reference for the pack. | `PIRN-2026-001234` | | `packUrn` | string | No | The client-supplied reference for the pack. Reconcile events against your own systems on this field. | `CLIENT-URN-001` | #### document The document the event is about. A separate event is fired for each document–combination mapping the invitee acted on. | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `uuid` | string | No | The document UUID assigned at pack create. | `d1e2f3a4-5678-4abc-9def-012345678902` | | `documentId` | string | No | The document handle used by the document-fetch endpoints. `mac`, when present, is computed over this value. | `01HN8Z2K7M9P4Q5R6S7T8U9V0` | | `documentStatus` | string | No | Live document state. This is persisted state, not the event outcome. `PACK_PENDING_COMPLETION` means this document is fully executed but the pack is waiting on other documents; a failed or rejected document remains `SENT`. **Possible values:** - `SENT` - `PACK_PENDING_COMPLETION` - `COMPLETED` Allowed: `SENT`, `PACK_PENDING_COMPLETION`, `COMPLETED`. | `PACK_PENDING_COMPLETION` | | `irn` | string | No | The document IRN. | `IRN-2026-001234` | | `signatureType` | string | No | The signature method the signer used to complete the signature. **Possible values:** - `AADHAAR` - `VIRTUAL_SIGN` - `QUICK_SIGN` - `VISUAL_SIGN` - `DSC` - `DOC_SIGNER` - `AUTOMATED_SIGN` - `AUTOMATED_VIRTUAL_SIGN` - `AUTOMATED_VISUAL_SIGN` - `AUTOMATED_DOC_SIGN` Allowed: `AADHAAR`, `VIRTUAL_SIGN`, `QUICK_SIGN`, `VISUAL_SIGN`, `DSC`, `DOC_SIGNER`, `AUTOMATED_SIGN`, `AUTOMATED_VIRTUAL_SIGN`, `AUTOMATED_VISUAL_SIGN`, `AUTOMATED_DOC_SIGN`, `null`. | `AADHAAR` | #### invitationGroup The signer or reviewer group the invitee belongs to. | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `uuid` | string | No | The group UUID. | `f7b8c9d0-1234-4abc-8def-567890123456` | | `groupName` | string | No | The group's display name. | `Borrowers` | | `groupStatus` | string | No | Live group state. This is persisted state, not the event outcome — a failure event can carry `groupStatus: COMPLETED` (for example, when a threshold group has already met its minimum). **Possible values:** - `INACTIVE` - `ACTIVE` - `COMPLETED` Allowed: `INACTIVE`, `ACTIVE`, `COMPLETED`. | `COMPLETED` | | `type` | string | No | The group role. For this event the invitee is a signer, so this is typically `SIGNER` or `GROUP_SIGNER` (`GROUP_*` indicates a threshold group). **Possible values:** - `SIGNER` - `REVIEWER` - `GROUP_SIGNER` - `GROUP_REVIEWER` Allowed: `SIGNER`, `REVIEWER`, `GROUP_SIGNER`, `GROUP_REVIEWER`. | `SIGNER` | #### invitee The invitee who acted or was affected. | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `uuid` | string | No | The invitee UUID. | `a1b2c3d4-5678-4abc-9def-012345678901` | | `inviteeName` | string | No | The invitee's name. | `Rajesh Kumar` | | `inviteeEmail` | string | No | The invitee's email address. | `rajesh@example.com` | | `inviteePhone` | string | No | The invitee's 10-digit mobile number. | `9820000001` | | `invitationStatus` | string | No | Live invitation state. Always `SIGNED` for this event. Allowed: `SIGNED`. | `SIGNED` | #### messages | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `errorCode` | string | No | The verification check that failed. **Possible values:** - `smartname.verification.failed` - `name.verification.failed` - `pincode.verification.failed` - `yob.verification.failed` - `gender.verification.failed` - `title.verification.failed` - `state.verification.failed` | `name.verification.failed` | | `errorMessage` | string | No | Human-readable description of the mismatch. | `Name doesn't match with the Digital Signature Certificate.` | ### Sample Request ```json { "webhookType": "SUCCESS", "eventType": "SIGNED", "rejectionReason": null, "combinationUuid": "c1d2e3f4-5678-4abc-9def-012345678903", "workflowRunContextId": "wrc_abc123", "timestamp": "30-06-2026 18:53:16", "pack": { "packId": "pack_abc123xyz", "packStatus": "SENT", "packIrn": "PIRN-2026-001234", "packUrn": "CLIENT-URN-001" }, "document": { "uuid": "d1e2f3a4-5678-4abc-9def-012345678902", "documentId": "01HN8Z2K7M9P4Q5R6S7T8U9V0", "documentStatus": "PACK_PENDING_COMPLETION", "irn": "IRN-2026-001234", "signatureType": "AADHAAR" }, "invitationGroup": { "uuid": "f7b8c9d0-1234-4abc-8def-567890123456", "groupName": "Borrowers", "groupStatus": "COMPLETED", "type": "SIGNER" }, "invitee": { "uuid": "a1b2c3d4-5678-4abc-9def-012345678901", "inviteeName": "Rajesh Kumar", "inviteeEmail": "rajesh@example.com", "inviteePhone": "9820000001", "invitationStatus": "SIGNED" }, "messages": [ { "errorCode": "smartname.verification.failed", "errorMessage": "Name (Smart Verification) doesn't match with the Digital Signature Certificate." }, { "errorCode": "name.verification.failed", "errorMessage": "Name doesn't match with the Digital Signature Certificate." }, { "errorCode": "pincode.verification.failed", "errorMessage": "Pincode doesn't match with the Digital Signature Certificate." }, { "errorCode": "yob.verification.failed", "errorMessage": "Year of birth doesn't match with the Digital Signature Certificate." }, { "errorCode": "gender.verification.failed", "errorMessage": "Gender doesn't match with the Digital Signature Certificate." }, { "errorCode": "title.verification.failed", "errorMessage": "Title doesn't match with the Digital Signature Certificate." }, { "errorCode": "state.verification.failed", "errorMessage": "State doesn't match with the Digital Signature Certificate." } ], "mac": "a3f5b9c8d2e1f0a9b8c7d6e5f4a3b2c1d0e9f8a7" } ``` --- ## Responses ### 2XX — Return any 2XX status code (200, 201, or 202) to acknowledge receipt. No specific response body is required. Any 2XX status code is accepted. --- URL: https://knowledge.leegality.com/document-execution/api/webhook-reviewer-approved # WEBHOOK /your-webhook-endpoint/v4/reviewer-approved — Reviewer Approved Fires when a reviewer approves the document. Delivered to `successWebhook`. **Authentication:** `X-Auth-Token` header required on every request. ## Request URL ``` WEBHOOK https://app1.leegality.com/api/your-webhook-endpoint/v4/reviewer-approved ``` **Environments:** - Production: `https://app1.leegality.com/api/your-webhook-endpoint/v4/reviewer-approved` - Sandbox: `https://sandbox.leegality.com/api/your-webhook-endpoint/v4/reviewer-approved` --- ## Request Body **Content-Type:** `application/json` The Webhook 4.0 envelope for the **Reviewer Approved** event, delivered on the success route when a reviewer approves the document. Every top-level key is always present; a value that does not apply to this event is sent as JSON null (the `mac` key is absent entirely when no account salt is configured). Branch your handling on `eventType`, which is always `REVIEWER_APPROVAL` here. | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `webhookType` | string | No | The delivery route the event was sent on. Always `SUCCESS` for this event. `SUCCESS` events are delivered to your `successWebhook` endpoint. Allowed: `SUCCESS`. | `SUCCESS` | | `eventType` | string | No | What happened. Always `REVIEWER_APPROVAL` for this event, which fires when a reviewer approves the document. Branch your handling on this field. Allowed: `REVIEWER_APPROVAL`. | `REVIEWER_APPROVAL` | | `rejectionReason` | string | No | No rejection occurs on approval. Not applicable for the Reviewer Approved event. | `null` | | `combinationUuid` | string | No | The UUID of the combination this event belongs to, as supplied on the pack-create request. Webhook 4.0 carries no separate combination object — use this identifier to correlate the event with the combination you configured. | `c1d2e3f4-5678-4abc-9def-012345678903` | | `workflowRunContextId` | string | No | The pack-run identifier returned when the pack was created. It is shared by every event fired for that pack, so you can group all events belonging to a single pack run. | `wrc_abc123` | | `timestamp` | string | No | The time the event occurred, formatted as `dd-MM-yyyy HH:mm:ss`. The string carries no timezone marker. | `30-06-2026 18:55:02` | | `pack` | object | No | The pack the event belongs to. See **pack** below. | — | | `document` | object | No | The document the event is about. A separate event is fired for each document–combination mapping the invitee acted on. See **document** below. | — | | `invitationGroup` | object | No | The signer or reviewer group the invitee belongs to. See **invitationGroup** below. | — | | `invitee` | object | No | The invitee who acted or was affected. See **invitee** below. | — | | `messages` | array\ | No | No error messages on approval. Not applicable for the Reviewer Approved event. See **messages** below. | `` | | `mac` | string | No | Hex-encoded HMAC-SHA1 of `document.documentId`, keyed by your account salt. This key is absent entirely (not null) when no salt is configured. | `a3f5b9c8d2e1f0a9b8c7d6e5f4a3b2c1d0e9f8a7` | #### pack The pack the event belongs to. | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `packId` | string | No | The pack identifier. Use it with the Check pack details endpoint to retrieve the current pack, documents and audit trail. | `pack_abc123xyz` | | `packStatus` | string | No | Live pack state at the time the event was built. This is persisted state, not the event outcome — a failure event can carry a terminal pack state such as `EXPIRED`. **Possible values:** - `SENT` - `EXPIRED` - `COMPLETED` Allowed: `SENT`, `EXPIRED`, `COMPLETED`. | `SENT` | | `packIrn` | string | No | Leegality's pack IRN, the platform-generated reference for the pack. | `PIRN-2026-001234` | | `packUrn` | string | No | The client-supplied reference for the pack. Reconcile events against your own systems on this field. | `CLIENT-URN-001` | #### document The document the event is about. A separate event is fired for each document–combination mapping the invitee acted on. | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `uuid` | string | No | The document UUID assigned at pack create. | `d1e2f3a4-5678-4abc-9def-012345678902` | | `documentId` | string | No | The document handle used by the document-fetch endpoints. `mac`, when present, is computed over this value. | `01HN8Z2K7M9P4Q5R6S7T8U9V0` | | `documentStatus` | string | No | Live document state. This is persisted state, not the event outcome. `PACK_PENDING_COMPLETION` means this document is fully executed but the pack is waiting on other documents; a failed or rejected document remains `SENT`. **Possible values:** - `SENT` - `PACK_PENDING_COMPLETION` - `COMPLETED` Allowed: `SENT`, `PACK_PENDING_COMPLETION`, `COMPLETED`. | `SENT` | | `irn` | string | No | The document IRN. | `IRN-2026-001234` | | `signatureType` | string | No | Reviewers do not sign. Not applicable for the Reviewer Approved event. | `null` | #### invitationGroup The signer or reviewer group the invitee belongs to. | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `uuid` | string | No | The group UUID. | `b2c3d4e5-6789-4abc-8def-123456789012` | | `groupName` | string | No | The group's display name. | `Reviewers` | | `groupStatus` | string | No | Live group state. This is persisted state, not the event outcome — a failure event can carry `groupStatus: COMPLETED` (for example, when a threshold group has already met its minimum). **Possible values:** - `INACTIVE` - `ACTIVE` - `COMPLETED` Allowed: `INACTIVE`, `ACTIVE`, `COMPLETED`. | `COMPLETED` | | `type` | string | No | The group role. For this event the invitee is a reviewer, so this is typically `REVIEWER` or `GROUP_REVIEWER` (`GROUP_*` indicates a threshold group). **Possible values:** - `SIGNER` - `REVIEWER` - `GROUP_SIGNER` - `GROUP_REVIEWER` Allowed: `SIGNER`, `REVIEWER`, `GROUP_SIGNER`, `GROUP_REVIEWER`. | `REVIEWER` | #### invitee The invitee who acted or was affected. | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `uuid` | string | No | The invitee UUID. | `c3d4e5f6-7890-4abc-8def-234567890123` | | `inviteeName` | string | No | The invitee's name. | `Anita Verma` | | `inviteeEmail` | string | No | The invitee's email address. | `anita@example.com` | | `inviteePhone` | string | No | The invitee's 10-digit mobile number. | `9820000003` | | `invitationStatus` | string | No | Live invitation state. Always `REVIEWER_APPROVED` for the Reviewer Approved event. Allowed: `REVIEWER_APPROVED`. | `REVIEWER_APPROVED` | #### messages | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `errorCode` | string | No | An error code. | — | | `errorMessage` | string | No | Human-readable message text. | — | ### Sample Request ```json { "webhookType": "SUCCESS", "eventType": "REVIEWER_APPROVAL", "rejectionReason": null, "combinationUuid": "c1d2e3f4-5678-4abc-9def-012345678903", "workflowRunContextId": "wrc_abc123", "timestamp": "30-06-2026 18:55:02", "pack": { "packId": "pack_abc123xyz", "packStatus": "SENT", "packIrn": "PIRN-2026-001234", "packUrn": "CLIENT-URN-001" }, "document": { "uuid": "d1e2f3a4-5678-4abc-9def-012345678902", "documentId": "01HN8Z2K7M9P4Q5R6S7T8U9V0", "documentStatus": "SENT", "irn": "IRN-2026-001234", "signatureType": null }, "invitationGroup": { "uuid": "b2c3d4e5-6789-4abc-8def-123456789012", "groupName": "Reviewers", "groupStatus": "COMPLETED", "type": "REVIEWER" }, "invitee": { "uuid": "c3d4e5f6-7890-4abc-8def-234567890123", "inviteeName": "Anita Verma", "inviteeEmail": "anita@example.com", "inviteePhone": "9820000003", "invitationStatus": "REVIEWER_APPROVED" }, "messages": [], "mac": "a3f5b9c8d2e1f0a9b8c7d6e5f4a3b2c1d0e9f8a7" } ``` --- ## Responses ### 2XX — Return any 2XX status code (200, 201, or 202) to acknowledge receipt. No specific response body is required. Any 2XX status code is accepted. --- URL: https://knowledge.leegality.com/document-execution/api/webhook-reviewer-rejected # WEBHOOK /your-webhook-endpoint/v4/reviewer-rejected — Reviewer Rejected A reviewer who rejects has completed their review — a decision was reached, so the event is delivered to `successWebhook` with `webhookType: SUCCESS` and `eventType: REVIEWER_REJECTION`. (A signer who rejects has not signed, so that event goes to `errorWebhook` as `SIGNER_REJECTION`.) Read `eventType`, not the route. **Authentication:** `X-Auth-Token` header required on every request. ## Request URL ``` WEBHOOK https://app1.leegality.com/api/your-webhook-endpoint/v4/reviewer-rejected ``` **Environments:** - Production: `https://app1.leegality.com/api/your-webhook-endpoint/v4/reviewer-rejected` - Sandbox: `https://sandbox.leegality.com/api/your-webhook-endpoint/v4/reviewer-rejected` --- ## Request Body **Content-Type:** `application/json` The Webhook 4.0 envelope for the **Reviewer Rejected** event. A reviewer rejection is a decision, so it is delivered on the **success** route with `eventType: REVIEWER_REJECTION`. Every top-level key is always present; a value that does not apply to this event is sent as JSON null (the `mac` key is absent entirely when no account salt is configured). Branch your handling on `eventType`, not on the route. | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `webhookType` | string | No | The delivery route the event was sent on. Always `SUCCESS` for this event. A reviewer decision is a `SUCCESS` event and is delivered to your `successWebhook` endpoint even though the outcome is a rejection — do not infer the outcome from this field; branch on `eventType`. Allowed: `SUCCESS`. | `SUCCESS` | | `eventType` | string | No | What happened. Always `REVIEWER_REJECTION` for this event, which fires when a reviewer rejects the document. Branch your handling on this field. Allowed: `REVIEWER_REJECTION`. | `REVIEWER_REJECTION` | | `rejectionReason` | string | No | The reason the reviewer gave when rejecting. Populated (non-null) on this event. | `Document content does not match the approved template` | | `combinationUuid` | string | No | The UUID of the combination this event belongs to, as supplied on the pack-create request. Webhook 4.0 carries no separate combination object — use this identifier to correlate the event with the combination you configured. | `c1d2e3f4-5678-4abc-9def-012345678903` | | `workflowRunContextId` | string | No | The pack-run identifier returned when the pack was created. It is shared by every event fired for that pack, so you can group all events belonging to a single pack run. | `wrc_abc123` | | `timestamp` | string | No | The time the event occurred, formatted as `dd-MM-yyyy HH:mm:ss`. The string carries no timezone marker. | `30-06-2026 19:02:41` | | `pack` | object | No | The pack the event belongs to. See **pack** below. | — | | `document` | object | No | The document the event is about. A separate event is fired for each document–combination mapping the invitee acted on. See **document** below. | — | | `invitationGroup` | object | No | The signer or reviewer group the invitee belongs to. See **invitationGroup** below. | — | | `invitee` | object | No | The invitee who acted or was affected. See **invitee** below. | — | | `messages` | array\ | No | No error messages on reviewer rejection. Not applicable for the Reviewer Rejected event. See **messages** below. | `` | | `mac` | string | No | Hex-encoded HMAC-SHA1 of `document.documentId`, keyed by your account salt. This key is absent entirely (not null) when no salt is configured. | `a3f5b9c8d2e1f0a9b8c7d6e5f4a3b2c1d0e9f8a7` | #### pack The pack the event belongs to. | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `packId` | string | No | The pack identifier. Use it with the Check pack details endpoint to retrieve the current pack, documents and audit trail. | `pack_abc123xyz` | | `packStatus` | string | No | Live pack state at the time the event was built. This is persisted state, not the event outcome — a failure event can carry a terminal pack state such as `EXPIRED`. **Possible values:** - `SENT` - `EXPIRED` - `COMPLETED` Allowed: `SENT`, `EXPIRED`, `COMPLETED`. | `SENT` | | `packIrn` | string | No | Leegality's pack IRN, the platform-generated reference for the pack. | `PIRN-2026-001234` | | `packUrn` | string | No | The client-supplied reference for the pack. Reconcile events against your own systems on this field. | `CLIENT-URN-001` | #### document The document the event is about. A separate event is fired for each document–combination mapping the invitee acted on. | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `uuid` | string | No | The document UUID assigned at pack create. | `d1e2f3a4-5678-4abc-9def-012345678902` | | `documentId` | string | No | The document handle used by the document-fetch endpoints. `mac`, when present, is computed over this value. | `01HN8Z2K7M9P4Q5R6S7T8U9V0` | | `documentStatus` | string | No | Live document state. This is persisted state, not the event outcome. `PACK_PENDING_COMPLETION` means this document is fully executed but the pack is waiting on other documents; a failed or rejected document remains `SENT`. **Possible values:** - `SENT` - `PACK_PENDING_COMPLETION` - `COMPLETED` Allowed: `SENT`, `PACK_PENDING_COMPLETION`, `COMPLETED`. | `SENT` | | `irn` | string | No | The document IRN. | `IRN-2026-001234` | | `signatureType` | string | No | Reviewers do not sign. Not applicable for the Reviewer Rejected event. | `null` | #### invitationGroup The signer or reviewer group the invitee belongs to. | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `uuid` | string | No | The group UUID. | `b2c3d4e5-6789-4abc-8def-123456789012` | | `groupName` | string | No | The group's display name. | `Reviewers` | | `groupStatus` | string | No | Live group state. This is persisted state, not the event outcome — a failure event can carry `groupStatus: COMPLETED` (for example, when a threshold group has already met its minimum). **Possible values:** - `INACTIVE` - `ACTIVE` - `COMPLETED` Allowed: `INACTIVE`, `ACTIVE`, `COMPLETED`. | `ACTIVE` | | `type` | string | No | The group role. For this event the invitee is a reviewer, so this is typically `REVIEWER` or `GROUP_REVIEWER` (`GROUP_*` indicates a threshold group). **Possible values:** - `SIGNER` - `REVIEWER` - `GROUP_SIGNER` - `GROUP_REVIEWER` Allowed: `SIGNER`, `REVIEWER`, `GROUP_SIGNER`, `GROUP_REVIEWER`. | `REVIEWER` | #### invitee The invitee who acted or was affected. | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `uuid` | string | No | The invitee UUID. | `c3d4e5f6-7890-4abc-8def-234567890123` | | `inviteeName` | string | No | The invitee's name. | `Anita Verma` | | `inviteeEmail` | string | No | The invitee's email address. | `anita@example.com` | | `inviteePhone` | string | No | The invitee's 10-digit mobile number, without country code. | `9820000003` | | `invitationStatus` | string | No | Live invitation state. Always `REVIEWER_REJECTED` for the Reviewer Rejected event. Allowed: `REVIEWER_REJECTED`. | `REVIEWER_REJECTED` | #### messages | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `errorCode` | string | No | An error code. | — | | `errorMessage` | string | No | Human-readable message text. | — | ### Sample Request ```json { "webhookType": "SUCCESS", "eventType": "REVIEWER_REJECTION", "rejectionReason": "Document content does not match the approved template", "combinationUuid": "c1d2e3f4-5678-4abc-9def-012345678903", "workflowRunContextId": "wrc_abc123", "timestamp": "30-06-2026 19:02:41", "pack": { "packId": "pack_abc123xyz", "packStatus": "SENT", "packIrn": "PIRN-2026-001234", "packUrn": "CLIENT-URN-001" }, "document": { "uuid": "d1e2f3a4-5678-4abc-9def-012345678902", "documentId": "01HN8Z2K7M9P4Q5R6S7T8U9V0", "documentStatus": "SENT", "irn": "IRN-2026-001234", "signatureType": null }, "invitationGroup": { "uuid": "b2c3d4e5-6789-4abc-8def-123456789012", "groupName": "Reviewers", "groupStatus": "ACTIVE", "type": "REVIEWER" }, "invitee": { "uuid": "c3d4e5f6-7890-4abc-8def-234567890123", "inviteeName": "Anita Verma", "inviteeEmail": "anita@example.com", "inviteePhone": "9820000003", "invitationStatus": "REVIEWER_REJECTED" }, "messages": [], "mac": "a3f5b9c8d2e1f0a9b8c7d6e5f4a3b2c1d0e9f8a7" } ``` --- ## Responses ### 2XX — Return any 2XX status code (200, 201, or 202) to acknowledge receipt. No specific response body is required. Any 2XX status code is accepted. --- URL: https://knowledge.leegality.com/document-execution/api/webhook-signer-rejected # WEBHOOK /your-webhook-endpoint/v4/signer-rejected — Signer Rejected Fires when a signer rejects the invitation. Delivered to `errorWebhook`. **Authentication:** `X-Auth-Token` header required on every request. ## Request URL ``` WEBHOOK https://app1.leegality.com/api/your-webhook-endpoint/v4/signer-rejected ``` **Environments:** - Production: `https://app1.leegality.com/api/your-webhook-endpoint/v4/signer-rejected` - Sandbox: `https://sandbox.leegality.com/api/your-webhook-endpoint/v4/signer-rejected` --- ## Request Body **Content-Type:** `application/json` The Webhook 4.0 envelope for the **Signer Rejected** event, delivered on the failure route when a signer rejected the invitation. Every top-level key is always present; a value that does not apply to this event is sent as JSON null (the `mac` key is absent entirely when no account salt is configured). Branch your handling on `eventType`, which is always `SIGNER_REJECTION` here. | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `webhookType` | string | No | The delivery route the event was sent on. Always `FAILED` for this event. `FAILED` events are delivered to your `errorWebhook` endpoint. Do not infer the outcome from this field; branch on `eventType`. Allowed: `FAILED`. | `FAILED` | | `eventType` | string | No | What happened. Always `SIGNER_REJECTION` for this event, which fires when a signer rejected the invitation. Branch your handling on this field. Allowed: `SIGNER_REJECTION`. | `SIGNER_REJECTION` | | `rejectionReason` | string | No | The reason the signer gave when rejecting. Populated (non-null) on this event. | `I do not agree with clause 5.2 regarding interest rates` | | `combinationUuid` | string | No | The UUID of the combination this event belongs to, as supplied on the pack-create request. Webhook 4.0 carries no separate combination object — use this identifier to correlate the event with the combination you configured. | `c1d2e3f4-5678-4abc-9def-012345678903` | | `workflowRunContextId` | string | No | The pack-run identifier returned when the pack was created. It is shared by every event fired for that pack, so you can group all events belonging to a single pack run. | `wrc_abc123` | | `timestamp` | string | No | The time the event occurred, formatted as `dd-MM-yyyy HH:mm:ss`. The string carries no timezone marker. | `30-06-2026 19:10:07` | | `pack` | object | No | The pack the event belongs to. See **pack** below. | — | | `document` | object | No | The document the event is about. A separate event is fired for each document–combination mapping the invitee acted on. See **document** below. | — | | `invitationGroup` | object | No | The signer or reviewer group the invitee belongs to. See **invitationGroup** below. | — | | `invitee` | object | No | The invitee who acted or was affected. See **invitee** below. | — | | `messages` | array\ | No | No error messages on signer rejection. Not applicable for the Signer Rejected event. See **messages** below. | `` | | `mac` | string | No | Hex-encoded HMAC-SHA1 of `document.documentId`, keyed by your account salt. This key is absent entirely (not null) when no salt is configured. | `a3f5b9c8d2e1f0a9b8c7d6e5f4a3b2c1d0e9f8a7` | #### pack The pack the event belongs to. | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `packId` | string | No | The pack identifier. Use it with the Check pack details endpoint to retrieve the current pack, documents and audit trail. | `pack_abc123xyz` | | `packStatus` | string | No | Live pack state at the time the event was built. This is persisted state, not the event outcome — a failure event can carry a terminal pack state such as `EXPIRED`. **Possible values:** - `SENT` - `EXPIRED` - `COMPLETED` Allowed: `SENT`, `EXPIRED`, `COMPLETED`. | `SENT` | | `packIrn` | string | No | Leegality's pack IRN, the platform-generated reference for the pack. | `PIRN-2026-001234` | | `packUrn` | string | No | The client-supplied reference for the pack. Reconcile events against your own systems on this field. | `CLIENT-URN-001` | #### document The document the event is about. A separate event is fired for each document–combination mapping the invitee acted on. | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `uuid` | string | No | The document UUID assigned at pack create. | `d1e2f3a4-5678-4abc-9def-012345678902` | | `documentId` | string | No | The document handle used by the document-fetch endpoints. `mac`, when present, is computed over this value. | `01HN8Z2K7M9P4Q5R6S7T8U9V0` | | `documentStatus` | string | No | Live document state. This is persisted state, not the event outcome. `PACK_PENDING_COMPLETION` means this document is fully executed but the pack is waiting on other documents; a failed or rejected document remains `SENT`. **Possible values:** - `SENT` - `PACK_PENDING_COMPLETION` - `COMPLETED` Allowed: `SENT`, `PACK_PENDING_COMPLETION`, `COMPLETED`. | `SENT` | | `irn` | string | No | The document IRN. | `IRN-2026-001234` | | `signatureType` | string | No | Signer rejection records no method. Not applicable for the Signer Rejected event. | `null` | #### invitationGroup The signer or reviewer group the invitee belongs to. | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `uuid` | string | No | The group UUID. | `f7b8c9d0-1234-4abc-8def-567890123456` | | `groupName` | string | No | The group's display name. | `Borrowers` | | `groupStatus` | string | No | Live group state. This is persisted state, not the event outcome — a failure event can carry `groupStatus: COMPLETED` (for example, when a threshold group has already met its minimum). **Possible values:** - `INACTIVE` - `ACTIVE` - `COMPLETED` Allowed: `INACTIVE`, `ACTIVE`, `COMPLETED`. | `ACTIVE` | | `type` | string | No | The group role. For this event the invitee is a signer, so this is typically `SIGNER` or `GROUP_SIGNER` (`GROUP_*` indicates a threshold group). **Possible values:** - `SIGNER` - `REVIEWER` - `GROUP_SIGNER` - `GROUP_REVIEWER` Allowed: `SIGNER`, `REVIEWER`, `GROUP_SIGNER`, `GROUP_REVIEWER`. | `SIGNER` | #### invitee The invitee who acted or was affected. | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `uuid` | string | No | The invitee UUID. | `a1b2c3d4-5678-4abc-9def-012345678901` | | `inviteeName` | string | No | The invitee's name. | `Rajesh Kumar` | | `inviteeEmail` | string | No | The invitee's email address. | `rajesh@example.com` | | `inviteePhone` | string | No | The invitee's 10-digit mobile number. | `9820000001` | | `invitationStatus` | string | No | Live invitation state. Always `SIGNER_REJECTED` for the Signer Rejected event. Allowed: `SIGNER_REJECTED`. | `SIGNER_REJECTED` | #### messages | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `errorCode` | string | No | An error code. | — | | `errorMessage` | string | No | Human-readable message text. | — | ### Sample Request ```json { "webhookType": "FAILED", "eventType": "SIGNER_REJECTION", "rejectionReason": "I do not agree with clause 5.2 regarding interest rates", "combinationUuid": "c1d2e3f4-5678-4abc-9def-012345678903", "workflowRunContextId": "wrc_abc123", "timestamp": "30-06-2026 19:10:07", "pack": { "packId": "pack_abc123xyz", "packStatus": "SENT", "packIrn": "PIRN-2026-001234", "packUrn": "CLIENT-URN-001" }, "document": { "uuid": "d1e2f3a4-5678-4abc-9def-012345678902", "documentId": "01HN8Z2K7M9P4Q5R6S7T8U9V0", "documentStatus": "SENT", "irn": "IRN-2026-001234", "signatureType": null }, "invitationGroup": { "uuid": "f7b8c9d0-1234-4abc-8def-567890123456", "groupName": "Borrowers", "groupStatus": "ACTIVE", "type": "SIGNER" }, "invitee": { "uuid": "a1b2c3d4-5678-4abc-9def-012345678901", "inviteeName": "Rajesh Kumar", "inviteeEmail": "rajesh@example.com", "inviteePhone": "9820000001", "invitationStatus": "SIGNER_REJECTED" }, "messages": [], "mac": "a3f5b9c8d2e1f0a9b8c7d6e5f4a3b2c1d0e9f8a7" } ``` --- ## Responses ### 2XX — Return any 2XX status code (200, 201, or 202) to acknowledge receipt. No specific response body is required. Any 2XX status code is accepted. --- URL: https://knowledge.leegality.com/document-execution/api/webhook-verification-failed # WEBHOOK /your-webhook-endpoint/v4/verification-failed — Verification Failed Fires when the invitation expired carrying one of the recorded verification failures — certificate details mismatch, signature verification, face match, face verification, or smart user liveliness. Delivered to `errorWebhook`; `messages[]` is populated. **Authentication:** `X-Auth-Token` header required on every request. ## Request URL ``` WEBHOOK https://app1.leegality.com/api/your-webhook-endpoint/v4/verification-failed ``` **Environments:** - Production: `https://app1.leegality.com/api/your-webhook-endpoint/v4/verification-failed` - Sandbox: `https://sandbox.leegality.com/api/your-webhook-endpoint/v4/verification-failed` --- ## Request Body **Content-Type:** `application/json` The Webhook 4.0 envelope for the **Verification Failed** event, delivered on the failure route when an invitation expired with a recorded verification failure. `messages[]` carries one entry per failed check. Every top-level key is always present; a value that does not apply to this event is sent as JSON null (the `mac` key is absent entirely when no account salt is configured). Branch your handling on `eventType`, which is always `VERIFICATION_FAILED` here. | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `webhookType` | string | No | The delivery route the event was sent on. Always `FAILED` for this event. `FAILED` events are delivered to your `errorWebhook` endpoint. Allowed: `FAILED`. | `FAILED` | | `eventType` | string | No | What happened. Always `VERIFICATION_FAILED` for this event, which fires when an invitation expired with a recorded verification failure. Branch your handling on this field. Allowed: `VERIFICATION_FAILED`. | `VERIFICATION_FAILED` | | `rejectionReason` | string | No | No invitee rejection here. Not applicable for the Verification Failed event. | `null` | | `combinationUuid` | string | No | The UUID of the combination this event belongs to, as supplied on the pack-create request. Webhook 4.0 carries no separate combination object — use this identifier to correlate the event with the combination you configured. | `c1d2e3f4-5678-4abc-9def-012345678903` | | `workflowRunContextId` | string | No | The pack-run identifier returned when the pack was created. It is shared by every event fired for that pack, so you can group all events belonging to a single pack run. | `wrc_abc123` | | `timestamp` | string | No | The time the event occurred, formatted as `dd-MM-yyyy HH:mm:ss`. The string carries no timezone marker. | `30-06-2026 19:14:33` | | `pack` | object | No | The pack the event belongs to. See **pack** below. | — | | `document` | object | No | The document the event is about. A separate event is fired for each document–combination mapping the invitee acted on. See **document** below. | — | | `invitationGroup` | object | No | The signer or reviewer group the invitee belongs to. See **invitationGroup** below. | — | | `invitee` | object | No | The invitee who acted or was affected. See **invitee** below. | — | | `messages` | array\ | No | One entry per failed verification check. See the message catalogue below for the keys and text. See **messages** below. | `[object Object],[object Object]` | | `mac` | string | No | Hex-encoded HMAC-SHA1 of `document.documentId`, keyed by your account salt. This key is absent entirely (not null) when no salt is configured. | `a3f5b9c8d2e1f0a9b8c7d6e5f4a3b2c1d0e9f8a7` | #### pack The pack the event belongs to. | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `packId` | string | No | The pack identifier. Use it with the Check pack details endpoint to retrieve the current pack, documents and audit trail. | `pack_abc123xyz` | | `packStatus` | string | No | Live pack state at the time the event was built. This is persisted state, not the event outcome — a failure event can carry a terminal pack state such as `EXPIRED`. **Possible values:** - `SENT` - `EXPIRED` - `COMPLETED` Allowed: `SENT`, `EXPIRED`, `COMPLETED`. | `SENT` | | `packIrn` | string | No | Leegality's pack IRN, the platform-generated reference for the pack. | `PIRN-2026-001234` | | `packUrn` | string | No | The client-supplied reference for the pack. Reconcile events against your own systems on this field. | `CLIENT-URN-001` | #### document The document the event is about. A separate event is fired for each document–combination mapping the invitee acted on. | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `uuid` | string | No | The document UUID assigned at pack create. | `d1e2f3a4-5678-4abc-9def-012345678902` | | `documentId` | string | No | The document handle used by the document-fetch endpoints. `mac`, when present, is computed over this value. | `01HN8Z2K7M9P4Q5R6S7T8U9V0` | | `documentStatus` | string | No | Live document state. This is persisted state, not the event outcome. `PACK_PENDING_COMPLETION` means this document is fully executed but the pack is waiting on other documents; a failed or rejected document remains `SENT`. **Possible values:** - `SENT` - `PACK_PENDING_COMPLETION` - `COMPLETED` Allowed: `SENT`, `PACK_PENDING_COMPLETION`, `COMPLETED`. | `SENT` | | `irn` | string | No | The document IRN. | `IRN-2026-001234` | | `signatureType` | string | No | The signature method the invitee was attempting when verification failed. **Possible values:** - `AADHAAR` - `VIRTUAL_SIGN` - `QUICK_SIGN` - `VISUAL_SIGN` - `DSC` - `DOC_SIGNER` - `AUTOMATED_SIGN` - `AUTOMATED_VIRTUAL_SIGN` - `AUTOMATED_VISUAL_SIGN` - `AUTOMATED_DOC_SIGN` Allowed: `AADHAAR`, `VIRTUAL_SIGN`, `QUICK_SIGN`, `VISUAL_SIGN`, `DSC`, `DOC_SIGNER`, `AUTOMATED_SIGN`, `AUTOMATED_VIRTUAL_SIGN`, `AUTOMATED_VISUAL_SIGN`, `AUTOMATED_DOC_SIGN`, `null`. | `AADHAAR` | #### invitationGroup The signer or reviewer group the invitee belongs to. | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `uuid` | string | No | The group UUID. | `f7b8c9d0-1234-4abc-8def-567890123456` | | `groupName` | string | No | The group's display name. | `Borrowers` | | `groupStatus` | string | No | Live group state. This is persisted state, not the event outcome — a failure event can carry `groupStatus: COMPLETED` (for example, when a threshold group has already met its minimum). **Possible values:** - `INACTIVE` - `ACTIVE` - `COMPLETED` Allowed: `INACTIVE`, `ACTIVE`, `COMPLETED`. | `ACTIVE` | | `type` | string | No | The group role. Reviewers can also reach verification failures, so any of the values below is possible. **Possible values:** - `SIGNER` - `REVIEWER` - `GROUP_SIGNER` - `GROUP_REVIEWER` Allowed: `SIGNER`, `REVIEWER`, `GROUP_SIGNER`, `GROUP_REVIEWER`. | `SIGNER` | #### invitee The invitee who acted or was affected. | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `uuid` | string | No | The invitee UUID. | `a1b2c3d4-5678-4abc-9def-012345678901` | | `inviteeName` | string | No | The invitee's name. | `Rajesh Kumar` | | `inviteeEmail` | string | No | The invitee's email address. | `rajesh@example.com` | | `inviteePhone` | string | No | The invitee's 10-digit mobile number. | `9820000001` | | `invitationStatus` | string | No | Live invitation state at the time the event was built. This is not fixed for this event — it is read from the invitation's persisted state, and `PENDING` is reachable, so do not assume a failure event means the invitation is closed. **Possible values:** - `PENDING` - `SIGNED` - `EXPIRED` - `REVIEWER_REJECTED` - `REVIEWER_APPROVED` - `SIGNER_REJECTED` Allowed: `PENDING`, `SIGNED`, `EXPIRED`, `REVIEWER_REJECTED`, `REVIEWER_APPROVED`, `SIGNER_REJECTED`. | `EXPIRED` | #### messages | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `errorCode` | string | No | An error code. | — | | `errorMessage` | string | No | Human-readable message text. | — | ### Sample Request ```json { "webhookType": "FAILED", "eventType": "VERIFICATION_FAILED", "rejectionReason": null, "combinationUuid": "c1d2e3f4-5678-4abc-9def-012345678903", "workflowRunContextId": "wrc_abc123", "timestamp": "30-06-2026 19:14:33", "pack": { "packId": "pack_abc123xyz", "packStatus": "SENT", "packIrn": "PIRN-2026-001234", "packUrn": "CLIENT-URN-001" }, "document": { "uuid": "d1e2f3a4-5678-4abc-9def-012345678902", "documentId": "01HN8Z2K7M9P4Q5R6S7T8U9V0", "documentStatus": "SENT", "irn": "IRN-2026-001234", "signatureType": "AADHAAR" }, "invitationGroup": { "uuid": "f7b8c9d0-1234-4abc-8def-567890123456", "groupName": "Borrowers", "groupStatus": "ACTIVE", "type": "SIGNER" }, "invitee": { "uuid": "a1b2c3d4-5678-4abc-9def-012345678901", "inviteeName": "Rajesh Kumar", "inviteeEmail": "rajesh@example.com", "inviteePhone": "9820000001", "invitationStatus": "EXPIRED" }, "messages": [ { "errorCode": "pincode.verification.failed", "errorMessage": "Pincode doesn't match with the Digital Signature Certificate. Document not signed." }, { "errorCode": "yob.verification.failed", "errorMessage": "Year of birth doesn't match with the Digital Signature Certificate. Document not signed." } ], "mac": "a3f5b9c8d2e1f0a9b8c7d6e5f4a3b2c1d0e9f8a7" } ``` --- ## Responses ### 2XX — Return any 2XX status code (200, 201, or 202) to acknowledge receipt. No specific response body is required. Any 2XX status code is accepted. --- URL: https://knowledge.leegality.com/document-execution/api/webhook-aadhaar-retry-exhausted # WEBHOOK /your-webhook-endpoint/v4/aadhaar-retry-exhausted — Aadhaar Retry Exhausted Fires when the invitee exhausts the permitted Aadhaar eSign retry attempts. Delivered to `errorWebhook`; `messages[]` is populated. **Authentication:** `X-Auth-Token` header required on every request. ## Request URL ``` WEBHOOK https://app1.leegality.com/api/your-webhook-endpoint/v4/aadhaar-retry-exhausted ``` **Environments:** - Production: `https://app1.leegality.com/api/your-webhook-endpoint/v4/aadhaar-retry-exhausted` - Sandbox: `https://sandbox.leegality.com/api/your-webhook-endpoint/v4/aadhaar-retry-exhausted` --- ## Request Body **Content-Type:** `application/json` The Webhook 4.0 envelope for the **Aadhaar Retry Exhausted** event, delivered on the failure route when the Aadhaar eSign retries are exhausted. `messages[]` carries the failure detail. Every top-level key is always present; a value that does not apply to this event is sent as JSON null (the `mac` key is absent entirely when no account salt is configured). Branch your handling on `eventType`, which is always `AADHAAR_RETRY_EXHAUSTED` here. | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `webhookType` | string | No | The delivery route the event was sent on. Always `FAILED` for this event. `FAILED` events are delivered to your `errorWebhook` endpoint. Allowed: `FAILED`. | `FAILED` | | `eventType` | string | No | What happened. Always `AADHAAR_RETRY_EXHAUSTED` for this event, which fires when the Aadhaar eSign retries are exhausted. Branch your handling on this field. Allowed: `AADHAAR_RETRY_EXHAUSTED`. | `AADHAAR_RETRY_EXHAUSTED` | | `rejectionReason` | string | No | No invitee rejection here. Not applicable for the Aadhaar Retry Exhausted event. | `null` | | `combinationUuid` | string | No | The UUID of the combination this event belongs to, as supplied on the pack-create request. Webhook 4.0 carries no separate combination object — use this identifier to correlate the event with the combination you configured. | `c1d2e3f4-5678-4abc-9def-012345678903` | | `workflowRunContextId` | string | No | The pack-run identifier returned when the pack was created. It is shared by every event fired for that pack, so you can group all events belonging to a single pack run. | `wrc_abc123` | | `timestamp` | string | No | The time the event occurred, formatted as `dd-MM-yyyy HH:mm:ss`. The string carries no timezone marker. | `30-06-2026 19:21:58` | | `pack` | object | No | The pack the event belongs to. See **pack** below. | — | | `document` | object | No | The document the event is about. A separate event is fired for each document–combination mapping the invitee acted on. See **document** below. | — | | `invitationGroup` | object | No | The signer or reviewer group the invitee belongs to. See **invitationGroup** below. | — | | `invitee` | object | No | The invitee who acted or was affected. See **invitee** below. | — | | `messages` | array\ | No | Carries the recorded messages, or a single synthesised entry whose `errorMessage` begins with the prefix `Retry attempt exhausted.` — match on the prefix or `errorCode`, not the full string. See **messages** below. | `[object Object]` | | `mac` | string | No | Hex-encoded HMAC-SHA1 of `document.documentId`, keyed by your account salt. This key is absent entirely (not null) when no salt is configured. | `a3f5b9c8d2e1f0a9b8c7d6e5f4a3b2c1d0e9f8a7` | #### pack The pack the event belongs to. | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `packId` | string | No | The pack identifier. Use it with the Check pack details endpoint to retrieve the current pack, documents and audit trail. | `pack_abc123xyz` | | `packStatus` | string | No | Live pack state at the time the event was built. This is persisted state, not the event outcome — a failure event can carry a terminal pack state such as `EXPIRED`. **Possible values:** - `SENT` - `EXPIRED` - `COMPLETED` Allowed: `SENT`, `EXPIRED`, `COMPLETED`. | `SENT` | | `packIrn` | string | No | Leegality's pack IRN, the platform-generated reference for the pack. | `PIRN-2026-001234` | | `packUrn` | string | No | The client-supplied reference for the pack. Reconcile events against your own systems on this field. | `CLIENT-URN-001` | #### document The document the event is about. A separate event is fired for each document–combination mapping the invitee acted on. | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `uuid` | string | No | The document UUID assigned at pack create. | `d1e2f3a4-5678-4abc-9def-012345678902` | | `documentId` | string | No | The document handle used by the document-fetch endpoints. `mac`, when present, is computed over this value. | `01HN8Z2K7M9P4Q5R6S7T8U9V0` | | `documentStatus` | string | No | Live document state. This is persisted state, not the event outcome. `PACK_PENDING_COMPLETION` means this document is fully executed but the pack is waiting on other documents; a failed or rejected document remains `SENT`. **Possible values:** - `SENT` - `PACK_PENDING_COMPLETION` - `COMPLETED` Allowed: `SENT`, `PACK_PENDING_COMPLETION`, `COMPLETED`. | `SENT` | | `irn` | string | No | The document IRN. | `IRN-2026-001234` | | `signatureType` | string | No | The Aadhaar eSign method attempted. Always `AADHAAR` for this event. Allowed: `AADHAAR`. | `AADHAAR` | #### invitationGroup The signer or reviewer group the invitee belongs to. | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `uuid` | string | No | The group UUID. | `f7b8c9d0-1234-4abc-8def-567890123456` | | `groupName` | string | No | The group's display name. | `Borrowers` | | `groupStatus` | string | No | Live group state. This is persisted state, not the event outcome — a failure event can carry `groupStatus: COMPLETED` (for example, when a threshold group has already met its minimum). **Possible values:** - `INACTIVE` - `ACTIVE` - `COMPLETED` Allowed: `INACTIVE`, `ACTIVE`, `COMPLETED`. | `ACTIVE` | | `type` | string | No | The group role. `GROUP_SIGNER` and `GROUP_REVIEWER` indicate a threshold group. **Possible values:** - `SIGNER` - `REVIEWER` - `GROUP_SIGNER` - `GROUP_REVIEWER` Allowed: `SIGNER`, `REVIEWER`, `GROUP_SIGNER`, `GROUP_REVIEWER`. | `SIGNER` | #### invitee The invitee who acted or was affected. | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `uuid` | string | No | The invitee UUID. | `a1b2c3d4-5678-4abc-9def-012345678901` | | `inviteeName` | string | No | The invitee's name. | `Rajesh Kumar` | | `inviteeEmail` | string | No | The invitee's email address. | `rajesh@example.com` | | `inviteePhone` | string | No | The invitee's 10-digit mobile number. | `9820000001` | | `invitationStatus` | string | No | Live invitation state at the time the event was built. This is not fixed for this event — it is read from the invitation's persisted state, and `PENDING` is reachable, so do not assume a failure event means the invitation is closed. **Possible values:** - `PENDING` - `SIGNED` - `EXPIRED` - `REVIEWER_REJECTED` - `REVIEWER_APPROVED` - `SIGNER_REJECTED` Allowed: `PENDING`, `SIGNED`, `EXPIRED`, `REVIEWER_REJECTED`, `REVIEWER_APPROVED`, `SIGNER_REJECTED`. | `EXPIRED` | #### messages | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `errorCode` | string | No | An error code. | — | | `errorMessage` | string | No | Human-readable message text. | — | ### Sample Request ```json { "webhookType": "FAILED", "eventType": "AADHAAR_RETRY_EXHAUSTED", "rejectionReason": null, "combinationUuid": "c1d2e3f4-5678-4abc-9def-012345678903", "workflowRunContextId": "wrc_abc123", "timestamp": "30-06-2026 19:21:58", "pack": { "packId": "pack_abc123xyz", "packStatus": "SENT", "packIrn": "PIRN-2026-001234", "packUrn": "CLIENT-URN-001" }, "document": { "uuid": "d1e2f3a4-5678-4abc-9def-012345678902", "documentId": "01HN8Z2K7M9P4Q5R6S7T8U9V0", "documentStatus": "SENT", "irn": "IRN-2026-001234", "signatureType": "AADHAAR" }, "invitationGroup": { "uuid": "f7b8c9d0-1234-4abc-8def-567890123456", "groupName": "Borrowers", "groupStatus": "ACTIVE", "type": "SIGNER" }, "invitee": { "uuid": "a1b2c3d4-5678-4abc-9def-012345678901", "inviteeName": "Rajesh Kumar", "inviteeEmail": "rajesh@example.com", "inviteePhone": "9820000001", "invitationStatus": "EXPIRED" }, "messages": [ { "errorCode": "AADHAAR_RETRY_EXHAUSTED", "errorMessage": "Retry attempt exhausted." } ], "mac": "a3f5b9c8d2e1f0a9b8c7d6e5f4a3b2c1d0e9f8a7" } ``` --- ## Responses ### 2XX — Return any 2XX status code (200, 201, or 202) to acknowledge receipt. No specific response body is required. Any 2XX status code is accepted. --- URL: https://knowledge.leegality.com/document-execution/api/webhook-invitation-timeout # WEBHOOK /your-webhook-endpoint/v4/invitation-timeout — Invitation Timeout Fires when an invitation expires with no failure recorded against it. Delivered to `errorWebhook`. **Authentication:** `X-Auth-Token` header required on every request. ## Request URL ``` WEBHOOK https://app1.leegality.com/api/your-webhook-endpoint/v4/invitation-timeout ``` **Environments:** - Production: `https://app1.leegality.com/api/your-webhook-endpoint/v4/invitation-timeout` - Sandbox: `https://sandbox.leegality.com/api/your-webhook-endpoint/v4/invitation-timeout` --- ## Request Body **Content-Type:** `application/json` The Webhook 4.0 envelope for the **Invitation Timeout** event, delivered on the failure route when an invitation expired with no failure recorded. Every top-level key is always present; a value that does not apply to this event is sent as JSON null (the `mac` key is absent entirely when no account salt is configured). Branch your handling on `eventType`, which is always `INVITATION_TIMEOUT` here. | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `webhookType` | string | No | The delivery route the event was sent on. Always `FAILED` for this event. `FAILED` events are delivered to your `errorWebhook` endpoint. Allowed: `FAILED`. | `FAILED` | | `eventType` | string | No | What happened. Always `INVITATION_TIMEOUT` for this event, which fires when an invitation expired with no failure recorded. Branch your handling on this field. Allowed: `INVITATION_TIMEOUT`. | `INVITATION_TIMEOUT` | | `rejectionReason` | string | No | No invitee rejection on timeout. Not applicable for the Invitation Timeout event. | `null` | | `combinationUuid` | string | No | The UUID of the combination this event belongs to, as supplied on the pack-create request. Webhook 4.0 carries no separate combination object — use this identifier to correlate the event with the combination you configured. | `c1d2e3f4-5678-4abc-9def-012345678903` | | `workflowRunContextId` | string | No | The pack-run identifier returned when the pack was created. It is shared by every event fired for that pack, so you can group all events belonging to a single pack run. | `wrc_abc123` | | `timestamp` | string | No | The time the event occurred, formatted as `dd-MM-yyyy HH:mm:ss`. The string carries no timezone marker. | `07-07-2026 00:00:11` | | `pack` | object | No | The pack the event belongs to. See **pack** below. | — | | `document` | object | No | The document the event is about. A separate event is fired for each document–combination mapping the invitee acted on. See **document** below. | — | | `invitationGroup` | object | No | The signer or reviewer group the invitee belongs to. See **invitationGroup** below. | — | | `invitee` | object | No | The invitee who acted or was affected. See **invitee** below. | — | | `messages` | array\ | No | No error messages on timeout. Not applicable for the Invitation Timeout event. See **messages** below. | `` | | `mac` | string | No | Hex-encoded HMAC-SHA1 of `document.documentId`, keyed by your account salt. This key is absent entirely (not null) when no salt is configured. | `a3f5b9c8d2e1f0a9b8c7d6e5f4a3b2c1d0e9f8a7` | #### pack The pack the event belongs to. | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `packId` | string | No | The pack identifier. Use it with the Check pack details endpoint to retrieve the current pack, documents and audit trail. | `pack_abc123xyz` | | `packStatus` | string | No | Live pack state at the time the event was built. This is persisted state, not the event outcome — a failure event can carry a terminal pack state such as `EXPIRED`. **Possible values:** - `SENT` - `EXPIRED` - `COMPLETED` Allowed: `SENT`, `EXPIRED`, `COMPLETED`. | `EXPIRED` | | `packIrn` | string | No | Leegality's pack IRN, the platform-generated reference for the pack. | `PIRN-2026-001234` | | `packUrn` | string | No | The client-supplied reference for the pack. Reconcile events against your own systems on this field. | `CLIENT-URN-001` | #### document The document the event is about. A separate event is fired for each document–combination mapping the invitee acted on. | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `uuid` | string | No | The document UUID assigned at pack create. | `d1e2f3a4-5678-4abc-9def-012345678902` | | `documentId` | string | No | The document handle used by the document-fetch endpoints. `mac`, when present, is computed over this value. | `01HN8Z2K7M9P4Q5R6S7T8U9V0` | | `documentStatus` | string | No | Live document state. This is persisted state, not the event outcome. `PACK_PENDING_COMPLETION` means this document is fully executed but the pack is waiting on other documents; a failed or rejected document remains `SENT`. **Possible values:** - `SENT` - `PACK_PENDING_COMPLETION` - `COMPLETED` Allowed: `SENT`, `PACK_PENDING_COMPLETION`, `COMPLETED`. | `SENT` | | `irn` | string | No | The document IRN. | `IRN-2026-001234` | | `signatureType` | string | No | The signature method the invitee had chosen before the invitation expired. This is non-null only if a method was already chosen; otherwise it is `null`. **Possible values:** - `AADHAAR` - `VIRTUAL_SIGN` - `QUICK_SIGN` - `VISUAL_SIGN` - `DSC` - `DOC_SIGNER` - `AUTOMATED_SIGN` - `AUTOMATED_VIRTUAL_SIGN` - `AUTOMATED_VISUAL_SIGN` - `AUTOMATED_DOC_SIGN` Allowed: `AADHAAR`, `VIRTUAL_SIGN`, `QUICK_SIGN`, `VISUAL_SIGN`, `DSC`, `DOC_SIGNER`, `AUTOMATED_SIGN`, `AUTOMATED_VIRTUAL_SIGN`, `AUTOMATED_VISUAL_SIGN`, `AUTOMATED_DOC_SIGN`, `null`. | `VIRTUAL_SIGN` | #### invitationGroup The signer or reviewer group the invitee belongs to. | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `uuid` | string | No | The group UUID. | `f7b8c9d0-1234-4abc-8def-567890123456` | | `groupName` | string | No | The group's display name. | `Borrowers` | | `groupStatus` | string | No | Live group state. This is persisted state, not the event outcome — a failure event can carry `groupStatus: COMPLETED` (for example, when a threshold group has already met its minimum). **Possible values:** - `INACTIVE` - `ACTIVE` - `COMPLETED` Allowed: `INACTIVE`, `ACTIVE`, `COMPLETED`. | `ACTIVE` | | `type` | string | No | The group role. `GROUP_SIGNER` and `GROUP_REVIEWER` indicate a threshold group. **Possible values:** - `SIGNER` - `REVIEWER` - `GROUP_SIGNER` - `GROUP_REVIEWER` Allowed: `SIGNER`, `REVIEWER`, `GROUP_SIGNER`, `GROUP_REVIEWER`. | `SIGNER` | #### invitee The invitee who acted or was affected. | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `uuid` | string | No | The invitee UUID. | `a1b2c3d4-5678-4abc-9def-012345678901` | | `inviteeName` | string | No | The invitee's name. | `Rajesh Kumar` | | `inviteeEmail` | string | No | The invitee's email address. | `rajesh@example.com` | | `inviteePhone` | string | No | The invitee's 10-digit mobile number. | `9820000001` | | `invitationStatus` | string | No | Live invitation state. Always `EXPIRED` for the Invitation Timeout event. Allowed: `EXPIRED`. | `EXPIRED` | #### messages | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `errorCode` | string | No | An error code. | — | | `errorMessage` | string | No | Human-readable message text. | — | ### Sample Request ```json { "webhookType": "FAILED", "eventType": "INVITATION_TIMEOUT", "rejectionReason": null, "combinationUuid": "c1d2e3f4-5678-4abc-9def-012345678903", "workflowRunContextId": "wrc_abc123", "timestamp": "07-07-2026 00:00:11", "pack": { "packId": "pack_abc123xyz", "packStatus": "EXPIRED", "packIrn": "PIRN-2026-001234", "packUrn": "CLIENT-URN-001" }, "document": { "uuid": "d1e2f3a4-5678-4abc-9def-012345678902", "documentId": "01HN8Z2K7M9P4Q5R6S7T8U9V0", "documentStatus": "SENT", "irn": "IRN-2026-001234", "signatureType": "VIRTUAL_SIGN" }, "invitationGroup": { "uuid": "f7b8c9d0-1234-4abc-8def-567890123456", "groupName": "Borrowers", "groupStatus": "ACTIVE", "type": "SIGNER" }, "invitee": { "uuid": "a1b2c3d4-5678-4abc-9def-012345678901", "inviteeName": "Rajesh Kumar", "inviteeEmail": "rajesh@example.com", "inviteePhone": "9820000001", "invitationStatus": "EXPIRED" }, "messages": [], "mac": "a3f5b9c8d2e1f0a9b8c7d6e5f4a3b2c1d0e9f8a7" } ``` --- ## Responses ### 2XX — Return any 2XX status code (200, 201, or 202) to acknowledge receipt. No specific response body is required. Any 2XX status code is accepted. --- URL: https://knowledge.leegality.com/document-execution/api/list-stamp-series # GET /v3.1/series/list — List stamp series Returns details of all stamp paper series in your account. **Authentication:** `X-Auth-Token` header required on every request. ## Request URL ``` GET https://app1.leegality.com/api/v3.1/series/list?firstPartyName={firstPartyName}&secondPartyName={secondPartyName}&purpose={purpose}&legend={legend}&underProcess={underProcess}&blocked={blocked}&reserved={reserved}&unused={unused}&used={used}&expired={expired}&total={total} ``` **Environments:** - Production: `https://app1.leegality.com/api/v3.1/series/list` - Sandbox: `https://sandbox.leegality.com/api/v3.1/series/list` --- ## Parameters | Name | In | Required | Type | Description | Example | |------|----|----------|------|-------------|---------| | `firstPartyName` | query | No | boolean | Include the first party name in each series item. **Default:** `false` — field is omitted from response when not requested. | — | | `secondPartyName` | query | No | boolean | Include the second party name in each series item. **Default:** `false` — field is omitted from response when not requested. | — | | `purpose` | query | No | boolean | Include the purpose/use case configured for each series. **Default:** `false` — field is omitted from response when not requested. | — | | `legend` | query | No | boolean | Include the legend text configured for each series. The legend is the descriptive text printed on the stamp paper. **Default:** `false` — field is omitted from response when not requested. | — | | `underProcess` | query | No | boolean | Include the count of stamps currently under process in each series. **Default:** `false` — field is omitted from response when not requested. | — | | `blocked` | query | No | boolean | Include the count of blocked stamps in each series. **Default:** `false` — field is omitted from response when not requested. | — | | `reserved` | query | No | boolean | Include the count of reserved stamps in each series. **Default:** `false` — field is omitted from response when not requested. | — | | `unused` | query | No | boolean | Include the count of unused (available) stamps in each series. **Default:** `false` — field is omitted from response when not requested. | — | | `used` | query | No | boolean | Include the count of used stamps in each series. **Default:** `false` — field is omitted from response when not requested. | — | | `expired` | query | No | boolean | Include the count of expired stamps in each series. **Default:** `false` — field is omitted from response when not requested. | — | | `total` | query | No | boolean | Include the total stamp count in each series. **Note:** `total` = `unused` + `underProcess` + `blocked` + `used` + `expired` + `reserved`. **Default:** `false` — field is omitted from response when not requested. | — | --- ## Responses ### 200 — Stamp series list retrieved successfully. Response wrapper for the List Stamp Series API. On success (`status: 1`), `data.seriesList` contains the array of stamp series. The `messages` array is empty on success. | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `status` | integer | No | API response status. `1` = success, `0` = failure. Allowed: `0`, `1`. | `1` | | `messages` | array\ | No | Array of response messages. Empty array `[]` on success. See **Message** below. | — | | `data` | StampSeriesListData | No | Contains the list of stamp series in the account. See **StampSeriesListData** below. | — | #### Message Message object containing a machine-readable code and a human-readable description. Used for success confirmations, errors, and warnings. | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `code` | string | No | Response message code. | `simpleWorkFlow.success` | | `message` | string | No | Human-readable success or error message. | `Invitations sent successfully.` | #### StampSeriesListData Contains the list of stamp series in the account. | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `seriesList` | array\ | No | Array of stamp series objects. Each object represents one stamp paper series configured in the account. See **StampSeriesItem** below. | — | ##### StampSeriesItem Details of a single stamp paper series. The `seriesNumber`, `state`, and `denomination` fields are always present. All other fields are only included when their corresponding query parameter is set to `true`. | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `seriesNumber` | string | No | Unique series number identifying this stamp series. **Format:** Numeric string, typically zero-padded (e.g., `"01"`, `"07"`). This is the same value used in the `stampSeries` field of the Create eSigning request API. | `07` | | `state` | string | No | Indian state for which the stamp paper is issued. **Examples:** `"Maharashtra"`, `"Delhi"`, `"Tamil Nadu"`, `"All States Revenue Stamp"`. | `Delhi` | | `denomination` | number | No | Stamp paper denomination (face value) in Indian Rupees. **Format:** Decimal number (e.g., `100.0`, `53.0`, `10.0`). | `53` | | `firstPartyName` | string | No | Name of the first party configured for this series. Only present when `firstPartyName=true` is passed. | `ABCD Limited` | | `secondPartyName` | string | No | Name of the second party configured for this series. Only present when `secondPartyName=true` is passed. | `Second party name` | | `purpose` | string | No | Purpose or use case configured for this series. Only present when `purpose=true` is passed. | `General agreement (as per use case)` | | `legend` | string | No | Legend text printed on the stamp paper. This is the descriptive text that appears on the physical stamp paper. Only present when `legend=true` is passed. | `This Stamp Paper forms an integral part of the agreement bea` | | `underProcess` | integer | No | Number of stamps currently under process in this series. Only present when `underProcess=true` is passed. | `0` | | `blocked` | integer | No | Number of blocked stamps in this series. Only present when `blocked=true` is passed. | `3` | | `reserved` | integer | No | Number of reserved stamps in this series. Only present when `reserved=true` is passed. | `0` | | `unused` | integer | No | Number of unused (available) stamps in this series. Only present when `unused=true` is passed. | `258` | | `used` | integer | No | Number of used stamps in this series. Only present when `used=true` is passed. | `142` | | `expired` | integer | No | Number of expired stamps in this series. Only present when `expired=true` is passed. | `0` | | `total` | integer | No | Total number of stamps in this series (across all statuses). **Formula:** `total` = `unused` + `underProcess` + `blocked` + `used` + `expired` + `reserved`. Only present when `total=true` is passed. | `400` | ### Sample Response (200) ```json { "status": 1, "messages": [ { "code": "simpleWorkFlow.success", "message": "Invitations sent successfully." } ], "data": { "seriesList": [ { "seriesNumber": "07", "state": "Delhi", "denomination": 53, "firstPartyName": "ABCD Limited", "secondPartyName": "Second party name", "purpose": "General agreement (as per use case)", "legend": "This Stamp Paper forms an integral part of the agreement bearing unique ID No. (Doc. ID.,) , executed between tees and the Borrower.", "underProcess": 0, "blocked": 3, "reserved": 0, "unused": 258, "used": 142, "expired": 0, "total": 400 } ] } } ``` --- URL: https://knowledge.leegality.com/document-execution/api/list-expiring-stamps # GET /v3.1/series/expiry — List expiring stamp series Returns stamp series that are expiring soon or have already expired. **Authentication:** `X-Auth-Token` header required on every request. ## Request URL ``` GET https://app1.leegality.com/api/v3.1/series/expiry?lookUpPeriod={lookUpPeriod}&includeExpired={includeExpired} ``` **Environments:** - Production: `https://app1.leegality.com/api/v3.1/series/expiry` - Sandbox: `https://sandbox.leegality.com/api/v3.1/series/expiry` --- ## Parameters | Name | In | Required | Type | Description | Example | |------|----|----------|------|-------------|---------| | `lookUpPeriod` | query | No | integer | Number of days to look ahead for expiring stamps. Only stamps with an expiry date within this many days from today are returned. For example, `lookUpPeriod=30` returns stamps expiring in the next 30 days. **Default:** `30` **Note:** Negative values return 0 results without error. Non-numeric values return a `typeMismatch` error. | — | | `includeExpired` | query | No | boolean | Whether to include already-expired stamp series in the results. When `true`, **all** expired stamps are included regardless of the `lookUpPeriod` value. The expired entries appear alongside the future-expiring entries, sorted by expiry date. **Default:** `false` **Accepted truthy values:** `true`, `TRUE`, `1`. | — | --- ## Responses ### 200 — Expiring stamp series retrieved successfully. Response wrapper for the List Expiring Stamp Series API. On success (`status: 1`), `data.seriesList` contains the array of expiring stamp series. The `messages` array is empty on success. | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `status` | integer | No | API response status. `1` = success, `0` = failure. Allowed: `0`, `1`. | `1` | | `messages` | array\ | No | Array of response messages. Empty array `[]` on success. See **Message** below. | — | | `data` | StampSeriesExpiryData | No | Contains the list of expiring stamp series. See **StampSeriesExpiryData** below. | — | #### Message Message object containing a machine-readable code and a human-readable description. Used for success confirmations, errors, and warnings. | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `code` | string | No | Response message code. | `simpleWorkFlow.success` | | `message` | string | No | Human-readable success or error message. | `Invitations sent successfully.` | #### StampSeriesExpiryData Contains the list of expiring stamp series. | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `seriesList` | array\ | No | Array of stamp series expiry entries. Each entry represents a unique combination of series number, purchase date, and expiry date. The same series number can appear multiple times if stamps were purchased in separate batches with different expiry dates. Sorted in ascending order by expiry date (earliest expiry first). See **StampSeriesExpiryItem** below. | — | ##### StampSeriesExpiryItem Details of a single stamp series expiry entry. Each entry represents one batch of stamps with a specific purchase and expiry date. The same series number can appear multiple times with different dates. | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `expiryDate` | string | No | Expiry date and time of the stamp batch. **Format:** `DD-MM-YYYY HH:MM:SS` (e.g., `"31-12-2025 23:59:59"`). The time component is always `23:59:59` (end of day). | `31-12-2025 23:59:59` | | `purchaseDate` | string | No | Purchase date and time of the stamp batch. **Format:** `DD-MM-YYYY HH:MM:SS` (e.g., `"15-01-2025 12:30:45"`). Contains the actual timestamp of when the stamps were purchased. | `15-01-2025 12:30:45` | | `quantity` | integer | No | Number of stamps in this batch. | `50` | | `seriesNumber` | string | No | Series number identifying the stamp series. **Format:** Numeric string, typically zero-padded (e.g., `"01"`, `"07"`). This is the same value used in the `stampSeries` field of the Create eSigning request API and in the List Stamp Series API. | `07` | ### Sample Response (200) ```json { "status": 1, "messages": [ { "code": "simpleWorkFlow.success", "message": "Invitations sent successfully." } ], "data": { "seriesList": [ { "expiryDate": "31-12-2025 23:59:59", "purchaseDate": "15-01-2025 12:30:45", "quantity": 50, "seriesNumber": "07" } ] } } ``` --- URL: https://knowledge.leegality.com/document-execution/api/list-stamp-groups # GET /v3.0/series/groups/list — List stamp groups Returns details of all stamp groups in your account. **Authentication:** `X-Auth-Token` header required on every request. ## Request URL ``` GET https://app1.leegality.com/api/v3.0/series/groups/list ``` **Environments:** - Production: `https://app1.leegality.com/api/v3.0/series/groups/list` - Sandbox: `https://sandbox.leegality.com/api/v3.0/series/groups/list` --- ## Responses ### 200 — Stamp groups retrieved successfully. Response wrapper for the List Stamp Groups API. On success (`status: 1`), `data.seriesGroups` contains the array of stamp groups. The `messages` array is empty on success. | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `status` | integer | No | API response status. `1` = success, `0` = failure. Allowed: `0`, `1`. | `1` | | `messages` | array\ | No | Array of response messages. Empty array `[]` on success. See **Message** below. | — | | `data` | StampGroupListData | No | Contains the list of stamp groups in the account. See **StampGroupListData** below. | — | #### Message Message object containing a machine-readable code and a human-readable description. Used for success confirmations, errors, and warnings. | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `code` | string | No | Response message code. | `simpleWorkFlow.success` | | `message` | string | No | Human-readable success or error message. | `Invitations sent successfully.` | #### StampGroupListData Contains the list of stamp groups in the account. | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `seriesGroups` | array\ | No | Array of stamp group objects. Each object represents one stamp group configured in the account. See **StampGroupItem** below. | — | ##### StampGroupItem Details of a single stamp group. A stamp group bundles one or more stamp series under a common identifier, state, and maximum value limit. | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `groupName` | string | No | Display name of the stamp group. | `DL` | | `groupNumber` | string | No | Unique identifier for the stamp group. **Format:** State abbreviation followed by a number (e.g., `"MH01"`, `"DL02"`). | `DL01` | | `maximumValuePermitted` | string | No | Maximum stamp value allowed for this group, in Indian Rupees. **Format:** Numeric string (e.g., `"10000"`, `"1500"`). | `10000` | | `series` | array\ | No | Stamp series belonging to this group. See **StampGroupSeriesItem** below. | — | | `state` | string | No | Indian state associated with this stamp group. **Examples:** `"Maharashtra"`, `"Delhi"`. | `Delhi` | ###### StampGroupSeriesItem A stamp series within a stamp group. | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `denomination` | string | No | Stamp paper denomination (face value) in Indian Rupees. **Format:** Decimal string (e.g., `"100.0"`, `"53.0"`). | `100.0` | | `seriesNumber` | string | No | Series number identifying the stamp series. **Format:** Numeric string, typically zero-padded (e.g., `"01"`, `"07"`). This matches the `seriesNumber` from the List Stamp Series API. | `03` | ### Sample Response (200) ```json { "status": 1, "messages": [ { "code": "simpleWorkFlow.success", "message": "Invitations sent successfully." } ], "data": { "seriesGroups": [ { "groupName": "DL", "groupNumber": "DL01", "maximumValuePermitted": "10000", "series": [ { "denomination": "100.0", "seriesNumber": "03" } ], "state": "Delhi" } ] } } ``` --- URL: https://knowledge.leegality.com/document-execution/api/get-wallet-balance # GET /v3.0/wallet/balance/details — Get wallet balance Returns the eSign wallet balance for your account. **Authentication:** `X-Auth-Token` header required on every request. ## Request URL ``` GET https://app1.leegality.com/api/v3.0/wallet/balance/details ``` **Environments:** - Production: `https://app1.leegality.com/api/v3.0/wallet/balance/details` - Sandbox: `https://sandbox.leegality.com/api/v3.0/wallet/balance/details` --- ## Responses ### 200 — Wallet balance retrieved successfully. Response wrapper for the Get Wallet Balance API. On success (`status: 1`), `data` contains the wallet balance breakdown. The `messages` array is empty on success. | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `status` | integer | No | API response status. `1` = success, `0` = failure. Allowed: `0`, `1`. | `1` | | `messages` | array\ | No | Array of response messages. Empty array `[]` on success. See **Message** below. | — | | `data` | WalletBalanceData | No | eSign wallet balance breakdown. **Balance math:** `total` = `expired` + `consumed` + `unused` + `reserved`. See **WalletBalanceData** below. | — | #### Message Message object containing a machine-readable code and a human-readable description. Used for success confirmations, errors, and warnings. | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `code` | string | No | Response message code. | `simpleWorkFlow.success` | | `message` | string | No | Human-readable success or error message. | `Invitations sent successfully.` | #### WalletBalanceData eSign wallet balance breakdown. **Balance math:** `total` = `expired` + `consumed` + `unused` + `reserved`. | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `expired` | number | No | Number of eSign credits that have expired. | `0` | | `reserved` | number | No | Number of eSign credits currently reserved for in-progress documents. | `651` | | `unused` | number | No | Number of eSign credits available for use. | `13194` | | `consumed` | number | No | Number of eSign credits that have been consumed. | `4190` | | `total` | number | No | Total number of eSign credits in the account. **Formula:** `total` = `expired` + `consumed` + `unused` + `reserved`. | `18035` | ### Sample Response (200) ```json { "status": 1, "messages": [ { "code": "simpleWorkFlow.success", "message": "Invitations sent successfully." } ], "data": { "expired": 0, "reserved": 651, "unused": 13194, "consumed": 4190, "total": 18035 } } ``` --- URL: https://knowledge.leegality.com/document-execution/api/list-wallet-purchases # GET /v3.0/wallet/balance/list — List eSign purchases Returns consumption and expiry details of eSign purchases made from your account. **Authentication:** `X-Auth-Token` header required on every request. ## Request URL ``` GET https://app1.leegality.com/api/v3.0/wallet/balance/list?completed={completed}&max={max}&offset={offset} ``` **Environments:** - Production: `https://app1.leegality.com/api/v3.0/wallet/balance/list` - Sandbox: `https://sandbox.leegality.com/api/v3.0/wallet/balance/list` --- ## Parameters | Name | In | Required | Type | Description | Example | |------|----|----------|------|-------------|---------| | `completed` | query | No | boolean | Filter by purchase consumption status. When `true`, returns only purchases that are fully consumed (no remaining credits). When `false` or omitted, returns purchases that still have eSign credits remaining. **Default:** `false` | — | | `max` | query | No | integer | Maximum number of records to return. **Default:** `20` **Maximum:** `40` | — | | `offset` | query | No | integer | Number of records to skip before returning results. Use with `max` for pagination. **Default:** `0` | — | --- ## Responses ### 200 — eSign purchase list retrieved successfully. Response wrapper for the List eSign Purchases API. On success (`status: 1`), `data.balances` contains the array of purchase entries. The `messages` array is empty on success. | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `status` | integer | No | API response status. `1` = success, `0` = failure. Allowed: `0`, `1`. | `1` | | `messages` | array\ | No | Array of response messages. Empty array `[]` on success. See **Message** below. | — | | `data` | WalletPurchaseListData | No | Contains the list of eSign purchase entries. See **WalletPurchaseListData** below. | — | #### Message Message object containing a machine-readable code and a human-readable description. Used for success confirmations, errors, and warnings. | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `code` | string | No | Response message code. | `simpleWorkFlow.success` | | `message` | string | No | Human-readable success or error message. | `Invitations sent successfully.` | #### WalletPurchaseListData Contains the list of eSign purchase entries. | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `balances` | array\ | No | Array of eSign purchase entries, sorted by purchase date (oldest first). See **WalletPurchaseItem** below. | — | ##### WalletPurchaseItem Details of a single eSign purchase. **Purchase math:** `purchaseQuantity` = `consumed` + `unused` + `expired`. | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `consumed` | number | No | Number of eSign credits consumed from this purchase. | `420` | | `expired` | number | No | Number of eSign credits that have expired from this purchase. | `0` | | `expiryDate` | string | No | Expiry date and time of this purchase. **Format:** `DD-MM-YYYY HH:MM:SS`. | `29-05-2025 16:02:12` | | `purchaseDate` | string | No | Date and time when this purchase was made. **Format:** `DD-MM-YYYY HH:MM:SS`. | `29-05-2024 16:02:12` | | `purchaseQuantity` | number | No | Total number of eSign credits in this purchase. **Formula:** `purchaseQuantity` = `consumed` + `unused` + `expired`. | `435` | | `unused` | number | No | Number of eSign credits still available from this purchase. | `15` | ### Sample Response (200) ```json { "status": 1, "messages": [ { "code": "simpleWorkFlow.success", "message": "Invitations sent successfully." } ], "data": { "balances": [ { "consumed": 420, "expired": 0, "expiryDate": "29-05-2025 16:02:12", "purchaseDate": "29-05-2024 16:02:12", "purchaseQuantity": 435, "unused": 15 } ] } } ``` --- URL: https://knowledge.leegality.com/document-execution/api/retry-nesl-transaction # POST /v3.3/nesl/neslRetryRequest — Retry NeSL transaction Retries a failed NeSL transaction. **Authentication:** `X-Auth-Token` header required on every request. ## Request URL ``` POST https://app1.leegality.com/api/v3.3/nesl/neslRetryRequest ``` **Environments:** - Production: `https://app1.leegality.com/api/v3.3/nesl/neslRetryRequest` - Sandbox: `https://sandbox.leegality.com/api/v3.3/nesl/neslRetryRequest` --- ## Request Body **Content-Type:** `application/json` Request body for retrying a NeSL transaction. At least one of `documentId` or `neslTransactionId` must be provided. | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `documentId` | string | No | Unique Document ID generated by Leegality for every document in response to a successful create request. | `01KJ7APCJHJZGNRPXWX88MMCRG` | | `neslTransactionId` | string | No | Unique Transaction ID generated by Leegality for every NeSL document. | `kKoJTQ20Pu` | ### Sample Request ```json { "documentId": "01KJ7APCJHJZGNRPXWX88MMCRG", "neslTransactionId": "kKoJTQ20Pu" } ``` --- ## Responses ### 200 — NeSL retry response. Response wrapper for the Retry NeSL Transaction API. On a successful retry, `data.retryStatus` is `"SUCCESS"`. On failure, `data` contains the NeSL error details. When input validation fails (missing IDs, document not found), `data` is empty and errors appear in `messages`. | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `status` | integer | No | API response status. `1` = success, `0` = failure. Allowed: `0`, `1`. | `0` | | `messages` | array\ | No | Array of response messages. Empty array `[]` when the retry request reaches NeSL (regardless of retry outcome). See **Message** below. | — | | `data` | NeslRetryData | No | NeSL retry result details. This object is empty when input validation fails (missing IDs, document not found). See **NeslRetryData** below. | — | #### Message Message object containing a machine-readable code and a human-readable description. Used for success confirmations, errors, and warnings. | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `code` | string | No | Response message code. | `simpleWorkFlow.success` | | `message` | string | No | Human-readable success or error message. | `Invitations sent successfully.` | #### NeslRetryData NeSL retry result details. This object is empty when input validation fails (missing IDs, document not found). | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `canRetry` | boolean | No | Whether the transaction can be retried. `true` — retry is allowed, you can call this API again for failed transactions. `false` — retry is not allowed (e.g., due to validation errors that must be fixed first). | `false` | | `responseCode` | string | No | Response code returned by NeSL. **Example:** `"ER00J44"` (Invalid First Party Name). | `ER00J44` | | `responseDescription` | string | No | Human-readable description of the NeSL response code. | `Invalid First Party Name` | | `retryStatus` | string | No | Outcome of the retry attempt. Allowed: `SUCCESS`, `FAILED`. | `FAILED` | ### Sample Response (200) ```json { "status": 0, "messages": [ { "code": "simpleWorkFlow.success", "message": "Invitations sent successfully." } ], "data": { "canRetry": false, "responseCode": "ER00J44", "responseDescription": "Invalid First Party Name", "retryStatus": "FAILED" } } ``` --- URL: https://knowledge.leegality.com/document-execution/api/list-nesl-notifications # GET /v3.3/nesl/notification/list — List eBG notifications Returns a list of NeSL eBG (Electronic Bank Guarantee) event notifications. **Authentication:** `X-Auth-Token` header required on every request. ## Request URL ``` GET https://app1.leegality.com/api/v3.3/nesl/notification/list?q={q}&status={status}&requestType={requestType}&sentToMe={sentToMe}&max={max}&offset={offset} ``` **Environments:** - Production: `https://app1.leegality.com/api/v3.3/nesl/notification/list` - Sandbox: `https://sandbox.leegality.com/api/v3.3/nesl/notification/list` --- ## Parameters | Name | In | Required | Type | Description | Example | |------|----|----------|------|-------------|---------| | `q` | query | No | string | Search by loan number. Returns all eBG notifications associated with the specified loan number. | — | | `status` | query | No | string | Filter notifications by review status. **Possible values:** `ACCEPTED`, `REJECTED`, `PENDING`. | — | | `requestType` | query | No | string | Filter notifications by eBG event type. **Possible values:** `AMENDMENT`, `RENEWAL`, `EXTEND_OR_PAY`, `CANCELLATION`, `CLOSURE`, `PARTIAL_INVOCATION`, `INVOCATION`. | — | | `sentToMe` | query | No | boolean | Filter by notification recipient. When `true`, returns only notifications sent to the current API user. When `false`, returns all notifications received by any user in the organization. **Default:** `false` | — | | `max` | query | No | integer | Maximum number of results to return. | — | | `offset` | query | No | integer | Number of records to skip before returning results. Use with `max` for pagination. | — | --- ## Responses ### 200 — eBG notifications retrieved successfully. Response wrapper for the List eBG Notifications API. On success (`status: 1`), `data` contains the notification list and total count. | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `status` | integer | No | API response status. `1` = success, `0` = failure. Allowed: `0`, `1`. | `1` | | `messages` | array\ | No | Array of response messages. Empty array `[]` on success. See **Message** below. | — | | `data` | NeslNotificationListData | No | Contains the list of eBG notifications and the total count. See **NeslNotificationListData** below. | — | #### Message Message object containing a machine-readable code and a human-readable description. Used for success confirmations, errors, and warnings. | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `code` | string | No | Response message code. | `simpleWorkFlow.success` | | `message` | string | No | Human-readable success or error message. | `Invitations sent successfully.` | #### NeslNotificationListData Contains the list of eBG notifications and the total count. | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `notificationList` | array\ | No | Array of eBG notification objects. See **NeslNotificationItem** below. | — | | `totalCount` | integer | No | Total number of notification records matching the query. Use with `max` and `offset` for pagination. | `5` | ##### NeslNotificationItem Details of a single NeSL eBG event notification. | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `eventType` | string | No | Type of the eBG event. **Possible values:** `Amendment`, `Renewal`, `Extend_or_pay`, `Cancellation`, `Closure`, `Partial_invocation`, `Invocation`. | `Invocation` | | `lastUpdated` | string | No | Timestamp of the most recent update to the notification. **Format:** ISO 8601 (e.g., `"2025-08-24T14:15:22Z"`). | `2025-08-24T14:15:22Z` | | `loanNo` | string | No | Loan number associated with the eBG notification. | `LOAN001` | | `notifTxnId` | string | No | Unique notification transaction ID. | `NTX12345` | | `requestId` | string | No | Request ID associated with the eBG notification. | `REQ001` | | `reviewedBy` | string | No | Name of the user who reviewed the notification. Empty or null if not yet reviewed. | `John Doe` | | `status` | string | No | Review status of the notification. **Possible values:** `Accepted`, `Rejected`, `Pending`. | `Pending` | ### Sample Response (200) ```json { "status": 1, "messages": [ { "code": "simpleWorkFlow.success", "message": "Invitations sent successfully." } ], "data": { "notificationList": [ { "eventType": "Invocation", "lastUpdated": "2025-08-24T14:15:22Z", "loanNo": "LOAN001", "notifTxnId": "NTX12345", "requestId": "REQ001", "reviewedBy": "John Doe", "status": "Pending" } ], "totalCount": 5 } } ``` --- URL: https://knowledge.leegality.com/document-execution/api/get-nesl-notification-detail # GET /v3.3/nesl/notification/detail/{notifTxnId} — Get eBG notification detail Returns the complete details of a specific eBG notification. **Authentication:** `X-Auth-Token` header required on every request. ## Request URL ``` GET https://app1.leegality.com/api/v3.3/nesl/notification/detail/{notifTxnId} ``` **Environments:** - Production: `https://app1.leegality.com/api/v3.3/nesl/notification/detail/{notifTxnId}` - Sandbox: `https://sandbox.leegality.com/api/v3.3/nesl/notification/detail/{notifTxnId}` --- ## Parameters | Name | In | Required | Type | Description | Example | |------|----|----------|------|-------------|---------| | `notifTxnId` | path | Yes | string | The unique notification transaction ID of the eBG event for which details are to be retrieved. | — | --- ## Responses ### 200 — eBG notification details retrieved successfully. Response object for the Get eBG notification detail API. | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `data` | NeslNotificationDetailData | No | Wrapper object containing the notification details. See **NeslNotificationDetailData** below. | — | | `messages` | array\ | No | Additional response messages, if any. See **Message** below. | — | | `status` | integer | No | API status code. **Possible values:** - `1` — Success - `0` — Failure | `1` | #### NeslNotificationDetailData Wrapper object containing the notification details. | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `notificationDetails` | NeslNotificationDetails | No | Complete details of a single NeSL eBG notification event. See **NeslNotificationDetails** below. | — | ##### NeslNotificationDetails Complete details of a single NeSL eBG notification event. | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `canReview` | boolean | No | Indicates whether the notification can be reviewed. | — | | `loanDetails` | array\ | No | Contains details of the loan associated with the notification. See **NeslNotificationLoanDetail** below. | — | | `neslTxnId` | string | No | Transaction ID assigned by NeSL. | — | | `notifTxnId` | string | No | Unique notification transaction ID. | — | | `participantDetails` | array\ | No | List of associated participants. See **NeslNotificationParticipant** below. | — | | `portalId` | string | No | Portal ID assigned to the creditor by NeSL. | — | | `rejected` | boolean | No | Indicates if the notification request was rejected. | — | | `requestDetails` | NeslNotificationRequestDetails | No | Details of the request that triggered the eBG notification. See **NeslNotificationRequestDetails** below. | — | | `reviewRemarks` | string | No | Remarks provided during review. | — | | `reviewedBy` | string | No | Name of the reviewer. | — | | `reviewedDate` | string | No | Date when the review was completed. **Format:** ISO 8601 (e.g., `"2025-08-24T14:15:22Z"`). | — | | `status` | string | No | Status of the notification. **Possible values:** `Accepted`, `Rejected`. | — | | `timestamp` | string | No | Timestamp of the notification (if available). | — | ###### NeslNotificationLoanDetail Loan details associated with an eBG notification. | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `claimExpiryDate` | string | No | Claim expiry date of the eBG. **Format:** `YYYY-MM-DD`. | — | | `contractRefNo` | string | No | Contract reference number. | — | | `creditSubtype` | string | No | Credit subtype of the loan. | — | | `currencyOfDebt` | string | No | Currency of the debt (e.g., `INR`). | — | | `event` | string | No | eBG event type. **Possible values:** `INVOCATION`, `AMENDMENT`, `CANCELLATION`, `RENEWAL`, `CLOSURE`, `PARTIAL_INVOCATION`, `ISSUANCE`. | — | | `expiryDate` | string | No | Expiry date of the eBG. **Format:** `YYYY-MM-DD`. | — | | `loanNumber` | string | No | Loan number associated with the eBG. | — | | `loanRemark` | string | No | Remarks related to the loan. | — | | `sanctionAmount` | string | No | Sanctioned amount. | — | | `sanctionCurrency` | string | No | Currency of the sanction (e.g., `INR`). | — | | `totalOutstandingAmount` | string | No | Total outstanding amount. | — | | `vendorCode` | string | No | Vendor code. | — | ###### NeslNotificationParticipant Participant details associated with an eBG notification. | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `businessUnit` | string | No | Business unit of the participant. | — | | `contactRelation` | string | No | Relationship of the participant. **Possible values:** `Beneficiary`, `Creditor`, `Debtor`. | — | | `fullName` | string | No | Full name of the participant. | — | | `officialDocId` | string | No | Official document ID of the participant (e.g., PAN number). | — | | `officialDocType` | string | No | Type of official document (e.g., `PAN card`). | — | ###### NeslNotificationRequestDetails Details of the request that triggered the eBG notification. | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `accountHolderName` | string | No | Name of the account holder. | — | | `accountNumber` | string | No | Account number. | — | | `bankName` | string | No | Name of the bank. | — | | `contactMobile` | string | No | Contact number. | — | | `contactPersonName` | string | No | Full name of the contact person of the party. | — | | `department` | string | No | Department. | — | | `emailId` | string | No | Email address. | — | | `entityName` | string | No | Name of the requesting entity. | — | | `extensionPeriod` | string | No | Extension period. | — | | `ifscCode` | string | No | IFSC code. | — | | `invocationAmount` | string | No | Invocation amount. | — | | `requesRemarks` | string | No | Remarks provided in the request. | — | | `requestDate` | string | No | Date and time when the request was made. | — | | `requestId` | string | No | Unique identifier for the request. | — | | `requestSource` | string | No | Source of the request (e.g., `NeSLPortal`). | — | | `requestType` | string | No | Type of request. **Possible values:** `AMENDMENT`, `RENEWAL`, `EXTEND_OR_PAY`, `CANCELLATION`, `CLOSURE`, `PARTIAL_INVOCATION`, `INVOCATION`. | — | | `requestorRelationship` | string | No | Relationship of the requester to the debt. | — | | `supportingDoc` | string | No | Path to the supporting document. | — | | `userName` | string | No | Name of the user who initiated the request. | — | #### Message Message object containing a machine-readable code and a human-readable description. Used for success confirmations, errors, and warnings. | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `code` | string | No | Response message code. | `simpleWorkFlow.success` | | `message` | string | No | Human-readable success or error message. | `Invitations sent successfully.` | ### Sample Response (200) ```json { "data": { "notificationDetails": { "canReview": false, "loanDetails": [ { "claimExpiryDate": "2024-01-01", "contractRefNo": "string", "creditSubtype": "string", "currencyOfDebt": "string", "event": "string", "expiryDate": "2024-01-01", "loanNumber": "string", "loanRemark": "string", "sanctionAmount": "string", "sanctionCurrency": "string", "totalOutstandingAmount": "string", "vendorCode": "string" } ], "neslTxnId": "string", "notifTxnId": "string", "participantDetails": [ { "businessUnit": "string", "contactRelation": "string", "fullName": "string", "officialDocId": "string", "officialDocType": "string" } ], "portalId": "string", "rejected": false, "requestDetails": { "accountHolderName": "string", "accountNumber": "string", "bankName": "string", "contactMobile": "string", "contactPersonName": "string", "department": "string", "emailId": "string", "entityName": "string", "extensionPeriod": "string", "ifscCode": "string", "invocationAmount": "string", "requesRemarks": "string", "requestDate": "string", "requestId": "string", "requestSource": "string", "requestType": "string", "requestorRelationship": "string", "supportingDoc": "string", "userName": "string" }, "reviewRemarks": "string", "reviewedBy": "string", "reviewedDate": "string", "status": "string", "timestamp": "string" } }, "messages": [ { "code": "simpleWorkFlow.success", "message": "Invitations sent successfully." } ], "status": 1 } ``` --- URL: https://knowledge.leegality.com/document-execution/api/review-nesl-notification # POST /v3.3/nesl/notification/review — Review eBG notification Approves or rejects an eBG event notification. **Authentication:** `X-Auth-Token` header required on every request. ## Request URL ``` POST https://app1.leegality.com/api/v3.3/nesl/notification/review ``` **Environments:** - Production: `https://app1.leegality.com/api/v3.3/nesl/notification/review` - Sandbox: `https://sandbox.leegality.com/api/v3.3/nesl/notification/review` --- ## Request Body **Content-Type:** `application/json` Request body for reviewing an eBG event notification. | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `data` | object | No | Review details for the eBG notification. See **data** below. | — | #### data Review details for the eBG notification. | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `requestId` | string | No | Unique identifier for the request. | — | | `loanNumber` | string | No | The loan number associated with the eBG notification. | — | | `reviewStatus` | string | No | Status of the review. Allowed: `Accepted`, `Rejected`. | — | | `reviewRemarks` | string | No | Remarks or comments provided during the review. | — | | `notifTxnId` | string | No | Unique transaction ID of the notification to be reviewed. | — | ### Sample Request ```json { "data": { "requestId": "string", "loanNumber": "string", "reviewStatus": "Accepted", "reviewRemarks": "string", "notifTxnId": "string" } } ``` --- ## Responses ### 200 — eBG notification review response. Response for the Review eBG Notification API. | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `data` | object | No | Response data object. Empty on success. | — | | `messages` | array\ | No | Contains details about the response message. See **messages** below. | — | | `status` | integer | No | Indicates API response status. `1` means success. | `1` | #### messages | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `code` | string | Yes | Response code. | `ebg.notification.review.success` | | `message` | string | Yes | Review confirmation message. | `eBG notification review success.` | ### Sample Response (200) ```json { "data": {}, "messages": [ { "code": "ebg.notification.review.success", "message": "eBG notification review success." } ], "status": 1 } ``` --- URL: https://knowledge.leegality.com/document-execution/api/calculate-nesl-stamp-duty # POST /v4/nesl/stampDuty/calculate — Calculate NeSL stamp duty Calculates the stamp duty amount applicable for a NeSL document based on the consideration amount, article code, and state. **Authentication:** `X-Auth-Token` header required on every request. ## Request URL ``` POST https://app1.leegality.com/api/v4/nesl/stampDuty/calculate ``` **Environments:** - Production: `https://app1.leegality.com/api/v4/nesl/stampDuty/calculate` - Sandbox: `https://sandbox.leegality.com/api/v4/nesl/stampDuty/calculate` --- ## Request Body **Content-Type:** `application/json` | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `considerationAmount` | string | Yes | The consideration amount on which stamp duty is to be calculated. - **Format:** Numeric value passed as a string. | `10000` | | `articleId` | string | Yes | Article code applicable for the document type. Use the same article code provided by NeSL. | `115` | | `articleSubCode` | string | No | This is article sub-code. | `159` | | `stateCode` | string | Yes | Two-letter state code where the stamp duty is being paid. Currently supported only for **eGRAS states** (not for SHCIL states). Accepted values are- MH, MP, KL, WB, KA, TS, BH, RJ. Allowed: `MH`, `MP`, `KL`, `WB`, `KA`, `TS`, `BH`, `RJ`. | `MP` | ### Sample Request ```json { "considerationAmount": "10000", "articleId": "115", "articleSubCode": "159", "stateCode": "MP" } ``` --- ## Responses ### 200 — NeSL stamp duty calculation response. Response for the Calculate NeSL Stamp Duty API. | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `data` | object | No | Response data object containing the calculated stamp duty. See **data** below. | — | | `messages` | array\ | No | Contains details about the response message. Empty on success. See **messages** below. | — | | `status` | integer | No | Indicates API response status. `1` means success. | `1` | #### data Response data object containing the calculated stamp duty. | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `stampDutyAmount` | string | No | The calculated stamp duty amount for the given consideration amount, article code, and state. | `100` | #### messages | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `code` | string | No | Response code. | — | | `message` | string | No | Response message. | — | ### Sample Response (200) ```json { "data": { "stampDutyAmount": "100" }, "messages": [ { "code": "string", "message": "string" } ], "status": 1 } ``` --- URL: https://knowledge.leegality.com/document-execution/api/authentication # Authentication > **Tip — Using the v4 Workflow APIs?** > > The v4 Workflow APIs authenticate with **OAuth 2.0**, not the Auth Token below. See **[v4 Authentication (OAuth 2.0)](https://knowledge.leegality.com/document-execution/api/v4-authentication)**. The Auth Token authenticates all v3 API requests to Leegality. This section explains how to generate the token from your dashboard. When you enable the API, you receive two credentials: 1. **Auth Token**: Required in the `X-Auth-Token` header for all v3 API requests 2. **Private Salt**: Used to verify webhook authenticity via HMAC-SHA1 signature. Learn more about [webhooks](https://knowledge.leegality.com/document-execution/api/webhooks/webhook-event-types) 1. Log in to your Leegality Dashboard - **Production:** https://dashboard.leegality.com - **Sandbox:** https://sandbox-dashboard.leegality.com 2. Click the **Settings** ⚙️ icon in the top right corner 3. Navigate to **Settings > API** from the left panel 4. Click the **Enable API** button to generate your credentials. 5. Click the **Copy** icon next to **Auth Token** > **Info — Environment Separation** > > Sandbox and Production have separate *auth token* and *private salt*. ## Using Your Auth Token Include `X-Auth-Token` and `Content-Type` headers in every v3 API request: ```bash curl --location 'https://app1.leegality.com/api/v3.0/sign/request' \ --header 'X-Auth-Token: your_auth_token_here' \ --header 'Content-Type: application/json' \ --data '{}' ``` > **Warning** > > For v3 APIs, use the `X-Auth-Token` header — do not use `Authorization: Bearer` (that header is for the v4 APIs). Including both will cause authentication to fail. --- URL: https://knowledge.leegality.com/document-execution/api/quick-start # Quick Start Get up and running with the Leegality API in four steps. ### 1. Create a Workflow Workflows define your document sending configuration — signers, signature types, signing order, and notifications. Create one in the Leegality dashboard before making your first API call. [Learn how to create a workflow →](https://knowledge.leegality.com/document-execution/workflows/create-workflow) ### 2. Download Request Payload Once your workflow is ready, download its API payload from the dashboard — this gives you the exact JSON structure to use in your API request, including the `profileId` and all workflow-specific fields. [Learn how to download the request payload →](https://knowledge.leegality.com/document-execution/workflows/run-workflow?type=via-api) ### 3. Send a Document for eSigning Use the Create eSigning Request API to send a document programmatically. The request body includes your workflow ID (`profileId`), the document as a Base64-encoded PDF, and the invitee details. [See the full API reference →](https://knowledge.leegality.com/document-execution/api/create-an-e-signing-request) ### 4. Track Document Progress After sending a document, you need to know what's happening with it — whether an invitee has signed, who's still pending, and where to find the final signed document. Leegality gives you two mechanisms for this, and most integrations use both: **[Webhooks](https://knowledge.leegality.com/document-execution/api/webhooks/webhook-configuration)** for real-time event notifications, and the **[Document Details API](https://knowledge.leegality.com/document-execution/api/check-document-details)** for the full document state on demand. #### Webhooks Webhooks are HTTP POST requests Leegality sends to a URL you configure on each invitee in the workflow. The moment an invitee completes a signing action — signs, approves, rejects, or fails certificate verification — Leegality fires a webhook to the corresponding URL. Each payload tells you: - Which document the event belongs to (`documentId`) - What happened (`webhookType`: `"Success"` or `"Error"`) - Whether the overall document is still `"Sent"` or now `"Completed"` (`documentStatus`) - The invitee's name, email, action taken, and signing URL (`request`) - A `mac` field — an HMAC-SHA1 signature using your Private Salt — to verify the request came from Leegality Webhooks cover six event types across success and error flows. See [Webhook Event Types](https://knowledge.leegality.com/document-execution/api/webhooks/webhook-event-types) for the full list, and [Verify Webhook Request](https://knowledge.leegality.com/document-execution/api/webhooks/verify-webhook-request) for how to validate the `mac` field. > **Warning** > > Always verify the `mac` field before processing a webhook payload. This confirms the request genuinely came from Leegality. **What webhooks do not include:** The webhook payload does not contain the signed document or the audit trail. Once you receive a webhook confirming document completion, use the [Check Document Details API](#check-document-details-api) to retrieve those. For endpoint requirements, configuration steps, and retry timing, see [Webhook Introduction](https://knowledge.leegality.com/document-execution/api/webhooks/webhook-configuration). #### Check Document Details API The [Check Document Details API](https://knowledge.leegality.com/document-execution/api/check-document-details) returns the full state of a document in a single GET request. This is a much richer data source than any individual webhook payload — not a fallback, but a complementary tool that serves different needs. A single call can return: - **Signed file and audit trail** — CDN URLs for the completed PDF and the audit trail (expires in 15 seconds — download server-side immediately) - **Every invitee's status** — name, email, signing timestamp, current invitation status, and rejection messages where applicable - **Certificate and verification data** — the signer's certificate details, verification configuration, and match results (name, face match, liveliness) - **Document metadata** — workflow name and type, template details, folder, sender, account/organization info - **Stamp paper details** — group name, number, stamp series, and associated document IDs - **NeSL transaction data** — for documents with NeSL-type signers The response is opt-in by field group — you pass boolean query parameters (`file=true`, `auditTrail=true`, `invitations_certificateData=true`, etc.) to request only the data you need. Fields you don't request are omitted entirely. Send a `GET` request to `/v3.3/document/details` with your `documentId` and `X-Auth-Token` header. See the [Check Document Details API reference](https://knowledge.leegality.com/document-execution/api/check-document-details) for the full parameter list and response schema. #### How They Work Together A typical integration uses both: 1. **Webhooks trigger your business logic** — when Leegality fires a `"Signer Signs Document"` webhook, your server records the event and can take immediate action (send a confirmation email, update a database, unlock a next step) 2. **Check Document Details provides the complete picture** — once the document is complete, call the API with `file=true` and `auditTrail=true` to fetch the signed PDF and audit trail for storage or downstream processing 3. **Check Document Details as recovery** — if a webhook is missed or your endpoint was temporarily down, the API gives you the full current state of the document at any time --- URL: https://knowledge.leegality.com/document-execution/api/create-an-e-signing-request # POST /v3.0/sign/request — Create eSigning request Creates a new eSigning request based on a published Workflow. Use this endpoint to run a workflow and send a document with pre-configured settings. **Authentication:** `X-Auth-Token` header required on every request. ## Request URL ``` POST https://app1.leegality.com/api/v3.0/sign/request ``` **Environments:** - Production: `https://app1.leegality.com/api/v3.0/sign/request` - Sandbox: `https://sandbox.leegality.com/api/v3.0/sign/request` --- ## Request Body **Content-Type:** `application/json` | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `profileId` | string | Yes | The Workflow ID for this signing request. Find it in your Leegality Dashboard. | `7WMVrYf` | | `file` | File | Yes | File configuration. For PDF workflows, provide a base64-encoded PDF. For template workflows, provide the template field values. See **File** below. | — | | `stampSeries` | string | No | The stamp series to apply to this document. - **Note:** Ensure the selected series has stamps available. You can verify and manage stamp inventory under the **[Stamp](https://knowledge.leegality.com/document-execution/stamps/stamp-series/)** tab in your Dashboard. | — | | `multipleStampSeries` | array\ | No | Ensure the selected series has stamps available. You can verify and manage stamp inventory under the **[Stamp](https://knowledge.leegality.com/document-execution/stamps/stamp-series/)** tab in your Dashboard. See **multipleStampSeries** below. | — | | `seriesGroup` | string | No | Stamp group to use for this document. - **Note:** You can view available groups under the **[Stamp](https://knowledge.leegality.com/document-execution/stamps/stamp-group/stamp-groups)** tab in your Dashboard. | `DL02` | | `stampValue` | string | No | Stamp amount value for this document. | `5000` | | `stampUpload` | stampUpload | No | Configuration for uploading physical stamp paper. Required when the workflow uses **upload stamp paper**. All fields are required when this object is provided. See **stampUpload** below. | — | | `revenueStampSeries` | string | No | Revenue stamp series to use. | `06` | | `revenueStampQuantity` | string | No | Number of revenue stamps to attach to the document. - **Default:** 1 | `2` | | `neslData` | Nesl | No | See **Nesl** below. | — | | `invitees` | array\ | Yes | See **Invitee** below. | — | | `cc` | array\ | No | See **Cc** below. | — | | `irn` | string | No | Internal Reference Number (IRN) for the document. Used to search or reference this document via API or Dashboard. - **Allowed characters:** Alphanumeric, `+`, `\|`, `-`, `:`, `(`, `)`, `,`, `_`, `.`, `[`, `]`, `&`, `/`, and `@` - **Max length:** 255 characters | — | #### File File configuration. For PDF workflows, provide a base64-encoded PDF. For template workflows, provide the template field values. | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `name` | string | No | Name for the document. - **Allowed characters:** Alphanumeric, `+`, `\|`, `-`, `:`, `(`, `)`, `,`, `_`, `.`, `[`, `]`, `&`, `/`, and `@` - **Max length:** 255 characters | `KYC_Application_Form` | | `file` | string | No | Base64-encoded string of the PDF to be eSigned. - **Format:** Base64-encoded PDF - **Max size:** 15 MB (before encoding) | `JVBERi0xLjQKJeLjz9MKMSAwIG9iago8PC9UeXBlL...` | | `fields` | array\ | No | One object represents a single field in a template-type workflow. Get the complete field structure including IDs from Dashboard > Template Editor > Download Form Fields. Leave empty if you want the first invitee to fill in this field themselves. See **TemplateFields** below. | — | | `autoGroupedFieldsFill` | boolean | No | Enables automatic population of grouped fields in HTML templates. Grouped fields share the same data across multiple locations (e.g., an address repeated in five places). When `true`, pass only one field from each group — all others in the group are auto-populated. When `false`, all grouped fields must be passed individually. - **Default:** `false` - **Note:** Only works with HTML templates. Currently in Beta. | `true` | | `additionalFiles` | array\ | No | Array of Base64-encoded PDF strings to append to the main document. - **Format:** Array of Base64-encoded PDFs - **Max total size:** 15 MB | `JVBERi0xLjQKJeLjz9MKMSAwIG9iago...,JVBERi0xLjcKJcfsj6UKMzQgM` | ##### TemplateFields One object represents a single field in a template-type workflow. Get the complete field structure including IDs from Dashboard > Template Editor > Download Form Fields. | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `id` | string | No | Unique identifier of the template field. | `field_123` | | `name` | string | No | Name of the template field. | `employeeName` | | `type` | string | No | Type of the template field. - **Allowed:** `checkbox`, `radio`, `text`, `dropdown`, `textarea`, `select`, `files` Allowed: `text`, `textarea`, `checkbox`, `radio`, `dropdown`, `select`, `files`. | `text` | | `value` | string | No | The value to pre-fill for this template field. | `John Doe` | | `checked` | boolean | No | Indicates whether this option is selected by default in template. - **Required:** When `type` is `checkbox` or `radio`. | `true` | | `multiple` | boolean | No | Indicates whether the user can select more than one option.. **Required:** When `type` is `dropdown`. | `false` | | `width` | string | No | Width of the image in px. - **Required:** When `type` is `files` (image). | `200` | | `height` | string | No | Height of the image in px. - **Required:** When `type` is `files` (image). | `150` | | `required` | boolean | No | Indicates whether the invitee must fill in this field during the signing process. | `true` | #### multipleStampSeries Configuration for affixing multiple stamps from a specific series to the document. | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `stampSeries` | string | No | Unique series number of the stamp series to use. | `07` | | `seriesQuantity` | string | No | Number of stamps from this series to affix to the document. - **Range:** 1 – 99 | `2` | #### stampUpload Configuration for uploading physical stamp paper. Required when the workflow uses **upload stamp paper**. All fields are required when this object is provided. | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `state` | string | Yes | Name of the state for the uploaded stamp paper. | `Maharashtra` | | `denomination` | string | Yes | Denomination of the uploaded stamp paper. | `100` | | `firstPartyName` | string | Yes | Name of the first party on the uploaded stamp paper. | `ABC Pvt Ltd` | | `secondPartyName` | string | Yes | Name of the second party on the uploaded stamp paper. | `XYZ Corporation` | | `stampSerial` | string | Yes | Serial number of the uploaded stamp paper. | `IN-KA20230012345` | | `stampFile` | string | Yes | Base64-encoded string of the stamp paper to upload. - **Format:** Base64-encoded PDF | `JVBERi0xLjQKJeLjz9MK...` | #### Nesl | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `documentDetail` | NeslDocument | No | See **NeslDocument** below. | — | | `stampData` | array\ | No | See **NeslStamp** below. | — | | `entities` | array\ | No | See **NeslEntity** below. | — | | `participants` | array\ | No | See **NeslParticipants** below. | — | | `neslParties` | array\ | No | See **NeslParties** below. | — | | `neslSecurities` | array\ | No | See **NeslSecurities** below. | — | ##### NeslDocument | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `loanNumber` | string | No | The loan number associated with the debt. Mandatory for Individual, non-individual loans and eBG | — | | `sanctionNumber` | string | No | The sanction number associated with the debt. Mandatory for Individual, non-individual loans and eBG | — | | `registrationType` | string | Yes | Type of debt (Individual Loan or Non-Individual Loan) or eBG Accepted values are- INDIVIDUAL_LOAN, NON_INDIVIDUAL_LOAN, non_lending, EBG Allowed: `INDIVIDUAL_LOAN`, `NON_INDIVIDUAL_LOAN`, `NON_LENDING`, `EBG`. | — | | `state` | string | Yes | The state in which stamp duty is being paid. | — | | `branchName` | string | No | The name of the branch granting the loan. | — | | `branchAddress` | string | No | The address of the branch granting the loan. | — | | `dateOfSanction` | string | No | The date on which the loan was sanctioned as per the lender's CBS. Mandatory for Individual and non-individual loans. | `2018-02-02` | | `emiAmount` | string | No | Interest installment amount payable on the loan. Mandatory for Individual and non-individual loans. | — | | `rateOfInterest` | string | No | Rate of Interest on the loan. Mandatory for Individual and non-individual loans. | — | | `sanctionAmount` | string | No | The amount sanctioned by the financial creditor. Mandatory for Individual, non-individual loans and eBG | — | | `tenure` | string | No | The tenure of the loan. Mandatory for Individual and non-individual loans. | — | | `typeOfDebt` | string | No | The type of loan (financial debt or operational debt). Mandatory for Individual, non-individual loans and eBG Accepted values are- FINANCIAL, OPERATIONAL. Allowed: `FINANCIAL`, `OPERATIONAL`. | — | | `accountClosedFlag` | string | No | Whether the account is closed (yes, no, or assigned debt). Mandatory for Individual, non-individual loans and eBG Accepted values are- YES, NO, ASSIGNED. Allowed: `YES`, `NO`, `ASSIGNED`. | — | | `fundType` | string | No | Whether the credit facility is funded or non funded. Mandatory for Individual, non-individual loans and eBG Accepted values are- FUNDED, NON_FUNDED. Allowed: `FUNDED`, `NON_FUNDED`. | — | | `sanctionCurrency` | string | No | The currency in which the loan is denominated (INR). Mandatory for Individual, non-individual loans and eBG. Accepted values are- INR Allowed: `INR`. | — | | `creditSubtype` | string | No | Whether the financial debt is created pursuant to a credit facility or the purchase of a property. Mandatory for Individual, non-individual loans and eBG Accepted values are- CREDIT_FACILITY, PROPERTY_BUYER, GRANT Allowed: `CREDIT_FACILITY`, `PROPERTY_BUYER`, `HYBRID_EBG`. | — | | `facilityName` | string | No | The name of the loan facility. Mandatory for Individual and non-individual loans. | — | | `amountOverdue` | string | No | The amount overdue on the loan. | — | | `otherChargeAmount` | string | No | Any other charges (if applicable). | — | | `debtStartDate` | string | No | The date on which the financial debt started. | — | | `interestAmount` | string | No | The amount of interest. | — | | `oldDebtRefNo` | string | No | The old debt reference number (applicable in case there is a change in the debt reference number). | — | | `principalOutstanding` | string | No | The outstanding principal amount. | — | | `loanRemark` | string | No | Loan remarks (if any). | — | | `totalOutstandingAmount` | string | No | Total outstanding amount. | — | | `creditorBusinessUnit` | string | No | The business unit of the creditor providing the debt (such as SME, Retail etc). | — | | `drawingPower` | string | No | The drawing power of the loan. | — | | `daysPastDue` | string | No | The number of days past due date. | — | | `docRefNo` | string | No | This parameter is applicable only for Non-Lending Flow. An alphanumeric document reference number can be added in this parameter which will be stored in the IU. Note- This is a mandatory parameter for Non-lending flow. | — | | `expiryDateEbg` | string | No | The Expiry Date of eBG in "yyyy-MM-dd" format. Mandatory for eBG | — | | `claimExpiryDate` | string | No | The Claim Expiry Date of eBG in "yyyy-MM-dd" format. Mandatory for eBG | — | | `contractRefNo` | string | No | Vendor Contract Reference Number | — | | `vendorCode` | string | No | Vendor Code | — | | `portalId` | string | No | Portal ID as assigned to the Creditor by NeSL | — | | `event` | string | No | Specifies the type of electronic Bank Guarantee (eBG) event. This field is **required** if `registrationType` is set to EBG. Allowed values are: - Issuance - Amendment - Partial_invocation - Invocation - Cancellation - Closure - Renewal - Court_injunction | — | ##### NeslStamp | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `firstParty` | string | Yes | The name of the first party (for the stamp paper). | — | | `secondParty` | string | Yes | The name of the second party (for the stamp paper). | — | | `stampDutyAmount` | string | Yes | The stamp duty amount. **Note:** For West Bengal, Maharashtra, Madhya Pradesh, Kerala, and Telangana, the stamp duty is automatically calculated based on the considerationPrice and will override the value passed in this parameter, if there is a difference between the two. | — | | `considerationPrice` | string | Yes | The consideration price for the purposes of stamp duty. | — | | `descriptionOfDocument` | string | Yes | The description of the document for the purposes of stamp duty. | — | | `stampDutyPaidBy` | string | Yes | The name of the party paying the stamp duty. | — | | `articleCode` | string | Yes | Article code for payment of stamp duty. | — | | `articleSubCode` | string | No | Article sub-code as per the selected state. | — | | `firstPartyPin` | string | No | The pincode of the first party (for the stamp paper). This is mandatory for the states of Madhya Pradesh & West Bengal. | — | | `secondPartyPin` | string | No | The pincode of the second party (for the stamp paper). This is mandatory for the states of Madhya Pradesh & West Bengal. | — | | `firstPartyOVDType` | string | No | The OVD Type of the first party (for the stamp paper). This will be List of values. This is mandatory for the states of West Bengal. Accepted values are - PAN_CARD, DRIVING_LICENSE, VOTER_ID, PASSPORT, ANY_OTHER_OFFICIAL_ID. Allowed: `PAN_CARD`, `DRIVING_LICENSE`, `VOTER_ID`, `PASSPORT`, `ANY_OTHER_OFFICIAL_ID`. | — | | `firstPartyOVDValue` | string | No | The OVD Value of the first party (for the stamp paper). This is mandatory for the states of West Bengal. | — | | `secondPartyOVDType` | string | No | The OVD Type of the second party (for the stamp paper). This will be List of values. This is mandatory for the states of West Bengal. Accepted values are - PAN_CARD, DRIVING_LICENSE, VOTER_ID, PASSPORT, ANY_OTHER_OFFICIAL_ID. Allowed: `PAN_CARD`, `DRIVING_LICENSE`, `VOTER_ID`, `PASSPORT`, `ANY_OTHER_OFFICIAL_ID`. | — | | `secondPartyOVDValue` | string | No | The OVD Value of the second party (for the stamp paper). This is mandatory for the states of West Bengal. | — | ##### NeslEntity NeSL entity details for non-individual participants (companies, partnerships, etc.). - **For `NON_INDIVIDUAL_LOAN` and `NON_LENDING`:** Only one entity object is allowed. - **For `EBG`:** Multiple entity objects may be passed based on the number of non-individual participants. They are maintained as an array. - The entity object is optional. | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `entityName` | string | Yes | Name of the entity associated with the document. - **Max length:** 100 characters - **Allowed characters:** Alphanumeric only | `ABC Corporation Pvt Ltd` | | `entityPan` | string | Yes | PAN number of the entity associated with the document. - **Length:** 10 characters - **Allowed characters:** Alphanumeric only - **Format:** First 5 characters alphabetic, next 4 numeric, last character alphabetic. - **4th character rule:** Must be `C` or `E`, OR `P` when `legalConstitution` is `PROPRIETORSHIP`, OR `F` when `legalConstitution` is `PARTNERSHIP`. | `ASDCB1234B` | | `legalConstitution` | string | Yes | Legal constitution of the entity. Accepted values are- - `RESIDENT_INDIVIDUAL` - `PUBLIC_LTD` - `PRIVATE_LTD` - `LLP` - `PROPRIETORSHIP` - `PARTNERSHIP` - `ENTITY_CREATED_BY_STATUTE` - `TRUST` - `HUF` - `CO_OP_SOCIETY` - `ASSOCIATION_OF_PERSONS` - `GOVERNMENT` - `SELF_HELP_GROUP` - `NON_RESIDENT` - `FOREIGN_COMPANY` Allowed: `RESIDENT_INDIVIDUAL`, `PUBLIC_LTD`, `PRIVATE_LTD`, `LLP`, `PROPRIETORSHIP`, `PARTNERSHIP`, `ENTITY_CREATED_BY_STATUTE`, `TRUST`, `HUF`, `CO_OP_SOCIETY`, `ASSOCIATION_OF_PERSONS`, `GOVERNMENT`, `SELF_HELP_GROUP`, `NON_RESIDENT`, `FOREIGN_COMPANY`. | — | | `dateOfIncorporation` | string | Yes | Date of incorporation of the legal entity. - **Format:** YYYY-MM-DD - **Length:** 10 characters | `1992-05-18` | | `emailId` | string | Yes | Email address of the entity. - **Max length:** 100 characters - **Allowed special characters:** `-`, `_`, `.`, `@` - **Format:** Must be a valid email address. | `abc@company.com` | | `mobileNumber` | string | Yes | Contact number of the entity. - **Length:** 10 characters - **Allowed characters:** Numeric only | `7795719077` | | `registeredAddress` | string | Yes | Registered office address of the entity. - **Max length:** 300 characters - **Allowed characters:** Alphanumeric and `@!@#$%^&*()_+-=}{[]:;\|'.,/?~` | `Bangalore` | | `registeredPincode` | string | Yes | PIN code of the registered office address. Must be a valid 6-digit Indian PIN code. - **Length:** 6 characters - **Allowed characters:** Numeric only | `560001` | | `communicationAddress` | string | Yes | Communication address of the entity. - **Max length:** 300 characters - **Allowed characters:** Alphanumeric and `@!@#$%^&*()_+-=}{[]:;\|'.,/?~` | `Test` | | `communicationAddressPinCode` | string | Yes | PIN code of the communication address. Must be a valid 6-digit Indian PIN code. - **Length:** 6 characters - **Allowed characters:** Numeric only | `111111` | | `businessUnitCode` | string | No | Business unit code of the entity. **Only for `EBG`.** - **Max length:** 30 characters - **Allowed characters:** Alphanumeric only | `BU001` | ##### NeslParticipants NeSL participant details. The number of participants must equal the number of NeSL-type invitees in the request. The first participant (matching the first NeSL invitee) must have contactRelation set to `DEBTOR`. For `NON_INDIVIDUAL_LOAN`, participants additionally require: registeredAddress, registeredPinCode, communicationAddress, communicationAddressPinCode, and a company PAN (4th letter C or E in officialDocId). | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `fullName` | string | Yes | Full name of the Party. | — | | `contactPersonName` | string | No | Full name of the contact person of the Party. | — | | `contactRelation` | string | Yes | Relation of the party to the debt (Debtor, Guarantor, Co-obligant, Beneficiary, Creditor). Accepted values are- CREDITOR, DEBTOR, GUARANTOR, CO_OBLIGANT, SECURITY_PROVIDER, ASSIGNEE, BENEFICIARY. Allowed: `CREDITOR`, `DEBTOR`, `GUARANTOR`, `CO_OBLIGANT`, `SECURITY_PROVIDER`, `ASSIGNEE`, `BENEFICIARY`. | — | | `emailId` | string | Yes | Email ID of the signer. | — | | `mobileNumber` | string | Yes | Mobile Number of the signer. | `9876543210` | | `dob` | string | Yes | Date of Birth/Incorporation. | `1990-05-15` | | `legalConstitution` | string | Yes | Legal constitution of the signer (Resident Individual, Private Limited, Public Limited, LLP, Proprietorship, Partnership, Entity created by Statute, Trust, HUF, Coop Society, Association of Persons, Government, Self Help Groups, Non-Resident, Foreign Company). Accepted values are- RESIDENT_INDIVIDUAL, PUBLIC_LTD, PRIVATE_LTD, LLP, PROPRIETORSHIP, PARTNERSHIP, ENTITY_CREATED_BY_STATUTE, TRUST, HUF, CO_OP_SOCIETY, ASSOCIATION_OF_PERSONS, GOVERNMENT, SELF_HELP_GROUP, NON_RESIDENT, FOREIGN_COMPANY. Allowed: `RESIDENT_INDIVIDUAL`, `PUBLIC_LTD`, `PRIVATE_LTD`, `LLP`, `PROPRIETORSHIP`, `PARTNERSHIP`, `ENTITY_CREATED_BY_STATUTE`, `TRUST`, `HUF`, `CO_OP_SOCIETY`, `ASSOCIATION_OF_PERSONS`, `GOVERNMENT`, `SELF_HELP_GROUP`, `NON_RESIDENT`, `FOREIGN_COMPANY`. | — | | `alternateEmailId` | string | No | Alternate email ID of the signer. | — | | `alternateMobileNumber` | string | No | Alternate mobile of the signer. | — | | `officialDocType` | string | Yes | Official Document Type (Pan Card, Driving License, Voter ID, Passport, Others). Accepted values are- PAN_CARD, DRIVING_LICENSE, VOTER_ID, PASSPORT, ANY_OTHER_OFFICIAL_ID. Allowed: `PAN_CARD`, `DRIVING_LICENSE`, `VOTER_ID`, `PASSPORT`, `ANY_OTHER_OFFICIAL_ID`. | — | | `officialDocId` | string | Yes | Official Document ID. | — | | `registeredAddress` | string | No | Registered address of the signer. | — | | `registeredPinCode` | string | No | PIN code of the registered address of the signer. | — | | `designation` | string | No | Designation of the signer (relevant in case of corporate entities). | — | | `communicationAddress` | string | No | Communication address of the signer. | — | | `communicationAddressPinCode` | string | No | PIN code of the communication address of the signer. | — | | `cin` | string | No | Corporate Identification Number (relevant in case of corporate entities). | — | | `kin` | string | No | KYC Identification Number of signer. | — | | `partyType` | string | Yes | Type of Party (Indian entity/ Resident Individual/ Foreign Entity/ NRI/Foreign Individual. Accepted values are- INDIAN_ENTITY, RESIDENT_INDIVIDUAL, FOREIGN_ENTITY, NRI. Allowed: `INDIAN_ENTITY`, `RESIDENT_INDIVIDUAL`, `FOREIGN_ENTITY`, `NRI`. | — | | `isIndividual` | string | No | Whether the participant is individual or not Accepted values are - YES, NO Allowed: `YES`, `NO`. | — | | `signatoryGender` | string | No | Gender of the participant Accepted values are - MALE, FEMALE Allowed: `MALE`, `FEMALE`. | — | | `businessUnit` | string | No | Business Unit Code of the party. It is an alphanumeric string with a maximum length of 30 characters. (Only for eBG) | — | ##### NeslParties Additional NeSL party details for non-signing parties involved in the transaction. Unlike participants, neslParties do not need to match invitees. | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `fullName` | string | Yes | Full name of the Party. | — | | `contactPersonName` | string | Yes | Full name of the contact person of the Party. | — | | `contactRelation` | string | Yes | Relation of the party to the debt (Debtor, Guarantor, Co-obligant, Beneficiary, Creditor). Accepted values are- CREDITOR, DEBTOR, GUARANTOR, CO_OBLIGANT, SECURITY_PROVIDER, ASSIGNEE, BENEFICIARY. Allowed: `CREDITOR`, `DEBTOR`, `GUARANTOR`, `CO_OBLIGANT`, `SECURITY_PROVIDER`, `ASSIGNEE`, `BENEFICIARY`. | — | | `emailId` | string | Yes | Email ID of the signer. | — | | `mobileNumber` | string | Yes | Mobile Number of the signer. | `9876543210` | | `dob` | string | Yes | Date of Birth/Incorporation. | `1990-05-15` | | `legalConstitution` | string | Yes | Legal constitution of the signer (Resident Individual, Private Limited, Public Limited, LLP, Proprietorship, Partnership, Entity created by Statute, Trust, HUF, Coop Society, Association of Persons, Government, Self Help Groups, Non-Resident, Foreign Company). Accepted values are- RESIDENT_INDIVIDUAL, PUBLIC_LTD, PRIVATE_LTD, LLP, PROPRIETORSHIP, PARTNERSHIP, ENTITY_CREATED_BY_STATUTE, TRUST, HUF, CO_OP_SOCIETY, ASSOCIATION_OF_PERSONS, GOVERNMENT, SELF_HELP_GROUP, NON_RESIDENT, FOREIGN_COMPANY. Allowed: `RESIDENT_INDIVIDUAL`, `PUBLIC_LTD`, `PRIVATE_LTD`, `LLP`, `PROPRIETORSHIP`, `PARTNERSHIP`, `ENTITY_CREATED_BY_STATUTE`, `TRUST`, `HUF`, `CO_OP_SOCIETY`, `ASSOCIATION_OF_PERSONS`, `GOVERNMENT`, `SELF_HELP_GROUP`, `NON_RESIDENT`, `FOREIGN_COMPANY`. | — | | `alternateEmailId` | string | No | Alternate email ID of the signer. | — | | `alternateMobileNumber` | string | No | Alternate mobile of the signer. | — | | `officialDocType` | string | Yes | Official Document Type (Pan Card, Driving License, Voter ID, Passport, Others). Accepted values are- PAN_CARD, DRIVING_LICENSE, VOTER_ID, PASSPORT, ANY_OTHER_OFFICIAL_ID. Allowed: `PAN_CARD`, `DRIVING_LICENSE`, `VOTER_ID`, `PASSPORT`, `ANY_OTHER_OFFICIAL_ID`. | — | | `officialDocId` | string | Yes | Official Document ID. | — | | `registeredAddress` | string | No | Registered address of the signer. | — | | `registeredPinCode` | string | No | PIN code of the registered address of the signer. | — | | `designation` | string | No | Designation of the signer (relevant in case of corporate entities). | — | | `communicationAddress` | string | No | Communication address of the signer. | — | | `communicationAddressPinCode` | string | No | PIN code of the communication address of the signer. | — | | `cin` | string | No | Corporate Identification Number (relevant in case of corporate entities). | — | | `kin` | string | No | KYC Identification Number of signer. | — | | `partyType` | string | Yes | Type of Party (Indian entity/ Resident Individual/ Foreign Entity/ NRI/Foreign Individual. Accepted values are- INDIAN_ENTITY, RESIDENT_INDIVIDUAL, FOREIGN_ENTITY, NRI. Allowed: `INDIAN_ENTITY`, `RESIDENT_INDIVIDUAL`, `FOREIGN_ENTITY`, `NRI`. | — | | `isIndividual` | string | No | Whether the parties is individual or not. Mandatory for eBG Accepted values are - YES, NO Allowed: `YES`, `NO`. | — | | `signatoryGender` | string | No | Gender of the participant Accepted values are - MALE, FEMALE Allowed: `MALE`, `FEMALE`. | — | ##### NeslSecurities | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `securityDescription` | string | Yes | Description of security. | — | | `assetsType` | string | Yes | Type of asset forming security (Movable, Immovable, Intangible, Not Classified). Accepted values are- MOVABLE, IMMOVABLE, INTANGIBLE, NOT_CLASSIFIED. Allowed: `MOVABLE`, `IMMOVABLE`, `INTANGIBLE`, `NOT_CLASSIFIED`. | — | | `chargeType` | string | Yes | Type of charge created (Mortgage, Hypothecation, Charge, Assignment, Pledge, Lien, Negative Lien, Guarantee, Others, Not Classified). Accepted values are- MORTGAGE, HYPOTHECATION, CHARGE, ASSIGNMENT, PLEDGE, LIEN, NEGATIVE_LIEN, GUARANTEE, OTHERS, NOT_CLASSIFIED. Allowed: `MORTGAGE`, `HYPOTHECATION`, `CHARGE`, `ASSIGNMENT`, `PLEDGE`, `LIEN`, `NEGATIVE_LIEN`, `GUARANTEE`, `OTHERS`, `NOT_CLASSIFIED`. | — | | `assetId` | string | Yes | Asset ID of the Security (used internally by the lender). | — | | `doc` | string | No | Date of creation of security. | — | | `dov` | string | No | Date of valuation of security. | — | | `cersaiId` | string | No | CERSAI ID of security created. | — | | `rocChargeId` | string | No | ROC ID for security created. | — | | `securityValue` | string | No | Value of security. | — | | `abc` | string | No | Asset ID of the Security (used internally by the lender). | — | #### Invitee Represents a single signer or approver in the eSigning workflow. Each invitee receives a unique signing URL and can be configured with signature verification, GPS restrictions, and face matching. | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `name` | string | Yes | Full name of the invitee. - **Maximum Length:** 255 Characters | — | | `email` | string | No | Email address of the invitee. - **Required:** At least one of `email` or `phone` must be provided. - **Format:** `johndoe@example.com` | — | | `phone` | string | No | Mobile number of the invitee. - **Required:** At least one of `email` or `phone` must be provided. - **Format:** 10-digit mobile number | — | | `groupId` | string | No | Group ID for the invitee when using the Group Invitee feature. Find this value in the API payload downloaded from your Dashboard. - **Required:** When signing from a group. | — | | `groupName` | string | No | Group name for the invitee when using the Group Invitee feature. Auto-filled if configured in the Dashboard workflow. - **Required:** When signing from a group. | — | | `completionThreshold` | string | No | Completion threshold for the group. Auto-filled if configured in the Dashboard workflow. - **Required:** When signing from a group. | — | | `organizationName` | string | No | Organization name of the signer. - **Required:** When the workflow is configured to use organizational signatures. | — | | `defaultLanguageSelect` | string | No | Language for the signing journey presented to this invitee. - **Allowed:** `ENGLISH`, `HINDI`, `MARATHI`, `GUJARATI`, `BENGALI`, `MALAYALAM`, `TAMIL`, `TELUGU`, `KANNADA`, `ODIA` Allowed: `ENGLISH`, `HINDI`, `MARATHI`, `GUJARATI`, `BENGALI`, `MALAYALAM`, `TAMIL`, `TELUGU`, `KANNADA`, `ODIA`. | `ENGLISH` | | `faceMatchImage` | string | No | Reference image for face match verification. - **Required:** When face match is enabled in the workflow configuration. Omitting this when face match is enabled will return an error. - **Format:** Base64-encoded image | — | | `workflowPaymentCollectionConfig` | workflowPaymentCollectionConfig | No | Payment collection configuration for collecting a fee from the signer before they can sign the document. See **workflowPaymentCollectionConfig** below. | — | | `gpsConfig` | gpsConfig | No | GPS location restriction and accuracy configuration for the signer. When enabled, the signer must be within the specified location and accuracy threshold to sign. **Dashboard Override:** If the workflow toggle "Allow sender to make changes while running" is OFF, API values are ignored and dashboard values are used instead. See **gpsConfig** below. | — | | `aadhaarConfig` | AadhaarConfig | No | Aadhaar certificate verification configuration. When enabled, the signer's Aadhaar certificate details are verified against the values provided here before signing. > On any verification mismatch or failure to meet the threshold, whether the signer can proceed depends on sender's **[Department > eSignature](https://knowledge.leegality.com/document-execution/settings/Department/esignature-settings#configure-certificate-verification-settings)** settings. - **Dashboard Override:** If a verification field is disabled on the Dashboard, the API value is ignored. If enabled and marked mandatory on the Dashboard, the field becomes required. See **AadhaarConfig** below. | — | | `dscConfig` | DscConfig | No | DSC verification configuration. > On any verification mismatch or failure to meet the threshold, whether the signer can proceed depends on sender's **[Department > eSignature](https://knowledge.leegality.com/document-execution/settings/Department/esignature-settings#configure-certificate-verification-settings)** settings. - **Dashboard Override:** If a verification field is disabled on the Dashboard, the API value is ignored. If enabled and marked mandatory on the Dashboard, the field becomes required regardless of the API value. See **DscConfig** below. | — | | `neslConfig` | NeslConfig | No | **Dashboard Override:** If a verification field is disabled on the Dashboard, the API value is ignored. If enabled and marked mandatory on the Dashboard, the field becomes required regardless of the API value. See **NeslConfig** below. | — | ##### workflowPaymentCollectionConfig Payment collection configuration for collecting a fee from the signer before they can sign the document. | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `amount` | string | No | Amount to collect from the signer before signing. - **Range:** Greater than ₹10 | `500` | ##### gpsConfig GPS location restriction and accuracy configuration for the signer. When enabled, the signer must be within the specified location and accuracy threshold to sign. **Dashboard Override:** If the workflow toggle "Allow sender to make changes while running" is OFF, API values are ignored and dashboard values are used instead. | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `applyLocationRestriction` | boolean | No | Enables location-based signing restriction. When `true`, the signer can only sign from within the area defined by `allowedLatitude`, `allowedLongitude`, and `permissibleRadius`. | — | | `allowedLatitude` | number | No | Latitude of the permitted signing location. - **Required:** When `applyLocationRestriction` is `true`. - **Format:** Decimal degrees | `29.982643` | | `allowedLongitude` | number | No | Longitude of the permitted signing location. - **Required:** When `applyLocationRestriction` is `true`. - **Format:** Decimal degrees | `78.055405` | | `permissibleRadius` | integer | No | Radius (in meters) around the permitted location within which signing is allowed. - **Required:** When `applyLocationRestriction` is `true`. | `5000` | | `applyLocationAccuracy` | boolean | No | Enables GPS accuracy-based restriction. When `true`, the signer's device GPS accuracy is validated against `accuracyThreshold`. | — | | `accuracyThreshold` | integer | No | Maximum allowed GPS accuracy in meters. Signing is blocked if the device accuracy exceeds this value. - **Required:** When `applyLocationAccuracy` is `true`. | `10000` | ##### AadhaarConfig Aadhaar certificate verification configuration. When enabled, the signer's Aadhaar certificate details are verified against the values provided here before signing. > On any verification mismatch or failure to meet the threshold, whether the signer can proceed depends on sender's **[Department > eSignature](https://knowledge.leegality.com/document-execution/settings/Department/esignature-settings#configure-certificate-verification-settings)** settings. - **Dashboard Override:** If a verification field is disabled on the Dashboard, the API value is ignored. If enabled and marked mandatory on the Dashboard, the field becomes required. | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `verifyName` | boolean | No | Indicates whether the signer's name on the signing certificate must match the name provided in the request. | — | | `verifySmartName` | boolean | No | When `true`, returns a percentage similarity score between the certificate name and the provided name. | — | | `verifyPincode` | string | No | PIN code to verify against the signer's certificate. Ignored if the certificate does not contain a PIN code. | `247667` | | `verifyYob` | string | No | Year of birth to verify against the signer's certificate. Only works for Aadhaar eSign or NESL. - **Format:** 4-digit year | `1998` | | `verifyTitle` | string | No | Last 4 digits of the signer's Aadhaar UID to verify against the certificate. Only works for Aadhaar eSign or NESL. | `3870` | | `verifyState` | string | No | State name to verify against the signer's certificate. | `Uttarakhand` | | `verifyGender` | string | No | Gender to verify against the signer's certificate.Only works for Aadhaar eSign or NESL. - **Allowed:** `M` (Male), `F` (Female), `T` (Transgender) Allowed: `M`, `F`. | — | ##### DscConfig DSC verification configuration. > On any verification mismatch or failure to meet the threshold, whether the signer can proceed depends on sender's **[Department > eSignature](https://knowledge.leegality.com/document-execution/settings/Department/esignature-settings#configure-certificate-verification-settings)** settings. - **Dashboard Override:** If a verification field is disabled on the Dashboard, the API value is ignored. If enabled and marked mandatory on the Dashboard, the field becomes required regardless of the API value. | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `verifyName` | boolean | No | When `true`, the signer's name in the signing certificate must match the name provided. - **Note:** If set as mandatory in the Dashboard workflow, this API value is ignored. | — | | `verifySmartName` | boolean | No | When `true`, returns a percentage similarity score between the certificate name and the provided name. - **Note:** If set as mandatory in the Dashboard workflow, this API value is ignored. | — | | `verifyPincode` | string | No | PIN code to verify against the signer's certificate. Ignored if the certificate does not contain a PIN code. - **Note:** If turned off in the Dashboard workflow, this API value is ignored. | `247667` | | `verifyState` | string | No | State name to verify against the signer's certificate. Ignored if the certificate does not contain a state. - **Note:** If turned off in the Dashboard workflow, this API value is ignored. | `Uttarakhand` | ##### NeslConfig **Dashboard Override:** If a verification field is disabled on the Dashboard, the API value is ignored. If enabled and marked mandatory on the Dashboard, the field becomes required regardless of the API value. | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `verifyName` | boolean | No | When `true`, the signer's name in the signing certificate must match the name provided. | — | | `verifySmartName` | boolean | No | When `true`, returns a percentage similarity score between the certificate name and the provided name. | — | | `verifyPincode` | string | No | PIN code to verify against the signer's certificate. Ignored if the certificate does not contain a PIN code. | `247667` | | `verifyYob` | integer | No | Year of birth to verify against the signer's certificate. - **Format:** 4-digit year | `1998` | | `verifyTitle` | string | No | Last 4 digits of the signer's Aadhaar UID to verify against the certificate. | `3870` | | `verifyState` | string | No | State name to verify against the signer's certificate. Ignored if the certificate does not contain a state. | `Uttarakhand` | | `verifyGender` | string | No | Gender to verify against the signer's certificate. Only works for Aadhaar eSign or NESL. - **Allowed:** `M` (Male), `F` (Female), `T` (Transgender) Allowed: `M`, `F`, `T`. | — | #### Cc Carbon Copy recipient who receives a copy of the signed document via email after all signers complete their action. | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `name` | string | Yes | Full name of the CC recipient. | `Finance Team` | | `email` | string | Yes | Email address of the CC recipient. The recipient will receive a copy of the signed document. - **Format:** Valid email address. | `finance@example.com` | ### Sample Request ```json { "profileId": "7WMVrYf", "file": { "name": "KYC_Application_Form", "file": "JVBERi0xLjQKJeLjz9MKMSAwIG9iago8PC9UeXBlL...", "fields": [ { "id": "field_123", "name": "employeeName", "type": "text", "value": "John Doe", "checked": true, "multiple": false, "width": "200", "height": "150", "required": true } ], "autoGroupedFieldsFill": true, "additionalFiles": [ "JVBERi0xLjQKJeLjz9MKMSAwIG9iago...", "JVBERi0xLjcKJcfsj6UKMzQgMCBvYmo..." ] }, "stampSeries": "string", "multipleStampSeries": [ { "stampSeries": "07", "seriesQuantity": "2" } ], "seriesGroup": "DL02", "stampValue": "5000", "stampUpload": { "state": "Maharashtra", "denomination": "100", "firstPartyName": "ABC Pvt Ltd", "secondPartyName": "XYZ Corporation", "stampSerial": "IN-KA20230012345", "stampFile": "JVBERi0xLjQKJeLjz9MK..." }, "revenueStampSeries": "06", "revenueStampQuantity": "2", "neslData": { "documentDetail": { "loanNumber": "string", "sanctionNumber": "string", "registrationType": "INDIVIDUAL_LOAN", "state": "string", "branchName": "string", "branchAddress": "string", "dateOfSanction": "2018-02-02", "emiAmount": "string", "rateOfInterest": "string", "sanctionAmount": "string", "tenure": "string", "typeOfDebt": "FINANCIAL", "accountClosedFlag": "YES", "fundType": "FUNDED", "sanctionCurrency": "INR", "creditSubtype": "CREDIT_FACILITY", "facilityName": "string", "amountOverdue": "string", "otherChargeAmount": "string", "debtStartDate": "string", "interestAmount": "string", "oldDebtRefNo": "string", "principalOutstanding": "string", "loanRemark": "string", "totalOutstandingAmount": "string", "creditorBusinessUnit": "string", "drawingPower": "string", "daysPastDue": "string", "docRefNo": "string", "expiryDateEbg": "string", "claimExpiryDate": "string", "contractRefNo": "string", "vendorCode": "string", "portalId": "string", "event": "string" }, "stampData": [ { "firstParty": "string", "secondParty": "string", "stampDutyAmount": "string", "considerationPrice": "string", "descriptionOfDocument": "string", "stampDutyPaidBy": "string", "articleCode": "string", "articleSubCode": "string", "firstPartyPin": "string", "secondPartyPin": "string", "firstPartyOVDType": "PAN_CARD", "firstPartyOVDValue": "string", "secondPartyOVDType": "PAN_CARD", "secondPartyOVDValue": "string" } ], "entities": [ { "entityName": "ABC Corporation Pvt Ltd", "entityPan": "ASDCB1234B", "legalConstitution": "RESIDENT_INDIVIDUAL", "dateOfIncorporation": "1992-05-18", "emailId": "abc@company.com", "mobileNumber": "7795719077", "registeredAddress": "Bangalore", "registeredPincode": "560001", "communicationAddress": "Test", "communicationAddressPinCode": "111111", "businessUnitCode": "BU001" } ], "participants": [ { "fullName": "string", "contactPersonName": "string", "contactRelation": "CREDITOR", "emailId": "string", "mobileNumber": "9876543210", "dob": "1990-05-15", "legalConstitution": "RESIDENT_INDIVIDUAL", "alternateEmailId": "string", "alternateMobileNumber": "string", "officialDocType": "PAN_CARD", "officialDocId": "string", "registeredAddress": "string", "registeredPinCode": "string", "designation": "string", "communicationAddress": "string", "communicationAddressPinCode": "string", "cin": "string", "kin": "string", "partyType": "INDIAN_ENTITY", "isIndividual": "YES", "signatoryGender": "MALE", "businessUnit": "string" } ], "neslParties": [ { "fullName": "string", "contactPersonName": "string", "contactRelation": "CREDITOR", "emailId": "string", "mobileNumber": "9876543210", "dob": "1990-05-15", "legalConstitution": "RESIDENT_INDIVIDUAL", "alternateEmailId": "string", "alternateMobileNumber": "string", "officialDocType": "PAN_CARD", "officialDocId": "string", "registeredAddress": "string", "registeredPinCode": "string", "designation": "string", "communicationAddress": "string", "communicationAddressPinCode": "string", "cin": "string", "kin": "string", "partyType": "INDIAN_ENTITY", "isIndividual": "YES", "signatoryGender": "MALE" } ], "neslSecurities": [ { "securityDescription": "string", "assetsType": "MOVABLE", "chargeType": "MORTGAGE", "assetId": "string", "doc": "string", "dov": "string", "cersaiId": "string", "rocChargeId": "string", "securityValue": "string", "abc": "string" } ] }, "invitees": [ { "name": "string", "email": "string", "phone": "string", "groupId": "string", "groupName": "string", "completionThreshold": "string", "organizationName": "string", "defaultLanguageSelect": "ENGLISH", "faceMatchImage": "string", "workflowPaymentCollectionConfig": { "amount": "500" }, "gpsConfig": { "applyLocationRestriction": false, "allowedLatitude": 29.982643, "allowedLongitude": 78.055405, "permissibleRadius": 5000, "applyLocationAccuracy": false, "accuracyThreshold": 10000 }, "aadhaarConfig": { "verifyName": false, "verifySmartName": false, "verifyPincode": "247667", "verifyYob": "1998", "verifyTitle": "3870", "verifyState": "Uttarakhand", "verifyGender": "M" }, "dscConfig": { "verifyName": false, "verifySmartName": false, "verifyPincode": "247667", "verifyState": "Uttarakhand" }, "neslConfig": { "verifyName": false, "verifySmartName": false, "verifyPincode": "247667", "verifyYob": 1998, "verifyTitle": "3870", "verifyState": "Uttarakhand", "verifyGender": "M" } } ], "cc": [ { "name": "Finance Team", "email": "finance@example.com" } ], "irn": "string" } ``` --- ## Responses ### 200 — eSigning request created. Check status in the response body — 1 indicates success, 0 indicates a validation or configuration error. On success, the data object contains documentId, per-invitee signUrl, and expiryDate. Response returned by the Create eSigning Request endpoint. Contains the document ID, invitee signing URLs, and status/message details. | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `status` | integer | No | Indicates success (`1`) or failure (`0`). Allowed: `0`, `1`. | — | | `messages` | array\ | No | Array of message objects containing success, error, or warning details. On success, contains `{"code": "simpleWorkFlow.success", "message": "Invitations sent successfully."}`. Also contain warning messages even on success (e.g., when dashboard overrides API values). See **Message** below. | — | | `data` | object | No | Response data containing the document ID and invitee details. Returns an empty object `{}` when `status` is `0` (failure). See **data** below. | — | #### Message Message object containing a machine-readable code and a human-readable description. Used for success confirmations, errors, and warnings. | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `code` | string | No | Response message code. | `simpleWorkFlow.success` | | `message` | string | No | Human-readable success or error message. | `Invitations sent successfully.` | #### data Response data containing the document ID and invitee details. Returns an empty object `{}` when `status` is `0` (failure). | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `documentId` | string | No | Unique Leegality ID for this eSigning request. | `01KJPV67NZQFX5P2JRTSPSFKYY` | | `irn` | string | No | Internal Reference Number set for this document. | `LOAN-2024-00142` | | `invitees` | array\ | No | Array of invitee objects with their signing URLs and status. Includes all invitees — both from the API request and any auto-added from dashboard configuration. See **Request** below. | — | ##### Request Invitee details returned in the Create eSigning Request response. Contains the signing URL and invitation status for each invitee. | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `name` | string | No | Name of the invitee. | `Abhishek Sharma` | | `email` | string | No | Email address of the invitee. | `abhishek@example.com` | | `phone` | string | No | Mobile number of the invitee. | `9876543210` | | `signUrl` | string | No | Signing URL unique to this invitee and request. | `https://app1.leegality.com/sign/uuid-here` | | `active` | boolean | No | Whether the signing URL is currently active. | — | | `expiryDate` | string | No | Expiry date and time of the signing invite. - **Format:** `DD-MM-YYYY HH:MM:SS` - **Note:** If `null`, the invite expires in 45 minutes. | `2026-03-12T18:29:59Z` | ### Sample Response (200) ```json { "status": 0, "messages": [ { "code": "simpleWorkFlow.success", "message": "Invitations sent successfully." } ], "data": { "documentId": "01KJPV67NZQFX5P2JRTSPSFKYY", "irn": "LOAN-2024-00142", "invitees": [ { "name": "Abhishek Sharma", "email": "abhishek@example.com", "phone": "9876543210", "signUrl": "https://app1.leegality.com/sign/uuid-here", "active": false, "expiryDate": "2026-03-12T18:29:59Z" } ] } } ``` --- URL: https://knowledge.leegality.com/document-execution/api/delete-document # DELETE /v3.0/sign/request — Delete document Permanently deletes a document and all associated data. **Authentication:** `X-Auth-Token` header required on every request. ## Request URL ``` DELETE https://app1.leegality.com/api/v3.0/sign/request?documentId={documentId} ``` **Environments:** - Production: `https://app1.leegality.com/api/v3.0/sign/request` - Sandbox: `https://sandbox.leegality.com/api/v3.0/sign/request` --- ## Parameters | Name | In | Required | Type | Description | Example | |------|----|----------|------|-------------|---------| | `documentId` | query | Yes | string | Unique identifier of the document to delete. **Format:** Alphanumeric string. Get from the **Create eSigning request** API response or from the dashboard. | — | --- ## Responses ### 200 — Delete response. Check `status` field: `1` = success, `0` = failure. Response wrapper for the Delete Document API. On success (`status: 1`), `data` is an empty object. On failure (`status: 0`), `messages` contains the error details. | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `status` | integer | No | API response status. `1` = success (document deleted), `0` = failure. Allowed: `0`, `1`. | `1` | | `messages` | array\ | No | Array of response messages. **Success codes:** - `document.delete.success` — Document deleted successfully **Error codes:** - `no.document.found` — Document ID does not exist - `document.id.required` — documentId query parameter is missing or empty See **Message** below. | — | | `data` | object | No | Always an empty object `{}` for this endpoint. | — | #### Message Message object containing a machine-readable code and a human-readable description. Used for success confirmations, errors, and warnings. | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `code` | string | No | Response message code. | `simpleWorkFlow.success` | | `message` | string | No | Human-readable success or error message. | `Invitations sent successfully.` | ### Sample Response (200) ```json { "status": 1, "messages": [ { "code": "simpleWorkFlow.success", "message": "Invitations sent successfully." } ], "data": {} } ``` --- URL: https://knowledge.leegality.com/document-execution/api/check-transaction-status # GET /v3.2/sign/request — Check transaction status Returns a lightweight summary of a document's transaction status, including signing state, download URLs, and signer certificate data. **Authentication:** `X-Auth-Token` header required on every request. ## Request URL ``` GET https://app1.leegality.com/api/v3.2/sign/request?documentId={documentId} ``` **Environments:** - Production: `https://app1.leegality.com/api/v3.2/sign/request` - Sandbox: `https://sandbox.leegality.com/api/v3.2/sign/request` --- ## Parameters | Name | In | Required | Type | Description | Example | |------|----|----------|------|-------------|---------| | `documentId` | query | Yes | string | Unique identifier of the document to check. **Format:** Alphanumeric string (e.g., `01KJCHZ1Z3XRFP04DPT195AJH6`). Get from the **Create eSigning request** API response or from the dashboard. | — | --- ## Responses ### 200 — Transaction status retrieved successfully. Response wrapper for the Transaction Status API. Contains the transaction data, status code, and any messages. | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `status` | integer | No | Indicates API response status. `1` = success, `0` = failure. Allowed: `0`, `1`. | `1` | | `messages` | array\ | No | Array of response messages. Empty array on success. See **Message** below. | — | | `data` | TransactionStatusData | No | Transaction status data for a document. Contains the document identifier, signing status of each invitee, download URLs for files and audit trail, and signer certificate data for signed documents. See **TransactionStatusData** below. | — | #### Message Message object containing a machine-readable code and a human-readable description. Used for success confirmations, errors, and warnings. | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `code` | string | No | Response message code. | `simpleWorkFlow.success` | | `message` | string | No | Human-readable success or error message. | `Invitations sent successfully.` | #### TransactionStatusData Transaction status data for a document. Contains the document identifier, signing status of each invitee, download URLs for files and audit trail, and signer certificate data for signed documents. | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `documentId` | string | No | Unique identifier of the document. - **Format:** Alphanumeric string. | `01KJCHZ1Z3XRFP04DPT195AJH6` | | `irn` | string | No | Invitation Reference Number — the unique reference you passed when creating the eSigning request. Returns `null` if no IRN was set during document creation. | `INV-2026-001` | | `folderId` | string | No | Unique identifier of the folder the document belongs to. Returns `null` if the document is not assigned to any folder. | — | | `files` | array\ | No | CDN download URLs for the document PDF(s). Always present in the response, even for unsigned or rejected documents. URLs are time-limited and will expire. | — | | `auditTrail` | string | No | CDN download URL for the audit trail PDF. **Only present when the document has been completed i.e. signed by all required invitees.** For unsigned, rejected, or expired documents, this field is absent from the response. The URL is time-limited and will expire. | `https://sandbox-downloads.leegality.com/export/2026/03/02/a4` | | `requests` | array\ | No | Array of invitee (signer/approver) status objects. Each entry represents one invitee and their current signing status. See **TransactionStatusRequest** below. | — | | `signers` | array\ | No | Certificate data of invitee's digital signature — one entry per signature embedded in the final PDF. **Only present when the document has been completed (signed by all required invitees).** For unsigned, rejected, or expired documents, this field is absent from the response. The values in each entry depend on the eSign type: - **Aadhaar, Doc Signer, DSC, or NeSL** — Digital signature certificate details (name, pincode, state, title). - **Virtual, Visual, or Quick Sign** — Leegality's details, since these are signed with Leegality acting as the Application Service Provider (ASP), the entity providing the platform used to eSign. - **External Signature Details:** If the document already has a signature applied via other platforms like DocuSign or Adobe, then their details appear too. See **TransactionStatusSigner** below. | — | ##### TransactionStatusRequest Signing status of an individual invitee. Uses boolean fields (`signed`, `rejected`, `expired`) to indicate the invitee's current state. | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `name` | string | No | Full name of the invitee. | `Abhishek Sharma` | | `email` | string | No | Email address of the invitee. | `signer@example.com` | | `phone` | string | No | Mobile number of the invitee. - **Format:** 10-digit Indian mobile number. | `9876543210` | | `signUrl` | string | No | Unique signing URL for this invitee. The invitee uses this URL to access the signing page. | `https://sandbox.leegality.com/sign/2bdcc3ef-661f-440c-b059-8` | | `signed` | boolean | No | Whether the invitee has signed the document. - `true` — signed - `false` — not yet signed | `true` | | `rejected` | boolean | No | Whether the invitee has rejected the document. - `true` — explicitly rejected by the invitee - `false` — not rejected | `false` | | `expired` | boolean | No | Whether the invitee's signing invitation has expired. - `true` — expired (time-based expiry or verification failure) - `false` — not expired - **Note:** Also set to `true` when certificate verification fails during signing (e.g., Aadhaar details mismatch, DSC details mismatch). | `false` | | `expiryDate` | string | No | Expiry date and time for the signing invitation. - **Format:** `dd-MM-yyyy HH:mm:ss` | `08-03-2026 23:59:59` | | `signType` | string | No | Type of signature used by the invitee. Returns `null` if the invitee has not signed yet. - **Possible values:** `AADHAAR`, `VIRTUAL`, `DSC` Allowed: `AADHAAR`, `VIRTUAL`, `DSC`. | `AADHAAR` | | `active` | boolean | No | Whether it is currently the invitee's turn to act. - `true` — the invitee can currently sign or approve the document | `true` | ##### TransactionStatusSigner Certificate data extracted from a single digital signature in the document. Depending on the sign type, the fields reflect the individual signer's certificate (Aadhaar, Document Signer, DSC, NeSL), Leegality's details (Virtual, Visual, Quick Sign), or the details of another platform if the document was already signed via one (e.g., DocuSign, Adobe). | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `name` | string | No | Name recorded on the signing certificate. - **Aadhaar, Document Signer, DSC, NeSL** — the signer's name as per digital certificate. - **Virtual, Visual, Quick Sign** — Leegality's details: "DS Grey Swift Private Limited" (the Leegality entity). - If the document already has a signature applied via other platforms like DocuSign or Adobe — that platform's organisation name (e.g., "DocuSign, Inc."). | `Abhishek Sharma` | | `pincode` | string | No | Pincode as per digital signature certificate. Returns `null` when not present (e.g., Virtual, Visual, Quick Sign, or signatures applied via other platforms like DocuSign or Adobe). - **Format:** 6-digit string. | `110053` | | `state` | string | No | State as per digital signature certificate. - Individual digital certificates (Aadhaar, Document Signer, DSC, NeSL). - Virtual, Visual, Quick Sign — "HR" (Haryana), where Leegality is registered. - Signatures applied via other platforms like DocuSign or Adobe — that platform's location. | `Delhi` | | `title` | string | No | Title (last 4 Aadhaar number digits). - Returns `null` for Virtual, Visual, Quick Sign, or signatures applied via other platforms like DocuSign or Adobe. | `1234` | ### Sample Response (200) ```json { "status": 1, "messages": [ { "code": "simpleWorkFlow.success", "message": "Invitations sent successfully." } ], "data": { "documentId": "01KJCHZ1Z3XRFP04DPT195AJH6", "irn": "INV-2026-001", "folderId": "string", "files": [ "https://sandbox-downloads.leegality.com/export/2026/03/02/c9845ec1-..." ], "auditTrail": "https://sandbox-downloads.leegality.com/export/2026/03/02/a441a5e8-...", "requests": [ { "name": "Abhishek Sharma", "email": "signer@example.com", "phone": "9876543210", "signUrl": "https://sandbox.leegality.com/sign/2bdcc3ef-661f-440c-b059-82c0ff6ce4d8", "signed": true, "rejected": false, "expired": false, "expiryDate": "08-03-2026 23:59:59", "signType": "AADHAAR", "active": true } ], "signers": [ { "name": "Abhishek Sharma", "pincode": "110053", "state": "Delhi", "title": "1234" } ] } } ``` --- URL: https://knowledge.leegality.com/document-execution/api/reactivate-document # POST /v3.0/sign/request/reactivate — Reactivate document Reactivates an expired document by resetting the expiry period, allowing invitees to sign again. **Authentication:** `X-Auth-Token` header required on every request. ## Request URL ``` POST https://app1.leegality.com/api/v3.0/sign/request/reactivate ``` **Environments:** - Production: `https://app1.leegality.com/api/v3.0/sign/request/reactivate` - Sandbox: `https://sandbox.leegality.com/api/v3.0/sign/request/reactivate` --- ## Request Body **Content-Type:** `application/json` Request body for reactivating an expired document. Pass either `expiryDays` or `expiryTime` to set the new expiry period. If neither is provided, the API uses the default expiry from the workflow configuration. | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `documentId` | string | Yes | Unique identifier of the expired document to reactivate. **Format:** Alphanumeric string. The document must have at least one invitation with `expired: true` status. | `01KJCHYRSQGA24YDZ044BS6MTS` | | `expiryDays` | integer | No | New expiry period as a relative number of days. **Range:** `-1` to `365` \| Value \| Meaning \| \|---\|---\| \| `-1` \| Expires in 45 minutes \| \| `0` \| Expires same day at 11:59 PM \| \| `1` \| Expires next day at 11:59 PM \| \| `2`–`365` \| Expires in N days at 11:59 PM \| Use this for simple relative expiry. For a specific date/time, use `expiryTime` instead. | `5` | | `expiryTime` | integer | No | This is used to define the new timeout time after which an uncompleted transaction get cancelled and reversed. Maximum value can be equal to 365 days. Value in this parameter to be passed as long format of date. | `1773576000000` | ### Sample Request ```json { "documentId": "01KJCHYRSQGA24YDZ044BS6MTS", "expiryDays": 5, "expiryTime": 1773576000000 } ``` --- ## Responses ### 200 — Reactivation response. Check `status` field: `1` = success, `0` = failure. Response wrapper for the Reactivate Document API. On success (`status: 1`), `data` contains the document ID, IRN, and updated invitee statuses. On failure (`status: 0`), `data` is an empty object and `messages` contains the error details. | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `status` | integer | No | API response status. `1` = success, `0` = failure. Allowed: `0`, `1`. | `1` | | `messages` | array\ | No | Array of response messages. **Success codes:** - `signinvitation.activate.success` — Invitation activated successfully **Error codes:** - `no.expired.invitation.found` — No expired invitation exists (document is completed, rejected, active, or already reactivated) - `no.document.found` — Document ID does not exist - `invalid.expiry.days.value` — expiryDays is outside the valid range (-1 to 365) - `invalid.expiry.time` — expiryTime is in the past or negative - `invalid.expiry.time.maxerror` — expiryTime exceeds 365 days from now See **Message** below. | — | | `data` | ReactivateData | No | Reactivation result data. On success, contains the document details and updated invitee statuses with the new expiry. On failure, this is an empty object `{}`. See **ReactivateData** below. | — | #### Message Message object containing a machine-readable code and a human-readable description. Used for success confirmations, errors, and warnings. | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `code` | string | No | Response message code. | `simpleWorkFlow.success` | | `message` | string | No | Human-readable success or error message. | `Invitations sent successfully.` | #### ReactivateData Reactivation result data. On success, contains the document details and updated invitee statuses with the new expiry. On failure, this is an empty object `{}`. | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `documentId` | string | No | Unique identifier of the reactivated document. | `01KJCHYRSQGA24YDZ044BS6MTS` | | `irn` | string | No | Invitation Reference Number set during document creation. Returns `null` if no IRN was set. | `INV-2026-001` | | `requests` | array\ | No | Array of invitee status objects with updated expiry. After reactivation, `expired` resets to `false` and `expiryDate` reflects the new expiry period. The `signUrl` remains the same as the original invitation. See **TransactionStatusRequest** below. | — | ##### TransactionStatusRequest Signing status of an individual invitee. Uses boolean fields (`signed`, `rejected`, `expired`) to indicate the invitee's current state. | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `name` | string | No | Full name of the invitee. | `Abhishek Sharma` | | `email` | string | No | Email address of the invitee. | `signer@example.com` | | `phone` | string | No | Mobile number of the invitee. - **Format:** 10-digit Indian mobile number. | `9876543210` | | `signUrl` | string | No | Unique signing URL for this invitee. The invitee uses this URL to access the signing page. | `https://sandbox.leegality.com/sign/2bdcc3ef-661f-440c-b059-8` | | `signed` | boolean | No | Whether the invitee has signed the document. - `true` — signed - `false` — not yet signed | `true` | | `rejected` | boolean | No | Whether the invitee has rejected the document. - `true` — explicitly rejected by the invitee - `false` — not rejected | `false` | | `expired` | boolean | No | Whether the invitee's signing invitation has expired. - `true` — expired (time-based expiry or verification failure) - `false` — not expired - **Note:** Also set to `true` when certificate verification fails during signing (e.g., Aadhaar details mismatch, DSC details mismatch). | `false` | | `expiryDate` | string | No | Expiry date and time for the signing invitation. - **Format:** `dd-MM-yyyy HH:mm:ss` | `08-03-2026 23:59:59` | | `signType` | string | No | Type of signature used by the invitee. Returns `null` if the invitee has not signed yet. - **Possible values:** `AADHAAR`, `VIRTUAL`, `DSC` Allowed: `AADHAAR`, `VIRTUAL`, `DSC`. | `AADHAAR` | | `active` | boolean | No | Whether it is currently the invitee's turn to act. - `true` — the invitee can currently sign or approve the document | `true` | ### Sample Response (200) ```json { "status": 1, "messages": [ { "code": "simpleWorkFlow.success", "message": "Invitations sent successfully." } ], "data": { "documentId": "01KJCHYRSQGA24YDZ044BS6MTS", "irn": "INV-2026-001", "requests": [ { "name": "Abhishek Sharma", "email": "signer@example.com", "phone": "9876543210", "signUrl": "https://sandbox.leegality.com/sign/2bdcc3ef-661f-440c-b059-82c0ff6ce4d8", "signed": true, "rejected": false, "expired": false, "expiryDate": "08-03-2026 23:59:59", "signType": "AADHAAR", "active": true } ] } } ``` --- URL: https://knowledge.leegality.com/document-execution/api/list-documents # GET /v3.0/sign/request/list — List documents Search and list documents from your Leegality account with optional filters. **Authentication:** `X-Auth-Token` header required on every request. ## Request URL ``` GET https://app1.leegality.com/api/v3.0/sign/request/list?q={q}&status={status}&max={max}&offset={offset} ``` **Environments:** - Production: `https://app1.leegality.com/api/v3.0/sign/request/list` - Sandbox: `https://sandbox.leegality.com/api/v3.0/sign/request/list` --- ## Parameters | Name | In | Required | Type | Description | Example | |------|----|----------|------|-------------|---------| | `q` | query | No | string | Search query to find documents. Searches across: - **Document name** — the PDF filename - **Document ID** — the unique identifier returned by the Create eSigning Request API - **Internal Reference Number (IRN)** — set during document creation Search is **case-insensitive** and matches the **exact full value**. Partial matches are not supported — for example, searching `01KGRZ2F` will not match `01KGRZ2F9YNZ828PYDYE29JYZS`. | — | | `status` | query | No | string | Filter documents by status. | — | | `max` | query | No | integer | Maximum number of documents to return per page. Default: `20`. Maximum: `40`. Values above 40 are silently reset to 20. Use with `offset` for pagination. Example: for page 2 with 10 results per page, use `max=10&offset=10`. | — | | `offset` | query | No | integer | Number of documents to skip before returning results. Default: `0`. Use with `max` for pagination. Example: for page 2 with 10 results per page, use `max=10&offset=10`. | — | --- ## Responses ### 200 — List of documents matching the search criteria. Response wrapper for the List Documents API. On success (`status: 1`), `data` contains the total count and array of matching documents. On failure (`status: 0`), `messages` contains the error details. | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `status` | integer | No | API response status. `1` = success, `0` = failure. Allowed: `0`, `1`. | `1` | | `messages` | array\ | No | Array of response messages. Empty array on success. **Error codes:** - `typeMismatch` — Invalid value for `status` parameter See **Message** below. | — | | `data` | ListDocumentsData | No | Paginated list of documents matching the search criteria. `total` represents the total number of matching documents across all pages, while `documents` contains only the current page of results. See **ListDocumentsData** below. | — | #### Message Message object containing a machine-readable code and a human-readable description. Used for success confirmations, errors, and warnings. | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `code` | string | No | Response message code. | `simpleWorkFlow.success` | | `message` | string | No | Human-readable success or error message. | `Invitations sent successfully.` | #### ListDocumentsData Paginated list of documents matching the search criteria. `total` represents the total number of matching documents across all pages, while `documents` contains only the current page of results. | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `total` | integer | No | Total number of documents matching the search/filter criteria. Use this with `max` and `offset` to calculate pagination. | `233` | | `documents` | array\ | No | Array of document summary objects for the current page. See **ListDocumentItem** below. | — | ##### ListDocumentItem Summary of a document in the list results. | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `documentId` | string | No | Unique identifier of the document. | `01KGRZ2F9YNZ828PYDYE29JYZS` | | `name` | string | No | Name of the document (typically the uploaded PDF filename). | `Loan-Agreement.pdf` | | `irn` | string | No | Internal Reference Number set during document creation. Returns `null` if no IRN was set. | `INV-2026-001` | | `status` | string | No | Current status of the document. Allowed: `DRAFT`, `SENT`, `RECEIVED`, `SIGNED`, `COMPLETED`, `EXPIRED`. | `COMPLETED` | | `folderId` | string | No | Unique identifier of the folder the document belongs to. Returns `null` if not in a folder. | — | | `folderName` | string | No | Name of the folder the document belongs to. Returns `null` if not in a folder. | — | ### Sample Response (200) ```json { "status": 1, "messages": [ { "code": "simpleWorkFlow.success", "message": "Invitations sent successfully." } ], "data": { "total": 233, "documents": [ { "documentId": "01KGRZ2F9YNZ828PYDYE29JYZS", "name": "Loan-Agreement.pdf", "irn": "INV-2026-001", "status": "COMPLETED", "folderId": "string", "folderName": "string" } ] } } ``` --- URL: https://knowledge.leegality.com/document-execution/api/check-document-details # GET /v3.3/document/details — Check document details Returns in-depth details about a document. **Authentication:** `X-Auth-Token` header required on every request. ## Request URL ``` GET https://app1.leegality.com/api/v3.3/document/details?documentId={documentId}&file={file}&auditTrail={auditTrail}&document_scheduledDeletionDate={document_scheduledDeletionDate}&document_customMessage={document_customMessage}&document_deleteOnComplete={document_deleteOnComplete}&document_requestSigningOrder={document_requestSigningOrder}&document_requireSigningOrder={document_requireSigningOrder}&sftp={sftp}&workflow={workflow}&workflow_name={workflow_name}&workflow_type={workflow_type}&workflow_subType={workflow_subType}&template={template}&template_name={template_name}&account={account}&account_name={account_name}&account_label={account_label}&account_brandName={account_brandName}&sender={sender}&sender_name={sender_name}&folder={folder}&folder_name={folder_name}&stampDetails={stampDetails}&stampDetails_groupName={stampDetails_groupName}&stampDetails_groupNumber={stampDetails_groupNumber}&stampDetails_maximumValuePermitted={stampDetails_maximumValuePermitted}&stampDetails_stamps={stampDetails_stamps}&stampDetails_stamps_associatedDocumentId={stampDetails_stamps_associatedDocumentId}&stampDetails_stamps_multipleStampSeries={stampDetails_stamps_multipleStampSeries}&referenceAttachments={referenceAttachments}&neslDocumentDetails={neslDocumentDetails}&neslDocumentDetails_responseCode={neslDocumentDetails_responseCode}&neslDocumentDetails_responseMessage={neslDocumentDetails_responseMessage}&neslDocumentDetails_isRetryAllowed={neslDocumentDetails_isRetryAllowed}&neslDocumentDetails_loanDetails_event={neslDocumentDetails_loanDetails_event}&neslDocumentDetails_loanDetails_expiryDate={neslDocumentDetails_loanDetails_expiryDate}&neslDocumentDetails_loanDetails_claimExpiryDate={neslDocumentDetails_loanDetails_claimExpiryDate}&neslDocumentDetails_loanDetails_currencyOfDebt={neslDocumentDetails_loanDetails_currencyOfDebt}&neslDocumentDetails_loanDetails_docRefNo={neslDocumentDetails_loanDetails_docRefNo}&neslDocumentDetails_loanDetails_contractRefNo={neslDocumentDetails_loanDetails_contractRefNo}&neslDocumentDetails_loanDetails_vendorCode={neslDocumentDetails_loanDetails_vendorCode}&neslDocumentDetails_loanDetails_portalID={neslDocumentDetails_loanDetails_portalID}&neslDocumentDetails_securityDetails={neslDocumentDetails_securityDetails}&neslDocumentDetails_partyDetails={neslDocumentDetails_partyDetails}&neslDocumentDetails_stampDetails={neslDocumentDetails_stampDetails}&neslDocumentDetails_neslEstampStatusDetails={neslDocumentDetails_neslEstampStatusDetails}&refreshNeslDocument={refreshNeslDocument}&cc={cc}&coordinatePicker={coordinatePicker}&invitations_inviteeConfigs={invitations_inviteeConfigs}&invitations_inviteeConfigs_retry={invitations_inviteeConfigs_retry}&invitations_inviteeConfigs_fixedName={invitations_inviteeConfigs_fixedName}&invitations_inviteeConfigs_noName={invitations_inviteeConfigs_noName}&invitations_inviteeConfigs_supportingDocument={invitations_inviteeConfigs_supportingDocument}&invitations_inviteeConfigs_viewSupportingDocument={invitations_inviteeConfigs_viewSupportingDocument}&invitations_inviteeConfigs_organizationConfig={invitations_inviteeConfigs_organizationConfig}&invitations_inviteeConfigs_security={invitations_inviteeConfigs_security}&invitations_inviteeConfigs_security_gpsConfig={invitations_inviteeConfigs_security_gpsConfig}&invitations_inviteeConfigs_security_faceMatch={invitations_inviteeConfigs_security_faceMatch}&invitations_inviteeConfigs_security_smartUserLiveliness={invitations_inviteeConfigs_security_smartUserLiveliness}&invitations_inviteeConfigs_eSignPriorityConfig={invitations_inviteeConfigs_eSignPriorityConfig}&invitations_inviteeConfigs_eSignPriorityConfig_orderLevelRetryCount={invitations_inviteeConfigs_eSignPriorityConfig_orderLevelRetryCount}&invitations_inviteeConfigs_customURL={invitations_inviteeConfigs_customURL}&invitations_inviteeConfigs_customConsent={invitations_inviteeConfigs_customConsent}&invitations_inviteeConfigs_enableRejectDocument={invitations_inviteeConfigs_enableRejectDocument}&invitations_inviteeConfigs_enableRejectMessage={invitations_inviteeConfigs_enableRejectMessage}&invitations_inviteeConfigs_languageDetails={invitations_inviteeConfigs_languageDetails}&invitations_inviteeConfigs_paymentDetails={invitations_inviteeConfigs_paymentDetails}&invitations_inviteeConfigs_maskContactDetails={invitations_inviteeConfigs_maskContactDetails}&invitations_recordReviewerDetails={invitations_recordReviewerDetails}&invitations_inviteeGroup={invitations_inviteeGroup}&invitations_inviteeGroup_name={invitations_inviteeGroup_name}&invitations_inviteeGroup_completionThreshold={invitations_inviteeGroup_completionThreshold}&invitations_inviteeGroup_size={invitations_inviteeGroup_size}&invitations_inviteeGroup_completed={invitations_inviteeGroup_completed}&invitations_signatureOptions={invitations_signatureOptions}&invitations_signatureOptions_quickSign={invitations_signatureOptions_quickSign}&invitations_signatureOptions_visualSign={invitations_signatureOptions_visualSign}&invitations_signatureOptionsUsed={invitations_signatureOptionsUsed}&invitations_neslInvitationDetails={invitations_neslInvitationDetails}&invitations_neslInvitationDetails_participantDetails={invitations_neslInvitationDetails_participantDetails}&invitations_neslInvitationDetails_participantDetails_isIndividual={invitations_neslInvitationDetails_participantDetails_isIndividual}&invitations_neslInvitationDetails_participantDetails_signatoryGender={invitations_neslInvitationDetails_participantDetails_signatoryGender}&invitations_neslInvitationDetails_participantDetails_businessUnit={invitations_neslInvitationDetails_participantDetails_businessUnit}&invitations_invitationStatus_failureReason={invitations_invitationStatus_failureReason}&invitations_invitationStatus_rejectionMessage={invitations_invitationStatus_rejectionMessage}&invitations_invitationStatus_signRejectionMessage={invitations_invitationStatus_signRejectionMessage}&invitations_certificateData={invitations_certificateData}&invitations_certificateData_photoHash={invitations_certificateData_photoHash}&invitations_certificateData_uid={invitations_certificateData_uid}&invitations_certificateData_serialNumber={invitations_certificateData_serialNumber}&invitations_verificationRequest={invitations_verificationRequest}&invitations_verificationResponse={invitations_verificationResponse}&invitations_espResponse={invitations_espResponse}&invitations_verificationResponse_smartNameAI={invitations_verificationResponse_smartNameAI}&invitations_verificationResponse_faceMatch={invitations_verificationResponse_faceMatch}&invitations_verificationResponse_smartUserLiveliness={invitations_verificationResponse_smartUserLiveliness}&invitations_verificationResponse_neslVerficationResponse={invitations_verificationResponse_neslVerficationResponse}&invitations_supportingDocuments={invitations_supportingDocuments}&invitations_requiresApproverOtp={invitations_requiresApproverOtp}&invitations_signatureSubOptionUsed={invitations_signatureSubOptionUsed} ``` **Environments:** - Production: `https://app1.leegality.com/api/v3.3/document/details` - Sandbox: `https://sandbox.leegality.com/api/v3.3/document/details` --- ## Parameters | Name | In | Required | Type | Description | Example | |------|----|----------|------|-------------|---------| | `documentId` | query | Yes | string | Unique document ID generated by Leegality. Get from the Create eSigning Request API response or from the dashboard. - **Format:** Alphanumeric string | — | | `file` | query | No | boolean | Pass `true` to receive the signed PDF file as a CDN URL in the response. - **Validity:** CDN URL expires in **15 seconds** — download immediately at server level, not for browser preview. | — | | `auditTrail` | query | No | boolean | Pass `true` to receive the Audit Trail PDF as a CDN URL in the response. Only applicable to completed documents (all signatories have signed). - **Validity:** CDN URL expires in **15 seconds** — download immediately at server level, not for browser preview. - Audit trail for a deleted document can also be fetched. | — | | `document_scheduledDeletionDate` | query | No | boolean | Pass `true` to receive the scheduled document deletion date and time. Applicable when the "Auto delete on complete" is enabled in the **[Department > Document Security](https://knowledge.leegality.com/document-execution/settings/Department/document-security-settings)** setting or while sending the document. | — | | `document_customMessage` | query | No | boolean | Pass `true` to receive the custom message configured on the invitation email. | — | | `document_deleteOnComplete` | query | No | boolean | Pass `true` to receive whether auto-delete on complete was enabled for the document. | — | | `document_requestSigningOrder` | query | No | boolean | Pass `true` to receive whether signing links are activated sequentially. | — | | `document_requireSigningOrder` | query | No | boolean | Pass `true` to receive whether signing order was required for the document. | — | | `sftp` | query | No | boolean | Pass `true` to receive whether SFTP was enabled for the document, and the SFTP server ID configured to receive the completed document and audit trail. | — | | `workflow` | query | No | boolean | Pass `true` to receive workflow ID associated with the document. | — | | `workflow_name` | query | No | boolean | Pass `true` to receive the workflow name. > **Note:** Requires `workflow=true`. | — | | `workflow_type` | query | No | boolean | Pass `true` to receive the workflow type (PDF or Template). > **Note:** Requires `workflow=true`. | — | | `workflow_subType` | query | No | boolean | Pass `true` to receive the workflow sub-type (Single PDF/template or Multiple PDF enabled). > **Note:** Requires `workflow=true`. | — | | `template` | query | No | boolean | Pass `true` to receive template ID associated with the document. | — | | `template_name` | query | No | boolean | Pass `true` to receive the template name used for the document. > **Note:** Requires `template=true`. | — | | `account` | query | No | boolean | Pass `true` to receive account ID associated with the document. | — | | `account_name` | query | No | boolean | Pass `true` to receive the organisation's name. > **Note:** Requires `account=true`. | — | | `account_label` | query | No | boolean | Pass `true` to receive the department name configured in **Settings > Admin > Department**. > **Note:** Requires `account=true`. | — | | `account_brandName` | query | No | boolean | Pass `true` to receive the brand name configured in **Settings > Department > Branding**. > **Note:** Requires `account=true`. | — | | `sender` | query | No | boolean | Pass `true` to receive sender's email address associated with the document. | — | | `sender_name` | query | No | boolean | Pass `true` to receive the sender's name. > **Note:** Requires `sender=true`. | — | | `folder` | query | No | boolean | Pass `true` to receive folder ID associated with the document. | — | | `folder_name` | query | No | boolean | Pass `true` to receive the folder name(s) for the document. > **Note:** Requires `folder=true`. | — | | `stampDetails` | query | No | boolean | Pass `true` to receive stamp paper state and value attached to the document. | — | | `stampDetails_groupName` | query | No | boolean | Pass `true` to receive the group name for the stamp papers attached. Stamp groups are a collection of stamp series for a single state. > **Note:** Requires `stampDetails=true`. | — | | `stampDetails_groupNumber` | query | No | boolean | Pass `true` to receive the group number for the stamp papers attached. > **Note:** Requires `stampDetails=true`. | — | | `stampDetails_maximumValuePermitted` | query | No | boolean | Pass `true` to receive the maximum permitted stamp value configured in the stamp group. Any stamp value above this limit passed in the Create API will be rejected. > **Note:** Requires `stampDetails=true`. | — | | `stampDetails_stamps` | query | No | boolean | Pass `true` to receive an array containing stamp paper details - stamp series number, stamp amount and stamp serial number - for each stamp associated with the document. > **Note:** Requires `stampDetails=true`. | — | | `stampDetails_stamps_associatedDocumentId` | query | No | boolean | Pass `true` to receive the associated document ID physically printed on the stamp paper. > **Note:** Requires `stampDetails_stamps=true`. | — | | `stampDetails_stamps_multipleStampSeries` | query | No | boolean | Pass `true` to receive whether Multiple Stamp Series was used. > **Note:** Requires `stampDetails_stamps=true`. | — | | `referenceAttachments` | query | No | boolean | Pass `true` to receive the array containing reference attachments details - file, name, and type - for each reference attachment sent with the document. These are files uploaded by the document owner while sending the document. | — | | `neslDocumentDetails` | query | No | boolean | Pass `true` to include NeSL transaction details in the response. Only relevant when the document has a NeSL-type signer. | — | | `neslDocumentDetails_responseCode` | query | No | boolean | Pass `true` to receive the response code sent by NeSL. > **Note:** Requires `neslDocumentDetails=true`. | — | | `neslDocumentDetails_responseMessage` | query | No | boolean | Pass `true` to receive the response message associated with the NeSL response code. > **Note:** Requires `neslDocumentDetails=true`. | — | | `neslDocumentDetails_isRetryAllowed` | query | No | boolean | Pass `true` to receive whether retrying is allowed for this NeSL document. Retry is only allowed when the NeSL invitation has failed due to errors other than validation errors. > **Note:** Requires `neslDocumentDetails=true`. | — | | `neslDocumentDetails_loanDetails_event` | query | No | boolean | Pass `true` to receive the selected eBG event for this request. > **Note:** Requires `neslDocumentDetails=true` and `neslDocumentDetails_loanDetails=true`. | — | | `neslDocumentDetails_loanDetails_expiryDate` | query | No | boolean | Pass `true` to receive the specified expiry date of the eBG for this request. > **Note:** Requires `neslDocumentDetails=true` and `neslDocumentDetails_loanDetails=true`. | — | | `neslDocumentDetails_loanDetails_claimExpiryDate` | query | No | boolean | Pass `true` to receive the specified claim expiry date of the eBG for this request. > **Note:** Requires `neslDocumentDetails=true` and `neslDocumentDetails_loanDetails=true`. | — | | `neslDocumentDetails_loanDetails_currencyOfDebt` | query | No | boolean | Pass `true` to receive the specified currency of debt for this request. > **Note:** Requires `neslDocumentDetails=true` and `neslDocumentDetails_loanDetails=true`. | — | | `neslDocumentDetails_loanDetails_docRefNo` | query | No | boolean | Pass `true` to receive the document reference number for this request. > **Note:** Requires `neslDocumentDetails=true` and `neslDocumentDetails_loanDetails=true`. | — | | `neslDocumentDetails_loanDetails_contractRefNo` | query | No | boolean | Pass `true` to receive the contract reference number for this request. > **Note:** Requires `neslDocumentDetails=true` and `neslDocumentDetails_loanDetails=true`. | — | | `neslDocumentDetails_loanDetails_vendorCode` | query | No | boolean | Pass `true` to receive the Vendor Code for this request. > **Note:** Requires `neslDocumentDetails=true` and `neslDocumentDetails_loanDetails=true`. | — | | `neslDocumentDetails_loanDetails_portalID` | query | No | boolean | Pass `true` to receive the Portal ID for this request. > **Note:** Requires `neslDocumentDetails=true` and `neslDocumentDetails_loanDetails=true`. | — | | `neslDocumentDetails_securityDetails` | query | No | boolean | Pass `true` to receive NeSL security details for the document. > **Note:** Requires `neslDocumentDetails=true`. | — | | `neslDocumentDetails_partyDetails` | query | No | boolean | Pass `true` to receive NeSL party details for the document. > **Note:** Requires `neslDocumentDetails=true`. | — | | `neslDocumentDetails_stampDetails` | query | No | boolean | Pass `true` to receive NeSL stamp details for the document. > **Note:** Requires `neslDocumentDetails=true`. | — | | `neslDocumentDetails_neslEstampStatusDetails` | query | No | boolean | Pass this parameter as `TRUE` to receive the NeSL stamp status and certificate details. **Note:** "neslDocumentDetails" parameter also needs to be passed as true to receive this in response. | — | | `refreshNeslDocument` | query | No | boolean | Pass `true` to get the latest status, certificate details, and document from NeSL in the response. **Note:** If the document is stamped but not yet signed, NeSL might not provide the stamped file by default. In such cases, clients may need to enable this setting with NeSL for retrieval of the stamped document. **Combined limit:** Each document allows a maximum of 50 calls across this parameter and the dashboard's **Refresh** and **Retry** actions. Once exhausted, further requests with `refreshNeslDocument=true` for that document will return without refreshed data. | — | | `cc` | query | No | boolean | Pass `true` to receive an array containing details - name, email, notification types, and more configured for a CC invitees in the document. | — | | `coordinatePicker` | query | No | boolean | Pass `true` to receive the coordinate picker URL and webhook configured in this document. | — | | `invitations_inviteeConfigs` | query | No | boolean | Pass `true` to receive invitee-level configurations associated with each invitation. | — | | `invitations_inviteeConfigs_retry` | query | No | boolean | Pass `true` to receive the number of retry attempts configured for the signer. Only applicable to Aadhaar eSign. > **Note:** Requires `invitations_inviteeConfigs=true`. | — | | `invitations_inviteeConfigs_fixedName` | query | No | boolean | Pass `true` to receive whether the invitee is allowed to edit their name during the signing journey. > **Note:** Requires `invitations_inviteeConfigs=true`. | — | | `invitations_inviteeConfigs_noName` | query | No | boolean | Pass `true` to receive whether the invitee name will appear in the signature appearance. > **Note:** Requires `invitations_inviteeConfigs=true`. | — | | `invitations_inviteeConfigs_supportingDocument` | query | No | boolean | Pass `true` to receive the supporting document requirement configured for the invitee. > **Note:** Requires `invitations_inviteeConfigs=true`. | — | | `invitations_inviteeConfigs_viewSupportingDocument` | query | No | boolean | Pass `true` to receive the view supporting document configuration for the invitee. > **Note:** Requires `invitations_inviteeConfigs=true`. | — | | `invitations_inviteeConfigs_organizationConfig` | query | No | boolean | Pass `true` to receive the organization seal settings configured for this invitation. The organization name appears in the signature box, and the chosen seal forms a digital rubber stamp around it. > **Note:** Requires `invitations_inviteeConfigs=true`. | — | | `invitations_inviteeConfigs_security` | query | No | boolean | Pass `true` to receive the status of all security modules configured for each invitee. > **Note:** Requires `invitations_inviteeConfigs=true`. | — | | `invitations_inviteeConfigs_security_gpsConfig` | query | No | boolean | Pass `true` to receive the GPS configuration for the invitee. > **Note:** Requires `invitations_inviteeConfigs=true` and `invitations_inviteeConfigs_security=true`. | — | | `invitations_inviteeConfigs_security_faceMatch` | query | No | boolean | Pass `true` to receive the Face Match security module configuration for the invitee. > **Note:** Requires `invitations_inviteeConfigs=true` and `invitations_inviteeConfigs_security=true`. | — | | `invitations_inviteeConfigs_security_smartUserLiveliness` | query | No | boolean | Pass `true` to receive the Smart User Liveliness configuration for the invitee. This only reflects the configuration at the time the invitation was created or edited, and does not capture any admin-level changes. > **Note:** Requires `invitations_inviteeConfigs=true` and `invitations_inviteeConfigs_security=true`. | — | | `invitations_inviteeConfigs_eSignPriorityConfig` | query | No | boolean | Pass `true` to receive the eSign priority configuration for the invitee. > **Note:** Requires `invitations_inviteeConfigs=true`. | — | | `invitations_inviteeConfigs_eSignPriorityConfig_orderLevelRetryCount` | query | No | boolean | Pass `true` to receive the order-level retry count configured for the invitee. > **Note:** Requires `invitations_inviteeConfigs=true` and `invitations_inviteeConfigs_eSignPriorityConfig=true`. | — | | `invitations_inviteeConfigs_customURL` | query | No | boolean | Pass `true` to receive the custom URL configuration for each invitee. > **Note:** Requires `invitations_inviteeConfigs=true`. | — | | `invitations_inviteeConfigs_customConsent` | query | No | boolean | Pass `true` to receive the custom consent content configured for the invitee. Custom consent is an additional configurable consent the signer must accept before proceeding to sign. > **Note:** Requires `invitations_inviteeConfigs=true`. | — | | `invitations_inviteeConfigs_enableRejectDocument` | query | No | boolean | Pass `true` to receive whether the signer is allowed to reject the invitation during the signing journey. > **Note:** Requires `invitations_inviteeConfigs=true`. | — | | `invitations_inviteeConfigs_enableRejectMessage` | query | No | boolean | Pass `true` to receive whether the signer is required to provide a message when rejecting the invitation. > **Note:** Requires `invitations_inviteeConfigs=true`. | — | | `invitations_inviteeConfigs_languageDetails` | query | No | boolean | Pass `true` to receive the language configuration details for the signer. > **Note:** Requires `invitations_inviteeConfigs=true`. | — | | `invitations_inviteeConfigs_paymentDetails` | query | No | boolean | Pass `true` to receive the payment collection details configured for the invitee. > **Note:** Requires `invitations_inviteeConfigs=true`. | — | | `invitations_inviteeConfigs_maskContactDetails` | query | No | boolean | Pass `true` to receive whether Contact Details Masking is enabled for the invitee. > **Note:** Requires `invitations_inviteeConfigs=true`. | — | | `invitations_recordReviewerDetails` | query | No | boolean | Pass `true` to receive whether "Record reviewer details" is activated for each invitee in the audit trail. **Note:** This parameter works independently — no parent parameter is required. | — | | `invitations_inviteeGroup` | query | No | boolean | Pass `true` to receive invitee group details. An invitee group is a single invite consisting of multiple signers where a configurable subset (e.g. 2 out of 5) must sign for the invite to be considered complete. | — | | `invitations_inviteeGroup_name` | query | No | boolean | Pass `true` to receive the invitee group name. > **Note:** Requires `invitations_inviteeGroup=true`. | — | | `invitations_inviteeGroup_completionThreshold` | query | No | boolean | Pass `true` to receive the group completion threshold — the number of signatures required in the group invite for it to be considered complete. > **Note:** Requires `invitations_inviteeGroup=true`. | — | | `invitations_inviteeGroup_size` | query | No | boolean | Pass `true` to receive the total number of invitees in the group invite. > **Note:** Requires `invitations_inviteeGroup=true`. | — | | `invitations_inviteeGroup_completed` | query | No | boolean | Pass `true` to receive whether the group signing has been completed. > **Note:** Requires `invitations_inviteeGroup=true`. | — | | `invitations_signatureOptions` | query | No | boolean | Pass `true` to receive the signature options allowed for each invitee. | — | | `invitations_signatureOptions_quickSign` | query | No | boolean | Pass `true` to receive the signature options allowed for Quick Sign. > **Note:** Requires `invitations_signatureOptions=true`. | — | | `invitations_signatureOptions_visualSign` | query | No | boolean | Pass `true` to receive the signature options allowed for Visual Sign. > **Note:** Requires `invitations_signatureOptions=true`. | — | | `invitations_signatureOptionsUsed` | query | No | boolean | Pass `true` to receive the specific signature sub-type used by the invitee during signing. | — | | `invitations_neslInvitationDetails` | query | No | boolean | Pass `true` to receive NeSL invitation details for each invitee. | — | | `invitations_neslInvitationDetails_participantDetails` | query | No | boolean | Pass `true` to receive the participant details of the NeSL invitation. > **Note:** Requires `invitations_neslInvitationDetails=true`. | — | | `invitations_neslInvitationDetails_participantDetails_isIndividual` | query | No | boolean | Pass `true` to receive whether the NeSL participant is an individual. > **Note:** Requires `invitations_neslInvitationDetails_participantDetails=true`. | — | | `invitations_neslInvitationDetails_participantDetails_signatoryGender` | query | No | boolean | Pass `true` to receive the NeSL signatory's gender. > **Note:** Requires `invitations_neslInvitationDetails_participantDetails=true`. | — | | `invitations_neslInvitationDetails_participantDetails_businessUnit` | query | No | boolean | Pass `true` to receive the NeSL participant's business unit. > **Note:** Requires `invitations_neslInvitationDetails_participantDetails=true`. | — | | `invitations_invitationStatus_failureReason` | query | No | boolean | Pass `true` to receive the failure or status reason for the invitation. | — | | `invitations_invitationStatus_rejectionMessage` | query | No | boolean | Pass `true` to receive the reason provided by the approver for rejecting the invitation. | — | | `invitations_invitationStatus_signRejectionMessage` | query | No | boolean | Pass `true` to receive the reason provided by the signer for rejecting the invitation. | — | | `invitations_certificateData` | query | No | boolean | Pass `true` to receive the signing certificate data (excluding photoHash, uid, and serialNumber, which require their own sub-parameters). | — | | `invitations_certificateData_photoHash` | query | No | boolean | Pass `true` to receive the photoHash from the signing certificate. > **Note:** Requires `invitations_certificateData=true`. | — | | `invitations_certificateData_uid` | query | No | boolean | Pass `true` to receive the UID from the signing certificate. > **Note:** Requires `invitations_certificateData=true`. | — | | `invitations_certificateData_serialNumber` | query | No | boolean | Pass `true` to receive the serial number from the signing certificate. > **Note:** Requires `invitations_certificateData=true`. | — | | `invitations_verificationRequest` | query | No | boolean | Pass `true` to receive the verification configuration for each invitee — which certificate parameters have been activated for verification. Only applicable to Aadhaar eSign, Offline Sign (Cloud DSC), DSC, and NeSL. | — | | `invitations_verificationResponse` | query | No | boolean | Pass `true` to receive the results of certificate verification — the actual match outcomes of the configured input values against the signer's certificate data. | — | | `invitations_espResponse` | query | No | boolean | Pass `true` to include transaction status and error details as provided by ESP for a signer. These details are available for up to 2 days from the current date. | — | | `invitations_verificationResponse_smartNameAI` | query | No | boolean | Pass `true` to receive whether Smart Name AI was enabled during verification. > **Note:** Requires `invitations_verificationResponse=true`. | — | | `invitations_verificationResponse_faceMatch` | query | No | boolean | Pass `true` to receive the Face Match verification results for the invitee. > **Note:** Requires `invitations_verificationResponse=true`. | — | | `invitations_verificationResponse_smartUserLiveliness` | query | No | boolean | Pass `true` to receive Smart User Liveliness verification results. > **Note:** Requires `invitations_verificationResponse=true`. | — | | `invitations_verificationResponse_neslVerficationResponse` | query | No | boolean | Pass `true` to receive the NeSL invitee's verification results (Name, Gender, and Year of Birth). > **Note:** Requires `invitations_verificationResponse=true`. | — | | `invitations_supportingDocuments` | query | No | boolean | Pass `true` to receive the supporting documents requested from the signer. | — | | `invitations_requiresApproverOtp` | query | No | boolean | Pass `true` to receive whether the non-OTP approver flow is activated for the invitee. | — | | `invitations_signatureSubOptionUsed` | query | No | boolean | Pass `true` to receive the Signature subtype used by the invitee to sign the document. | — | --- ## Responses ### 200 — Response Data | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `status` | integer | No | - `1` — success - `0` — failure | — | | `messages` | array\ | No | See **Message** below. | — | | `data` | object | No | See **data** below. | — | #### Message Message object containing a machine-readable code and a human-readable description. Used for success confirmations, errors, and warnings. | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `code` | string | No | Response message code. | `simpleWorkFlow.success` | | `message` | string | No | Human-readable success or error message. | `Invitations sent successfully.` | #### data | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `file` | string | No | CDN URL of the signed document PDF. Valid for only **15 seconds** — intended for server-level download only. Returns `null` if the `file` parameter is not `true` in the API call. **Download method:** `curl -output ` | — | | `auditTrail` | string | No | CDN URL of the audit trail PDF. Valid for only **15 seconds** — intended for server-level download only. Returns `null` if the document is not completed or if the `auditTrail` parameter is not enabled in the API call. **Download method:** `curl -output ` | — | | `document` | DocumentDetails3_1ResponseObject | No | See **DocumentDetails3_1ResponseObject** below. | — | | `sftp` | SftpDetails3_1ResponseObject | No | See **SftpDetails3_1ResponseObject** below. | — | | `workflow` | WorkflowDetails3_1ResponseObject | No | See **WorkflowDetails3_1ResponseObject** below. | — | | `template` | TemplateDetails3_1ResponseObject | No | See **TemplateDetails3_1ResponseObject** below. | — | | `account` | AccountDetails3_1ResponseObject | No | See **AccountDetails3_1ResponseObject** below. | — | | `sender` | SenderDetails3_1ResponseObject | No | See **SenderDetails3_1ResponseObject** below. | — | | `folders` | array\ | No | Array containing the full hierarchy of folders. The last child folder appears as the first element of the array, with parent folders following. See **FolderArrayResponseObject** below. | — | | `stampDetails` | StampDetails3_1ResponseObject | No | See **StampDetails3_1ResponseObject** below. | — | | `referenceAttachments` | array\ | No | Array of reference attachments uploaded by the sender of the document, visible to invitees during the signing journey. See **AttachmentsArrayResponseObjectWithURL** below. | — | | `neslDocumentDetails` | NeslDetails3_1ResponseObject | No | See **NeslDetails3_1ResponseObject** below. | — | | `cc` | array\ | No | See **CCArrayResponseObject** below. | — | | `coordinatePicker` | CoordinatePickerDetails3_1ResponseObject | No | See **CoordinatePickerDetails3_1ResponseObject** below. | — | | `invitations` | array\ | No | Array containing details of all invitees (signers, reviewers, coordinate pickers) associated with this document. See **InvitationsArray3_1ResponseObject** below. | — | ##### DocumentDetails3_1ResponseObject | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `id` | string | No | Unique Document ID generated by Leegality for every document. | — | | `name` | string | No | Document name as configured during creation. | — | | `irn` | string | No | Internal Reference Number (IRN) assigned to the document during creation. | — | | `status` | string | No | Current status of the document. - `DRAFT` — Document created but not yet sent for signing - `SENT` — Document sent for signing, signing in progress - `COMPLETED` — All required signers have signed the document | — | | `coordinatePicker` | boolean | No | Indicates whether coordinate picker is enabled for this document. | — | | `deleted` | boolean | No | Indicates whether the document has been deleted. `true` if deleted, `false` otherwise. | — | | `creationDate` | string | No | Document creation date. - **Format:** `DD-MM-YYYY HH:MM:SS` | — | | `completionDate` | string | No | Document completion date — when all signers have completed their signatures. - **Format:** `DD-MM-YYYY HH:MM:SS` | — | | `scheduledDeletionDate` | string | No | Scheduled deletion date for the document. - **Format:** `DD-MM-YYYY HH:MM:SS` Once completed, calculated as `completionDate + retention period` configured in the "Auto Delete on Complete" settings. | — | | `customMessage` | string | No | Custom message configured for the invitation email sent to signers. Returns `null` if no custom message was configured. | — | | `deleteOnComplete` | boolean | No | Indicates whether the document is set for automatic deletion after completion. - `true` — deletion enabled - `false` — deletion not enabled | — | | `requestSigningOrder` | boolean | No | Indicates whether the signature links are activated sequentially. - `true` — sequential signing enabled; next signer receives link only after previous signer has signed - `false` — sequential signing disabled | — | | `requireSigningOrder` | boolean | No | Indicates whether signing order is strictly required. - `true` — signing order required - `false` — signing order not required | — | ##### SftpDetails3_1ResponseObject | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `sftpEnabled` | boolean | No | Indicates whether SFTP was enabled for this document. - `true` — SFTP was configured - `false` — SFTP was not configured | — | | `profileId` | string | No | SFTP Profile ID of the server where the completed document and audit trail will be sent. Returns `null` if SFTP is not configured. | — | ##### WorkflowDetails3_1ResponseObject | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `id` | string | No | Unique Workflow ID through which the document was created. | — | | `name` | string | No | Workflow name for the corresponding Workflow ID. | — | | `type` | string | No | Workflow type. - `Pdf` — PDF-based workflow - `Template` - Template-based workflow | — | | `subtype` | string | No | Workflow sub-type. - `Single PDF` — No additional PDFs are appended to the template - `Multiple PDF` — Additional PDFs are appended to the template - `null` — Workflow not used to send this document | — | ##### TemplateDetails3_1ResponseObject | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `id` | string | No | Unique Template ID. Returns `null` if no template was used. This response may be sent in case of a deleted document, subject to availability. | — | | `name` | string | No | Template name for the corresponding Template ID. | — | ##### AccountDetails3_1ResponseObject | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `id` | string | No | Unique Account ID generated by Leegality. This response may be sent in case of a deleted document, subject to availability. | — | | `name` | string | No | Organisation name configured. | — | | `label` | string | No | Department name configured in the Leegality dashboard. | — | | `brandName` | string | No | Brand name configured in the Leegality dashboard. | — | ##### SenderDetails3_1ResponseObject | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `name` | string | No | Name of the user who sent/created the document. | — | | `username` | string | No | Username (email or phone number) of the sender. | — | ##### FolderArrayResponseObject | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `id` | string | No | Unique Folder ID. Returns `null` if the document is not saved in any folder. | — | | `name` | string | No | Folder name. Returns `null` if the document is not saved in any folder. | — | ##### StampDetails3_1ResponseObject | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `groupName` | string | No | Name of the stamp group from which the stamp paper was procured. | — | | `groupNumber` | string | No | Number of the stamp group. | — | | `stampValue` | string | No | Total Stamp value (denomination) attached to this document, as a numeric string. | — | | `maximumValuePermitted` | string | No | Maximum stamp value permitted for this stamp group, as a numeric string. | — | | `state` | string | No | Indian state associated with the stamp group (e.g., Delhi, Maharashtra, Karnataka). | — | | `stamps` | array\ | No | See **StampArray3_1ResponseObject** below. | — | | `multipleStampSeriesUsed` | boolean | No | Indicates whether multiple stamp series were used for this document. `true` if multiple series were used, `false` otherwise. | — | ###### StampArray3_1ResponseObject Array of stamps containing details of each stamp attached to the document. | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `series` | string | No | Stamp series number | `03` | | `amount` | string | No | Denomination/value of the stamp paper attached to the document. - **Format:** Numeric string (e.g., `"53.0"`) | — | | `serialNumber` | string | No | Serial number affixed on the stamp paper by the issuing authority. | — | | `associatedDocumentId` | string | No | Document ID physically printed on the stamp paper. This links the stamp paper to the document. | — | ##### AttachmentsArrayResponseObjectWithURL | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `file` | string | No | CDN URL for the reference attachment file. Valid for only **15 seconds**. Use this URL for downloading at the server level only, not for previewing in the host application. **Download method:** `curl -output ` | — | | `name` | string | No | Name of the reference attachment file. | — | | `type` | string | No | MIME type of the reference attachment file. **Possible values:** `application/pdf`, `image/png`, `image/jpg`, `image/jpeg` | — | ##### NeslDetails3_1ResponseObject | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `transactionId` | string | No | Transaction ID received during NESL transaction. | — | | `responseCode` | string | No | Response Code sent by NeSL. | — | | `responseMessage` | string | No | Response message for the code received. | — | | `isRetryAllowed` | string | No | Indicates whether retry is allowed for this NeSL document. - `true` — retry is allowed; call the Retry NeSL API - `false` — retry is not allowed | — | | `loanDetails` | NeslLoanDetails3_1ResponseObject | No | See **NeslLoanDetails3_1ResponseObject** below. | — | | `securityDetails` | array\ | No | See **NeslSecurityDetails3_1ResponseObject** below. | — | | `stampDetails` | NeslStampDetails3_1ResponseObject | No | See **NeslStampDetails3_1ResponseObject** below. | — | | `partyDetails` | NeslPartyDetails3_1ResponseObject | No | See **NeslPartyDetails3_1ResponseObject** below. | — | | `neslEstampStatus` | string | No | - `SUCCESS` — Stamping is completed at NeSL - `PENDING` — Stamping is not yet completed at NeSL | — | | `neslEstampCertificates` | array\ | No | A list of the Stamp ID(s) that have been stamped by NeSL. | — | ###### NeslLoanDetails3_1ResponseObject | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `loanNumber` | string | No | The loan number associated with the debt. | — | | `sanctionNumber` | string | No | The sanction number associated with the debt. | — | | `registrationType` | string | No | Type of debt (Individual Loan or Non-Individual Loan). | — | | `state` | string | No | The state in which stamp duty is being paid. | — | | `branchName` | string | No | The name of the branch granting the loan. | — | | `branchAddress` | string | No | The address of the branch granting the loan. | — | | `dateOfSanction` | string | No | The date on which the loan was sanctioned as per the lender's CBS. | — | | `emiAmount` | string | No | Interest installment amount payable on the loan. | — | | `rateOfInterest` | string | No | Rate of Interest on the loan. | — | | `sanctionAmount` | string | No | The amount sanctioned by the financial creditor. | — | | `tenure` | string | No | The tenure of the loan. | — | | `typeOfDebt` | string | No | The type of loan (financial debt or operational debt). | — | | `accountClosedFlag` | string | No | Whether the account is closed (yes, no, or assigned debt). | — | | `fundType` | string | No | Whether the credit facility is funded or non funded. | — | | `sanctionCurrency` | string | No | The currency in which the loan is denominated (INR or USD). | — | | `creditSubtype` | string | No | Whether the financial debt is created pursuant to a credit facility or the purchase of a property. | — | | `facilityName` | string | No | The name of the loan facility. | — | | `amountOverdue` | string | No | The amount overdue on the loan. | — | | `otherChargeAmount` | string | No | Any other charges (if applicable). | — | | `debtStartDate` | string | No | The date on which the financial debt started. | — | | `interestAmount` | string | No | The amount of interest. | — | | `oldDebtRefNo` | string | No | The old debt reference number (applicable in case there is a change in the debt reference number). | — | | `principalOutstanding` | string | No | The outstanding principal amount. | — | | `loanRemark` | string | No | Loan remarks (if any). | — | | `totalOutstandingAmount` | string | No | Total outstanding amount. | — | | `creditorBusinessUnit` | string | No | The business unit of the creditor providing the debt (such as SME, Retail etc). | — | | `drawingPower` | string | No | The drawing power of the loan. | — | | `daysPastDue` | string | No | The number of days past due date. | — | | `event` | string | No | The type of eBG event. **Note:** Valid values for eBG document creation: `INVOCATION`, `AMENDMENT`, `CANCELLATION`, `RENEWAL`, `CLOSURE`, `PARTIAL_INVOCATION`. `EXTEND_OR_PAY` is not valid for document creation but may be received as a notification event type. Allowed: `INVOCATION`, `AMENDMENT`, `CANCELLATION`, `RENEWAL`, `CLOSURE`, `PARTIAL_INVOCATION`. | — | | `expiryDate` | string | No | The expiry date of eBG | — | | `claimExpiryDate` | string | No | The claim expiry date of eBG | — | | `currencyOfDebt` | string | No | The currency of the debt | — | ###### NeslSecurityDetails3_1ResponseObject | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `securityDescription` | string | No | Description of security. | — | | `assetsType` | string | No | Type of asset forming security (Movable, Immovable, Intangible, Not Classified). | — | | `chargeType` | string | No | Type of charge created (Mortgage, Hypothecation, Charge, Assignment, Pledge, Lien, Negative Lien, Guarantee, Others, Not Classified). | — | | `assetId` | string | No | Asset ID of the Security (used internally by the lender). | — | | `doc` | string | No | Date of creation of security. | — | | `dov` | string | No | Date of valuation of security. | — | | `cersaiId` | string | No | CERSAI ID of security created. | — | | `rocChargeId` | string | No | ROC ID for security created. | — | | `securityValue` | string | No | Value of security. | — | ###### NeslStampDetails3_1ResponseObject | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `firstParty` | string | No | The name of the first party (for the stamp paper). | — | | `secondParty` | string | No | The name of the second party (for the stamp paper). | — | | `stampDutyAmount` | string | No | The stamp duty amount. | — | | `considerationPrice` | string | No | The consideration price for the purposes of stamp duty. | — | | `descriptionOfDocument` | string | No | The description of the document for the purposes of stamp duty. | — | | `stampDutyPaidBy` | string | No | The name of the party paying the stamp duty. `firstParty` or `secondParty` | — | | `articleCode` | string | No | Article code used in the document. | — | | `articleSubCode` | string | No | Article Sub-code used in the document. | — | | `firstPartyPin` | string | No | The pin of the first party (for the stamp paper). | — | | `secondPartyPin` | string | No | The pin of the second party (for the stamp paper). | — | | `firstPartyOVDType` | string | No | The OVD Type of the first party (for the stamp paper). | — | | `firstPartyOVDValue` | string | No | The OVD Value of the first party (for the stamp paper). | — | | `secondPartyOVDType` | string | No | The OVD Type of the second party (for the stamp paper). | — | | `secondPartyOVDValue` | string | No | The OVD Value of the second party (for the stamp paper). | — | ###### NeslPartyDetails3_1ResponseObject | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `fullName` | string | No | Full name of the Party. | — | | `contactPersonName` | string | No | Full name of the contact person of the Party. | — | | `contactRelation` | string | No | Relation of the party to the debt (Debtor, Guarantor, Co-obligant). | — | | `emailId` | string | No | Email ID of the signer. | — | | `mobileNumber` | string | No | Mobile Number of the signer. | — | | `dob` | string | No | Date of Birth/Incorporation. | — | | `legalConstitution` | string | No | Legal constitution of the signer (Resident Individual, Private Limited, Public Limited, LLP, Proprietorship, Partnership, Entity created by Statute, Trust, HUF, Coop Society, Association of Persons, Government, Self Help Groups, Non-Resident, Foreign Company). | — | | `alternateEmailId` | string | No | Alternate email ID of the signer. | — | | `alternateMobileNumber` | string | No | Alternate mobile of the signer. | — | | `officialDocType` | string | No | Official Document Type (Pan Card, Driving License, Voter ID, Passport, Others). | — | | `officialDocId` | string | No | Official Document ID. | — | | `registeredAddress` | string | No | Registered address of the signer. | — | | `registeredPinCode` | string | No | PIN code of the registered address of the signer. | — | | `designation` | string | No | Designation of the signer (relevant in case of corporate entities). | — | | `communicationAddress` | string | No | Communication address of the signer. | — | | `communicationAddressPinCode` | string | No | PIN code of the communication address of the signer. | — | | `cin` | string | No | Corporate Identification Number (relevant in case of corporate entities). | — | | `kin` | string | No | KYC Identification Number of signer. | — | | `partyType` | string | No | Type of Party (Indian entity/ Resident Individual/ Foreign Entity/ NRI/Foreign Individual. | — | | `isIndividual` | string | No | If the party is individual or not. **Note:** Valid values are `YES` or `NO` (case-insensitive, full words). Allowed: `YES`, `NO`. | — | | `signatoryGender` | string | No | Gender of the signatory | — | | `businessUnit` | string | No | Business Unit | — | ##### CCArrayResponseObject | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `id` | string | No | Unique identifier for this CC recipient. | — | | `name` | string | No | Name of the CC recipient. | — | | `email` | string | No | Email address of the CC recipient. | — | | `invitationNotification` | boolean | No | Indicates whether invitation notifications are enabled for this CC. | — | | `signingNotification` | boolean | No | Indicates whether signing notifications (sent when a signer signs) are enabled for this CC. | — | | `completionNotification` | boolean | No | Indicates whether completion notifications (sent when all signers have signed) are enabled for this CC. | — | | `failureNotification` | boolean | No | Indicates whether failure notifications are enabled for this CC. | — | | `sendInvitationUrl` | boolean | No | Indicates whether the signing invitation URL is shared with this CC. | — | | `shareDocAuditTrail` | boolean | No | Indicates whether the audit trail are shared with this CC. | — | | `enforceOneFactorAuthentication` | boolean | No | Indicates whether one-factor authentication (OTP) is required for this CC to access the document. | — | | `recordAuditTrail` | boolean | No | Indicates whether this CC's notification events are recorded in the audit trail. | — | ##### CoordinatePickerDetails3_1ResponseObject | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `coordinatePickerUrl` | string | No | URL for the coordinate picker to set eSign coordinates on the document. | — | | `coordinatePickerWebhook` | string | No | Webhook URL on which a response is sent when eSign coordinates are set by the coordinate picker. | — | ##### InvitationsArray3_1ResponseObject | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `name` | string | No | Name of the invitee (signer/reviewer). | — | | `email` | string | No | Email address of the invitee. | — | | `phone` | string | No | Phone number of the invitee (10-digit format without country code). | — | | `inviteeType` | string | No | Type of the invitee. - `APPROVER` — A reviewer who reviews and approves the document before signers can proceed - `SIGNER` — A signer who applies a signature to the document | — | | `inviteeConfigs` | InviteeConfigDetails3_1ResponseObject | No | See **InviteeConfigDetails3_1ResponseObject** below. | — | | `recordReviewerDetails` | boolean | No | Indicates whether the reviewer's details are captured in the audit trail. Applicable only for reviewer invitee type. | — | | `inviteeGroup` | InviteeGroupDetails3_1ResponseObject | No | See **InviteeGroupDetails3_1ResponseObject** below. | — | | `invitationUrl` | string | No | Signing/reviewing URL generated for this invitee. The invitee uses this URL to access and sign/review the document. | — | | `allowedSignatures` | array\ | No | List of signature types allowed for this invitee. - **Possible values:** `Virtual Sign`, `Visual Sign`, `Quick Sign`, `Aadhaar eSign`, `DSC Token`, `NeSL`, `Doc Signer` | — | | `usedSignatureType` | string | No | The signature type actually used by the invitee to sign. Returns `null` if the invitee has not yet signed. - **Possible values:** `Virtual Sign`, `Visual Sign`, `Quick Sign`, `Aadhaar eSign`, `DSC Token`, `Nesl_eSign`, `Doc Signer` | — | | `signatureSubOptionUsed` | string | No | The signature sub-type actually used by the invitee to sign. Returns `null` if the invitee has not yet signed. Possible values are - **NeSL eSign:** `OTP`, `BIO`, `FACE`, `IRIS`, `ETOKEN` | — | | `signatureOptions` | InviteeSignatureOptionDetails3_1ResponseObject | No | See **InviteeSignatureOptionDetails3_1ResponseObject** below. | — | | `signatureOptionUsed` | string | No | The specific signature option (sub-type) used under the selected signature type. Returns `null` if not yet signed. - **Aadhaar eSign:** `One Time Password`, `Bio-Metric`, `Iris`, `Face` - **Virtual Sign:** `Allow Draw`, `Allow Choose`, `Affix Fingerprint` - **Visual Sign:** `Allow Draw`, `Allow Choose`, `Physical Signature` - **Quick Sign:** `Allow Draw`, `Allow Choose`, `Affix Fingerprint`, `Physical Signature` | — | | `neslInvitationDetails` | InviteeNESLParticipantDetails3_1ResponseObject | No | See **InviteeNESLParticipantDetails3_1ResponseObject** below. | — | | `offlineSignDetails` | InviteeOfflineSignDetails3_1ResponseObject | No | See **InviteeOfflineSignDetails3_1ResponseObject** below. | — | | `invitationStatus` | InviteeStatusDetails3_1ResponseObject | No | See **InviteeStatusDetails3_1ResponseObject** below. | — | | `certificateData` | InviteeCertificateDetails3_1ResponseObject | No | See **InviteeCertificateDetails3_1ResponseObject** below. | — | | `verificationRequest` | InviteeVerificationRequestDetails3_1ResponseObject | No | See **InviteeVerificationRequestDetails3_1ResponseObject** below. | — | | `verificationResponse` | object | No | Verification results for this invitee. Returned only when the `invitations_verificationResponse` query parameter is set to `true`. Contains the outcome of each configured verification check (name, pincode, state, title, YOB, gender) as well as face match and smart user liveliness results. See **verificationResponse** below. | — | | `supportingDocuments` | array\ | No | Supporting documents uploaded by the invitee during the signing journey. > **Note:** The response field name is `attachments` (not `supportingDocuments`). See **AttachmentsArrayResponseObject** below. | — | | `espResponse` | array\ | No | ESP transaction details for this invitation. Present only when `invitations_espResponse=true`. Each entry represents one ESP visit by the signer — for example, if the signer visits two ESP pages, there are two entries. ESP logs are available for up to 2 days from the current date and older logs are not available. See **espResponse** below. | — | ###### InviteeConfigDetails3_1ResponseObject | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `emailNotification` | boolean | No | Indicates whether email notifications are enabled for this invitee. | — | | `phoneNotification` | boolean | No | Indicates whether phone/SMS notifications are enabled for this invitee. | — | | `whatsappEnabled` | boolean | No | Indicates whether WhatsApp notifications for completion are enabled for this invitee. | — | | `whatsAppNotification` | boolean | No | Indicates whether WhatsApp notifications for eSigning invitation, reminders, and all others are enabled. Only applicable if `whatsappEnabled` is `true`. | — | | `retry` | integer | No | Number of retry attempts configured for this invitee (applicable only for Aadhaar eSign). This is the number of additional attempts allowed after the first attempt. | — | | `fixedName` | boolean | No | If `true`, the invitee will NOT be able to edit their name in the signing journey. If `false`, the invitee can edit their name. | — | | `noName` | boolean | No | If `true`, the invitee's name will not appear in the signature appearance. | — | | `supportingDocument` | array\ | No | Array of supporting document names requested from the invitee during the signing journey. | — | | `viewSupportingDocument` | boolean | No | If `true`, the invitee can view the supporting documents uploaded by all other invitees in the signing journey. | — | | `organizationConfig` | InviteeOrganisationConfigDetails3_1ArrayResponseObject | No | See **InviteeOrganisationConfigDetails3_1ArrayResponseObject** below. | — | | `security` | InviteeSecurityDetails3_1ArrayResponseObject | No | See **InviteeSecurityDetails3_1ArrayResponseObject** below. | — | | `eSignPriority` | InviteeESignPriorityDetails3_1ArrayResponseObject | No | See **InviteeESignPriorityDetails3_1ArrayResponseObject** below. | — | | `customURL` | InviteeCustomURLDetails3_1ArrayResponseObject | No | See **InviteeCustomURLDetails3_1ArrayResponseObject** below. | — | | `customConsent` | string | No | Custom consent content displayed to the invitee during the signing journey. Returns `null` if no custom consent is configured. | — | | `enableRejectDocument` | boolean | No | If `true`, the signer is allowed to reject this invitation in the signing journey. | — | | `enableRejectMessage` | boolean | No | If `true`, the signer is required to provide a message when rejecting the invitation. | — | | `maskContactDetails` | boolean | No | If `true`, the invitee is restricted from viewing the contact details of other invitees during and after the signing journey. If `false`, the invitee can view other invitees' contact details. | — | | `languageDetails` | object | No | Language configuration for the invitee's signing journey. See **languageDetails** below. | — | | `paymentDetails` | InviteePaymentDetails | No | See **InviteePaymentDetails** below. | — | ###### InviteeOrganisationConfigDetails3_1ArrayResponseObject | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `nameRequired` | boolean | No | Indicates whether an organization name is required. The organization name appears on the rubber seal and signature appearance. | — | | `fixedName` | boolean | No | If `true`, the invitee cannot edit the organization name that was pre-set. If `false`, the invitee can modify it. | — | | `name` | string | No | Organization name. If `fixedName` is `false`, this is the name the invitee entered during the signing journey. | — | | `requireSeal` | boolean | No | Indicates whether a rubber seal is required for this invitee. | — | | `sealType` | string | No | Type of rubber seal configured for this invitee. - **Possible values:** `Authorized signatory seal`, `Director Seal`, `Custom Seal` | — | ###### InviteeSecurityDetails3_1ArrayResponseObject | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `enforceAuthentication` | boolean | No | Indicates whether OTP verification is required before the invitee can access the document. | — | | `twoFactorAuthentication` | boolean | No | Indicates whether two-factor authentication (both Email and Phone OTP) is enabled for this invitee. | — | | `sendDocumentRawUrl` | boolean | No | Indicates whether the raw document PDF URL is sent along with OTP emails/SMS messages. | — | | `captureLocation` | boolean | No | Indicates whether geolocation capture is enabled during the signing journey. | — | | `capturePhoto` | boolean | No | Indicates whether face/photo capture is enabled during the signing journey. | — | | `gpsConfig` | gpsConfigResponse | No | GPS location restriction and accuracy configuration set by the sender for this invitee. See **gpsConfigResponse** below. | — | | `faceMatch` | faceMatch | No | See **faceMatch** below. | — | | `userLiveliness` | boolean | No | Indicates whether User Liveliness (Live OTP verification) is enabled. | — | | `smartUserLiveliness` | smartUserLiveliness | No | See **smartUserLiveliness** below. | — | ###### gpsConfigResponse GPS location restriction and accuracy configuration set by the sender for this invitee. | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `applyLocationRestriction` | boolean | No | `true` indicates location-based signing restriction is enabled for this invitee. The invitee can only sign from within the area defined by `allowedLatitude`, `allowedLongitude`, and `permissibleRadius`. | — | | `allowedLatitude` | number | No | Latitude of the permitted signing location configured by the sender. | `28.50950813247034` | | `allowedLongitude` | number | No | Longitude of the permitted signing location configured by the sender. | `77.08920288142689` | | `permissibleRadius` | integer | No | Radius (in meters) around the permitted location within which the invitee is allowed to sign. | `5000` | | `restrictToIndia` | boolean | No | Indicates whether 'Restrict to India' was enabled in the workflow. If enabled, the signer must be present in India to sign the document. | `true` | | `applyLocationAccuracy` | boolean | No | `true` indicates GPS accuracy validation is enabled. The invitee's device GPS accuracy must meet the `accuracyThreshold` to proceed with signing. | — | | `accuracyThreshold` | integer | No | Maximum allowed GPS accuracy in meters configured by the sender. Signing is blocked if the invitee's device accuracy exceeds this value. | `10000` | ###### faceMatch | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `faceMatchEnabled` | boolean | No | Indicates whether Face Match is enabled (true) or disabled (false). | — | | `faceMatchRetriesConfigured` | integer | No | Number of additional retry attempts configured beyond the first attempt. For example, a value of `3` means the invitee gets 1 original attempt + 3 retries = 4 total face match attempts. Returns `null` if face match is not enabled. | — | ###### smartUserLiveliness | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `smartUserLivelinessEnabled` | boolean | No | Indicates whether Smart User Liveliness is enabled for this invitee. `true` if enabled, `false` if not. Returns `false` when not configured. | — | | `smartUserLivelinessRetriesConfigured` | integer | No | Number of additional retry attempts configured beyond the first attempt for Smart User Liveliness. Returns `null` if Smart User Liveliness is not enabled. | — | ###### InviteeESignPriorityDetails3_1ArrayResponseObject | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `eSignPriorityEnabled` | boolean | No | Priority sequence is enabled for eSign types like Aadhaar | — | | `eSignPriorityConfig` | array\ | No | Configurations like retry attempt and order for eSign types (e.g., AADHAAR) and subtypes (e.g., OTP, BIO, IRIS) See **InviteeESignPriorityESignPriorityConfig3_1ArrayResponseObject** below. | — | ###### InviteeESignPriorityESignPriorityConfig3_1ArrayResponseObject | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `signatureType` | string | No | Type eSign selected for the invitee like AADHAAR | — | | `eSignSubType` | string | No | Subtype of eSign selected for the invitee. - **Possible values:** `OTP`, `BIO`, `IRIS`, `FACE` | — | | `retryAttempts` | integer | No | Number of retry attempts assigned to this eSign subtype before the nextin order eSign subtype is shown to the signer | — | | `eSignOrder` | integer | No | The sequence in which this eSign subtype will appear in the signing journey | — | ###### InviteeCustomURLDetails3_1ArrayResponseObject | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `webhookURL` | string | No | The configured webhook URL for this invitee. Leegality sends a POST request to this URL after the invitee successfully signs. Returns `null` if no webhook URL is configured. | — | | `redirectURL` | string | No | URL where you want the user to be redirected on completion of the transaction (Not applicable if you are using our Front-end SDKs). documentId will be appended to the URL on redirection. | — | | `errorWebhookURL` | string | No | The configured error webhook URL for this invitee. Leegality sends a POST request to this URL after expiry, failure, or rejection of the signature. Returns `null` if no error webhook URL is configured for this invitee. | — | | `baseURL` | string | No | URL where you want the user to be redirected on rejection/failure of the transaction (Not applicable if you are using our Front-end SDKs). documentId will be appended to the URL on redirection. | — | | `webhookVersion` | string | No | The webhook version configured for this invitee, which determines the webhook payload format. - **Possible values:** `V2.1` (default), `V2.5` | — | ###### languageDetails Language configuration for the invitee's signing journey. | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `enableLanguage` | boolean | No | Whether language selection is enabled for this invitee. Returns `null` if not configured. | — | | `defaultLanguage` | boolean | No | Whether a default language has been set. Returns `null` if not configured. | — | | `defaultLanguageSelect` | string | No | The default language configured for this invitee's signing journey. - **Example values:** `HINDI`, `MARATHI`, `TAMIL` | — | ###### InviteePaymentDetails | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `paymentCollectionEnabled` | boolean | No | Indicates whether payment collection is enabled for this invitee. `true` if enabled, `false` if not. | — | | `paymentProfileId` | string | No | Profile ID of the selected payment profile. Refer to the Account Tab in the Leegality dashboard to see details of the payment profile. | — | | `paymentCollectionAmount` | string | No | The configured payment amount to be collected from the invitee, as a string. | — | | `paymentCollectionMessage` | string | No | Message displayed to the invitee during payment collection. Returns `null` if no message was configured. | — | | `paymentCollectStatus` | string | No | Current status of payment collection for this invitee. - **Razorpay:** `notPaid`, `Authorised`, `Captured`, `Refunded` - **Billdesk:** `notPaid`, `Completed`, `Refunded` | — | | `paymentId` | string | No | Payment transaction ID. Available when `paymentCollectStatus` is `Authorised` or `Captured` (Razorpay), or `Completed` (Billdesk). Returns `null` otherwise. | — | | `paymentEventDate` | string | No | Payment transaction date. Available when `paymentCollectStatus` is `Authorised` or `Captured` (Razorpay), or `Completed` (Billdesk). Returns `null` otherwise. | — | ###### InviteeGroupDetails3_1ResponseObject | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `id` | string | No | Unique identifier for the invitee group. | — | | `name` | string | No | Name of the invitee group. | — | | `completionThreshold` | integer | No | Number of people required to sign in the group for the group signature to be considered complete. For example, if a group has 5 members and the threshold is 3, only 3 out of 5 need to sign. Returns `null` for invitees not in a group. | — | | `completionStatus` | string | No | Completion status of the group signing process as a fraction string. - **Format:** `"signed/total"` (e.g., `"1/2"` means 1 out of 2 members have signed) | — | | `size` | integer | No | Total number of invitations/members in the group. | — | | `completed` | boolean | No | Indicates whether the group signature requirement has been met (i.e., the number of signers has reached the `completionThreshold`). | — | ###### InviteeSignatureOptionDetails3_1ResponseObject | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `aadhaar` | array\ | No | Aadhaar authentication method(s) configured for this invitee. - **Possible values:** `OTP`, `BIO`, `IRIS`, `FACE` | — | | `virtual` | array\ | No | Virtual sign type(s) configured for this invitee. - **Possible values:** `Allow Choose`, `Allow Draw`, `Affix Fingerprint` | — | | `visualSign` | array\ | No | Visual Sign type(s) configured for this invitee. Only present when `invitations_signatureOptions_visualSign` is passed as `true`. - **Possible values:** `Allow Choose`, `Allow Draw`, `Physical Signature` | — | | `quickSign` | array\ | No | Quick Sign option(s) configured for this invitee. Only present when `invitations_signatureOptions_quickSign` is passed as `true`. - **Possible values:** `Allow Choose`, `Allow Draw`, `Affix Fingerprint`, `Physical Signature` | — | ###### InviteeNESLParticipantDetails3_1ResponseObject | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `type` | string | No | NeSL participant type. - `F2F` — invitee receives sign URL from Leegality via mail/SMS - `Non F2F` — sign URL is sent directly by NeSL | — | | `participantDetails` | NeslparticipantDetails3_1ResponseObject | No | See **NeslparticipantDetails3_1ResponseObject** below. | — | ###### NeslparticipantDetails3_1ResponseObject | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `fullName` | string | No | Full name of the Party. | — | | `contactPersonName` | string | No | Full name of the contact person of the Party. | — | | `contactRelation` | string | No | Relation of the party to the debt (Debtor, Guarantor, Co-obligant). **Note:** For EBG, only `DEBTOR` (first participant) and `BENEFICIARY` are accepted. | — | | `emailId` | string | No | Email ID of the signer. | — | | `mobileNumber` | string | No | Mobile Number of the signer. | — | | `dob` | string | No | Date of Birth/Incorporation. | — | | `legalConstitution` | string | No | Legal constitution of the signer (Resident Individual, Private Limited, Public Limited, LLP, Proprietorship, Partnership, Entity created by Statute, Trust, HUF, Coop Society, Association of Persons, Government, Self Help Groups, Non-Resident, Foreign Company). | — | | `alternateEmailId` | string | No | Alternate email ID of the signer. | — | | `alternateMobileNumber` | string | No | Alternate mobile of the signer. | — | | `officialDocType` | string | No | Official Document Type (Pan Card, Driving License, Voter ID, Passport, Others). | — | | `officialDocId` | string | No | Official Document ID. | — | | `registeredAddress` | string | No | Registered address of the signer. | — | | `registeredPinCode` | string | No | PIN code of the registered address of the signer. | — | | `designation` | string | No | Designation of the signer (relevant in case of corporate entities). | — | | `communicationAddress` | string | No | Communication address of the signer. | — | | `communicationAddressPinCode` | string | No | PIN code of the communication address of the signer. | — | | `cin` | string | No | Corporate Identification Number (relevant in case of corporate entities). | — | | `kin` | string | No | KYC Identification Number of signer. | — | | `partyType` | string | No | Type of Party (Indian entity/ Resident Individual/ Foreign Entity/ NRI/Foreign Individual. | — | | `isIndividual` | string | No | If the participant is individual or not. **Note:** Valid values are `YES` or `NO` (case-insensitive, full words). Required for EBG registrationType. Allowed: `YES`, `NO`. | — | | `signatoryGender` | string | No | Gender of the signatory | — | | `businessUnit` | string | No | Business Unit | — | ###### InviteeOfflineSignDetails3_1ResponseObject | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `fixSignerId` | boolean | No | Parameter to find out if signerID is fixed for the invitation. | — | | `mobileNumber` | string | No | Mobile number corresponding to the signerID fixed for the invitation. | — | | `pan` | string | No | PAN corresponding to the signerID fixed for the invitation. | — | | `signerId` | string | No | SignerID corresponding to the signerID fixed for the invitation. | — | ###### InviteeStatusDetails3_1ResponseObject | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `active` | boolean | No | Indicates it is the invitee's turn to act (sign/review). - `true` — invitee can currently access and act on the document - `false` — not the invitee's turn yet When signing order is enabled, only the current invitee(s) in the sequence will have `active=true`. > **Note:** `active` remains `true` even after the invitee has signed/approved. | — | | `signed` | boolean | No | Indicates the invitation has been signed successfully by the invitee. | — | | `reviewed` | boolean | No | Applicable only for Reviewer invitee type. Indicates the invitation has been reviewed (either approved or rejected). | — | | `approved` | boolean | No | Applicable only for Reviewer invitee type. Indicates the reviewer has approved the document. | — | | `rejected` | boolean | No | Applicable only for Signer invitee type. Indicates the signer has rejected the invitation. Resets to `false` if the invitation is re-sent and the signer subsequently signs. | — | | `expired` | boolean | No | Indicates the invitation has expired. The invitee can no longer access the signing URL. **Note:** Also set to `true` when a group signing threshold is met and this invitee was a non-signing member of the group. In that case, `failureReason` will contain `"Group Minimum Signature Completed."`. | — | | `recordApproverResponse` | boolean | No | Indicates whether the reviewer/approver's actions are recorded in the audit trail. | — | | `creationDate` | string | No | Creation date of the signing invitation. **Format:** `DD-MM-YYYY HH:MM:SS` | — | | `expiryDate` | string | No | Expiry date of the signing invitation. **Format:** `DD-MM-YYYY HH:MM:SS` If `null`, the default expiry is 45 minutes from creation. | — | | `signDate` | string | No | Date when the invitee signed the document. Returns `null` if not yet signed. **Format:** `DD-MM-YYYY HH:MM:SS` | — | | `failureReason` | string | No | Reason for failure or special status. Not limited to error scenarios — also contains informational messages. - `"Group Minimum Signature Completed."` — Group threshold was met; remaining group members' invitations closed - `"Signed but Verification Failed."` — Invitee signed but certificate verification failed - `null` — No failure or special status | — | | `rejectionMessage` | string | No | The message sent by the approver/reviewer at the time of rejecting the invitation. Returns `null` if no rejection occurred or no message was provided. | — | | `signRejectionMessage` | string | No | The message sent by the signer/invitee at the time of rejecting the invitation. Returns `null` if no rejection occurred or no message was provided. **Note:** This value persists even if the invitee later signs the document (after re-sending). The `rejected` field resets to `false` after signing, but this message remains. | — | ###### InviteeCertificateDetails3_1ResponseObject | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `name` | string | No | Name of the signer as recorded in the digital signature certificate. Returns `null` if not available. | — | | `yob` | string | No | Year of birth of the signer from the digital signature certificate. - **Format:** `YYYY` (e.g., `"1998"`) | — | | `gender` | string | No | Gender of the signer from the digital signature certificate. - `M` — Male - `F` — Female - `T` — Transgender | — | | `pincode` | string | No | PIN code of the signer from the digital signature certificate (6-digit string). Returns `null` if not available. | — | | `title` | string | No | Last 4 digits of the Aadhaar number of the signer, as recorded in the digital signature certificate. Returns `null` if not available. | — | | `state` | string | No | State of the signer from the digital signature certificate. Returns `null` if not available. | — | | `photoHash` | string | No | SHA-256 hash of the signer's photo from the digital signature certificate. - **Format:** 64-character hexadecimal string | — | | `uid` | string | No | UID from the digital signature certificate. **Note:** This field is typically `null` (masked/not returned) even after Aadhaar-based signing, due to privacy restrictions. | — | | `serialNumber` | string | No | Serial number of the digital signature certificate used for signing. Returns `null` if not available. | — | ###### InviteeVerificationRequestDetails3_1ResponseObject | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `aadhaarConfig` | InviteeAadhaarVerificationRequestDetails3_1ResponseObject | No | Verification request configuration for this invitee. These fields contain the **input values** provided when creating the document — not boolean flags. **Note:** `smartNamePercentage` is a boolean toggle (`true`/`null`). All other fields contain the actual input values to verify against (e.g., pincode string, state name, year of birth integer). See **InviteeAadhaarVerificationRequestDetails3_1ResponseObject** below. | — | | `offlineConfig` | InviteeAadhaarVerificationRequestDetails3_1ResponseObject | No | Verification request configuration for this invitee. These fields contain the **input values** provided when creating the document — not boolean flags. **Note:** `smartNamePercentage` is a boolean toggle (`true`/`null`). All other fields contain the actual input values to verify against (e.g., pincode string, state name, year of birth integer). See **InviteeAadhaarVerificationRequestDetails3_1ResponseObject** below. | — | | `dscConfig` | InviteeDSCVerificationRequestDetails3_1ResponseObject | No | See **InviteeDSCVerificationRequestDetails3_1ResponseObject** below. | — | | `neslConfig` | InviteeAadhaarVerificationRequestDetails3_1ResponseObject | No | Verification request configuration for this invitee. These fields contain the **input values** provided when creating the document — not boolean flags. **Note:** `smartNamePercentage` is a boolean toggle (`true`/`null`). All other fields contain the actual input values to verify against (e.g., pincode string, state name, year of birth integer). See **InviteeAadhaarVerificationRequestDetails3_1ResponseObject** below. | — | ###### InviteeAadhaarVerificationRequestDetails3_1ResponseObject Verification request configuration for this invitee. These fields contain the **input values** provided when creating the document — not boolean flags. **Note:** `smartNamePercentage` is a boolean toggle (`true`/`null`). All other fields contain the actual input values to verify against (e.g., pincode string, state name, year of birth integer). | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `smartNamePercentage` | boolean | No | Whether smart name percentage matching is enabled for this invitee. Returns `true` if enabled, `null` if not configured. | — | | `nameVerification` | boolean | No | Whether exact name verification is enabled for this invitee. Returns `true` if enabled, `null` if not configured. | — | | `pincodeVerification` | string | No | The pincode value to verify against the signer's certificate. **Example:** `"247667"` Returns `null` if pincode verification is not configured. | — | | `stateVerification` | string | No | The state name to verify against the signer's certificate. **Example:** `"Uttarakhand"` Returns `null` if state verification is not configured. | — | | `titleVerification` | string | No | The last 4 digits of the Aadhaar number to verify against the signer's certificate. **Example:** `"3870"` Returns `null` if title verification is not configured. | — | | `yobVerification` | integer | No | The year of birth to verify against the signer's certificate. **Example:** `1998` Returns `null` if YOB verification is not configured. | — | | `genderVerification` | string | No | The gender value to verify against the signer's certificate. - `M` — Male - `F` — Female - `T` — Transgender | — | ###### InviteeAadhaarVerificationRequestDetails3_1ResponseObject Verification request configuration for this invitee. These fields contain the **input values** provided when creating the document — not boolean flags. **Note:** `smartNamePercentage` is a boolean toggle (`true`/`null`). All other fields contain the actual input values to verify against (e.g., pincode string, state name, year of birth integer). | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `smartNamePercentage` | boolean | No | Whether smart name percentage matching is enabled for this invitee. Returns `true` if enabled, `null` if not configured. | — | | `nameVerification` | boolean | No | Whether exact name verification is enabled for this invitee. Returns `true` if enabled, `null` if not configured. | — | | `pincodeVerification` | string | No | The pincode value to verify against the signer's certificate. **Example:** `"247667"` Returns `null` if pincode verification is not configured. | — | | `stateVerification` | string | No | The state name to verify against the signer's certificate. **Example:** `"Uttarakhand"` Returns `null` if state verification is not configured. | — | | `titleVerification` | string | No | The last 4 digits of the Aadhaar number to verify against the signer's certificate. **Example:** `"3870"` Returns `null` if title verification is not configured. | — | | `yobVerification` | integer | No | The year of birth to verify against the signer's certificate. **Example:** `1998` Returns `null` if YOB verification is not configured. | — | | `genderVerification` | string | No | The gender value to verify against the signer's certificate. - `M` — Male - `F` — Female - `T` — Transgender | — | ###### InviteeDSCVerificationRequestDetails3_1ResponseObject | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `smartNamePercentage` | boolean | No | Whether smart name verification is turned on or not. | — | | `nameVerification` | boolean | No | Whether name verification is turned on or not. | — | | `pincodeVerification` | boolean | No | Whether pincode verification is turned on or not. | — | | `stateVerification` | boolean | No | Whether state verification is turned on or not. | — | ###### InviteeAadhaarVerificationRequestDetails3_1ResponseObject Verification request configuration for this invitee. These fields contain the **input values** provided when creating the document — not boolean flags. **Note:** `smartNamePercentage` is a boolean toggle (`true`/`null`). All other fields contain the actual input values to verify against (e.g., pincode string, state name, year of birth integer). | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `smartNamePercentage` | boolean | No | Whether smart name percentage matching is enabled for this invitee. Returns `true` if enabled, `null` if not configured. | — | | `nameVerification` | boolean | No | Whether exact name verification is enabled for this invitee. Returns `true` if enabled, `null` if not configured. | — | | `pincodeVerification` | string | No | The pincode value to verify against the signer's certificate. **Example:** `"247667"` Returns `null` if pincode verification is not configured. | — | | `stateVerification` | string | No | The state name to verify against the signer's certificate. **Example:** `"Uttarakhand"` Returns `null` if state verification is not configured. | — | | `titleVerification` | string | No | The last 4 digits of the Aadhaar number to verify against the signer's certificate. **Example:** `"3870"` Returns `null` if title verification is not configured. | — | | `yobVerification` | integer | No | The year of birth to verify against the signer's certificate. **Example:** `1998` Returns `null` if YOB verification is not configured. | — | | `genderVerification` | string | No | The gender value to verify against the signer's certificate. - `M` — Male - `F` — Female - `T` — Transgender | — | ###### verificationResponse Verification results for this invitee. Returned only when the `invitations_verificationResponse` query parameter is set to `true`. Contains the outcome of each configured verification check (name, pincode, state, title, YOB, gender) as well as face match and smart user liveliness results. | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `smartNamePercentage` | integer | No | Name matching percentage between the provided name and the name from the CA authority certificate. **Example:** `45` (means 45% match) Returns `null` if smart name verification is not configured. | — | | `smartNameAI` | boolean | No | Whether Smart Name AI matching was enabled for this invitee. `true` = enabled, `false` = disabled, `null` = not configured. | — | | `signatureVerification` | boolean | No | Whether signature certificate verification was enabled for this invitee. `true` = enabled, `false` = disabled, `null` = not configured. | — | | `nameVerification` | boolean | No | Result of name verification against the signer's certificate. `true` = verification passed, `false` = verification failed, `null` = not configured. | — | | `pincodeVerification` | boolean | No | Result of pincode verification against the signer's certificate. `true` = verification passed, `false` = verification failed, `null` = not configured. | — | | `stateVerification` | boolean | No | Result of state verification against the signer's certificate. `true` = verification passed, `false` = verification failed, `null` = not configured. | — | | `titleVerification` | boolean | No | Result of title (last 4 digits of Aadhaar) verification against the signer's certificate. `true` = verification passed, `false` = verification failed, `null` = not configured. | — | | `yobVerification` | boolean | No | Result of year of birth verification against the signer's certificate. `true` = verification passed, `false` = verification failed, `null` = not configured. | — | | `genderVerification` | boolean | No | Result of gender verification against the signer's certificate. `true` = verification passed, `false` = verification failed, `null` = not configured. | — | | `neslNameVerification` | boolean | No | Indicates whether the invitee's name has been successfully verified. true means the verification succeeded, and false means it failed. | — | | `neslNameVerificationPercentage` | integer | No | The percentage of accuracy achieved during the invitee's name verification. | — | | `neslGenderVerification` | boolean | No | Indicates whether the invitee's gender has been successfully verified. true means the verification succeeded, and false means it failed. | — | | `neslYobVerification` | boolean | No | Indicates whether the invitee's Year of Birth (YOB) has been successfully verified. true means the verification succeeded, and false means it failed. | — | | `neslTitleVerification` | boolean | No | Indicates whether the invitee's Title (last 4 digits of Aadhaar number) has been successfully verified. true means the verification succeeded, and false means it failed. | — | | `faceMatch` | FaceMatchArrayResponseObject | No | See **FaceMatchArrayResponseObject** below. | — | | `smartUserLiveliness` | SmartUserLivelinessArrayResponseObject | No | See **SmartUserLivelinessArrayResponseObject** below. | — | ###### FaceMatchArrayResponseObject | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `faceMatchPercentage` | integer | No | Percentage of similarity between the source image and the image captured by the signer during face match. **Type:** Integer (e.g., `99`) Returns `null` if face match is not enabled or if the invitee has not yet completed signing. Only populated after the invitee has signed the document. | — | | `faceMatchAttemptsLeft` | integer | No | Number of remaining face match retry attempts. Decrements with **every** attempt (both successful and failed matches). Starts at the value of `faceMatchRetriesConfigured` and counts down. Returns `null` if face match is not enabled for this invitee. | — | | `faceMatchError` | string | No | Error message from the face matching process, if any. Returns `null` when face match is not enabled, when no error has occurred, or when attempts are still remaining. | — | ###### SmartUserLivelinessArrayResponseObject | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `smartUserLivelinessPercentage` | integer | No | The percentage achieved by the invitee during Smart User Liveliness verification. Only the percentage of the invitee's most recent verification attempt is displayed. > **Note:** This percentage is only available after the invitee has either signed the document or the invitation has expired. Otherwise, it will return a `null` value. | — | | `smartUserLivelinessAttemptsLeft` | integer | No | Number of remaining attempts for the invitee to complete Smart User Liveliness. This value updates with each attempt. | — | ###### AttachmentsArrayResponseObject | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `file` | string | No | CDN download URL for the attachment file. This is a signed URL with an expiration time — not a base64-encoded string. | — | | `name` | string | No | Filename of the attachment. **Example:** `"Invoice-6814F2DA-0024.pdf"` | — | | `type` | string | No | MIME type of the attachment. **Possible values:** `application/pdf`, `image/png`, `image/jpg`, `image/jpeg` | — | ###### espResponse | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `status` | string | No | Status of the ESP transaction. **Possible values:** - `pending` — set when the user lands on the ESP screen. - `success` — the transaction completed. - `error` — the transaction failed. Allowed: `pending`, `error`, `success`. | `error` | | `createdTime` | string | No | The time the user landed on the ESP screen (when `status` becomes `pending`). Format `dd-MM-yyyy HH:mm:ss`. | `31-08-2026 12:38:53` | | `lastUpdatedTime` | string | No | The time the user exited the ESP — usually after an error or completion (`status` = `error`/`success`). Format `dd-MM-yyyy HH:mm:ss`. | `31-08-2026 12:39:01` | | `errorCode` | string | No | Error code as received from the ESP. **Possible values:** - An ESP error code like `ESP-945` — when `status` is `error`. - `NA` — when `status` is `success`. - `null` — when `status` is `pending`. | `ESP-945` | | `errorMessage` | string | No | Error message as received from the ESP. **Possible values:** - An ESP error message like `User terminated eKYC process after OTP Generation` — when `status` is `error`. - `NA` — when `status` is `success`. - `null` — when `status` is `pending`. | `User terminated eKYC process after OTP Generation` | ### Sample Response (200) ```json { "status": 0, "messages": [ { "code": "simpleWorkFlow.success", "message": "Invitations sent successfully." } ], "data": { "file": "string", "auditTrail": "string", "document": { "id": "string", "name": "string", "irn": "string", "status": "string", "coordinatePicker": false, "deleted": false, "creationDate": "string", "completionDate": "string", "scheduledDeletionDate": "string", "customMessage": "string", "deleteOnComplete": false, "requestSigningOrder": false, "requireSigningOrder": false }, "sftp": { "sftpEnabled": false, "profileId": "string" }, "workflow": { "id": "string", "name": "string", "type": "string", "subtype": "string" }, "template": { "id": "string", "name": "string" }, "account": { "id": "string", "name": "string", "label": "string", "brandName": "string" }, "sender": { "name": "string", "username": "string" }, "folders": [ { "id": "string", "name": "string" } ], "stampDetails": { "groupName": "string", "groupNumber": "string", "stampValue": "string", "maximumValuePermitted": "string", "state": "string", "stamps": [ { "series": "03", "amount": "string", "serialNumber": "string", "associatedDocumentId": "string" } ], "multipleStampSeriesUsed": false }, "referenceAttachments": [ { "file": "string", "name": "string", "type": "string" } ], "neslDocumentDetails": { "transactionId": "string", "responseCode": "string", "responseMessage": "string", "isRetryAllowed": "string", "loanDetails": { "loanNumber": "string", "sanctionNumber": "string", "registrationType": "string", "state": "string", "branchName": "string", "branchAddress": "string", "dateOfSanction": "string", "emiAmount": "string", "rateOfInterest": "string", "sanctionAmount": "string", "tenure": "string", "typeOfDebt": "string", "accountClosedFlag": "string", "fundType": "string", "sanctionCurrency": "string", "creditSubtype": "string", "facilityName": "string", "amountOverdue": "string", "otherChargeAmount": "string", "debtStartDate": "string", "interestAmount": "string", "oldDebtRefNo": "string", "principalOutstanding": "string", "loanRemark": "string", "totalOutstandingAmount": "string", "creditorBusinessUnit": "string", "drawingPower": "string", "daysPastDue": "string", "event": "INVOCATION", "expiryDate": "string", "claimExpiryDate": "string", "currencyOfDebt": "string" }, "securityDetails": [ { "securityDescription": "string", "assetsType": "string", "chargeType": "string", "assetId": "string", "doc": "string", "dov": "string", "cersaiId": "string", "rocChargeId": "string", "securityValue": "string" } ], "stampDetails": { "firstParty": "string", "secondParty": "string", "stampDutyAmount": "string", "considerationPrice": "string", "descriptionOfDocument": "string", "stampDutyPaidBy": "string", "articleCode": "string", "articleSubCode": "string", "firstPartyPin": "string", "secondPartyPin": "string", "firstPartyOVDType": "string", "firstPartyOVDValue": "string", "secondPartyOVDType": "string", "secondPartyOVDValue": "string" }, "partyDetails": { "fullName": "string", "contactPersonName": "string", "contactRelation": "string", "emailId": "string", "mobileNumber": "string", "dob": "string", "legalConstitution": "string", "alternateEmailId": "string", "alternateMobileNumber": "string", "officialDocType": "string", "officialDocId": "string", "registeredAddress": "string", "registeredPinCode": "string", "designation": "string", "communicationAddress": "string", "communicationAddressPinCode": "string", "cin": "string", "kin": "string", "partyType": "string", "isIndividual": "YES", "signatoryGender": "string", "businessUnit": "string" }, "neslEstampStatus": "string", "neslEstampCertificates": [ "string" ] }, "cc": [ { "id": "string", "name": "string", "email": "string", "invitationNotification": false, "signingNotification": false, "completionNotification": false, "failureNotification": false, "sendInvitationUrl": false, "shareDocAuditTrail": false, "enforceOneFactorAuthentication": false, "recordAuditTrail": false } ], "coordinatePicker": { "coordinatePickerUrl": "string", "coordinatePickerWebhook": "string" }, "invitations": [ { "name": "string", "email": "string", "phone": "string", "inviteeType": "string", "inviteeConfigs": { "emailNotification": false, "phoneNotification": false, "whatsappEnabled": false, "whatsAppNotification": false, "retry": 0, "fixedName": false, "noName": false, "supportingDocument": [ "string" ], "viewSupportingDocument": false, "organizationConfig": { "nameRequired": false, "fixedName": false, "name": "string", "requireSeal": false, "sealType": "string" }, "security": { "enforceAuthentication": false, "twoFactorAuthentication": false, "sendDocumentRawUrl": false, "captureLocation": false, "capturePhoto": false, "gpsConfig": { "applyLocationRestriction": false, "allowedLatitude": 28.50950813247034, "allowedLongitude": 77.08920288142689, "permissibleRadius": 5000, "restrictToIndia": true, "applyLocationAccuracy": false, "accuracyThreshold": 10000 }, "faceMatch": { "faceMatchEnabled": false, "faceMatchRetriesConfigured": 0 }, "userLiveliness": false, "smartUserLiveliness": { "smartUserLivelinessEnabled": false, "smartUserLivelinessRetriesConfigured": 0 } }, "eSignPriority": { "eSignPriorityEnabled": false, "eSignPriorityConfig": [ { "signatureType": "string", "eSignSubType": "string", "retryAttempts": 0, "eSignOrder": 0 } ] }, "customURL": { "webhookURL": "string", "redirectURL": "string", "errorWebhookURL": "string", "baseURL": "string", "webhookVersion": "string" }, "customConsent": "string", "enableRejectDocument": false, "enableRejectMessage": false, "maskContactDetails": false, "languageDetails": { "enableLanguage": false, "defaultLanguage": false, "defaultLanguageSelect": "string" }, "paymentDetails": { "paymentCollectionEnabled": false, "paymentProfileId": "string", "paymentCollectionAmount": "string", "paymentCollectionMessage": "string", "paymentCollectStatus": "string", "paymentId": "string", "paymentEventDate": "string" } }, "recordReviewerDetails": false, "inviteeGroup": { "id": "string", "name": "string", "completionThreshold": 0, "completionStatus": "string", "size": 0, "completed": false }, "invitationUrl": "string", "allowedSignatures": [ "string" ], "usedSignatureType": "string", "signatureSubOptionUsed": "string", "signatureOptions": { "aadhaar": [ "string" ], "virtual": [ "string" ], "visualSign": [ "string" ], "quickSign": [ "string" ] }, "signatureOptionUsed": "string", "neslInvitationDetails": { "type": "string", "participantDetails": { "fullName": "string", "contactPersonName": "string", "contactRelation": "string", "emailId": "string", "mobileNumber": "string", "dob": "string", "legalConstitution": "string", "alternateEmailId": "string", "alternateMobileNumber": "string", "officialDocType": "string", "officialDocId": "string", "registeredAddress": "string", "registeredPinCode": "string", "designation": "string", "communicationAddress": "string", "communicationAddressPinCode": "string", "cin": "string", "kin": "string", "partyType": "string", "isIndividual": "YES", "signatoryGender": "string", "businessUnit": "string" } }, "offlineSignDetails": { "fixSignerId": false, "mobileNumber": "string", "pan": "string", "signerId": "string" }, "invitationStatus": { "active": false, "signed": false, "reviewed": false, "approved": false, "rejected": false, "expired": false, "recordApproverResponse": false, "creationDate": "string", "expiryDate": "string", "signDate": "string", "failureReason": "string", "rejectionMessage": "string", "signRejectionMessage": "string" }, "certificateData": { "name": "string", "yob": "string", "gender": "string", "pincode": "string", "title": "string", "state": "string", "photoHash": "string", "uid": "string", "serialNumber": "string" }, "verificationRequest": { "aadhaarConfig": { "smartNamePercentage": false, "nameVerification": false, "pincodeVerification": "string", "stateVerification": "string", "titleVerification": "string", "yobVerification": 0, "genderVerification": "string" }, "offlineConfig": { "smartNamePercentage": false, "nameVerification": false, "pincodeVerification": "string", "stateVerification": "string", "titleVerification": "string", "yobVerification": 0, "genderVerification": "string" }, "dscConfig": { "smartNamePercentage": false, "nameVerification": false, "pincodeVerification": false, "stateVerification": false }, "neslConfig": { "smartNamePercentage": false, "nameVerification": false, "pincodeVerification": "string", "stateVerification": "string", "titleVerification": "string", "yobVerification": 0, "genderVerification": "string" } }, "verificationResponse": { "smartNamePercentage": 0, "smartNameAI": false, "signatureVerification": false, "nameVerification": false, "pincodeVerification": false, "stateVerification": false, "titleVerification": false, "yobVerification": false, "genderVerification": false, "neslNameVerification": false, "neslNameVerificationPercentage": 0, "neslGenderVerification": false, "neslYobVerification": false, "neslTitleVerification": false, "faceMatch": { "faceMatchPercentage": 0, "faceMatchAttemptsLeft": 0, "faceMatchError": "string" }, "smartUserLiveliness": { "smartUserLivelinessPercentage": 0, "smartUserLivelinessAttemptsLeft": 0 } }, "supportingDocuments": [ { "file": "string", "name": "string", "type": "string" } ], "espResponse": [ { "status": "error", "createdTime": "31-08-2026 12:38:53", "lastUpdatedTime": "31-08-2026 12:39:01", "errorCode": "ESP-945", "errorMessage": "User terminated eKYC process after OTP Generation" } ] } ] } } ``` --- URL: https://knowledge.leegality.com/document-execution/api/list-completed-documents # GET /v3.0/document/completed — List completed documents Retrieves a paginated list of all completed documents from your Leegality account. Documents are returned in **ascending order** by completion date (oldest first). **Authentication:** `X-Auth-Token` header required on every request. ## Request URL ``` GET https://app1.leegality.com/api/v3.0/document/completed?max={max}&offset={offset}&name={name}&irn={irn}&startDate={startDate}&endDate={endDate} ``` **Environments:** - Production: `https://app1.leegality.com/api/v3.0/document/completed` - Sandbox: `https://sandbox.leegality.com/api/v3.0/document/completed` --- ## Parameters | Name | In | Required | Type | Description | Example | |------|----|----------|------|-------------|---------| | `max` | query | No | integer | Maximum number of documents to return per request. **Default:** `20` **Valid range:** `1` to `40` **Note:** If a value greater than `40` is passed, the API silently resets it to `20` (the default) instead of returning an error or capping at 40. | — | | `offset` | query | No | integer | Number of documents to skip before returning results. Used for pagination. **Default:** `0` **Example:** To get the second page of results with 20 per page, use `offset=20`. If `offset` exceeds the total number of documents, an empty `documents` array is returned with the correct `totalCount`. | — | | `name` | query | No | string | Filter documents by name using **pattern matching** (case-insensitive partial match). **Example:** `name=dummy` will match documents named `dummy PDF.pdf`, `My dummy document`, etc. The `totalCount` in the response reflects the filtered count. | — | | `irn` | query | No | string | Filter documents by Invoice Reference Number (IRN). This is an **exact match** filter — partial IRN values will not return results. **Example:** If a document has IRN `12222223`, searching for `irn=12222223` returns it, but `irn=12222` returns nothing. | — | | `startDate` | query | No | string | Filter documents completed on or after this date. **Format:** `dd-MM-yyyy` **Example:** `01-01-2026` Can be used alone (without `endDate`) to get all documents completed from this date onwards. **Note:** The filter is based on the document's completion date, not the creation date. An invalid format returns error code `validator.invalid`. | — | | `endDate` | query | No | string | Filter documents completed on or before this date. **Format:** `dd-MM-yyyy` **Example:** `28-02-2026` Can be used alone (without `startDate`) to get all documents completed up to this date. **Note:** The filter is based on the document's completion date, not the creation date. An invalid format returns error code `validator.invalid`. | — | --- ## Responses ### 200 — Default Response Response for the List Completed Documents API. | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `status` | integer | No | API response status. `1` = Success `0` = Failure (e.g., invalid date format) | `1` | | `data` | CompletedDocumentsData | No | Contains the paginated list of completed documents and the total count. See **CompletedDocumentsData** below. | — | | `messages` | array\ | No | Array of error/validation messages. Empty array on success. On validation failure (e.g., invalid date format), contains objects with `code` and `message` fields. See **Message** below. | — | #### CompletedDocumentsData Contains the paginated list of completed documents and the total count. | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `totalCount` | integer | No | Total number of completed documents matching the applied filters. This count reflects all matching documents, not just those in the current page. Use this with `max` and `offset` to implement pagination. | `130` | | `documents` | array\ | No | Array of completed document objects, sorted in **ascending order** by `completionDate` (oldest first). The number of items is limited by the `max` parameter (default 20, maximum 40). See **CompletedDocumentItem** below. | — | ##### CompletedDocumentItem A completed document summary object. | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `documentId` | string | No | The unique identifier for the document, generated by Leegality when the eSigning request was created. | `FR601AA019` | | `documentName` | string | No | The name of the document as specified when creating the eSigning request. > **Note:** This field is named `documentName` (not `name` as in the List Documents API). | `Template-VuMT` | | `irn` | string | No | Invoice Reference Number associated with the document. Returns `null` if no IRN was assigned. | `12222223` | | `completionDate` | string | No | The date and time when the document was completed (all signatures collected). **Format:** `yyyy-MM-dd HH:mm:ss.S` Documents are sorted by this field in ascending order. | `2024-01-02 11:20:04.0` | | `dateCreated` | string | No | The date and time when the eSigning request was created. **Format:** `yyyy-MM-dd HH:mm:ss.S` | `2024-01-02 11:17:36.0` | | `folderId` | string | No | The unique identifier of the folder containing this document. Returns `null` if the document is not in a folder. | `null` | | `folderName` | string | No | The name of the folder containing this document. Returns `null` if the document is not in a folder. | `null` | #### Message Message object containing a machine-readable code and a human-readable description. Used for success confirmations, errors, and warnings. | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `code` | string | No | Response message code. | `simpleWorkFlow.success` | | `message` | string | No | Human-readable success or error message. | `Invitations sent successfully.` | ### Sample Response (200) ```json { "status": 1, "data": { "totalCount": 130, "documents": [ { "documentId": "FR601AA019", "documentName": "Template-VuMT", "irn": "12222223", "completionDate": "2024-01-02 11:20:04.0", "dateCreated": "2024-01-02 11:17:36.0", "folderId": null, "folderName": null } ] }, "messages": [ { "code": "simpleWorkFlow.success", "message": "Invitations sent successfully." } ] } ``` --- URL: https://knowledge.leegality.com/document-execution/api/fetch-document # GET /v3.3/document/fetchDocument — Fetch document Downloads the signed document, audit trail, sender attachments, or invitee supporting documents associated with a completed document. **Authentication:** `X-Auth-Token` header required on every request. ## Request URL ``` GET https://app1.leegality.com/api/v3.3/document/fetchDocument?documentId={documentId}&documentDownloadType={documentDownloadType}&supportDocumentUrl={supportDocumentUrl}&index={index} ``` **Environments:** - Production: `https://app1.leegality.com/api/v3.3/document/fetchDocument` - Sandbox: `https://sandbox.leegality.com/api/v3.3/document/fetchDocument` --- ## Parameters | Name | In | Required | Type | Description | Example | |------|----|----------|------|-------------|---------| | `documentId` | query | Yes | string | The unique Document ID generated by Leegality when the eSigning request was created. Can also be retrieved from the Leegality dashboard. **Note:** Only completed documents can be fetched. SENT or DRAFT documents return error `no.document.found`. | — | | `documentDownloadType` | query | Yes | string | The type of file to download. Only one value can be passed per API call. **Possible values:** - `DOCUMENT` — The signed PDF document - `AUDIT_TRAIL` — The audit trail generated by Leegality on document completion - `ATTACHMENT` — Reference attachments uploaded by the sender (requires `index`) - `SUPPORTING_DOCUMENT` — Supporting documents uploaded by an invitee (requires `supportDocumentUrl` and `index`) **Note:** Values are **case-sensitive** and must be uppercase. Lowercase or invalid values return error code `document.download.type` with the list of valid values. | — | | `supportDocumentUrl` | query | No | string | The invitation URL of the invitee whose supporting documents you want to fetch. The invitation URL is returned in the Create eSigning Request API response. Accepts either the full invitation URL (e.g., `https://sandbox.leegality.com/sign/544bf18f-...`) or just the UUID portion (e.g., `544bf18f-91b8-4afb-96ee-8ff1927a2726`). **Required when** `documentDownloadType` = `SUPPORTING_DOCUMENT`. Ignored for other `documentDownloadType` values. | — | | `index` | query | No | integer | The 0-based index of the attachment or supporting document to fetch. **Example:** Pass `0` for the first file, `1` for the second, and so on. **Required when** `documentDownloadType` = `ATTACHMENT` or `SUPPORTING_DOCUMENT`. Ignored for `DOCUMENT` and `AUDIT_TRAIL` types. **Error codes:** - `index.not.negative` — Returned if a negative value is passed - `index.out.of.bound` — Returned if the index exceeds the number of available files - `no.attachments.exists` — Returned if no attachments exist for the document | — | --- ## Responses ### 200 — Default Response Response for the Fetch Document API. | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `status` | integer | No | API response status. `1` = Success — the `data.file` field contains the CDN download URL `0` = Failure — check the `messages` array for error details | `1` | | `data` | FetchDocumentData | No | Contains the CDN download URL for the requested file. Empty object `{}` on failure. See **FetchDocumentData** below. | — | | `messages` | array\ | No | Array of error/validation messages. Empty array `[]` on success. **Common error codes:** - `no.document.found` — Document ID not found or document is not in COMPLETED status - `document.download.type` — Invalid `documentDownloadType` value (case-sensitive, must be uppercase) - `no.attachments.exists` — No attachments exist for the given document ID - `index.out.of.bound` — Index exceeds the number of available files - `index.not.negative` — Negative index value passed - `invitation.not.found` — Invalid `supportDocumentUrl` (invitee not found) - `validator.invalid` — Required parameter missing or invalid See **Message** below. | — | #### FetchDocumentData Contains the CDN download URL for the requested file. Empty object `{}` on failure. | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `file` | string | No | A temporary CDN download URL for the requested file. **Important:** - The URL expires in **15 seconds**. Download the file immediately at the server level. - Do not use this URL for previewing files in a browser — it is intended for server-side downloads only. - Each API call generates a **unique URL**. If the URL expires, simply call the API again to get a new one. **URL format:** `https:///export//?Expires=&Signature=&Key-Pair-Id=` | `https://sandbox-downloads.leegality.com/export/2026/03/05/70` | #### Message Message object containing a machine-readable code and a human-readable description. Used for success confirmations, errors, and warnings. | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `code` | string | No | Response message code. | `simpleWorkFlow.success` | | `message` | string | No | Human-readable success or error message. | `Invitations sent successfully.` | ### Sample Response (200) ```json { "status": 1, "data": { "file": "https://sandbox-downloads.leegality.com/export/2026/03/05/70476a7c-17bc-4d32-ae64-6687200ca73d?Expires=1772689002&Signature=...&Key-Pair-Id=..." }, "messages": [ { "code": "simpleWorkFlow.success", "message": "Invitations sent successfully." } ] } ``` --- URL: https://knowledge.leegality.com/document-execution/api/fetch-document-binary # GET /v3.1/document/fetchDocument — Fetch document (binary) Downloads the signed document, audit trail, sender attachments, or invitee supporting documents in **raw binary format**. **Authentication:** `X-Auth-Token` header required on every request. ## Request URL ``` GET https://app1.leegality.com/api/v3.1/document/fetchDocument?documentId={documentId}&documentDownloadType={documentDownloadType}&supportDocumentUrl={supportDocumentUrl}&index={index} ``` **Environments:** - Production: `https://app1.leegality.com/api/v3.1/document/fetchDocument` - Sandbox: `https://sandbox.leegality.com/api/v3.1/document/fetchDocument` --- ## Parameters | Name | In | Required | Type | Description | Example | |------|----|----------|------|-------------|---------| | `documentId` | query | Yes | string | The unique Document ID generated by Leegality when the eSigning request was created. Can also be retrieved from the Leegality dashboard. **Note:** `DOCUMENT`, `ATTACHMENT`, and `SUPPORTING_DOCUMENT` types can be fetched at any document stage. `AUDIT_TRAIL` requires the document to be fully completed. | — | | `documentDownloadType` | query | Yes | string | The type of file to download. Only one value can be passed per request — passing multiple values returns error `document.download.type`. **Possible values:** - `DOCUMENT` — The signed PDF document (Content-Type: `application/pdf`). Available at any document stage. - `AUDIT_TRAIL` — The audit trail generated by Leegality (Content-Type: `application/pdf`). Only available after the document is fully completed; returns error `document.not.completed` otherwise. - `ATTACHMENT` — Reference attachments uploaded by the sender (requires `index`). Available at any document stage. - `SUPPORTING_DOCUMENT` — Supporting documents uploaded by an invitee (requires `supportDocumentUrl` and `index`). Available at any document stage. **Note:** Values are **case-sensitive** and must be uppercase. Lowercase or invalid values return error code `document.download.type`. | — | | `supportDocumentUrl` | query | No | string | The invitation URL of the invitee whose supporting documents you want to fetch. Accepts either the full invitation URL (e.g., `https://sandbox.leegality.com/sign/544bf18f-...`) or just the UUID portion (e.g., `544bf18f-91b8-4afb-96ee-8ff1927a2726`). **Required when** `documentDownloadType` = `SUPPORTING_DOCUMENT`. Ignored for other `documentDownloadType` values. | — | | `index` | query | No | integer | The 0-based index of the attachment or supporting document to fetch. **Example:** Pass `0` for the first file, `1` for the second, and so on. **Required when** `documentDownloadType` = `ATTACHMENT` or `SUPPORTING_DOCUMENT`. Ignored for `DOCUMENT` and `AUDIT_TRAIL` types. **Error codes:** - `index.not.negative` — Returned if a negative value is passed - `index.out.of.bound` — Returned if the index exceeds the number of available files - `no.attachments.exists` — Returned if no attachments exist for the document | — | --- ## Responses ### 200 — **On success:** Returns the raw binary file with the appropriate Content-Type header (`application/pdf` for documents and audit trails; varies for attachments and supporting documents). **On error:** Returns a JSON response with `status: 0` and an error code in `messages[].code`. **All errors are returned with HTTP 200** — use the `status` field and `messages[].code` to detect failures, not the HTTP status code. | `messages[].code` | `messages[].message` | |---|---| | `document.not.completed` | Document has not been completed yet. Audit trail cannot be downloaded for incomplete documents. | | `document.download.type` | Document Type (AUDIT_TRAIL,DOCUMENT) Not Supported. Please enter value as : [DOCUMENT, AUDIT_TRAIL, ATTACHMENT, SUPPORTING_DOCUMENT]. | Error response returned when the fetch request fails. On success, this endpoint returns raw binary data (not JSON), so this schema only applies to error responses. | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `status` | integer | No | `0` = Failure | `0` | | `data` | object | No | Empty object `{}` on error. | `[object Object]` | | `messages` | array\ | No | Array of error/validation messages. **Error codes:** - `document.not.completed` — `AUDIT_TRAIL` was requested but the document has not been fully completed yet - `document.download.type` — Invalid or unsupported `documentDownloadType` value, including passing multiple values in the same request - `no.document.found` — Document ID not found or you do not have access to it - `no.attachments.exists` — No attachments exist for the given document - `index.out.of.bound` — Index exceeds the number of available files - `index.not.negative` — A negative index value was passed - `invitation.not.found` — Invalid `supportDocumentUrl` (invitee not found) - `validator.invalid` — A required parameter is missing or invalid See **Message** below. | `[object Object]` | #### Message Message object containing a machine-readable code and a human-readable description. Used for success confirmations, errors, and warnings. | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `code` | string | No | Response message code. | `simpleWorkFlow.success` | | `message` | string | No | Human-readable success or error message. | `Invitations sent successfully.` | ### Sample Response (200) ```json { "status": 0, "data": {}, "messages": [ { "code": "document.not.completed", "message": "Document has not been completed yet. Audit trail cannot be downloaded for incomplete documents." } ] } ``` --- URL: https://knowledge.leegality.com/document-execution/api/mark-document-complete # POST /v3.0/sign/request/complete — Mark document as complete Marks an incomplete (SENT) document as complete, even if not all invitees have signed. **Authentication:** `X-Auth-Token` header required on every request. ## Request URL ``` POST https://app1.leegality.com/api/v3.0/sign/request/complete ``` **Environments:** - Production: `https://app1.leegality.com/api/v3.0/sign/request/complete` - Sandbox: `https://sandbox.leegality.com/api/v3.0/sign/request/complete` --- ## Request Body **Content-Type:** `application/json` | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `documentId` | string | Yes | Unique identifier of the document to mark as complete. **Format:** Alphanumeric string. Get from the **Create eSigning request** API response or from the dashboard. | `01KJCHYRSQGA24YDZ044BS6MTS` | ### Sample Request ```json { "documentId": "01KJCHYRSQGA24YDZ044BS6MTS" } ``` --- ## Responses ### 200 — Complete document response. Check `status` field: `1` = success, `0` = failure. Response wrapper for the Mark Document Complete API. On success (`status: 1`), `data` is an empty object and the document status changes to COMPLETED. On failure (`status: 0`), `data` is an empty object and `messages` contains the error details. | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `status` | integer | No | API response status. `1` = success (document marked as complete), `0` = failure. Allowed: `0`, `1`. | `1` | | `messages` | array\ | No | Array of response messages. **Error codes:** - `no.document.found` — The document ID does not exist or is not accessible - `document.already.completed` — The document has already been completed (all invitees signed or previously force-completed) **Validation errors (code is `null`):** - `Property documentId cannot be null` — The `documentId` field is missing, null, or empty in the request body See **Message** below. | — | | `data` | object | No | Always an empty object `{}` for this endpoint. | — | #### Message Message object containing a machine-readable code and a human-readable description. Used for success confirmations, errors, and warnings. | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `code` | string | No | Response message code. | `simpleWorkFlow.success` | | `message` | string | No | Human-readable success or error message. | `Invitations sent successfully.` | ### Sample Response (200) ```json { "status": 1, "messages": [ { "code": "simpleWorkFlow.success", "message": "Invitations sent successfully." } ], "data": {} } ``` --- URL: https://knowledge.leegality.com/document-execution/api/resend-notifications # POST /v3.0/sign/request/resend — Resend notifications Resends signing invitation notifications (email/SMS) to invitees who have not yet signed. **Authentication:** `X-Auth-Token` header required on every request. ## Request URL ``` POST https://app1.leegality.com/api/v3.0/sign/request/resend ``` **Environments:** - Production: `https://app1.leegality.com/api/v3.0/sign/request/resend` - Sandbox: `https://sandbox.leegality.com/api/v3.0/sign/request/resend` --- ## Request Body **Content-Type:** `application/json` Request body for resending signing notifications. | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `signUrls` | array\ | Yes | Array of sign URLs to resend notifications for. **Size:** 1 to 15 URLs per request. Each URL can be either the full signing URL or just the UUID portion. Get the sign URLs from the **Create eSigning request** API response, **Check transaction status** API, or **Check document details** API. | `https://sandbox.leegality.com/sign/2bdcc3ef-661f-440c-b059-8` | ### Sample Request ```json { "signUrls": [ "https://sandbox.leegality.com/sign/2bdcc3ef-661f-440c-b059-82c0ff6ce4d8" ] } ``` --- ## Responses ### 200 — Resend response with per-invitee status. Response wrapper for the Resend Notifications API. The top-level `status` is `1` as long as the request format is valid. Check each item in `data.invitations` for per-invitee success or failure. | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `status` | integer | No | API response status. `1` = request processed (check individual invitation statuses), `0` = request-level failure. Allowed: `0`, `1`. | `1` | | `messages` | array\ | No | Request-level error messages. Empty array when the request is valid. **Error codes:** - `validator.invalid` — signUrls array is empty or exceeds 15 items - *(null code)* — signUrls field is missing from the request body See **Message** below. | — | | `data` | ResendData | No | Resend result data. Contains per-invitee results. On request-level failure, this is an empty object `{}`. See **ResendData** below. | — | #### Message Message object containing a machine-readable code and a human-readable description. Used for success confirmations, errors, and warnings. | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `code` | string | No | Response message code. | `simpleWorkFlow.success` | | `message` | string | No | Human-readable success or error message. | `Invitations sent successfully.` | #### ResendData Resend result data. Contains per-invitee results. On request-level failure, this is an empty object `{}`. | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `invitations` | array\ | No | Array of per-invitee resend results. One entry per sign URL in the request. See **ResendInvitationResult** below. | — | ##### ResendInvitationResult Result of resending a notification for a single invitee. | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `status` | integer | No | Per-invitee resend status. `1` = notification resent successfully, `0` = resend failed for this invitee. Allowed: `0`, `1`. | `1` | | `name` | string | No | Name of the invitee. Returns `null` if the sign URL is invalid. | `Abhishek Sharma` | | `email` | string | No | Email address of the invitee. Returns `null` if the sign URL is invalid. | `signer@example.com` | | `phone` | string | No | Mobile number of the invitee. Returns `null` if no phone was provided or if the sign URL is invalid. | `9876543210` | | `signUrl` | string | No | The sign URL that was processed. Returns the full URL even if only the UUID was passed in the request. | `https://sandbox.leegality.com/sign/2bdcc3ef-661f-440c-b059-8` | | `message` | string | No | Human-readable result message for this invitee. **Success:** - `Invitation(s) sent successfully. Please ask invitees to check their inbox.` **Failure:** - `Document(s) already signed by the invitee.` - `You do not have access to the document.` - `You have already resent invitation mail 5 times. Please contact support@leegality.com for help.` | `Invitation(s) sent successfully. Please ask invitees to chec` | ### Sample Response (200) ```json { "status": 1, "messages": [ { "code": "simpleWorkFlow.success", "message": "Invitations sent successfully." } ], "data": { "invitations": [ { "status": 1, "name": "Abhishek Sharma", "email": "signer@example.com", "phone": "9876543210", "signUrl": "https://sandbox.leegality.com/sign/2bdcc3ef-661f-440c-b059-82c0ff6ce4d8", "message": "Invitation(s) sent successfully. Please ask invitees to check their inbox." } ] } } ``` --- URL: https://knowledge.leegality.com/document-execution/api/activate-invitation # PUT /v3.1/invitation/activate — Activate invitation Activates an invitation that is not yet active due to a pre-defined signing order. Use this API to enable invitations out of turn — for example, when an earlier signer is unable to sign and you want subsequent signers to proceed. **Authentication:** `X-Auth-Token` header required on every request. ## Request URL ``` PUT https://app1.leegality.com/api/v3.1/invitation/activate?signUrl={signUrl} ``` **Environments:** - Production: `https://app1.leegality.com/api/v3.1/invitation/activate` - Sandbox: `https://sandbox.leegality.com/api/v3.1/invitation/activate` --- ## Parameters | Name | In | Required | Type | Description | Example | |------|----|----------|------|-------------|---------| | `signUrl` | query | Yes | string | The sign URL (invitation URL) of the inactive invitation to activate. The invitation URL is returned in the Create eSigning Request API response for each invitee. Accepts either the full URL (e.g., `https://sandbox.leegality.com/sign/544bf18f-...`) or just the UUID portion (e.g., `544bf18f-91b8-4afb-96ee-8ff1927a2726`). | — | --- ## Responses ### 200 — Default Response Response for the Activate Invitation API. | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `status` | integer | No | API response status. `1` = Success — the invitation has been activated `0` = Failure — check the `messages` array for error details | `1` | | `data` | object | No | Empty object `{}` for both success and error responses. | `[object Object]` | | `messages` | array\ | No | Array of messages. Unlike most other APIs, this field contains a message on **both success and failure**. **Success code:** - `invitation.activate.success` — Invitation activated successfully. The invitee will receive a notification to sign. **Error codes:** - `sign.url.required` — The `signUrl` parameter is missing or empty - `invitation.not.found` — The sign URL is invalid or you do not have access to the document - `invitation.already.activated` — The invitation is already active (no action needed) - `invitation.signed` — The invitation has already been completed (signed/approved) - `invitation.expired` — The invitation has expired. Use the [Reactivate document](https://knowledge.leegality.com/document-execution/api/reactivate-document) API to reactivate expired invitations - `invitation.completed` — The document has already been completed (all signatures collected) - `invitation.manual.activation.not.allowed` — NeSL invitations cannot be manually activated - `sign.invitation.rejected` — The invitation was rejected by the signer. Re-invite the signer first See **Message** below. | — | #### Message Message object containing a machine-readable code and a human-readable description. Used for success confirmations, errors, and warnings. | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `code` | string | No | Response message code. | `simpleWorkFlow.success` | | `message` | string | No | Human-readable success or error message. | `Invitations sent successfully.` | ### Sample Response (200) ```json { "status": 1, "data": {}, "messages": [ { "code": "simpleWorkFlow.success", "message": "Invitations sent successfully." } ] } ``` --- URL: https://knowledge.leegality.com/document-execution/api/esign-docsigner-invitation # POST /v3.0/sign/docSigner/invitation — eSign DocSigner invitation Signs an invitation configured with the **Document Signer Certificate** (DocSigner) sign type via API. **Authentication:** `X-Auth-Token` header required on every request. ## Request URL ``` POST https://app1.leegality.com/api/v3.0/sign/docSigner/invitation ``` **Environments:** - Production: `https://app1.leegality.com/api/v3.0/sign/docSigner/invitation` - Sandbox: `https://sandbox.leegality.com/api/v3.0/sign/docSigner/invitation` --- ## Request Body **Content-Type:** `application/json` Request body for the eSign DocSigner Invitation API. | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `signUrl` | string | Yes | The sign URL (invitation URL) of the invitation to eSign. The invitation must have DocSigner as the allowed signature type, must be active, and must be unsigned. The sign URL is returned in the Create eSigning Request API response. > **Note:** The auth token must belong to the **invitee's account**. If the auth token belongs to a different account (e.g., the sender's account but the invitee is a different user), the API returns `invitation.not.exists`. | `https://sandbox.leegality.com/sign/6069cd1e-961f-47b1-bd27-a` | | `profileId` | string | Yes | The unique identifier of the DocSigner profile saved in the invitee's Leegality dashboard. **How to find it:** Log into the signer's dashboard and navigate to: Settings > eSignature & Seal > Document Signer Certificate This can be any valid DocSigner profile — whether hosted on Leegality's server or the client's own server. | `d4NrfHV` | | `consent` | string | Yes | The exact consent string required to authorize the eSigning. You must pass this string **exactly as shown** — any changes (including case, spacing, or punctuation) will result in an `invalid.consent` error. **Required value:** `By using this authenticated API and the ProfileID associated with this Document Signer Certificate, I agree that the Document Signer Certificate saved in this Account will be used to eSign documents for me. I also understand that recipients of such electronic documents will be able to see my signing details.` | `By using this authenticated API and the ProfileID associated` | ### Sample Request ```json { "signUrl": "https://sandbox.leegality.com/sign/6069cd1e-961f-47b1-bd27-ac7ba1d7363c", "profileId": "d4NrfHV", "consent": "By using this authenticated API and the ProfileID associated with this Document Signer Certificate, I agree that the Document Signer Certificate saved in this Account will be used to eSign documents for me. I also understand that recipients of such electronic documents will be able to see my signing details." } ``` --- ## Responses ### 200 — Default Response Response for the eSign DocSigner Invitation API. | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `status` | integer | No | API response status. `1` = Success — the document has been signed with the DocSigner certificate `0` = Failure — check the `messages` array for error details | `1` | | `data` | object | No | Empty object `{}` for both success and error responses. | `[object Object]` | | `messages` | array\ | No | Array of messages. Unlike most other APIs, this field contains a message on **both success and failure**. **Success code:** - `signing.success` — The document has been signed successfully **Error codes:** - `invitation.not.exists` — The invitation was not found. This can mean: - The sign URL is invalid or does not exist - The invitation is not a DocSigner type - The invitation has already been signed - The invitation has expired or the document is completed - The auth token does not belong to the invitee's account - `invalid.consent` — The consent string does not match the required exact text - `profile.not.exists` — The DocSigner profile ID is invalid or not found in the invitee's account See **Message** below. | — | #### Message Message object containing a machine-readable code and a human-readable description. Used for success confirmations, errors, and warnings. | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `code` | string | No | Response message code. | `simpleWorkFlow.success` | | `message` | string | No | Human-readable success or error message. | `Invitations sent successfully.` | ### Sample Response (200) ```json { "status": 1, "data": {}, "messages": [ { "code": "simpleWorkFlow.success", "message": "Invitations sent successfully." } ] } ``` --- URL: https://knowledge.leegality.com/document-execution/api/delete-invitation # DELETE /v3.0/sign/request/invitation — Delete invitation Deletes an unsigned invitation from a document, permanently removing the invitee's access. **Authentication:** `X-Auth-Token` header required on every request. ## Request URL ``` DELETE https://app1.leegality.com/api/v3.0/sign/request/invitation?signUrl={signUrl} ``` **Environments:** - Production: `https://app1.leegality.com/api/v3.0/sign/request/invitation` - Sandbox: `https://sandbox.leegality.com/api/v3.0/sign/request/invitation` --- ## Parameters | Name | In | Required | Type | Description | Example | |------|----|----------|------|-------------|---------| | `signUrl` | query | Yes | string | Signature URL of the invitation to delete. **Format:** Either the full sign URL or just the UUID portion. Both formats are accepted: - Full URL: `https://sandbox.leegality.com/sign/db9f8b15-84be-47e4-a885-66cdce4bc80c` - UUID only: `db9f8b15-84be-47e4-a885-66cdce4bc80c` Get from the **Create eSigning request** API response (`invitations[].signUrl`) or from the **Check document details** API response. | — | --- ## Responses ### 200 — Delete invitation response. Check `status` field: `1` = success, `0` = failure. Response wrapper for the Delete Invitation API. On success (`status: 1`), `data` is an empty object and `messages` contains `invitation.deleted.success`. On failure (`status: 0`), `data` is an empty object and `messages` contains the error details. | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `status` | integer | No | API response status. `1` = success (invitation deleted), `0` = failure. Allowed: `0`, `1`. | `1` | | `messages` | array\ | No | Array of response messages. **Success codes:** - `invitation.deleted.success` — Invitation deleted successfully. The invitee will no longer be able to access the document. **Error codes:** - `sign.url.required` — The `signUrl` query parameter is missing or empty - `invitation.not.exists` — The invitation was not found. This can mean: - The sign URL is invalid or does not exist - The invitation has already been signed (signed invitations cannot be deleted) - The invitation was already deleted - The document is completed See **Message** below. | — | | `data` | object | No | Always an empty object `{}` for this endpoint. | — | #### Message Message object containing a machine-readable code and a human-readable description. Used for success confirmations, errors, and warnings. | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `code` | string | No | Response message code. | `simpleWorkFlow.success` | | `message` | string | No | Human-readable success or error message. | `Invitations sent successfully.` | ### Sample Response (200) ```json { "status": 1, "messages": [ { "code": "simpleWorkFlow.success", "message": "Invitations sent successfully." } ], "data": {} } ``` --- URL: https://knowledge.leegality.com/document-execution/api/webhooks/webhook-configuration # Webhooks When you send a document for eSigning using Leegality, webhooks can notify you the moment each invitee goes through a signing action — they sign, approve, reject, or fails signature certificate verification, without you having to poll the Check Document Details API. Leegality sends a JSON webhook payload to the endpoint you've configured in the workflow, containing the event type, invitee details, and document status. The payload does not include the signed document or audit trail — use the [Details API](https://knowledge.leegality.com/document-execution/api/check-document-details) to retrieve those once you've received the webhook. ## How It Works 1. You configure webhook URLs for invitee(s) in a document or a workflow in the Leegality dashboard 2. A document is sent using that workflow 3. When an invitee completes or fails a signing action, Leegality sends a JSON payload to the corresponding URL 4. Your server processes the payload and returns any 2XX response 5. If your server does not respond with 2XX, Leegality retries up to 3 more times ## Requirements for Your Endpoint - Must be **publicly accessible** over HTTPS - Must accept **POST** requests with `Content-Type: application/json` - Must return a **2XX** status code (200, 201, or 202) to acknowledge request ## Configuring Webhooks Sender needs to add webhook specific to invitee while creating a workflow. They cannot be set via the Create eSigning Request API. 1. Go to your Leegality dashboard 2. Open the workflow you want to configure (create one if needed) 3. For each invitee, expand **More Options** > **Add custom URLs and webhooks** 4. Enter the URLs you want to receive events on: - **Webhook URL** — for success events - **Error Webhook URL** — for failure and rejection events 5. Set **Webhook Version** to **v2.5** 6. Save the workflow > **Caution** > > Webhook URLs are stored on each document at the time it is sent. Changing URLs on a workflow **does not update documents that have already been sent**. To change webhook URLs for an in-flight document, edit it individually from the dashboard. ## Retry Behavior If your endpoint does not return a 2XX response, Leegality retries the webhook on a fixed schedule: | Attempt | Timing | |---------|--------| | Initial delivery | Immediately when the event occurs | | 1st retry | Immediately after the initial failure | | 2nd retry | 1 hour after the 1st retry | | 3rd retry | 3 hours after the 2nd retry | After 3 failed retries, no further delivery attempts are made. Use the [Check Document Details](https://knowledge.leegality.com/document-execution/api/check-document-details) API to retrieve the document status if a webhook was missed. --- URL: https://knowledge.leegality.com/document-execution/api/webhooks/webhook-event-types # Webhook Event Types ### Success Events Delivered to the **Webhook URL** configured on the invitee. - [Signer Signs Document](https://knowledge.leegality.com/document-execution/api/signer-signs-document) — Signer successfully signed the document - [Reviewer Approves Document](https://knowledge.leegality.com/document-execution/api/reviewer-approves-document) — Reviewer approved the document - [Reviewer Rejects Document](https://knowledge.leegality.com/document-execution/api/reviewer-rejects-document) — Reviewer rejected the document ### Error Events Delivered to the **Error Webhook URL** configured on the invitee. - [Signer Rejects Document](https://knowledge.leegality.com/document-execution/api/signer-rejects-document) — Signer explicitly rejected the document - [Certificate Verification Failed](https://knowledge.leegality.com/document-execution/api/certificate-verification-failed) — Signer's signature certificate details did not match the configured verification criteria and signing was blocked - [Document Expired](https://knowledge.leegality.com/document-execution/api/document-expired) — Document exceeds its configured expiry date ### Coordinate Picker Events Delivered to the **Coordinate Picker Webhook URL**. Only applicable when the **Coordinate Picker** feature is enabled in the workflow. - [Coordinate Picker Webhook](https://knowledge.leegality.com/document-execution/api/coordinate-picker-webhook) — Sender successfully placed coordinates using the Coordinate Picker feature --- URL: https://knowledge.leegality.com/document-execution/api/webhooks/verify-webhook-request # Verify Webhook Request Every webhook payload Leegality sends includes a `mac` field. This is an HMAC-SHA1 signature that lets you confirm the request genuinely came from Leegality and was not tampered with in transit. ## How the MAC Is Computed Leegality computes the `mac` value as: ``` HMAC-SHA1(documentId, privateSalt) ``` Where: - `documentId` is the unique Leegality document ID in the payload - `privateSalt` is your account's private salt from the API Settings tab on the dashboard ## Verification Steps 1. Retrieve your **Private Salt** from **Dashboard** → **API Settings** 2. Extract `documentId` from the incoming webhook payload 3. Compute `HMAC-SHA1(documentId, privateSalt)` on your server 4. Compare your computed value with the `mac` field in the payload 5. If they match — the webhook is authentic. If they don't — discard it. --- URL: https://knowledge.leegality.com/document-execution/api/signer-signs-document # WEBHOOK /your-webhook-endpoint/signer-signs — Invitee Signed Fires when a signer successfully completes a signing action. Delivered to the **Webhook URL** configured on the invitee in the workflow. **Authentication:** `X-Auth-Token` header required on every request. ## Request URL ``` WEBHOOK https://app1.leegality.com/api/your-webhook-endpoint/signer-signs ``` **Environments:** - Production: `https://app1.leegality.com/api/your-webhook-endpoint/signer-signs` - Sandbox: `https://sandbox.leegality.com/api/your-webhook-endpoint/signer-signs` --- ## Request Body **Content-Type:** `application/json` | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `webhookType` | string | No | Indicates whether this is a success or error event. Allowed: `Success`, `Error`. | `Success` | | `documentId` | string | No | The unique Leegality document ID. Use with the [Details API](https://knowledge.leegality.com/document-execution/api/check-document-details) to fetch full document information. | `01KMFEE9T8WPY0WPWXQHQ7DTJ2` | | `documentStatus` | string | No | The document's status at the time of this event. - `"Sent"` — one or more invitees are still pending. - `"Completed"` — all invitees have acted. Allowed: `Draft`, `Sent`, `Completed`. | `Sent` | | `irn` | string | No | Internal Reference Number from the original eSigning request. | `null` | | `mac` | string | No | HMAC-SHA1 of `documentId` using your Private Salt. Use to [verify the webhook](https://knowledge.leegality.com/document-execution/api/webhooks/verify-webhook-request). | `6b736eb163fba3983a0348bc05ffad62a6cbaea1` | | `messages` | array | No | An array of event messages. | `` | | `verification` | object | No | Certificate verification results. Present as an object when verification is configured, regardless of outcome. - **No verification configured** — all fields are `null`. - **Verification configured** — each field is `true` (match), `false` (mismatch), or `null` (that field not configured). `smartName` is an integer (0–100). If the department is set to **"Reject if failed"**, a mismatch triggers the [Certificate Verification Failed](https://knowledge.leegality.com/document-execution/api/certificate-verification-failed) event instead. If set to **"Accept but show results"**, signing proceeds and results appear here. See **verification** below. | — | | `request` | object | No | Details about the invitee associated with this webhook event. See **request** below. | — | #### verification Certificate verification results. Present as an object when verification is configured, regardless of outcome. - **No verification configured** — all fields are `null`. - **Verification configured** — each field is `true` (match), `false` (mismatch), or `null` (that field not configured). `smartName` is an integer (0–100). If the department is set to **"Reject if failed"**, a mismatch triggers the [Certificate Verification Failed](https://knowledge.leegality.com/document-execution/api/certificate-verification-failed) event instead. If set to **"Accept but show results"**, signing proceeds and results appear here. | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `name` | boolean | No | Whether the invitee's name matched the certificate. - `true` — match - `false` — mismatch - `null` — not configured | `null` | | `smartName` | integer | No | Name similarity score against the certificate (0–100). `0` = no match, `100` = exact match. `null` if not configured. | `null` | | `pincode` | boolean | No | Whether the invitee's pincode matched the certificate. - `true` — match - `false` — mismatch - `null` — not configured | `null` | | `state` | boolean | No | Whether the invitee's state matched the certificate. - `true` — match - `false` — mismatch - `null` — not configured | `null` | | `title` | boolean | No | Whether the invitee's title matched the certificate. - `true` — match - `false` — mismatch - `null` — not configured | `null` | | `yob` | boolean | No | Whether the invitee's year of birth matched the certificate. - `true` — match - `false` — mismatch - `null` — not configured | `null` | | `gender` | boolean | No | Whether the invitee's gender matched the certificate. - `true` — match - `false` — mismatch - `null` — not configured | `null` | #### request Details about the invitee associated with this webhook event. | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `inviteeType` | string | No | The role of the invitee in the workflow. Allowed: `Signer`. | `Signer` | | `name` | string | No | The full name of the invitee. | `Abhishek Sharma` | | `email` | string | No | The email address of the invitee. | `abhishek@example.com` | | `phone` | string | No | The phone number of the invitee. | `null` | | `invitationUrl` | string | No | The URL for this invitee to sign or review the document. | `https://sandbox.leegality.com/sign/uuid-here` | | `active` | boolean | No | Indicates whether it is this invitee's turn to act in the signing sequence. | `true` | | `action` | string | No | The action taken by the invitee. Allowed: `Signed`. | `Signed` | | `error` | string | No | Error message for this event. | `null` | | `expired` | boolean | No | Indicates whether the invitation has been terminated. | `false` | | `expiryDate` | string | No | The date and time the invitation is configured to expire. Format: `dd-MM-yyyy HH:mm:ss`. | `03-04-2026 23:59:59` | | `rejectionMessage` | string | No | The rejection reason provided by the invitee. | `null` | | `signType` | string | No | The signature method used. - `AADHAAR` - `VIRTUAL_SIGN` - `QUICK_SIGN` - `DSC` - `NESL_SIGN` - `OFFLINE_SIGN` - `DOC_SIGNER` - `AUTOMATED_SIGN` Allowed: `AADHAAR`, `VIRTUAL_SIGN`, `QUICK_SIGN`, `DSC`, `NESL_SIGN`, `OFFLINE_SIGN`, `DOC_SIGNER`, `AUTOMATED_SIGN`. | `AADHAAR` | ### Sample Request ```json { "webhookType": "Success", "documentId": "01KMFEE9T8WPY0WPWXQHQ7DTJ2", "documentStatus": "Sent", "irn": null, "mac": "6b736eb163fba3983a0348bc05ffad62a6cbaea1", "messages": [], "verification": { "name": null, "smartName": null, "pincode": null, "state": null, "title": null, "yob": null, "gender": null }, "request": { "inviteeType": "Signer", "name": "Abhishek Sharma", "email": "abhishek@example.com", "phone": null, "invitationUrl": "https://sandbox.leegality.com/sign/uuid-here", "active": true, "action": "Signed", "error": null, "expired": false, "expiryDate": "03-04-2026 23:59:59", "rejectionMessage": null, "signType": "AADHAAR" } } ``` --- ## Responses ### 2XX — Return any 2XX status code (200, 201, or 202) to acknowledge receipt. No specific response body is required. Any 2XX status code is accepted. --- URL: https://knowledge.leegality.com/document-execution/api/reviewer-approves-document # WEBHOOK /your-webhook-endpoint/reviewer-approves — Reviewer Approved Fires when a reviewer successfully approves a document. Delivered to the **Webhook URL** configured on the invitee in the workflow. **Authentication:** `X-Auth-Token` header required on every request. ## Request URL ``` WEBHOOK https://app1.leegality.com/api/your-webhook-endpoint/reviewer-approves ``` **Environments:** - Production: `https://app1.leegality.com/api/your-webhook-endpoint/reviewer-approves` - Sandbox: `https://sandbox.leegality.com/api/your-webhook-endpoint/reviewer-approves` --- ## Request Body **Content-Type:** `application/json` | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `webhookType` | string | No | Indicates whether this is a success or error event. Allowed: `Success`, `Error`. | `Success` | | `documentId` | string | No | The unique Leegality document ID. Use with the [Details API](https://knowledge.leegality.com/document-execution/api/check-document-details) to fetch full document information. | `01KMFEE9T8WPY0WPWXQHQ7DTJ2` | | `documentStatus` | string | No | The document's status at the time of this event. - `"Sent"` — one or more invitees are still pending. - `"Completed"` — all invitees have acted. Allowed: `Draft`, `Sent`, `Completed`. | `Sent` | | `irn` | string | No | Internal Reference Number from the original eSigning request. | `null` | | `mac` | string | No | HMAC-SHA1 of `documentId` using your Private Salt. Use to [verify the webhook](https://knowledge.leegality.com/document-execution/api/webhooks/verify-webhook-request). | `6b736eb163fba3983a0348bc05ffad62a6cbaea1` | | `messages` | array | No | An array of event messages. | `` | | `verification` | object | No | Certificate verification results. Not applicable to approvers. | `null` | | `request` | object | No | Details about the invitee associated with this webhook event. See **request** below. | — | #### request Details about the invitee associated with this webhook event. | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `inviteeType` | string | No | The role of the invitee in the workflow. Allowed: `Approver`. | `Approver` | | `name` | string | No | The full name of the invitee. | `Abhishek Sharma` | | `email` | string | No | The email address of the invitee. | `abhishek@example.com` | | `phone` | string | No | The phone number of the invitee. | `null` | | `invitationUrl` | string | No | The URL for this invitee to sign or review the document. | `https://sandbox.leegality.com/sign/52b44c7d-803a-4bc2-adb7-e` | | `active` | boolean | No | Indicates whether it is this invitee's turn to act in the signing sequence. | `true` | | `action` | string | No | The action taken by the invitee. Allowed: `APPROVED`. | `APPROVED` | | `error` | string | No | Error message for this event. | `null` | | `expired` | boolean | No | Indicates whether the invitation has been terminated. | `false` | | `expiryDate` | string | No | The date and time the invitation is configured to expire. Format: `dd-MM-yyyy HH:mm:ss`. | `03-04-2026 23:59:59` | | `rejectionMessage` | string | No | The rejection reason provided by the invitee. | `null` | | `signType` | string | No | The signature method used. Allowed: `null`. | `null` | ### Sample Request ```json { "webhookType": "Success", "documentId": "01KMFEE9T8WPY0WPWXQHQ7DTJ2", "documentStatus": "Sent", "irn": null, "mac": "6b736eb163fba3983a0348bc05ffad62a6cbaea1", "messages": [], "verification": null, "request": { "inviteeType": "Approver", "name": "Abhishek Sharma", "email": "abhishek@example.com", "phone": null, "invitationUrl": "https://sandbox.leegality.com/sign/52b44c7d-803a-4bc2-adb7-efa58ce45fce", "active": true, "action": "APPROVED", "error": null, "expired": false, "expiryDate": "03-04-2026 23:59:59", "rejectionMessage": null, "signType": null } } ``` --- ## Responses ### 2XX — Return any 2XX status code (200, 201, or 202) to acknowledge receipt. No specific response body is required. Any 2XX status code is accepted. --- URL: https://knowledge.leegality.com/document-execution/api/signer-rejects-document # WEBHOOK /your-webhook-endpoint/signer-rejects — Signer Rejected Fires when a signer explicitly rejects a document. Delivered to the **Error Webhook URL** configured on the invitee in the workflow. **Authentication:** `X-Auth-Token` header required on every request. ## Request URL ``` WEBHOOK https://app1.leegality.com/api/your-webhook-endpoint/signer-rejects ``` **Environments:** - Production: `https://app1.leegality.com/api/your-webhook-endpoint/signer-rejects` - Sandbox: `https://sandbox.leegality.com/api/your-webhook-endpoint/signer-rejects` --- ## Request Body **Content-Type:** `application/json` | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `webhookType` | string | No | Indicates whether this is a success or error event. Allowed: `Success`, `Error`. | `Error` | | `documentId` | string | No | The unique Leegality document ID. Use with the [Details API](https://knowledge.leegality.com/document-execution/api/check-document-details) to fetch full document information. | `01KMFPEMC6907ERY22NBBMEEHA` | | `documentStatus` | string | No | The document's status at the time of this event. - `"Sent"` — one or more invitees are still pending. - `"Completed"` — all invitees have acted. Allowed: `Draft`, `Sent`, `Completed`. | `Sent` | | `irn` | string | No | Internal Reference Number from the original eSigning request. | `null` | | `mac` | string | No | HMAC-SHA1 of `documentId` using your Private Salt. Use to [verify the webhook](https://knowledge.leegality.com/document-execution/api/webhooks/verify-webhook-request). | `7e70aaef3f77eb72d3df19c4411e2d397c48c173` | | `messages` | array | No | An array of event messages. | `` | | `verification` | object | No | Certificate verification results. Not applicable to rejection events. | `null` | | `request` | object | No | Details about the invitee associated with this webhook event. See **request** below. | — | #### request Details about the invitee associated with this webhook event. | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `inviteeType` | string | No | The role of the invitee in the workflow. Allowed: `Signer`. | `Signer` | | `name` | string | No | The full name of the invitee. | `Abhishek Sharma` | | `email` | string | No | The email address of the invitee. | `abhishek@example.com` | | `phone` | string | No | The phone number of the invitee. | `null` | | `invitationUrl` | string | No | The URL for this invitee to sign or review the document. | `https://sandbox.leegality.com/sign/3990a31a-19fa-48f3-b032-e` | | `active` | boolean | No | Indicates whether it is this invitee's turn to act in the signing sequence. | `true` | | `action` | string | No | The action taken by the invitee. Allowed: `Rejected`. | `Rejected` | | `error` | string | No | Error message for this event. | `Invitation rejected by the signer.` | | `expired` | boolean | No | Indicates whether the invitation has been terminated. | `false` | | `expiryDate` | string | No | The date and time the invitation is configured to expire. Format: `dd-MM-yyyy HH:mm:ss`. | `03-04-2026 23:59:59` | | `rejectionMessage` | string | No | The rejection reason provided by the signer. Retrieve the signer's reason via the [Details API](https://knowledge.leegality.com/document-execution/api/check-document-details) using `invitations_invitationStatus_signRejectionMessage`. | `null` | | `signType` | string | No | The signature method used. Allowed: `null`. | `null` | ### Sample Request ```json { "webhookType": "Error", "documentId": "01KMFPEMC6907ERY22NBBMEEHA", "documentStatus": "Sent", "irn": null, "mac": "7e70aaef3f77eb72d3df19c4411e2d397c48c173", "messages": [], "verification": null, "request": { "inviteeType": "Signer", "name": "Abhishek Sharma", "email": "abhishek@example.com", "phone": null, "invitationUrl": "https://sandbox.leegality.com/sign/3990a31a-19fa-48f3-b032-e45b6edd836d", "active": true, "action": "Rejected", "error": "Invitation rejected by the signer.", "expired": false, "expiryDate": "03-04-2026 23:59:59", "rejectionMessage": null, "signType": null } } ``` --- ## Responses ### 2XX — Return any 2XX status code (200, 201, or 202) to acknowledge receipt. No specific response body is required. Any 2XX status code is accepted. --- URL: https://knowledge.leegality.com/document-execution/api/reviewer-rejects-document # WEBHOOK /your-webhook-endpoint/reviewer-rejects — Reviewer Rejected Fires when a reviewer rejects a document. Delivered to the **Webhook URL** configured on the invitee in the workflow. **Authentication:** `X-Auth-Token` header required on every request. ## Request URL ``` WEBHOOK https://app1.leegality.com/api/your-webhook-endpoint/reviewer-rejects ``` **Environments:** - Production: `https://app1.leegality.com/api/your-webhook-endpoint/reviewer-rejects` - Sandbox: `https://sandbox.leegality.com/api/your-webhook-endpoint/reviewer-rejects` --- ## Request Body **Content-Type:** `application/json` | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `webhookType` | string | No | Indicates whether this is a success or error event. Allowed: `Success`. | `Success` | | `documentId` | string | No | The unique Leegality document ID. Use with the [Details API](https://knowledge.leegality.com/document-execution/api/check-document-details) to fetch full document information. | `01KGPHV8D39W733W3QBGD5P7SC` | | `documentStatus` | string | No | The document's status at the time of this event. - `"Sent"` — one or more invitees are still pending. - `"Completed"` — all invitees have acted. Allowed: `Draft`, `Sent`, `Completed`. | `Sent` | | `irn` | string | No | Internal Reference Number from the original eSigning request. | `null` | | `mac` | string | No | HMAC-SHA1 of `documentId` using your Private Salt. Use to [verify the webhook](https://knowledge.leegality.com/document-execution/api/webhooks/verify-webhook-request). | `c1515dd8d930a5accd7934d342cc069b23241b23` | | `messages` | array | No | An array of event messages. | `` | | `verification` | object | No | Certificate verification results. Not applicable to approvers. | `null` | | `request` | object | No | Details about the invitee associated with this webhook event. See **request** below. | — | #### request Details about the invitee associated with this webhook event. | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `inviteeType` | string | No | The role of the invitee in the workflow. Allowed: `Approver`. | `Approver` | | `name` | string | No | The full name of the invitee. | `Abhishek 2nd User` | | `email` | string | No | The email address of the invitee. | `abhishek@example.com` | | `phone` | string | No | The phone number of the invitee. | `null` | | `invitationUrl` | string | No | The URL for this invitee to sign or review the document. | `https://sandbox.leegality.com/sign/ee111a86-5f6d-40e7-9a53-d` | | `active` | boolean | No | Indicates whether it is this invitee's turn to act in the signing sequence. | `true` | | `action` | string | No | The action taken by the invitee. Allowed: `REJECTED`. | `REJECTED` | | `error` | string | No | Error message for this event. | `null` | | `expired` | boolean | No | Indicates whether the invitation has been terminated. | `false` | | `expiryDate` | string | No | The date and time the invitation is configured to expire. Format: `dd-MM-yyyy HH:mm:ss`. | `03-04-2026 23:59:59` | | `rejectionMessage` | string | No | The rejection reason provided by the reviewer. | `Document requires amendments before approval.` | | `signType` | string | No | The signature method used. Allowed: `null`. | `null` | ### Sample Request ```json { "webhookType": "Success", "documentId": "01KGPHV8D39W733W3QBGD5P7SC", "documentStatus": "Sent", "irn": null, "mac": "c1515dd8d930a5accd7934d342cc069b23241b23", "messages": [], "verification": null, "request": { "inviteeType": "Approver", "name": "Abhishek 2nd User", "email": "abhishek@example.com", "phone": null, "invitationUrl": "https://sandbox.leegality.com/sign/ee111a86-5f6d-40e7-9a53-d73bfa939473", "active": true, "action": "REJECTED", "error": null, "expired": false, "expiryDate": "03-04-2026 23:59:59", "rejectionMessage": "Document requires amendments before approval.", "signType": null } } ``` --- ## Responses ### 2XX — Return any 2XX status code (200, 201, or 202) to acknowledge receipt. No specific response body is required. Any 2XX status code is accepted. --- URL: https://knowledge.leegality.com/document-execution/api/certificate-verification-failed # WEBHOOK /your-webhook-endpoint/verification-failed — Certificate Verification Failed Fires when a signer's signature certificate does not match the verification criteria configured on the invitee (name, pincode, state, title, year of birth, or gender). The signing attempt is blocked and the invitation is terminated. Delivered to the **Error Webhook URL**. **Authentication:** `X-Auth-Token` header required on every request. ## Request URL ``` WEBHOOK https://app1.leegality.com/api/your-webhook-endpoint/verification-failed ``` **Environments:** - Production: `https://app1.leegality.com/api/your-webhook-endpoint/verification-failed` - Sandbox: `https://sandbox.leegality.com/api/your-webhook-endpoint/verification-failed` --- ## Request Body **Content-Type:** `application/json` | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `webhookType` | string | No | Indicates whether this is a success or error event. Allowed: `Error`. | `Error` | | `documentId` | string | No | The unique Leegality document ID. Use with the [Details API](https://knowledge.leegality.com/document-execution/api/check-document-details) to fetch full document information. | `01KFJ9KFSSFV9E97DHM2QTFQJ2` | | `documentStatus` | string | No | The document's status at the time of this event. - `"Sent"` — one or more invitees are still pending. - `"Completed"` — all invitees have acted. Allowed: `Draft`, `Sent`, `Completed`. | `Sent` | | `irn` | string | No | Internal Reference Number from the original eSigning request. | `null` | | `mac` | string | No | HMAC-SHA1 of `documentId` using your Private Salt. Use to [verify the webhook](https://knowledge.leegality.com/document-execution/api/webhooks/verify-webhook-request). | `b10862af9e05e194e6c6455fc839706ec5c8d554` | | `messages` | array\ | No | An array of event messages. One entry per failed verification field. See **messages** below. | — | | `verification` | object | No | Certificate verification results for each configured field. See **verification** below. | — | | `request` | object | No | Details about the invitee associated with this webhook event. See **request** below. | — | #### messages | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `code` | string | No | Machine-readable verification failure code. - `name.verification.failed` - `smartname.verification.failed` - `pincode.verification.failed` - `state.verification.failed` - `title.verification.failed` - `yob.verification.failed` - `gender.verification.failed` | `name.verification.failed` | | `message` | string | No | Human-readable description of the failure. - `Name doesn't match with the Digital Signature Certificate. Document not signed.` - `Name (Smart Verification) doesn't match with the Digital Signature Certificate. Document not signed.` - `Pincode doesn't match with the Digital Signature Certificate. Document not signed.` - `State doesn't match with the Digital Signature Certificate. Document not signed.` - `Title doesn't match with the Digital Signature Certificate. Document not signed.` - `Year of birth doesn't match with the Digital Signature Certificate. Document not signed.` - `Gender doesn't match with the Digital Signature Certificate. Document not signed.` | `Name doesn't match with the Digital Signature Certificate. D` | #### verification Certificate verification results for each configured field. | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `name` | boolean | No | Whether the invitee's name matched the certificate. - `true` — match - `false` — mismatch - `null` — not configured | `false` | | `smartName` | integer | No | Name similarity score against the certificate (0–100). `0` = no match, `100` = exact match. `null` if not configured. | `0` | | `pincode` | boolean | No | Whether the invitee's pincode matched the certificate. - `true` — match - `false` — mismatch - `null` — not configured | `false` | | `state` | boolean | No | Whether the invitee's state matched the certificate. - `true` — match - `false` — mismatch - `null` — not configured | `false` | | `title` | boolean | No | Whether the invitee's title matched the certificate. - `true` — match - `false` — mismatch - `null` — not configured | `false` | | `yob` | boolean | No | Whether the invitee's year of birth matched the certificate. - `true` — match - `false` — mismatch - `null` — not configured | `false` | | `gender` | boolean | No | Whether the invitee's gender matched the certificate. - `true` — match - `false` — mismatch - `null` — not configured | `false` | #### request Details about the invitee associated with this webhook event. | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `inviteeType` | string | No | The role of the invitee in the workflow. Allowed: `Signer`. | `Signer` | | `name` | string | No | The full name of the invitee. | `John Doe` | | `email` | string | No | The email address of the invitee. | `abhishek@example.com` | | `phone` | string | No | The phone number of the invitee. | `null` | | `invitationUrl` | string | No | The URL for this invitee to sign or review the document. | `https://sandbox.leegality.com/sign/2e4ace49-85bd-4dc6-86f9-c` | | `active` | boolean | No | Indicates whether it is this invitee's turn to act in the signing sequence. | `true` | | `action` | string | No | The action taken by the invitee. Allowed: `null`. | `null` | | `error` | string | No | Error message for this event. | `Verification details doesn't match with the Digital Signatur` | | `expired` | boolean | No | Indicates whether the invitation has been terminated. Can be reactivated from the Leegality dashboard. | `true` | | `expiryDate` | string | No | The date and time the invitation is configured to expire. Format: `dd-MM-yyyy HH:mm:ss`. | `03-04-2026 23:59:59` | | `rejectionMessage` | string | No | The rejection reason provided by the invitee. | `null` | | `signType` | string | No | The signature method used. Allowed: `null`. | `null` | ### Sample Request ```json { "webhookType": "Error", "documentId": "01KFJ9KFSSFV9E97DHM2QTFQJ2", "documentStatus": "Sent", "irn": null, "mac": "b10862af9e05e194e6c6455fc839706ec5c8d554", "messages": [ { "code": "name.verification.failed", "message": "Name doesn't match with the Digital Signature Certificate. Document not signed." } ], "verification": { "name": false, "smartName": 0, "pincode": false, "state": false, "title": false, "yob": false, "gender": false }, "request": { "inviteeType": "Signer", "name": "John Doe", "email": "abhishek@example.com", "phone": null, "invitationUrl": "https://sandbox.leegality.com/sign/2e4ace49-85bd-4dc6-86f9-c41242c35910", "active": true, "action": null, "error": "Verification details doesn't match with the Digital Signature Certificate. Document not signed.", "expired": true, "expiryDate": "03-04-2026 23:59:59", "rejectionMessage": null, "signType": null } } ``` --- ## Responses ### 2XX — Return any 2XX status code (200, 201, or 202) to acknowledge receipt. No specific response body is required. Any 2XX status code is accepted. --- URL: https://knowledge.leegality.com/document-execution/api/document-expired # WEBHOOK /your-webhook-endpoint/invitation-expired — Document Expired Fires when an invitation passes its configured expiry date without the invitee completing the signing action. Delivered to the **Error Webhook URL**. **Authentication:** `X-Auth-Token` header required on every request. ## Request URL ``` WEBHOOK https://app1.leegality.com/api/your-webhook-endpoint/invitation-expired ``` **Environments:** - Production: `https://app1.leegality.com/api/your-webhook-endpoint/invitation-expired` - Sandbox: `https://sandbox.leegality.com/api/your-webhook-endpoint/invitation-expired` --- ## Request Body **Content-Type:** `application/json` | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `webhookType` | string | No | Indicates whether this is a success or error event. Allowed: `Error`. | `Error` | | `documentId` | string | No | The unique Leegality document ID. Use with the [Details API](https://knowledge.leegality.com/document-execution/api/check-document-details) to fetch full document information. | `01KC8ZWZ7ZWNAFTZRYMYMWV84B` | | `documentStatus` | string | No | The document's status at the time of this event. - `"Sent"` — one or more invitees are still pending. - `"Completed"` — all invitees have acted. Allowed: `Draft`, `Sent`, `Completed`. | `Sent` | | `irn` | string | No | Internal Reference Number from the original eSigning request. | `null` | | `mac` | string | No | HMAC-SHA1 of `documentId` using your Private Salt. Use to [verify the webhook](https://knowledge.leegality.com/document-execution/api/webhooks/verify-webhook-request). | `9fc04ef2ce66849096b6c8e393f557794ddd61ac` | | `messages` | array | No | An array of event messages. | `` | | `verification` | object | No | Certificate verification results. | `null` | | `request` | object | No | Details about the invitee associated with this webhook event. See **request** below. | — | #### request Details about the invitee associated with this webhook event. | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `inviteeType` | string | No | The role of the invitee in the workflow. | `Signer` | | `name` | string | No | The full name of the invitee. | `Abhishek 2nd User` | | `email` | string | No | The email address of the invitee. | `abhishek@example.com` | | `phone` | string | No | The phone number of the invitee. | `null` | | `invitationUrl` | string | No | The URL for this invitee to sign or review the document. | `https://sandbox.leegality.com/sign/1e330008-e8e6-46b2-8564-d` | | `active` | boolean | No | Indicates whether it is this invitee's turn to act in the signing sequence. | `true` | | `action` | string | No | The action taken by the invitee. Allowed: `null`. | `null` | | `error` | string | No | Error message for this event. | `Transaction timed out.` | | `expired` | boolean | No | Indicates whether the invitation has been terminated. | `true` | | `expiryDate` | string | No | The date and time the invitation is configured to expire. Format: `dd-MM-yyyy HH:mm:ss`. | `null` | | `rejectionMessage` | string | No | The rejection reason provided by the invitee. | `null` | | `signType` | string | No | The signature method used. Allowed: `null`. | `null` | ### Sample Request ```json { "webhookType": "Error", "documentId": "01KC8ZWZ7ZWNAFTZRYMYMWV84B", "documentStatus": "Sent", "irn": null, "mac": "9fc04ef2ce66849096b6c8e393f557794ddd61ac", "messages": [], "verification": null, "request": { "inviteeType": "Signer", "name": "Abhishek 2nd User", "email": "abhishek@example.com", "phone": null, "invitationUrl": "https://sandbox.leegality.com/sign/1e330008-e8e6-46b2-8564-d55f906bfd24", "active": true, "action": null, "error": "Transaction timed out.", "expired": true, "expiryDate": null, "rejectionMessage": null, "signType": null } } ``` --- ## Responses ### 2XX — Return any 2XX status code (200, 201, or 202) to acknowledge receipt. No specific response body is required. Any 2XX status code is accepted. --- URL: https://knowledge.leegality.com/document-execution/api/coordinate-picker-webhook # WEBHOOK /your-webhook-endpoint/coordinate-picker — Coordinate Picker Leegality sends this payload to the **Coordinate Picker Webhook URL** configured in the invitee-level options when eSign coordinates are successfully placed on the document. **Authentication:** `X-Auth-Token` header required on every request. ## Request URL ``` WEBHOOK https://app1.leegality.com/api/your-webhook-endpoint/coordinate-picker ``` **Environments:** - Production: `https://app1.leegality.com/api/your-webhook-endpoint/coordinate-picker` - Sandbox: `https://sandbox.leegality.com/api/your-webhook-endpoint/coordinate-picker` --- ## Request Body **Content-Type:** `application/json` | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `documentId` | string | No | The unique Leegality document ID for the eSigning request. | `01KJ4SVYM95J35XVVJAXDPA7JW` | | `irn` | string | No | The Internal Reference Number passed in the original eSigning request. Returns `null` if no IRN was provided. | `123456` | | `mac` | string | No | HMAC-SHA1 hash of the `documentId` computed with your Private Salt. Use this to verify the webhook is genuinely from Leegality. | `a9cb19205a780900d33acef52cbf86ae04b3023c` | | `invitations` | array\ | No | Array of invitee objects for this document. Each object represents one invitee with their updated signing URL and status after coordinate placement. See **invitations** below. | — | #### invitations | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `name` | string | No | The full name of the invitee. | `John Doe` | | `email` | string | No | The email address of the invitee. | `john@example.com` | | `phone` | string | No | The phone number of the invitee. | `9876543210` | | `signUrl` | string | No | The unique signing URL for this invitee, generated after coordinate placement. Share this URL with the invitee to proceed to signing. | `https://app1.leegality.com/sign/uuid-here` | | `active` | boolean | No | Whether this invitation is currently active. | `true` | | `expiryDate` | string | No | The expiry date and time of the invitation. | `07-03-2026 23:59:59` | ### Sample Request ```json { "documentId": "01KJ4SVYM95J35XVVJAXDPA7JW", "irn": "123456", "mac": "a9cb19205a780900d33acef52cbf86ae04b3023c", "invitations": [ { "name": "John Doe", "email": "john@example.com", "phone": "9876543210", "signUrl": "https://app1.leegality.com/sign/uuid-here", "active": true, "expiryDate": "07-03-2026 23:59:59" } ] } ``` --- ## Responses ### 2XX — Return any 2XX status code (200, 201, or 202) to acknowledge receipt. No specific response body is required. Any 2XX status code is accepted. --- URL: https://knowledge.leegality.com/document-execution/api/error-reference # Error Reference Error code reference for the Document Execution APIs. ### SSL/TLS Connection Errors SSL/TLS Connection Errors occur when a secure HTTPS connection cannot be established between the client application and the Leegality server. As a result, the API request fails before it reaches the application layer. **Common Root Causes:** - **TLS Version Mismatch:** Client is using an older TLS version (e.g., TLS 1.0 or TLS 1.1) while the server supports only TLS 1.2 or above. - **Untrusted or Missing Root/Intermediate Certificates:** The client system does not trust the certificate chain presented by the server. - **SSL Certificate Validation Failure:** Hostname mismatch, expired certificate, or invalid certificate chain. - **Firewall or Proxy Interference:** Corporate firewall or proxy is intercepting SSL traffic and preventing successful handshake. - **SSL Handshake Failure:** Cipher suite mismatch between client and server, or unsupported encryption algorithms. - **Network Connectivity Issues:** Intermittent network failures causing connection termination during SSL negotiation. - **Incorrect Trust Store Configuration:** Required root/intermediate certificates are not imported into the application's trust store (Java Keystore, Windows Certificate Store, etc.). - **Mutual TLS (mTLS) Configuration Issues:** If applicable, client certificate is missing, expired, or incorrectly configured.
CodeMessageDescriptionSolution
(TLS handshake failure)
  • SSLHandshakeException
  • PKIX path building failed
  • Certificate path validation failed
  • Received fatal alert: handshake_failure
  • Unable to find valid certification path to requested target
  • javax.net.ssl.SSLException
  • A timeout error occurred whilst performing an SSL socket operation
 The client cannot establish a secure TLS connection with the Leegality server.
  1. Verify the endpoint URL is HTTPS.
  2. Confirm the client supports TLS 1.2 or higher.
  3. Check whether the SSL certificate is valid and trusted.
  4. Verify firewall/proxy restrictions.
  5. Review application logs for SSL handshake exceptions.
  6. Test connectivity using tools such as OpenSSL, Postman, or Curl.
  7. Compare successful and failed requests.
  8. Check whether the issue occurs for all API calls or only specific endpoints.
### Authentication Errors | Code | Message | Description | Solution | |------|---------|-------------|----------| | null | Access Denied | The `X-Auth-Token` header is missing from the request | Add the `X-Auth-Token` header with a valid authentication token | | *(empty)* | *(HTTP 401/403)* | The provided authentication token is invalid or expired | Obtain a new valid authentication token from the dashboard | ### Required Field Errors | Code | Message | Description | Solution | |------|---------|-------------|----------| | null | Property profileId cannot be null | The `profileId` field is missing or set to null | Provide a valid workflow profile ID in the `profileId` field | | null | Property file cannot be null | The `file` object is missing from the request | Include a `file` object with either `base64` content or `fields` array | | workflow.api.fields.or.file.required | Either file base64 or fields required for file. | The `file.fields` array is empty, OR the `profileId` is invalid/non-existent | Provide either `file.file` with document content OR `file.fields` with form field values. Also verify the `profileId` exists | | simpleWorkFlow.no.payload.invitee | Either send Invitees data or configure at least one Invitees in dashboard | The `invitees` array is empty and no invitees are configured in dashboard | Provide at least one invitee in the `invitees` array with name and email/phone | ### Invitee Validation Errors | Code | Message | Description | Solution | |------|---------|-------------|----------| | null | Invitee(N) name is required. | The invitee at index N has an empty or missing name | Provide a non-empty `name` for each invitee | | null | Invitee(N) email or phone is required. | The invitee at index N has neither email nor phone | Provide at least one of `email` or `phone` for each invitee | | null | Invitee(N) email is invalid. | The email format for invitee at index N is invalid | Provide a valid email address (e.g., `user@domain.com`) | | signer.reviewer.name.invalid[N] | Signer/Reviewer name is invalid for invitee N. | The invitee name contains invalid special characters (`<`, `>`, `'`, `&`, etc.) or Unicode | Use only alphanumeric characters, spaces, and basic punctuation (`.`, `-`, `,`) in names | | invitee.org.name.invalid[N] | Organisation name, under company seal, is invalid for Invitee N. | The `organizationName` contains invalid characters (HTML tags, `<`, `>`, etc.) | Use only alphanumeric characters and basic punctuation in organization name | | invalid.group.name[N] | Invalid input in Group Name. | The `groupName` contains invalid special characters | Use only alphanumeric characters and allowed special chars: `| - : () , _. [] & / # + @` | ### File & Fields Errors | Code | Message | Description | Solution | |------|---------|-------------|----------| | null | Property file cannot be null | The `file` object is completely missing | Include a `file` object in your request | | workflow.api.fields.or.file.required | Either file base64 or fields required for file. | Neither `file.file` nor `file.fields` is provided, or `fields` is an empty array | Provide `file.file` with base64-encoded document content, OR provide `file.fields` array with field values matching the workflow template | ### IRN Errors | Code | Message | Description | Solution | |------|---------|-------------|----------| | irn.length.invalid | IRN can not be greater than 255 characters. | The Internal Reference Number exceeds 255 characters | Shorten the IRN to 255 characters or less | ### Stamp Configuration Errors | Code | Message | Description | Solution | |------|---------|-------------|----------| | null | Stamp Series required for this Workflow Profile | Stamp is enabled in workflow but `stampSeries` or `multipleStampSeries` is missing/empty/null | Provide a valid `stampSeries` or `multipleStampSeries` array when stamp is enabled in the workflow | | invalid.stamp.series.value | Invalid input in stamp series. Allowed input includes numeric characters only. | The `stampSeries` contains non-numeric characters | Use only numeric characters (0-9) for stamp series. Example: `"03"` not `"TEST-03"` | | no.active.series.or.no.stamp.found | No active series found or sufficient active stamps not found in the series. | The stamp series doesn't exist, has no available stamps, or the format doesn't match exactly | Verify the series exists in dashboard, check stamp availability, match format exactly (e.g., `"03"` not `"3"` or `"003"`) | | workflow.stamp.series.mismatch | Stamp Series Number [X] mismatch with configured workflow. | The API-provided stamp series doesn't match the pre-configured series in dashboard | Use the exact stamp series configured in the workflow dashboard | | multiple.stamp.states.used | Please use stamps of same state only. | The `multipleStampSeries` array contains stamps from different states | Ensure all stamps in `multipleStampSeries` are from the same state | | stamp.quantity.less.than.1 | For multiple series minimum quantity per series is 1. | The `seriesQuantity` is 0, empty, or missing | Provide `seriesQuantity` with a value of at least `"1"` for each entry | | invalid.stamp.series.group | Invalid input in stamp group. Allowed input includes alphanumeric characters only. | The `seriesGroup` contains special characters | Use only alphanumeric characters (A-Z, a-z, 0-9) for `seriesGroup` | | workflow.excel.stamp.amount.invalid | Invalid Stamp Amount/Quantity. | The `stampValue` contains non-numeric characters | Provide a numeric string for `stampValue`. Example: `"100"` not `"abc"` | | stamp.value.exceeds.maximum.allowed.group.limit | Stamp value exceeds maximum allowed series group limit. | The `stampValue` exceeds the maximum allowed for the series group | Reduce the `stampValue` to within the allowed limit | | invalid.revenue.stamp.series | Invalid input in revenue stamp. Allowed input includes numeric characters only. | The `revenueStampSeries` contains non-numeric characters | Use only numeric characters for `revenueStampSeries` | | stamp.group.does.not.exist | Stamp group does not exist. | The `seriesGroup` value doesn't match any existing stamp group | Use a valid stamp group code that exists in your account | | no.stamp.combinations.found | Insufficient stamps in the stamp group to create desired stamp value. | The stamp group doesn't have enough stamps to create the requested value | Reduce the `stampValue` or ensure the stamp group has sufficient stamps | | selected.group.max.value.exceeded | Maximum allowed value for the selected group is Rs [X]... | The `stampValue` exceeds the maximum configured for the stamp group | Reduce the `stampValue` to be within the group's configured maximum | | null | Stamp Group is required for this Profile. | `seriesGroup` is missing when stamp group feature is enabled | Provide a valid `seriesGroup` value | | null | Stamp Amount is required. | `stampValue` is missing or zero when stamp group feature is enabled | Provide a valid non-zero `stampValue` | ### Face Match Errors | Code | Message | Description | Solution | |------|---------|-------------|----------| | workflow.face.match.invalid.image | The reference image for face match is either empty or invalid (max size - 4.5MB, formats - jpg, jpeg or png). | The `faceMatchImage` is empty, missing, or exceeds size/format limits | Provide a valid base64-encoded image (jpg/jpeg/png, max 4.5MB) | | invitee.invalid.face.match.image | Face Match Image type is invalid. | The `faceMatchImage` contains invalid base64 data or includes a data URI prefix | Remove any data URI prefix (e.g., `data:image/png;base64,`) and provide only the raw base64 string | ### GPS Configuration Errors | Code | Message | Description | Solution | |------|---------|-------------|----------| | typeMismatch | Property allowedLatitude is type-mismatched | The GPS coordinates are not in the correct format (non-numeric) | Provide coordinates as string decimal values. Example: `"29.982643"` | | location.restriction.true.allowed.longitude.required | allowedLongitude configured mandatory when applyLocationRestriction=true, value is required. | GPS location restriction is enabled but longitude is empty | Provide both `allowedLatitude` and `allowedLongitude` when `applyLocationRestriction` is true | | location.restriction.true.allowed.latitude.required | allowedLatitude configured mandatory when applyLocationRestriction=true, value is required. | GPS location restriction is enabled but latitude is empty | Provide both `allowedLatitude` and `allowedLongitude` when `applyLocationRestriction` is true | | invalid.gps.accuracy.permissableRadius | Invalid Permissible Radius. Enter any number from 0 to 9999999 | The `permissibleRadius` is negative or outside the valid range | Provide a value between 0 and 9999999 | | invalid.gps.accuracy.deviation | Please enter a valid value for Default Allowed Accuracy Deviation Acceptance Condition (Range : 0-99999) | The `accuracyThreshold` is negative or outside the valid range | Provide a value between 0 and 99999 | ### Group Invitee Errors | Code | Message | Description | Solution | |------|---------|-------------|----------| | null | Group Id: [ID], Group name is required. | A group invitee is missing the `groupName` field | Provide `groupName` for all invitees with a `groupId` | | null | Group Name: [name], Completion Threshold is required. | The `completionThreshold` is missing, empty, or zero for a group | Provide a `completionThreshold` value of at least 1 | | null | GroupName: [name], Completion Threshold value cannot be greater than invitees in group. | The `completionThreshold` exceeds the number of invitees in the group | Set `completionThreshold` to be less than or equal to the number of invitees in the group | | group.invitees.workflow.incorrect.payload | Group ID [ID] cannot have more than 0 Invitees. | The `groupId` doesn't match the workflow-configured group | Use the exact `groupId` configured in the workflow dashboard | ### 2FA Errors | Code | Message | Description | Solution | |------|---------|-------------|----------| | null | Invitee(N) Two-Factor Authentication enabled hence Email and Phone No. can not be empty. | 2FA is enabled but the invitee is missing email or phone | Provide BOTH `email` AND `phone` for all invitees when 2FA is enabled | ### CC Recipients Errors | Code | Message | Description | Solution | |------|---------|-------------|----------| | null | CCInvitee(N) email is invalid. Either send CC Invitees data or configure in dashboard. | The CC recipient email format is invalid OR CC configuration mismatch | Provide a valid email address for CC recipients and ensure CC invitees are configured in dashboard | ### Signing-Time Errors These errors occur during the signing process, not at document creation. The API accepts these configurations but signing fails. | Code | Message | Description | Solution | |------|---------|-------------|----------| | *(signing error)* | You are outside the permissible area. | The signer's GPS location is outside the allowed radius | Verify coordinates are correct, increase `permissibleRadius`. Do not use `permissibleRadius: 0` | | *(signing error)* | Your GPS location accuracy is low. | The signer's device GPS accuracy doesn't meet the threshold | Increase `accuracyThreshold` to a reasonable value (e.g., 100-1000). Do not use `accuracyThreshold: 0` | ### GPS Config Ignored (Feature Not Enabled) > **Warning — warnings** > > These are warnings returned in a successful response (status: 1). The request succeeds but values are ignored. | Code | Message | Description | Solution | |------|---------|-------------|----------| | workflow.captureLocation.off.allowed.latitude.ignored | Invitee(N) captureLocation is not on. allowedLatitude value ignored. | GPS is not enabled in workflow but coordinates were sent | Enable GPS in workflow dashboard, or remove `gpsConfig` from request | | workflow.captureLocation.off.allowed.longitude.ignored | Invitee(N) captureLocation is not on. allowedLongitude value ignored. | GPS is not enabled in workflow but coordinates were sent | Enable GPS in workflow dashboard, or remove `gpsConfig` from request | | workflow.captureLocation.off.permissable.radius.ignored | Invitee(N) captureLocation is not on. permissableRadius value ignored. | GPS is not enabled in workflow but radius was sent | Enable GPS in workflow dashboard, or remove `gpsConfig` from request | ### GPS Config Ignored (Toggle OFF) > **Warning — warnings** > > These are warnings returned in a successful response (status: 1). The request succeeds but values are ignored. When "Allow sender to make changes while running" toggle is OFF in dashboard: | Code | Message | Description | Solution | |------|---------|-------------|----------| | workflow.allowGpsConfigChange.off.allowed.latitude.ignored | Invitee(N) allowGpsConfigChange is not on. allowedLatitude value ignored. | API latitude is ignored; dashboard value used instead | Turn ON "Allow sender to make changes" toggle in workflow | | workflow.allowGpsConfigChange.off.allowed.longitude.ignored | Invitee(N) allowGpsConfigChange is not on. allowedLongitude value ignored. | API longitude is ignored; dashboard value used instead | Turn ON "Allow sender to make changes" toggle in workflow | | workflow.allowGpsConfigChange.off.permissable.radius.ignored | Invitee(N) allowGpsConfigChange is not on. permissableRadius value ignored. | API radius is ignored; dashboard value used instead | Turn ON "Allow sender to make changes" toggle in workflow | | workflow.allowGpsConfigChange.off.accuracy.deviation.ignored | Invitee(N) allowGpsConfigChange is not on. accuracyThreshold value ignored. | API accuracy threshold is ignored; dashboard value used instead | Turn ON "Allow sender to make changes" toggle in workflow | | workflow.allowGpsConfigChange.off.location.restriction.ignored | Invitee(N) allowGpsConfigChange is not on. applyLocationRestriction value ignored. | API location restriction flag is ignored | Turn ON "Allow sender to make changes" toggle in workflow | | workflow.allowGpsConfigChange.off.accuracy.restriction.ignored | Invitee(N) allowGpsConfigChange is not on. applyLocationAccuracy value ignored. | API accuracy restriction flag is ignored | Turn ON "Allow sender to make changes" toggle in workflow | ### Stamp Group Ignored (Dashboard Pre-defined) > **Warning — warnings** > > These are warnings returned in a successful response (status: 1). The request succeeds but values are ignored. | Code | Message | Description | Solution | |------|---------|-------------|----------| | workflow.stamp.warning | Warning: Stamp series already assigned to profile, given value for stamp series ignored. | seriesGroup is pre-defined in dashboard; API value is ignored | Use the dashboard-configured seriesGroup value, or remove seriesGroup from request | ### Aadhaar Config Ignored (Verification Disabled) > **Warning — warnings** > > These are warnings returned in a successful response (status: 1). The request succeeds but values are ignored. | Code | Message | Description | Solution | |------|---------|-------------|----------| | invitee.aadhaar.config.verify.certificate.off.property.ignored | Invitee(N) verify certificate details is not on. [property] value ignored. | Aadhaar verification master toggle not enabled | Enable Aadhaar verification in workflow dashboard | | invitee.aadhaar.config.verify.off.name.ignored | Invitee(N) verifyNameOn is not on. verifyName value ignored. | Name verification toggle disabled | Enable "Verify Name" toggle on dashboard | | invitee.aadhaar.config.verify.off.smartname.ignored | Invitee(N) verifySmartNameOn is not on. verifySmartName value ignored. | Smart name verification toggle disabled | Enable "Verify Smart Name" toggle on dashboard | | invitee.aadhaar.config.verify.off.yob.ignored | Invitee(N) verifyYobOn is not on. verifyYob value ignored. | Year of birth verification toggle disabled | Enable "Verify YOB" toggle on dashboard | | invitee.aadhaar.config.verify.off.gender.ignored | Invitee(N) verifyGenderOn is not on. verifyGender value ignored. | Gender verification toggle disabled | Enable "Verify Gender" toggle on dashboard | | invitee.aadhaar.config.verify.off.title.ignored | Invitee(N) verifyTitleOn is not on. verifyTitle value ignored. | Title verification toggle disabled | Enable "Verify Title" toggle on dashboard | | invitee.aadhaar.config.verify.off.pincode.ignored | Invitee(N) verifyPincodeOn is not on. verifyPincode value ignored. | Pincode verification toggle disabled | Enable "Verify Pincode" toggle on dashboard | | invitee.aadhaar.config.verify.off.state.ignored | Invitee(N) verifyStateOn is not on. verifyState value ignored. | State verification toggle disabled | Enable "Verify State" toggle on dashboard | ### Aadhaar Config Validation Errors | Code | Message | Description | Solution | |------|---------|-------------|----------| | typeMismatch[N] | Property N is type-mismatched | Aadhaar field has wrong type (e.g., string instead of boolean, or invalid enum value) | Check field types: verifyName/verifySmartName are booleans; verifyYob/verifyGender/verifyState/verifyPincode are strings | | certificate.pin.code.invalid[N] | Certificate pin code is invalid for invitee N. | Invalid pincode format in verifyPincode | Use valid 6-digit numeric pincode string (e.g., `"110001"`) | | certificate.title.invalid[N] | Certificate title is invalid for invitee N. | Invalid verifyTitle format | Use last 4 digits of Aadhaar number (e.g., `"3870"`), NOT titles like "Mr"/"Shri" | | null | Invitee(N) configured mandatory for Aadhaar [field] verification, value is required. | Toggle is enabled on dashboard but API didn't send value | Provide value for enabled verification fields | ### NeSL Required Data Errors These errors occur when required NeSL data is missing or incomplete. | Code | Message | Description | Solution | |------|---------|-------------|----------| | nesl.sign.neslRequestData.required | Required nesl api data for nesl sign. | The `neslData` object is missing from the request when an invitee has NeSL eSign type | Include the `neslData` object with `documentDetail`, `participants`, and optionally `stampData` | | nesl.stamp.data.required | At least one stamp data is required for stamping flow. | stampData array is empty and participants are missing or invalid | Provide at least one entry in `stampData`, or ensure `participants` array is valid | | nesl.participants.equal.nesl.invitees | Participants should be equal to nesl invitees. | The number of entries in `participants` doesn't match the number of NeSL-type invitees | Ensure `participants` count equals the number of invitees with NeSL eSign type | | nesl.first.invitee.party.debtor | Invitee/Party 1 should have Contact Relation 'Debtor'. | The first participant doesn't have `contactRelation` set to `DEBTOR`, or `fullName` is missing | Set the first participant's `contactRelation` to `DEBTOR` and ensure `fullName` is provided | | null | Invitee(N) configured mandatory for Nesl [field] verification, value is required., | NeSL verification is enabled on dashboard but the corresponding `neslConfig` field is missing | Provide all mandatory `neslConfig` verification fields (verifyPincode, verifyState, verifyYob, verifyTitle, verifyGender) | ### NeSL Document Detail Errors ### Missing Required Fields These errors follow the pattern `neslData.documentDetail.[field].validator.invalid` or `neslData.documentDetail.[field].nullable`. | Code | Message | Description | Solution | |------|---------|-------------|----------| | neslData.documentDetail.[field].validator.invalid | [field] is required for document detail. | A required documentDetail field is missing | Provide the required field. Required fields vary by `registrationType` — see below | | neslData.documentDetail.[field].nullable | [field] is required for document detail. | A required documentDetail field is null | Provide a non-null value for the field | | neslData.documentDetail.docRefNo.validator.invalid | docRefNo is required for document detail. | `docRefNo` is missing for `NON_LENDING` registrationType | Provide an alphanumeric `docRefNo` value | ### Enum Validation Errors | Code | Message | Description | Solution | |------|---------|-------------|----------| | registration.type.invalid | Invalid registration type. | The `registrationType` value is not recognized | Use one of: `INDIVIDUAL_LOAN`, `NON_INDIVIDUAL_LOAN`, `NON_LENDING`, `EBG` | | debt.type.invalid | Invalid debt type. | The `typeOfDebt` value is not recognized | Use one of: `FINANCIAL`, `OPERATIONAL` | | acount.closed.flag.type.invalid | Invalid account closed flag. | The `accountClosedFlag` value is not recognized. Note: error code has typo "acount" | Use one of: `YES`, `NO`, `ASSIGNED` | | fund.type.invalid | Invalid fund type. | The `fundType` value is not recognized | Use one of: `FUNDED`, `NON_FUNDED` | | sanction.currency.type.invalid | Invalid currency type. | The `sanctionCurrency` value is not recognized | Use `INR` (only accepted value) | | credit.sub.type.invalid | Invalid credit sub type. | The `creditSubtype` value is not valid for the given `registrationType` | Use `CREDIT_FACILITY` or `PROPERTY_BUYER` for INDIVIDUAL_LOAN / NON_INDIVIDUAL_LOAN | | event.type.invalid | Invalid event type. | The `event` value is not recognized (EBG only) | Use a valid event type value for EBG | ### Format Validation Errors | Code | Message | Description | Solution | |------|---------|-------------|----------| | nesl.field.date.error | Please enter date Of Sanction in format YYYY-MM-DD. | The `dateOfSanction` is not in the required date format | Use `YYYY-MM-DD` format (e.g., `2018-02-02`) | | field.value.alphanumeric | Please enter the correct value of Document Reference Number in alphanumeric characters only. | The `docRefNo` contains non-alphanumeric characters (hyphens, spaces, etc.) | Use only letters and numbers (e.g., `DOCREF001` not `DOC-REF-001`) | ### NeSL Participant Errors ### Missing Required Fields | Code | Message | Description | Solution | |------|---------|-------------|----------| | invitee.field.required | Mobile Number is required for NESL request for invitee N. | The participant is missing `mobileNumber` | Provide `mobileNumber` for each participant | | invitee.field.required | Date of Birth is required for NESL request for invitee N. | The participant is missing `dob` | Provide `dob` in `YYYY-MM-DD` format | | invitee.field.required | Official DocId is required for NESL request for invitee N. | The participant is missing `officialDocId` | Provide the document ID matching the `officialDocType` | | invitee.field.required | Official Doc is required for NESL request for invitee N. | The participant is missing `officialDocType` | Provide one of: `PAN_CARD`, `DRIVING_LICENSE`, `VOTER_ID`, `PASSPORT`, `ANY_OTHER_OFFICIAL_ID` | | invitee.field.required | Legal Constitution is required for NESL request for invitee N. | The participant is missing `legalConstitution` | Provide a valid `legalConstitution` value (e.g., `RESIDENT_INDIVIDUAL`, `PRIVATE_LTD`) | | invitee.field.required | PartyType is required for NESL request for invitee N. | The participant is missing `partyType` | Provide one of: `INDIAN_ENTITY`, `RESIDENT_INDIVIDUAL`, `FOREIGN_ENTITY`, `NRI` | | invitee.field.required | Registered Address is required for NESL request for invitee N. | Required for `NON_INDIVIDUAL_LOAN` participants | Provide `registeredAddress` for NON_INDIVIDUAL_LOAN | | invitee.field.required | Registered Pin Code is required for NESL request for invitee N. | Required for `NON_INDIVIDUAL_LOAN` participants | Provide `registeredPinCode` for NON_INDIVIDUAL_LOAN | | invitee.field.required | Communication Address is required for NESL request for invitee N. | Required for `NON_INDIVIDUAL_LOAN` participants | Provide `communicationAddress` for NON_INDIVIDUAL_LOAN | | invitee.field.required | Communication Address Pin Code is required for NESL request for invitee N. | Required for `NON_INDIVIDUAL_LOAN` participants | Provide `communicationAddressPinCode` for NON_INDIVIDUAL_LOAN | ### Enum Validation Errors | Code | Message | Description | Solution | |------|---------|-------------|----------| | party.type.invalid | Invalid party type. | The `partyType` value is not recognized | Use one of: `INDIAN_ENTITY`, `RESIDENT_INDIVIDUAL`, `FOREIGN_ENTITY`, `NRI` | | constitution.type.invalid | Invalid constitution type. | The `legalConstitution` value is not recognized | Use one of: `RESIDENT_INDIVIDUAL`, `PUBLIC_LTD`, `PRIVATE_LTD`, `LLP`, `PROPRIETORSHIP`, `PARTNERSHIP`, `ENTITY_CREATED_BY_STATUTE`, `TRUST`, `HUF`, `CO_OP_SOCIETY`, `ASSOCIATION_OF_PERSONS`, `GOVERNMENT`, `SELF_HELP_GROUP`, `NON_RESIDENT`, `FOREIGN_COMPANY` | | invitee.field.invalid | Please enter Contact Relation valid value for invitee N. | The `contactRelation` value is not recognized | Use one of: `CREDITOR`, `DEBTOR`, `GUARANTOR`, `CO_OBLIGANT`, `SECURITY_PROVIDER`, `ASSIGNEE`, `BENEFICIARY` | | official.doc.type.invalid | Invalid doc type. | The `officialDocType` value is not recognized | Use one of: `PAN_CARD`, `DRIVING_LICENSE`, `VOTER_ID`, `PASSPORT`, `ANY_OTHER_OFFICIAL_ID`. Note: `AADHAAR` is not valid | ### Format Validation Errors | Code | Message | Description | Solution | |------|---------|-------------|----------| | invitee.field.date.error | Please enter Date of Birth in format YYYY-MM-DD for invitee N. | The `dob` is not in the required date format | Use `YYYY-MM-DD` format (e.g., `2020-12-10`) | | invitee.field.value.alphanumeric | Please enter the correct value of Contact Person in alphanumeric characters only for invitee N. | The `contactPersonName` contains non-alphanumeric characters (hyphens, etc.) | Use only letters, numbers, and spaces in `contactPersonName` | | invitee.field.pan | Please enter Pan Card valid pan number for invitee N. | The `officialDocId` is not a valid PAN format when `officialDocType` is `PAN_CARD` | Provide a valid 10-character PAN number (e.g., `BHSPM9753J`) | | invitee.field.pan.error | Please enter valid pan number(C or E as fourth letter) for invitee N. | For `NON_INDIVIDUAL_LOAN`, the PAN must be a company PAN (4th letter C or E) | Use a company PAN with C or E as the 4th character (e.g., `AABCE1234F`) | ### NeSL Stamp Data Errors | Code | Message | Description | Solution | |------|---------|-------------|----------| | neslData.stampDatas.validator.invalid | firstParty is required for stamp N | The `firstParty` field is missing in stamp data entry N | Provide `firstParty` name for each stamp data entry | | neslData.stampDatas.validator.invalid | secondParty is required for stamp N | The `secondParty` field is missing in stamp data entry N | Provide `secondParty` name for each stamp data entry | | neslData.stampDatas.validator.invalid | stampDutyAmount is required for stamp N | The `stampDutyAmount` field is missing in stamp data entry N | Provide `stampDutyAmount` for each stamp data entry | | neslData.stampDatas.validator.invalid | considerationPrice is required for stamp N | The `considerationPrice` field is missing in stamp data entry N | Provide `considerationPrice` for each stamp data entry | | neslData.stampDatas.validator.invalid | descriptionOfDocument is required for stamp N | The `descriptionOfDocument` field is missing in stamp data entry N | Provide `descriptionOfDocument` for each stamp data entry | | neslData.stampDatas.validator.invalid | stampDutyPaidBy is required for stamp N | The `stampDutyPaidBy` field is missing in stamp data entry N | Provide `stampDutyPaidBy` for each stamp data entry | | neslData.stampDatas.validator.invalid | articleCode is required for stamp N | The `articleCode` field is missing in stamp data entry N | Provide `articleCode` for each stamp data entry | ### NeSL Security Errors | Code | Message | Description | Solution | |------|---------|-------------|----------| | neslData.neslSecurities.validator.invalid | assetsType is required for security N | The `assetsType` field is missing in security entry N | Provide one of: `MOVABLE`, `IMMOVABLE`, `INTANGIBLE`, `NOT_CLASSIFIED` | | neslData.neslSecurities.validator.invalid | chargeType is required for security N | The `chargeType` field is missing in security entry N | Provide one of: `MORTGAGE`, `HYPOTHECATION`, `CHARGE`, `ASSIGNMENT`, `PLEDGE`, `LIEN`, `NEGATIVE_LIEN`, `GUARANTEE`, `OTHERS`, `NOT_CLASSIFIED` | | neslData.neslSecurities.validator.invalid | assetId is required for security N | The `assetId` field is missing in security entry N | Provide an asset ID string | | neslData.neslSecurities.validator.invalid | securityDescription is required for security N | The `securityDescription` field is missing in security entry N | Provide a description of the security | ### NeSL Config Validation Errors | Code | Message | Description | Solution | |------|---------|-------------|----------| | typeMismatch[N] | Property N is type-mismatched | A neslConfig field has an invalid value (e.g., invalid `verifyGender` like "X") | Check field values: `verifyGender` must be `M`, `F`, or `T`; `verifyYob` accepts integer or string | | certificate.pin.code.invalid[N] | Certificate pin code is invalid for invitee N. | The `verifyPincode` is not a valid 6-digit pin code (e.g., `"ABC"`) | Use a valid 6-digit numeric pincode string (e.g., `"247667"`) | ## POST /v3.0/sign/request/reactivate — Reactivate Document | Code | Message | Description | Solution | |------|---------|-------------|----------| | signinvitation.activate.success | Invitation activated successfully | *(Success — not an error)* | — | | no.expired.invitation.found | No expired invitation exists | The document is completed, rejected, active, or already reactivated — no expired invitation to reactivate | Verify the document status before calling this endpoint. Only expired documents can be reactivated | | no.document.found | No document found | The provided document ID does not exist | Check that the `documentId` is correct and belongs to your account | | invalid.expiry.days.value | Invalid expiry days value | `expiryDays` is outside the valid range | Provide a value between `-1` and `365`. Use `-1` for no expiry | | invalid.expiry.time | Invalid expiry time | `expiryTime` is in the past or is a negative timestamp | Provide a future Unix timestamp (milliseconds) for `expiryTime` | | invalid.expiry.time.maxerror | Invalid expiry time — exceeds maximum | `expiryTime` is more than 365 days from now | Provide an `expiryTime` within 365 days from the current date | --- URL: https://knowledge.leegality.com/document-execution/api/customise-signing-journey # Customise Signing Journey Leegality customers can now control the user experience of the signing journey without relying on our SDKs. This option provides new query parameters to enhance the user experience of the Success Page. ## Dynamic Redirect URL - **Parameter:** `redirectUrl` - **Description:** Redirect invitees to a specific URL after they complete the signing process. - **Possible value:** Any https URL with a valid format. **Example:** `https://app1.leegality.com/sign/ea83da79-b228-492b-9e81-dad68trea4b5?redirectUrl=https://google.com` > **Info** > > If a redirect URL is specified in the workflow, it will override any redirect URL appended to the signURL using the `redirectUrl` parameter. ## Custom Countdown Timer - **Parameter:** `timer` - **Description:** Set how long the success page stays open before redirecting to the redirectUrl. - **Possible value:** 0 to 60 **Example:** `https://app1.leegality.com/sign/ea83ee79-b228-999b-9e49-faf68dade4b5?timer=30` > **Info** > > If the invitee clicks the **OK** button before the timer expires, they will be redirected immediately. ## Control the Visibility of the OK Button - **Parameter:** `Okbutton` - **Description:** Decide whether the **OK** button is shown on the success page. By default, OK button is always visible to the invitee. - **Possible value:** `false` **Example:** `https://app1.leegality.com/sign/ea83ee79-b999-492b-9e44-faf68dade4b5?timer=30\&Okbutton=false` In this example, the OK button will not be displayed on the success page because `Okbutton=false`. > **Info** > > The OK button will be displayed if the parameter is not passed. --- URL: https://knowledge.leegality.com/document-execution/api/resources # SDKs and Utilities SDKs and utilities to help you integrate Leegality APIs into your platform. [Web SDK Front-end SDK for integrating Leegality into web applications](https://gitlab.leegality.com/leegality-public/web-sdk) [Android SDK Front-end SDK for integrating Leegality into Android applications](https://gitlab.leegality.com/leegality-public/android-sdk) [Android Biometric SDK APK file for front-end biometric integration on Android](https://gitlab.leegality.com/leegality-public/leegality-helper) [iOS SDK Front-end SDK for integrating Leegality into iOS applications](https://gitlab.leegality.com/leegality-public/ios-sdk) [Document Signer Server Utility Backend utility for server-side document signing integration](https://gitlab.com/leegality-public/docsigner) [USB Dongle Utility Windows and Mac desktop utility for DSC-based signing. Requires Java 8.](https://gitlab.leegality.com/leegality-public/dsc-utility) --- URL: https://knowledge.leegality.com/deal-collaboration/getting-started # Introduction to Deal Collaboration This article provides an overview of the capabilities of Leegality’s Contract Lifecycle Management tool—**Deal Collaboration**. [Leegality](https://leegality.com/) is a leader in the Document Execution space, and as a company with the goal to digitize paperwork, we are here with the next leg of productive digital transformation. From draft to execution, Deal Collaboration has been tailor-made for the unique needs of Indian businesses, enabling them to manage contracts with minimal effort. It allows business teams to review, negotiate, and collaborate on a deal without the handholding of the legal teams. We have mindfully kept this tool simple and eliminated all the clutter and chaos of conventional CLM tools. ### Home Page The homepage gives you an overview of all your deals. You can see the number of contracts under review, contracts under negotiation and the contracts that have been executed. The left panel on the home page offers you easy navigation to various capabilities of the tool. - [**Tasks:**](https://knowledge.leegality.com/deal-collaboration/tasks) A collaborator can see all the tasks assigned to them by accessing tasks. A list of tasks is also visible in the middle section of the home page. Here you can also see the name of the task, the document that the task has been assigned, and the status of such document - directly from the home page.s - [**Contracts:**](https://knowledge.leegality.com/deal-collaboration/Contracts/initiate-contract) This is where you go to initiate a deal. This is also a repository of all contracts where you get access to all the information about the contracts that you are currently negotiating as well as the deals that you have closed. - [**Templates:**](https://knowledge.leegality.com/deal-collaboration/Templates/create-template) Templates allow you to create drafts with dynamic variables and sections simplifying document creation and management. This enables you to reuse fixed formats without the need to draft from scratch. - [**Workflows:**](https://knowledge.leegality.com/deal-collaboration/Workflows/create-workflow) With Workflows, you can automate your contract review processes by customizing the review and negotiation journeys and assigning specific users different roles and responsibilities. - [**Settings:**](https://knowledge.leegality.com/deal-collaboration/Settings/global-variables) Currently settings allow you to add global variables. ## How do you collaborate and negotiate on Deal Collaboration? There are various steps involved in negotiating a contract on Deal Collaboration. 1. You start with creating a contract with variables and sections—this is called a Template. 2. Once you have created a Template, you can either save it as a draft to edit later or publish the template. 3. Once a Template is published, it is ready to be used in a Workflow. A workflow can be set up using a template (outbound deals) or you can upload a draft received from a counterparty (inbound deals). 4. Setting up the Workflow involves various steps like selecting the relevant document, assigning specific roles to different users and enabling TAT to conclude the deal on time. 5. To initiate a deal, you need a pre-existing Workflow. It is at this stage that you introduce the counterparty, check internal collaborators and send the agreement to be reviewed. 6. The collaborators are now assigned tasks and as they complete the assigned tasks, the status of the contract keeps changing. - Reviewers review the contract - The initiator sends it for external review and uploads the document it receives from the Counterpart POC. - The business negotiator negotiates the business terms of the contract and the legal negotiator approves the document after checking for legal risks. 7. Once all the collaborators have performed their tasks, the contract can be configured for signing by the Legal Negotiator or the Initiator. 8. A task is created on the Contract Listing page to configure signing, this redirects you to Leeglaity’s Execution Platform - where you can easily configure a signing journey. 9. As soon as all the parties sign the document, the status of the document is changed to executed and the journey of your contract is complete. --- URL: https://knowledge.leegality.com/deal-collaboration/Templates/create-template # Creating a Template To create a template in Deal Collaboration’s software, follow these steps: 1. Select **Templates** from the left navigation panel. 2. Click **+ Add Template** on the top right and select: - **Create Template:** Start with a blank document and create a template from scratch. - **Upload Template:** Upload a pre-built document and create template using it. (**Note:** Allowed documet format is `.docx`) 3. Enter an appropriate **Template Name**. 4. A MS Word-like editor will open. You can use this editor to type and format your template similar to MS Word. > **Tip** > > The template name is displayed in the top-left corner of the window, along with the template version. Click the __Edit__ icon to rename the template. ## Add Variables to Templates Variables are dynamic fields within templates where users can input specific information. To add a variable to your template: 1. Click on the document where you want to add a variable and then click on **Add Variables** from the right side panel. 2. In the Select Variable dropdown, you have two options. - **Global Variables**: [Global variables](https://knowledge.leegality.com/deal-collaboration/Settings/global-variables) are pre-built variables available to all users in organization. In a situation where your internal terminology does not match the global variables, you can set an alias. > **Info — Example** > > Suppose you refer to the execution date as the effective date in your contracts. In that case, you can simply add the execution date as a variable and put the effective date (your terminology) as an alias for this variable. > > Now this variable will show as an effective date for all contracts. If you want to add an alias, just select the **Set Alias** checkbox, and add the **Variable Name (Alias)**. Now this alias will appear throughout the document. - **Custom Variables**: Alternatively, you can add a custom variable. To do this, select the **+ Add Custom Variable** option to add a new custom variable. 3. Enters the **Name** of the variable. 4. In Variable Type, you have five options. - **Text:** Allows users to input textual information, such as names, addresses, descriptions, etc. - **Number:** Used for capturing numerical data, such as tenure, amount or any other numeric values. - **Dropdown:** Provides users with a predefined list of options from which they can select one. Useful for presenting users with a limited set of choices, such as categories, statuses, or predefined values. - **Checkbox:** Used for capturing Yes or No responses. - **Date:** Specifically used for capturing date. It could be date of initiation, appointment dates, deadlines, or any other date values. 5. In **Placeholder Text:** Enter text to provide hints or examples of the expected input. > **Info — Note** > > You can mark a variable as **Optional**, allowing the deal initiator to decide whether to fill it or leave it blank. ## Create a Section in Template Sections provide flexibility and control over the contents of a template. They enable deal initiators to customise documents by keeping or removing specific sections according to the requirements of each agreement. You can select different parts of the document and mark them in the same section. The deal initiator has option to keep or remove specific sections when they use the template, without having to change the template itself. Specific sections can be assigned to Reviewer so they can review the text within those sections during deal negotiation. To add a section to your template: 1. Select a portion of the text you want to convert into a section. 2. After that click on **Add Section** from the right side panel. 3. Click the **Select Section** dropdown and choose **+ Add Custom Section** to create a new section. 4. Enter the **Section Name** and the **Placeholder Text**. - **Mark as Optional**: Enable this and the deal initiator will have the option to keep or remove this section. You can also add a **Question for Initiator**. 5. Click **Save**. After adding required variable fields and creating sections, you can either Save template as a **Draft** or **Publish Template** to use in the workflow. --- # Templates URL: https://knowledge.leegality.com/deal-collaboration/Templates > A template is a pre-designed contract format used to create standardized agreements efficiently. Instead of building a new contract from scratch each time, temp A template is a pre-designed contract format used to create standardized agreements efficiently. Instead of building a new contract from scratch each time, templates allow users to define the full content of a document including dynamic components that can be tailored for each use case. Templates are especially useful for commonly used agreements and other recurring legal or business documents. ### Key Features of Templates: * __Reusable Format:__ Once created, templates can be reused across multiple contracts, significantly reducing effort and ensuring consistency. * __Customizable Content:__ Templates support variable fields (also called metadata) that can be configured to reflect dynamic information. These variables enable smart contract behavior by allowing filtering, reporting, and the generation of insights based on key contract data. * __Section Management:__ Contract sections can be customized, making the template adaptable to various use cases and business requirements. * __Smart Document Functionality:__ Templates function similarly to intelligent Word documents that integrate seamlessly with the broader contract lifecycle management system. Templates that are still in progress or under review appear under the __Drafts__ section. Once finalized, templates are moved to the __Published__ section, making them available for active use across workflows. --- URL: https://knowledge.leegality.com/deal-collaboration/Workflows/create-workflow # Create a Workflow Workflows are useful for contracts you use often. You can create a standard process for review and negotiation once and then use it again and again. With Workflows, you can customize the review and negotiation process for contract journeys by designating specific users, different roles and responsibilities within the journey. There are three steps involved in creating a Workflow. ## Workflow Details 1. Select **Workflows** from the left navigation menu. 2. Click the **+ Create Workflow** button on the top right. 3. Select **Workflow Type**. Choose between **Outbound Deal** or **Inbound Deal** or both, depending on your requirements. - **Outbound Deal:** If you want to use your template for this deal. - **Inbound Deal:** If you want to upload the document shared by the counterparty. 4. Enter **Workflow Name** and **Description**. - For __Outbound Deals__, select the template(s) you want to use from the dropdown. A second field appears, allowing you to choose the version of the selected template. For each selected template, an **Assign Folder** button appears: - Click **Assign Folder** to open a popup and select a pre-configured folder for that template now. - Leave it **unassigned** to let the user select a folder at the Deal Initiation stage when running the workflow. - **Assign to Selected Templates:** After assigning a folder to the first template, check this box to apply the same folder to all selected templates. This avoids repetitive action. > **Info — Note** > > The **Assign to Selected Templates** checkbox is only available at the Edit Workflow stage. - For __Inbound Deals__, you can assign a folder for the documents that will be uploaded during deal initiation. You can configure it now or leave it open for the user to assign while running the workflow. > **Info** > > Both options can be enabled to accommodate documents received from the counterparty and those generated internally. ## Configure Collaborators On the next screen, you will see a list of collaborators. You can add the reviewers and the negotiators to the workflow at this stage. Below is a brief description of each collaborator. ### Initiator The initiator will [initiate the contract](https://knowledge.leegality.com/deal-collaboration/Contracts/initiate-contract) using this workflow. ### Pre-sharing Reviewer The pre-sharing reviewer reviews the document or a variable or a section in the document. You can add one or more reviewers, and different reviewers can review different variables and sections of the document. You can assign specific variables or sections to specific reviewers. 1. Click **+ Add Reviewer**. 2. You can either **assign a reviewer immediately or add them during deal initiation**. a. __To assign during workflow setup:__ Search and select the reviewer’s name, then choose the relevant template from the __Assign Template__ dropdown. b. __To assign during deal initiation:__ Simply select the template to be reviewed; reviewers can be added at that stage. - **Review Complete Document:** Specify the template that the reviewer needs to review. - **Review Specific Variables:** Enable this to assign particular variables to reviewers. Use the dropdown menu to select the specific variables that reviewers will review after deal initiation. - **Review Specific Sections:** Enable this to assign specific sections to reviewers. Use the dropdown menu to select the sections that reviewers will review after deal initiation. 3. You can include multiple pre-sharing reviewers and assign them different variables and sections to review. > **Info — ALERT** > > Pre-sharing reviewer unavailable with Inbound Workflow. ### Counterparty POC The Counterparty POC (Point of Contact) is the individual who negotiates on behalf of the counterparty during [deal negotiation](https://knowledge.leegality.com/deal-collaboration/deal-negotiation/introduction). You need to provide their contact details when initiating a deal. Configure how the document is shared with the counterparty using the __Counterparty Sharing Mode__ section. - Click __Share via Leegality Link__ to send the contract using a Leegality link. This link is specially configured to allow counterparty members that you configure, to access and review the document by logging in as **Guest Users** and getting access to the contract. An automated email is sent to those invited via this link, and they can login as Guest Users, view, download, upload their own version of the document and mark it as Final. Enable this option to share the Leegality link when sending the document for external review. - To share it outside the platform, click **Share Manually** and send the downloaded document manually. > **Info** > > You can also select both options to share the document. ### Negotiator The person who will be handling the negotiation of the contract. There are two types of negotiators. - **Business Negotiator:** Business negotiators will handle the negotiation with the counterparty POC. - Enable **Same as Initiator** if you want the business negotiator to be the same as the deal initiator. - Or, you can either **assign a Business Negotiator immediately** or **add them during deal initiation**. To Assign Now, simply search for their name, and then specify the template to the negotiator. - **Legal Negotiator:** Engages in legal review of documents during deal negotiation. - Click **+ Add Legal Reviewer** button. - You can either **Assign Now** or you can **Add during deal initiation**. To Assign Now, simply search for their name, and then specify the template. You can add multiple negotiators by clicking the **+ Add Business Negotiator** button below. 1. Click **Continue** to go to the **Workflow Settings** page. 2. Click **Previous** to go back. 3. Click **Cancel** to exit the workflow configuration. The progress made will be saved in the Workflow page as draft. A pop-up window appears as below: 4. Click **Exit** to confirm the cancellation. Click **Stay** to continue on the page. ## Workflow Settings ### TAT (Turnaround Time) Settings TAT allows you to set deadlines for specific collaborators. If a collaborator exceeds the set deadline, they will receive email notifications. ![TAT Settings](\img\DC-Counterparty-TAT.PNG) 1. Open the **TAT Settings**. 2. Select the **Collaborator** to whom you want to send the TAT notifications. 3. **Specify the TAT for Task** by entering the number of days within which the task should be completed. TAT value can be between 1 to 20 days. 4. Enable **Send TAT Breach email notification/s** to send recurring mail notifications. Upon enabling the same, the following fields appear: - **Repeat Breach Notifications**: Enable the toggle if you want to send recurring notifications for missed TAT deadlines. - __Repeat Every__: Enter how often the TAT breach notifications should be sent (in days). (Example: If set to 1, an email will be sent daily; if set to 2, an email will be sent every 2 days.) - __At Time__: Set the time of day (in HH:MM) when the notification should be sent. - __Ends After__: Specify the number of notifications after which the repeated TAT breach notifications should stop. 5. Add __Additional notification recipients__ for TAT breach notifications, if needed. (Note: The additional recipients will receive the CC email notification.) 6. Repeat the same steps to configure TAT notifications for other collaborators. 7. Click the __Continue__ button to save the workflow. The workflow has been created successfully. You will now get redirected to the **Workflow** page. --- URL: https://knowledge.leegality.com/deal-collaboration/Contracts/ai-smart-extraction # AI Smart Etraction AI Smart Extraction automatically detects and extracts key data points from your contracts using artificial intelligence. This feature reduces manual data entry and ensures all critical contract metadata is centralised in a searchable repository. ## How Smart Extraction Works Smart Extraction uses AI to analyse your contracts and extract variables such as deal value, effective date, tenure, renewal date, counterparty details, and any custom variables configured in your account. You can use Smart Extraction in two ways: | Method | When to Use | | :---- | :---- | | **During Upload** | Extract variables from new contracts as you upload them | | **From Repository** | Extract variables from contracts already uploaded to your repository | For Smart Extraction during upload, refer to the [Uploading Contracts](https://knowledge.leegality.com/deal-collaboration/Contracts/upload-contracts) page. --- ## Smart Extraction from Repository Extract variables from contracts already in your repository without re-uploading them. This is particularly useful when: - You have legacy contracts that need variable extraction - You create new global variables and need historical data populated - You want to extract additional variables not selected during upload ### Access Smart Extraction #### Single Contract 1. Go to **Contracts** from the left. 2. Click on a contract to open its **Contract Details** page. 3. Click the **Extract** button displayed on the page. #### Multiple Contracts (Bulk Extraction) 1. Go to **Contracts** from the left. 2. Select multiple contracts using the checkboxes. Make sure you select contracts in the **Executed** stage. 3. Click the **Smart Extraction** button. > **Info — Note** > > The **Smart Extraction** button is always visible, even if the contract has been extracted before. Clicking it will initiate a re-extraction. ### Select Variables for Extraction When you initiate Smart Extraction, a popup appears with variable selection options. 1. Review the variable chips under **All Variables**. 2. Click the variables you want the AI to extract. 3. Selected variables move to the **Selected Variables** section. 4. Click **Proceed** to start extraction. > **Info — Note** > > Core variables such as counterparty name, deal name, and document name are skipped during extraction from the repository since they already exist in the system. ### Review and Confirm Extracted Values After extraction completes, a toast message confirms that the extraction is done and ready for review. To review the AI-extracted values for accuracy: 1. Go to the **Contract Details** page for the processed contract. 2. Click **Review** to go to the **Review Extraction** page. This page allows you to validate the information and resolve flagged issues. 3. Edit any values that need correction manually. 4. Click **Confirm** next to each variable to verify it. 5. Click **Add Variables to Contract**. This moves the contract from the Pending section to the Add to Contracts Queue section. > **Tip** > > Click **Confirm All** to confirm all variables the AI has extracted at once. > **Warning — Important** > > Unconfirmed variables (those with the AI icon) do not appear in filters or search results. Confirm all extracted values to enable full filtering capabilities. Once you confirm a variable, it is stored as a permanent data point in your repository and the AI icon is removed. > > Always confirm previously extracted variables before running a new extraction. If you re-run Smart Extraction without confirming existing values, the new batch will replace all previously extracted but unconfirmed values — even if you select different variables in the new batch. To learn more about the detailed review process, refer to [Contracts Processing Hub](https://knowledge.leegality.com/deal-collaboration/Contracts/Contracts%20Processing%20Hub/contracts-processing-hub). ### Re-extract Variables You can re-extract variables from any contract at any time. This is useful when: - You need to extract additional variables not selected initially - New custom variables have been added to your account - You want to refresh extracted values from the source document To re-extract: 1. Go to the **Contracts** page. 2. Open the contract — a banner displays "AI-generated values detected!" indicating the document has been extracted before. 3. Click **Re-extract** from the banner to repeat extraction. 4. Alternatively, click **Review** to see the details of the last extraction. > **Info — Note** > > There is no restriction on the number of times you can perform re-extraction. > **Warning — Important** > > Before re-extracting, make sure all previously extracted variables are confirmed. Running a new extraction will replace any unconfirmed values from previous batches, even if the new batch targets different variables. Always review and confirm extracted values before initiating another round of extraction. ## Processing Status After initiating extraction, contracts go through the following states: | Status | Description | | :---- | :---- | | **Pending** | Contract is queued for AI analysis | | **Ready for Review** | Extraction complete — review and confirm extracted values | | **Completed** | All variables confirmed and available in filters | Monitor bulk extraction progress in the [Contracts Processing Hub](https://knowledge.leegality.com/deal-collaboration/Contracts/Contracts%20Processing%20Hub/contracts-processing-hub). ## Version History To view the history of extractions performed on a contract: 1. Go to the **Contract Details** page of the selected contract. 2. Click the **Clock** icon next to any variable to view its history. 3. A popup opens displaying: - All actions performed on that variable - Who made the change and what value was set - The original extracted value - An AI icon alongside variables that are not yet confirmed --- URL: https://knowledge.leegality.com/deal-collaboration/Contracts/initiate-contract # Initiate a Contract This article guides you through the step-by-step process for initiating a new contract within the ***Deal Collaboration*** by Leegality. #### Prerequisite Ensure you have created following before proceeding. - [Template](https://knowledge.leegality.com/deal-collaboration/Templates/create-template) - [Workflow](https://knowledge.leegality.com/deal-collaboration/Workflows/create-workflow) To initiate a new deal, select **Contracts** from the left navigation panel and Click the **+ Initiate Contract** button on the top right. The deal initiation process is divided into four steps. ## Step 1 - Deal Form 1. Enter the **Counterparty name**. Start typing to search existing users, or click **+ Add Counterparty** to add a new one. Once added, the counterparty details can be reused in future deals. 2. Enter the **Deal Name**. Start typing to search existing deals, or click **+ Add Deal Name** to add a new one. > **Info** > > Deal name must be unique. 3. Select the desired **Workflow** by searching its name. 4. Select **Template** configured under the workflow. > **Info — Note** > > In case you have used an Inbound Workflow- you need to upload the documents received from the counterparty. > * Supported format: Docx > * Maximum file size: 14 MB 5. **Assign Folder:** A folder field appears in the deal form. - If a folder was **pre-assigned** during [workflow configuration](https://knowledge.leegality.com/deal-collaboration/Workflows/create-workflow), the field appears **disabled** — the folder mapping is already set and cannot be changed here. - If the folder was **left unassigned** in the workflow, select a folder from the available options now. 6. Click **Proceed**. ## Step 2 - Document Details 1. On the next screen, you’ll be able to preview the document with all **Variable Fields** and **Sections** in the panel on the right side. > **Info — Note** > > You cannot edit the document content at this stage. 2. You need to input values for variable fields in the panel on the right. 3. You also keep or remove sections at this stage. 4. Click **Preview** to see what the filled template looks like and then **Proceed**. ## Step 3 - Collaborators In this step, the deal initiator needs to provide the details of all collaborators. 1. Enter the **Counterparty POC’s Name**.Note that special characters are not allowed. 2. Enter the **Counterparty Email Address**. The counterpart POC name and email address can be modified at certain stages following **Deal Initiation**. This flexibility ensures that users are not constrained by the need to finalize POC details during the initial setup. If the correct POC is not known at the time of initiation, the information can be updated later as needed based on evolving requirements. > **Info** > > The **Share via Leegality link** option is not available at this stage. To use this option, it must be configured during the **Workflow creation** process. 2. For other collaborators: - **Pre-sharing Reviewer** - **Business Negotiator** - **Legal Negotiator** The initiator will see the details as configured in the workflow. If these collaborators were not added at the time of [workflow creation](https://knowledge.leegality.com/deal-collaboration/Workflows/create-workflow) they have to be added at this stage. > **Info** > > In the above example, collaborator details were configured during workflow creation. ## Step - 4 Review and Confirm You can review all provided information before initiating the deal. 1. Here, you will see the final document with filled variable fields and sections. 2. In the right panel, you can confirm variable fields and their respective values. 3. Also, you can check collaborators along with sections and variables assigned to them. 4. Once satisfied with all the document details, click **Initiate Deal**. After a deal is initiated, it moves to the [negotiation](https://knowledge.leegality.com/deal-collaboration/deal-negotiation/introduction) stage. User is redirected to the **Contracts** page. > **Info** > > A pop-up appears: > **Deal initiated! View Deal.** 5. Click **View Deal** to to go to the list of contracts under the deal. --- URL: https://knowledge.leegality.com/deal-collaboration/Contracts/upload-contracts # Uploading Contracts The **Upload Contract** feature lets you upload completed agreements into the Deal Collaboration platform for centralized management and efficient processing. ## Why Upload Previous Contracts? * **Centralised Management:** All contracts will be stored in one place, making them easier to manage. * **Efficient Search:** You can [filter contracts](https://knowledge.leegality.com/deal-collaboration/Contracts/find-contracts) based on variables such as deal value, effective date, tenure, renewal date, and more, streamlining the process of finding specific documents. ## Upload a Single Contract Use this method to upload and process one contract document at a time. ![Upload Document window in DC](\img\DC_Upload_Contract.png) ### Step 1: Upload the Document ![Upload individual document](\img\DC_Upload-individually.PNG) 1. Select **Contracts** from the left navigation panel. 2. Click the **Upload Contracts** button in the top-right corner. 3. Upload the contract in __PDF__ format. > **Note:** The maximum file size is 14 MB. 4. **Assign Folder (Optional):** Select a folder to organise this contract. Choose from the pre-configured folders available in the dropdown. 5. Click **Next**. ### Step 2: Select Upload Type In this step, you can select how to populate the contract details: **Smart Extraction** or **Add Contract Data Manually**. #### Smart Extraction #### AI Smart Extraction **AI Smart Extraction** can automatically detect and pull key data points from your uploaded contract. Smart Extraction enables users to upload contracts in bulk or individually and extract key insights. The feature performs two primary functions: * **Data Extraction:** The AI model analyses the uploaded document and extracts key data points/metadata that you have selected. * **Repository Organization:** Extracted information is automatically organized into a single, searchable repository within the system. This automation significantly reduces the time required for data validation and ensures all critical contract metadata is centralized for quick access and complex querying. ![Smart extraction in single upload](\img\DC_Smart_Extraction_Individual.PNG) 1. Click **Smart Extraction** as **Select Upload type**. 2. Review the variable chips displayed under the **All variables** section. 3. Click the chips for the variables you want the AI to detect and extract. The selected variables will move to the **Selected variables** section. The AI scans your contract for all selected variables, confirming their presence and providing accurate, keyword-extracted insights. 4. **Add data manually:** Users can manually fill variable data with known values. The Smart AI will prioritize these manual entries and skip extraction for those specific fields. This optional step is ideal when you are certain about specific metadata and wish to bypass AI processing. 5. Click **Proceed**. #### Manual Upload #### Add Contract Data Manually If you choose to skip smart extraction, you must fill in all required contract details directly on the screen. 1. Fill in the following **Mandatory Fields:** * Counterparty Name * Counterparty POC Name * Counterparty POC Email address * Deal Name * Document Name Custom variables configured in your account are also available here. 2. Click **Proceed**. ## 2. Bulk Contract Upload Use this method to upload and process multiple contracts that fall under a single deal or batch. It is particularly useful when supporting contract details are pre-collected in an XLS template. ### Step 1: Upload the ZIP File ![Upload bulk contract](\img\DC_Upload-in-Bulk.PNG) 1. Go to the **Contracts** section using the left navigation panel. 2. Click the **Upload Contracts** button at the top-right corner. 3. Choose the **Upload in Bulk** option. 4. **Prepare Your Files:** * Each contract must be in __PDF format__. * Compress multiple PDF files into a single ZIP file. * **Size Limits:** Individual contract: Max 15 MB. ZIP file: Max 500 MB. 5. Upload your ZIP file. 6. **Assign Folder (Optional):** Select a folder to organise these contracts. Choose from the pre-configured folders available in the dropdown. 7. Click **Next** to continue. ### Step 2: Select Upload Type In this step, you select how to populate the contract details: **Smart Extraction** or **Add Contract Data Manually**. #### Smart Extraction #### Smart Extraction The system automatically begins AI extraction on the documents within the uploaded ZIP file. The AI extracts data fields from the contracts to populate relevant details. ![Smart extraction in bulk upload](\img\DC_Smart_Extraction_Bulk_Upload.png) 1. Review the variable chips displayed under the **All variables** section. 2. Click the chips for the variables you want the AI to detect and extract. The selected variables will move to the **Selected variables** section. The AI scans your contracts for all selected variables and provides keyword-extracted insights. 3. **Upload XLS:** Users can upload an excel file with values they already have. Smart AI will prioritize these and skip extraction. Note that this is optional. 4. Click **Proceed**. #### Manual Upload #### Add Contract data Manually (Using XLS Template) After uploading the ZIP file, you must provide supporting details for each contract using an XLS template. 1. **Download and Fill the XLS Template** - Click the **Download XLS** button to get the template. - **Fill in Mandatory Fields:** Fill out the contract details into downloaded excel sheet. The first row (header) contains fixed fields that **must not be altered**. Enter the following details for each contract (each row is one contract): * **File Name:** The exact name of the contract file (e.g., `MLA-Leegality.pdf`). This field is case-sensitive. * **Document Name:** The name that will appear in the repository. * **Deal Name:** The name of the deal. * **Counterparty Name** * **Counterparty POC Name** * **Counterparty POC Email** - Save the XLS file. 2. Upload the filled XL file. 3. Click **Proceed**. > **Tip** > > Additional fields correspond to global variables. If a contract detail is missing from the template, create the custom variable in your account and download the template again. Once uploaded, the contract status is automatically set as **Pending**. User is redirected to the **Contracts Processing Hub**. Once the AI review is complete, the status changes to **Ready for Review**. --- # Contracts Processing Hub URL: https://knowledge.leegality.com/deal-collaboration/Contracts/Contracts Processing Hub/contracts-processing-hub > On the **Processing Hub** page, monitor your bulk upload with the following details: On the **Processing Hub** page, monitor your bulk upload with the following details: * **Batch ID:** A unique identifier for your ZIP batch. Click the Batch ID to view the contracts added from that batch. * **Created By:** The user who uploaded the batch. * **Date Created:** The date and time when the upload was initiated. * **Status:** Current progress of the batch (e.g., Pending, Completed). * **Added to Contracts:** The number of contracts successfully added to the repository. * Use the **Three Dots (⋮)** to select **Download Success Report**, which includes contracts from a batch that have been successfully added to the contracts repository. * **Failed Documents:** The number of contracts that failed to upload due to errors. * **Documents with Issues:** The count of contracts flagged with critical processing errors. ### Contract Processing Status and Functions The Contracts Processing Hub tracks the real-time status of your bulk upload batch, reflecting its stage within the AI extraction and review workflow. ![Contract processing hub](\img\DC_Status.PNG) | Status | Definition | Available Actions | | :--- | :--- | :--- | | **Pending** | The contract has been uploaded and is queued for AI analysis. | 1. **Refresh**: Click to update the page and check for a status change. | | **Ready for Review** | The AI analysis is complete, and key data points have been extracted. | 1. If **Critical Issues Flagged**: Click **Review** to go to the Review Extraction page. 2. **Download Report**: View the details of the extracted data in an XLS file. 3. If **No Critical Issues are found**: Click **Add to Contracts** to finalize and add documents to the repository. | | **Completed** | The AI review is finalized, and the contract has been successfully added to the central repository. |1. **Refresh**: Click to update the page and check for a status change. 2. **Download Input XLS File**: Click to download the uploaded excel sheet. 3. **Download Success Report**: Only visible if the batch had no failed documents. 4. __Download Error Report:__ Only visible if the batch included documents that failed. | | **Failed** | The document upload or AI processing failed due to critical errors (e.g., corrupted file, unreadable format). | 1. **Refresh**: Click to update the page and check for a status change. 2.**Download Input XLS File**: Click to download the uploaded excel sheet. | ## Review Extraction ![Review extraction page](\img\DC_Review_Extraction_Page.png) The **Review Extraction** page displays the data identified and pulled from your uploaded documents by the Smart Extraction AI. This page allows you to validate the information, resolve flagged issues, and prepare the contracts for indexing. ### Identify and Filter Issues The system automatically flags potential data issues for review: * **Critical issues:** Major flaws or unreadable data points. * **Low confidence score:** AI uncertainty about the extracted value. * **Value missing:** A selected variable was not detected in the document. Use the following tools to manage the document list: * **Filters:** Use filters to prioritize documents based on the major flags listed above. * **Search:** Use the search option to quickly locate a specific document in the batch. * **Data Source Indicators:** An icon denotes which data was manually provided (via the XLS template) and which was extracted by the AI. * **Delete Icon:** Click the **Delete** icon to remove any documents from the current list. ### Detailed Document Review ![Detailed document review](\img\DC_SmartAI_Detailed_Review_Page.PNG) 1. Click the **Review** button to open the uploaded document alongside a detailed, categorical breakdown of the extracted data and corresponding flaws. 2. User can toggle **Show only AI extracted variables** to narrow the focus to AI-sourced data. 3. Once reviewing the detailed breakdown, two primary options are available: #### a. Confirm All - Click **Confirm All**. If critical issues are present, a pop-up appears, requiring resolution. - User can manually go through each flagged value to edit, remove, or confirm the data - After resolving all issues, click **Confirm All** again. > **Info** > > The document is verified, and the following message is displayed: > > *Review successfully completed! Document added to contracts is in queue. It can be viewed in the Added to Contracts Queue tab.* #### b. Remove All Click **Remove All** to clear variable values from the document. > **Info** > > Only non-mandatory variable values will be removed. Mandatory fields must be reviewed and confirmed individually to be cleared. 4. After detailed reviewing and resolving all errors: * Click the **Add to Contract** button to finalize the document and send it to the contracts repository. * Click **Delete document** to permanently remove the document entry. Once added to the contracts, the document is moved to the **Contracts** page with the **Executed** status. ### Reuploading Failed Documents If some contracts fail to upload, follow these steps: 1. **Download Error Report:** Click the **Three Dots (⋮)** and select **Download Error Report**. The XLS file will list failed contracts along with the *Failure Reason*. 2. **Correct Errors:** Fix the errors indicated in the report. Remove the *Failure Reason* column before reuploading. 3. **Download Failed Files:** Click the **Three Dots (⋮)** and select **Download Failed Files**. Create a new ZIP file containing the corrected contracts. 4. **Reupload:** Upload the new ZIP file to process the failed contracts. --- URL: https://knowledge.leegality.com/deal-collaboration/Contracts/find-contracts # Filter Contracts The Filters functionality in the **Contracts** section allows you to refine search results, helping you easily find specific contracts based on various criteria. ## To Apply Filters 1. Go to the **Contracts** from the left. 2. Click on the **Filters** on the top-right corner. 3. Select criteria to filter contracts. 4. Click on **Apply**. Contracts matching the applied criteria will be displayed. In the Filters panel, the selected filters are displayed at the top. To reset all applied filters, simply click the **Clear All** button in the Filters panel. ## Types of Filters Filters in the Contracts section are divided into two types: **General Filters** and **Variable-Based Filters**. ### General Filters General filters help you search for contracts based on their status, template used, counterparty, and creation or update date. * **Status:** You can filter contracts based on their current stage in the workflow. Available status options include: * Under Internal Review * Ready for External Review * External Review * Negotiation Internal * Negotiation External * Ready for Signing * Sent for Signing * Executed * Discarded * **Template:** Allows you to search for contracts by the name of the template used. You can select multiple templates simultaneously to broaden your search. * **Counterparty:** Allows you to search by **counterparty name**. Like the Template filter, you can select multiple counterparties. * **Create Date**: Filters contracts by the **date of creation**. Options include filtering by predefined periods such as days, months, quarters, or years. You can also specify a **custom date range**. * **Update Date:** This option allows you to filter contracts by the **last update date**. You can use predefined periods or select a **custom date range**. ### Variable-Based Filters Variable-based filters allow you to search and filter contracts based on the specific data entered into these dynamic fields. This makes it easier to locate contracts that match criteria like contract term, renewal date, etc. For example, in a template, a default variable like "Deal Value" is added. When a contract is initiated using that template, the initiator fills in the actual value of the deal. You can then filter contracts based on deal values using options like "less than," "greater than," or "equal to" a specific value. > **Info — Note** > > - Only active variables will be shown as filter options. > - Both Default and Custom Variables are supported in the filter. > **Tip — Reference** > > Learn more about [**Global Variables**](https://knowledge.leegality.com/deal-collaboration/Settings/global-variables). #### **Default Variable Filters** Below is a list of the system's default variables that can be used for filtering contracts. **Custom variables** can also be used similarly in the filters if they are active. * **Effective Date:** Filter contracts by the date they became effective. * **Deal Value:** * A field to input a specific deal value. * A dropdown to choose filtering criteria (e.g., Less than, Less than or equal to, Greater than, Greater than or equal to and Equals to). * **Region:** Filter contracts based on the specific region. * **Location:** Filter contracts by location. * **Counterparty:** Enter the counterparty name involved in the contract. * **Counterparty Signatory:** Filter by the name of the counterparty’s signatory. * **Deal Type:** Filter contracts by their deal type. * **Description of Services:** Filter contracts based on the description of service. * **Expiry Date:** Filter contracts by their expiry date. * **Renewal Date:** Filter contracts by their renewal date. * **Term Filters:** These allow you to filter contracts by their duration. * **Term (Months):** Enter the number of months and use the dropdown to filter by Less than, Less than or equal to, Greater than, Greater than or equal to and Equals to the specified number of months. * **Term (Years):** Enter the number of years and filter similarly. * **Term (Days):** Enter the number of days and filter accordingly. * **Payment Date:** Filter contracts by their payment date. --- URL: https://knowledge.leegality.com/deal-collaboration/Contracts/contract-renewal # Contract Renewals Contract Renewal option allows you to configure renewal tasks and reminders for contracts in the *Executed* status. ## Steps to Configure Renewal #### Single Contract Renewal 1. Click **Contracts** on the left. 2. The contract status must be *Executed* to configure renewal. You can use the [Filters](https://knowledge.leegality.com/deal-collaboration/Contracts/find-contracts) to find the desired contract. 3. Click on the contract name to open the detailed view. 4. Click the **Configure Renewal** button. 5. In the Contract Details section, enter the following details: - Effective Date - Term of Contract - Expiry Date These details are extracted from the document if included as [variables](https://knowledge.leegality.com/deal-collaboration/Settings/global-variables) within it. If not found in the contract, you can manually set the Effective Date and Term; the Expiry Date will auto-calculate. 6. Click **Next**. 7. **Assign Renewer:** Select the individual responsible for renewing the contract. 8. **Set Renewal Task Creation Date:** Enter the number of days prior to the contract’s expiry date for task creation. For example, if the expiry date is March 31, 2025, and you enter 30 days, the renewal task will be created on March 1, 2025. 9. **Define TAT (Turnaround Time):** Specify the number of days from the task creation date that the renewer has to complete the renewal. For example, if the task is created on March 1 and TAT is set to 15 days, breach notifications will start from March 16. 10. **Send TAT Breach Notifications:** Enable this option to send recurring emails when the TAT is breached. - **Repeat Task Reminder:** Enable this option to send recurring email reminders about the renewal task. - **Repeat TAT Breach Reminder:** Enable to send reminder email notifications regarding the TAT breach of renewal task. - **Repeats Every:** Specify the frequency in days and the time of delivery. - **End Notification After Set Number:** Configure when reminders should cease. - **Additional Recipients:** Add others to receive the reminder notifications. (Optional) 11. Click **Save**. After saving, a renewal task will be created per the configured Renewal Task Creation Date and assigned to the renewer. #### Bulk Contract Renewals 1. Click **Contracts** on the left. 2. The contract status must be *Executed* to configure renewal. You can use the [Filters](https://knowledge.leegality.com/deal-collaboration/Contracts/find-contracts) to find the desired contract. 3. Select the contracts for renewal by checking the boxes next to their names. 4. Click the **Configure Renewal** button on the top right. 5. **Assign Renewer:** Select the individual responsible for renewing the contract. 6. **Set Renewal Task Creation Date:** Enter the number of days prior to the contract’s expiry date for task creation. For example, if the expiry date is March 31, 2025, and you enter 30 days, the renewal task will be created on March 1, 2025. 7. **Define TAT (Turnaround Time):** Specify the number of days from the task creation date that the renewer has to complete the renewal. For example, if the task is created on March 1 and TAT is set to 15 days, breach notifications will start from March 16. 8. **Send TAT Breach Notifications:** Enable this option to send recurring emails when the TAT is breached. - **Repeat Task Reminder:** Enable this option to send recurring email reminders about the renewal task. - **Repeat TAT Breach Reminder:** Enable to send reminder email notifications regarding the TAT breach of renewal task. - **Frequency and Timing:** Specify the frequency in days and the time of delivery. - **End Notification After Set Number:** Configure when reminders should cease. - **Additional Recipients:** Add others to receive the reminder notifications. (Optional) 9. Click **Save**. --- ## Common Errors and Solutions When Configuring Renewals
Error Resolution Steps
Renewal already configured for the document

Unselect the contract for which renewal has already been configured. Steps to filter contracts pending renewal configuration:

  1. Click Filters.
  2. Choose Executed status.
  3. Choose Renewal Configuration as Not Configured.
  4. Click Apply.
Contract Expired The contract has already expired and is not eligible for renewal.
Expiry Date not available

The contract does not have an expiry date. To set an expiry date:

  1. Click the document name to open the detail view.
  2. Click the Configure Renewal button.
  3. Enter the Effective Date and Term of Contract. Click Save and Exit.
Task Creation date should lie between current date and expiry date

The entered number of days for task creation must fall within the range from the current date to the contract's expiry date.

Example:

  • Current Date: 01-Mar-2025
  • Expiry Date: 31-Mar-2025

The Task creation date (days) should be 30 days maximum. If you enter a value greater than 30 (e.g., 40), the task creation date would fall on 19-Feb-2025, which is in the past and not valid.

TAT should lie between current date and expiry date

The entered number of days for TAT must fall within the range from the current date to the contract's expiry date.

Example:

  • Current Date: 01-Mar-2025
  • Expiry Date: 31-Mar-2025

The TAT to complete the task should be 29 days (1 less day than the Task Creation Date) maximum.

--- URL: https://knowledge.leegality.com/deal-collaboration/Contracts/folders # Manage Folders The **Folders** feature lets you organise contracts into a structured hierarchy within Deal Collaboration. You can create folders, nest subfolders, and move contracts into them for easier management and retrieval. ## Folder Permissions Access to folders is permission-driven based on the user's role: | Role | Permissions | |---|---| | **Business Users** | View folders only | | **Admins & Legal Users** | Create, edit, move, and delete folders | > **Info — Note** > > During workflow execution, **Business Users can assign folders** to contracts, even though they do not have folder edit access in general. This is because the permission to work on a workflow is granted to Business Users. ## The Folders Panel Folders are accessible from the left sidebar on the Home screen. All existing folders are listed here. The icon next to each folder name indicates its structure: - `* Folder name` — The folder has **no subfolders**. - `> Folder name` — The folder **has subfolders**. Click the arrow to expand and view the nested structure. 1. Use the **search bar** in the panel to find a folder by name. 2. Click on any folder to open its details page. > **Info — NOTE** > > There is no limit to the number of folders you can create or the depth of subfolders you can nest within them. ## Create a New Folder 1. From the Home screen, click the **+** icon in the **Folders** section of the left sidebar. 2. Enter a **Folder Name**. 3. Click **Add Folder**. The new folder appears in the Folders panel. ## Folder Details Page Clicking a folder in the sidebar opens the **Folder Details** page, where you can view all contracts and subfolders within it. ### Add a Subfolder 1. Click **Add Subfolder**. 2. Enter a name for the subfolder. 3. Review the **path** shown to confirm its location in the hierarchy. 4. Click **Create**. ### Rename and Delete a Folder #### Rename a Folder To rename the selected folder: 1. Click the **edit icon** alongside the folder name. 2. Enter the new name. 3. Click **Save**. #### Other Actions Available * **View Folder Path**: Click the **info icon** alongside the folder name to see the full path of the folder in the hierarchy. * **Remove a Folder**: Click the **remove icon** alongside the folder name. * **Move to Another Folder**: 1. In the **Folder Details** page, Click **More Options**. 2. Select the folder you want to move the contract to. 3. Click **Move**. > **Warning — Important** > > Removing a folder **also removes all child folders** nested within it. The contracts inside are **not deleted** — they become unassigned from the folder structure. ## Move a Contract to a Folder 1. Go to **Contracts** from the left navigation panel. 2. Select the contract(s) you want to move. 3. Click **More Actions**. 4. Select **Move to Folder**. 5. Choose the target folder or subfolder from the list — you can move to a different top-level folder or to any subfolder within one. > **Info — Note** > > Moving a contract to a folder does not affect the contract itself — the contract's data, status, and workflow remain unchanged. ## Search and Filter by Folder You can locate contracts by folder in two ways: - **From the Folders panel** — Use the search bar in the left sidebar to find a folder by name. - **From the Contracts page** — Use the **Filters** panel and filter by folder. This works at every level — top-level folders, child folders, and deeply nested subfolders all return matching contracts. ## Other Ways to Assign Folders Folders can also be assigned to contracts through the following flows: - [Uploading Contracts](https://knowledge.leegality.com/deal-collaboration/Contracts/upload-contracts) — Assign a folder when uploading a legacy contract (single or bulk), before clicking Proceed. - [Create a Workflow](https://knowledge.leegality.com/deal-collaboration/Workflows/create-workflow) — Assign a folder per template during workflow configuration, or leave it open for the user to assign at runtime. - [Initiate a Contract](https://knowledge.leegality.com/deal-collaboration/Contracts/initiate-contract) — Assign a folder at the Deal Form step during deal initiation, if not already set in the workflow. --- URL: https://knowledge.leegality.com/deal-collaboration/Contracts/configurable-columns-and-saved-views # Configurable Columns and Saved Views The **Contracts** page lists every contract in your Deal Collaboration workspace, but not every user needs to see the same information. A legal reviewer may want to track status and counterparty, while a business owner may care more about deal value and renewal date. The **Configurable Columns and Saved Views** feature lets each user shape the Contracts page to match their workflow. This feature gives you two key capabilities: - **Curated views** — Display only the data points you actually need, keeping the Contracts page clean and relevant to your role. - **Repeated use** — Save your column and filter combinations so you don't have to reconfigure them each time you open the page. By default, when you open the Contracts page, a **Default View** is applied showing a standard set of columns. You can switch to a saved view at any time using the **views dropdown** in the page header, or create a new view of your own. ## Configure Columns The **Configure Columns** option lets you choose which data points appear as columns on the Contracts page. You can pick from a combination of general contract fields (such as Status, Counterparty, Create Date, Update Date) and active variables (both default and custom) used in your templates. The **Configure Columns** button is located at the top-right of the Contracts page header. 1. Click **Configure Columns**. 2. In the dropdown, select or deselect the data points you want to display. There is no limit on the number of columns you can select. 3. Click **Apply**. Your custom column view is now active on the Contracts page. > **Info — Note** > > **Document Name** is a constant column and is always displayed. It cannot be removed from the view. ## Apply Filters to the View Once your columns are configured, you can further narrow down the contracts displayed using filters. Filters work alongside the column selection — your chosen columns control **what data** you see, while filters control **which contracts** are listed. 1. Click the **Filters** option. 2. Use the checkboxes under each filter to select the values you want to apply. 3. To start over, click **Clear All** to deselect all selected filters. 4. Click **Apply** to apply the selected filters. > **Tip — Reference** > > For a full breakdown of the available filters, including general filters (Status, Template, Counterparty, dates) and variable-based filters, see [**Filter Contracts**](https://knowledge.leegality.com/deal-collaboration/Contracts/find-contracts). ## Save a View A **Saved View** captures your current column configuration along with the filters applied to the Contracts page. Saved views are useful when you regularly need the same slice of contracts — for example, a legal user can save a view that shows all contracts under internal review, while a business owner can save a view that lists all contracts expiring this quarter. To save your current column configuration and filters for repeated future use: 1. Click **Save your new view**. 2. Enter a **View Name**. 3. Select the **Visibility**: - **Team** — Makes the view accessible to your entire team. - **Private** — Keeps the view visible only to you. 4. Click **Save**. Your saved views are accessible from the **views dropdown** in the Contracts page header. There is no limit on the number of saved views per account. > **Info — Note** > > **Team** views are shared across every user in your organisation, so any change you make to a team view affects what others see. Use **Private** if the view is meant only for your own workflow. ## Edit a Saved View You can update the name or visibility of a saved view at any time. This is useful when a view needs to be renamed for clarity, or when a private view needs to be shared with the rest of the team (or vice versa). 1. Select the saved view from the dropdown. 2. Click **More Options**. 3. Click **Edit Details**. 4. Update the **View Name** or **Visibility** as needed. 5. Click **Save**. ## Delete a Saved View If a saved view is no longer needed, you can remove it from the views dropdown. 1. Select the saved view from the dropdown. 2. Click **More Options**. 3. Click **Delete**. 4. A confirmation pop-up appears — click **Delete** to confirm. > **Warning — Important** > > Deleting a **Team** view removes it for everyone in the organisation. --- URL: https://knowledge.leegality.com/deal-collaboration/deal-negotiation/introduction # Overview This article will give you an overview of the deal negotiation process, explaining the key stages and actions involved. ## What is Deal Negotiation? Deal negotiation is the process of discussing and agreeing on the terms of a contract with external parties. Using our software, you can create, review, edit and share documents until both parties are satisfied and the contract is ready for signing. ## Stages of Deal Negotiation 1. **Initiate the Deal:** The negotiation process begins when a deal is initiated in the Leegality Deal Collaboration. 2. **Internal Review:** The contract is reviewed internally to ensure all terms are correct before sharing with the external party. 3. **Ready for External Review:** Once the internal review is complete, the contract is prepared to be sent to the counterparty. 4. **External Review:** The counterparty reviews the contract and may suggest changes. 5. **Negotiation Internal:** Your team reviews the counterparty’s changes and decides whether to accept them, propose further changes, or finalize the contract. 5. **Ready to Sign:** When both parties agree on the terms, the contract is ready for signing. ## Key Collaborators and Their Roles This part of the article explains the roles of key collaborators in the deal negotiation process. Being familiar with the roles and responsibilities of the collaborators can help you navigate through a negotiation more effectively. ### 1. Initiators - **Role:** Initiators start the deal negotiation process by creating the contract. - **Responsibilities:** - Create the initial draft of the contract using templates and workflows. - Ensure all necessary information is included. - Assign tasks to the appropriate team members for review. ### 2. Pre-sharing Reviewer - **Role:** Review the assigned fields and sections in the contract before sending it to the External Review. - **Responsibilities:** - Review document before sending it to counterparty. - Approve, Edit, or Discard the variable fields and sections assigned to them. ### 3. Business Negotiators - **Role:** Business negotiators focus on the business terms of the contract. - **Responsibilities:** - Review the contract for business-related terms and conditions. - Suggest changes or improvements to the terms of the contract if required. - Communicate with the counterparty to negotiate business terms. ### 4. Legal Negotiators - **Role:** Legal negotiators ensure the contract is compliant with the law and is free from legal risks. - **Responsibilities:** - Review the contract for legal accuracy and compliance. - Suggest changes to ensure legal protection and compliance as and when required. - Collaborate with business negotiators to align business and legal terms. - Approve the contract before it goes for execution. ### 5. Counterparty POC - **Role** The counterparty POC (Point of Contact) is the representative from the external party involved in the negotiation. - **Responsibilities:** - Review the contract sent by the initiator or the negotiator. - Suggest changes or provide feedback on the contract terms. - Communicate any concerns to your team. --- URL: https://knowledge.leegality.com/deal-collaboration/deal-negotiation/deal-negotiation-flow-diagram # Deal Negotiation Flow Diagram This article summarises the negotiation workflow in Leegality Deal Collaboration software. Understanding the overall flow helps you navigate the process smoothly. The stage-wise process that a deal undergoes is captured in the chart below. ## Step-by-Step Explanation | **STAGE** | **ACTION** | **RESULT** | |----------|----------|----------| | **Initiate Contract**| The initiator configures the deal and selects the workflow and the template relevant for that deal.| Stage changes to “Ready for Internal Review.”| | **Internal Review**| The Reviewer(s) approve, reject or edit the variable fields and approve or reject the sections. If they have edit access, they can also click on “View Document” to make edits and leave comments on the document.| Stage changes to “Ready for External Review.”| | **Ready for External Review**| The initiator can click on the “Send for External Review” task and download the draft contract. All the internal comments are removed. Once the document is downloaded- the document cannot be edited.| The contract marked as External Review.| | **External Review**| The Counterparty reviews the contract and sends it back. This document is now uploaded back to Deal Collaboration.| Stage changes to “Negotiation Internal”| | **Negotiation Internal**| The internal negotiators can now review the document for any further changes that might be required. The legal negotiator is required to approve the document at this stage.| After the Legal Negotiator approves the document, the document can either be sent for another external review or be marked as ready to sign.| | **Send for External Review**| You can share the revised contract with the counterparty.| Contract status changes to Negotiation External.| | **Negotiation External**| Negotiations can go on till the draft contract is finalized.| Stage changes to “Ready for Signing”| | **Ready to eSign**| A task is created to “Configure Signing”. You can now select the draft that is required to be executed.| You will be redirected to the Document Execution platform where you can set up an eSigning flow.| --- URL: https://knowledge.leegality.com/deal-collaboration/deal-negotiation/ai-review # AI Review The AI Review feature enables collaborators to efficiently assess documents for potential risks and compliance issues at any stage of negotiation. This feature is available to every user who has access to the deal collaboration product. The AI Review system utilises a customisable Rule Set—a collection of pre-configured smart rules or guidelines—to ensure your contracts align with organisational standards. - **File Format:** The review functionality is currently open to .docx files only. - **Negotiation Stage:** The review can be run at all document negotiation stages but is only available before the contract reaches the final PDF state. ## Run AI Review Follow these steps to run an AI Review on a document: 1. While the document is in a negotiation stage, click **Open Document** to load the document in **OnlyOffice**. 2. On the document toolbar, click **AI Review**. A right-hand panel will open, displaying the review interface. 3. In the right-hand panel, select the Rule Set you wish to use for the review. > **Info** > > To learn how to define and manage rules, see [Rule Set Management](https://knowledge.leegality.com/deal-collaboration/Settings/rules-set). 4. Click **Run**. The system will thoroughly process the document against the selected rules. ### Re-running the Review You can run the AI Review as many times as needed to ensure confidence in the results. > **Warning — Note on Re-running** > > To see a change in the results, you must click **Re-run** after you have: > - Changed the content within the document. > - Modified the content of the selected Rule Set (e.g., if you closed the AI Review panel, navigated to the settings page, and edited a rule). After the review is complete, the right-hand panel displays a detailed answer for each rule within the chosen Rule Set. ## Detailed Review Results The AI Review results are categorised into three statuses: | Status | Description | Review Display | Possible User Action | |--------|-------------|----------------|---------------------| | **Met** | Required values or clauses fully meet the rule's expectations. | Displays the rule and reason for compliance. No clause suggestions are provided. | No changes needed. The condition is satisfied. | | **Not Met** | Required values or clauses are found but do not meet the rule's expectations. | Shows clauses that need review along with suggested additions. | Add the suggested clause or edit the document to meet the rule's requirements. | | **Not Found** | Required values or clauses are not found in the document. | Indicates missing details and provides suggested additions. | Add the suggested clause or manually edit the document to include the required information. | To view a detailed analysis of a specific rule, click the right arrow (→) alongside that rule in the results panel. The detailed review section provides critical information for remediation: - **Rule:** The specific guideline being checked. - **Rule Description:** A detailed explanation of the rule's purpose. - **Suggested Clause:** The original clause recommended by the user. - **Reason:** A clear explanation of why the rule was Met, Not Met, or Not Found. For issues, the reason includes a direct reference (e.g., text snippet) to the relevant section. - **Clause Suggestions:** For rules with **Not Met** or **Not Found** status, the Clause Suggestions section displays two components: 1. **Original Clause:** Shows what is currently mentioned in the document with respect to the rule. Click **Find** to locate the clause inside the document. 2. **Suggested Addition:** Provides a recommended alternative or addition to address the issue. After making changes and reviewing the document, click **Save** to save your work and return to the Document Details page. ## Bulk AI Review Bulk AI Review allows you to run AI Review on multiple executed contracts simultaneously. This is useful for reviewing a batch of contracts against a specific rule or rule set. > **Info — Note** > > - Bulk AI Review is available only for contracts in the **Executed** stage > - You can run **one rule** or **one rule set** individually at a time ### Run Bulk AI Review 1. Go to the **Contracts** page. 2. Select multiple contracts to be reviewed (must be in the Executed stage). 3. Click the **AI Review** button from the action bar above. 4. In the popup, select the rule or rule set you want to run the AI Review on. 5. Click **Run**. You will be redirected to the **Contracts Processing Hub** where the contracts under review are listed. ### Review Results Once the status changes from **Queued** to **Complete**, you can review the results: 1. Click the **Review** button next to the completed batch. 2. A tabular representation displays all documents under the contract with their status: - **Rules Met** - **Rules Not Met** - **Rules Not Found** 3. Click on any document to open the **Detailed Review Page** for individual review. The Detailed Review Page displays the same information as described in the [Detailed Review Results](#detailed-review-results) section above. ### Rerun AI Review To rerun the AI Review on a document: 1. Click **Rerun** next to the document you want to review again. 2. You will be redirected to the main PDF viewer page. 3. Click **Proceed** to access the page where you can rerun the rule or rules under the selected rule set. > **Info — NOTE** > > You can rerun documents one at a time from the repository or from clicking contracts individually. --- URL: https://knowledge.leegality.com/deal-collaboration/deal-negotiation/deal-negotiation-process # Deal Negotiation Process ## 1. Internal Review Internal Review is the first stage in the contract status workflow where your internal team reviews the contract to ensure all terms and conditions are correct before sharing it with the external party. ### Collaborator and Responsibilities **Pre-Sharing Reviewer(s):** The person responsible for reviewing the contract during the Internal Review stage. They will review and complete assigned tasks, including reviewing entire document, variable fields, and/or sections. ### To Perform an Internal Review 1. The pre-sharing reviewer can find the tasks assigned to them in the [**Tasks**](https://knowledge.leegality.com/deal-collaboration/tasks) section. Click on the **Review** to proceed. The tasks assigned to a user are also reflected on the contract details page and home page. > **Info** > > The reviewer also receives email notifications of the review process. 2. The reviewer then examines either the entire document or specific assigned variable fields and sections of the contract. 3. For entire document review, reviewer can either **Accept** or **Reject**. > **Warning — Note** > > If reviewer **Reject** the document, the entire deal will be discarded. The initiator will need to start a new deal again. 4. For each variable field and section, the pre-sharing reviewer can: - **Approve:** Confirm that the information is correct. - **Discard:** Remove any incorrect or unnecessary information. (**Note:** If a variable is rejected, a task will be created for the initiator to refill the variable field. Once the initiator has made the change, it’ll go back to the reviewer for approval.) - **Edit:** Make necessary changes. The pre-sharing reviewer completes their review tasks by making edits, discarding, or approving the fields and sections. 5. Once all variable fields are **Approved**, the contract status will change to *Ready for External Review*. This indicates that the contract is now ready to be shared with the counterparty for their review. > **Info — Note** > > User can also make Online Edits (if they have edit access) to the Contracts and these edits will be visible to other collaborators. ## 2. Ready for External Review Ready for External Review is the stage in the contract status workflow where the contract is prepared and deemed ready to be sent to the counterparty for review. This stage ensures that all internal reviews are complete and the document is ready for external review. ### Collaborators and Responsibilities **Initiators:** Initiator is responsible for sending the document to the counterparty for external review. ### To Send for External Review 1. The initiator will get a new task when the document status changes to *Ready for External Review*. Click on the **Review** to proceed. 2. On the Contracts detail page, the initiator can click on the **View Document** button to review the document before sending it. 3. Then the initiator needs to click on the **Send for External Review** button. A new window displaying the __Counterparty Sharing Mode__ opens: ![send for external review](\img\DC-CP-Share-for-external-review.PNG) Here, you can view the sharing mode selected during the workflow creation. You also have the option to update the Counterparty POC name and email. 4. To delete an existing __Counterparty POC__, first create a new credential using the __Add Counterparty POC__ section. 5. Click __Save__ to add the new details. 6. Remove the previous entry by clicking the delete icon. 7. You may also include an __additional message__ to be sent to your Counterparty POCs. This is sent as part of the automated email generated to the Counterparty POC when you hit __Proceed__. 8. Once you've made all necessary changes, click __Proceed__ to continue. > **Info — NOTE** > > Users can also execute this step during external review. 9. If the Counterparty POCs have not received the email, you can resend notification so that those emails can be resent to the users. To share the document manually, 1. **Download the document** to share it with the counterparty’s point of contact (POC). The format of the document is docx. Before the document is sent, all the internal comments are deleted. 2. After downloading, the status changes to *External Review*. 3. Share the document with the counterparty with your preferred mode of communication e.g. Email. The counterparty reviews the document and returns it with any revisions. This review cycle can continue until both parties are satisfied with the terms and ready to proceed with e-signing. > **Warning — Note** > > Once the document is sent for external review, all online editing is restricted. This restriction prevents discrepancies between the shared document and the internal document version. ## 3. Counterparty Review The Counterparty POCs receive an automated email from the initiator, which includes an attachment of the document. This allows the POCs to preview the document without needing to click any CTA, ensuring both safety and legitimacy. ![Email received by CP-POC](\img\DC-CP-POC-Inbox.PNG) 1. Click __View Document__ to review the document to be signed. 2. Click __Upload Document__ if the Counterparty POC needs to share any attachments with the initiator. > **Info** > > Clicking either button will initiate a one-time verification process. The email ID will be pre-filled and match the one provided during the Counterparty POC configuration. ![Guestuser signin](\img\DC-Guestuser-signin.PNG) 3. Enter the OTP sent to that email to complete the verification. 4. Once verified, a guest portal opens, providing access to options for reviewing, verifying, and editing the document. 5. The guest user can __Download__ the document to make changes and then __Upload__ the revised version. ![Guestuser upload window](\img\DC-Guestuser-Uploadwindow.PNG) 6. Click __Mark as Final and Send__ to send the uploaded document. 7. Click __Comments__ to view any external feedback or remarks on the document. 8. Once all the changes are made, click __Accept as Final and Send__. 9. The guest user can also mark it as final and send if they have no changes to offer. ## 4. Negotiation Internal Negotiation Internal is the stage where the contract, after being reviewed by the counterparty, is uploaded back to Leegality Deal Collaboration for further review and possible modification. During this stage, the internal negotiator examines the changes suggested by the counterparty, makes necessary adjustments, and decides on the next steps. ### Roles and Responsibilities - **Business and Legal Negotiators:** The primary responsibility is to review the document, compare versions, make necessary changes, and decide whether to send it back for external review or mark it as ready for signing. ### Internal Negotiation Process Once you receive the revised document from the counterparty, you need to upload the document on Leegality DC. For this: 1. On the __Contracts detail__ page, click on the **Upload** button. 2. Select the document you received from the counterparty and click **Proceed**. The status will change to *Negotiation-Internal*. 3. A task is created for the Legal Negotiator to review the document. The negotiator can click on the **View Document** to see the changes. 4. The negotiator can also review the changes by [comparing the document versions](https://knowledge.leegality.com/deal-collaboration/Collaboration/comparing-document-versions). Any necessary edits can be made directly using the online editor. 5. Save the edited document to ensure changes are visible to other collaborators. You can [add comments](https://knowledge.leegality.com/deal-collaboration/Collaboration/add-comments) for other collaborators and external stakeholders as well. 6. After reviewing and making the necessary changes, click the **Approve** button. 7. The Business Negotiator has two options: - **Send for External Review:** If further review by the counterparty is needed, the negotiator can send the document back for external review. - **Mark as Ready for Signing:** If no further review is required, the negotiator can mark the document as ready for signing. In this case, you need to [send contract for eSigning](https://knowledge.leegality.com/deal-collaboration/signing-journey). --- URL: https://knowledge.leegality.com/deal-collaboration/deal-negotiation/upload-signed-document # Upload Signed Document The Upload Signed Document option allows you to upload a signed contract when negotiations are completed. This is useful if the document was signed physically or using a platform other than Leegality. ## Prerequisites * The document Status must be Ready for Signing. * You must be a collaborator in the deal with one of the following roles: Initiator, Business Negotiator, or Legal Negotiator. ## Steps to upload a signed document 1. In the contract, click on the three dots (**…**). 2. Select the **Upload Signed Document** option. 3. Upload a signed PDF document. (**Note:** Maximum upload size is 20 MB.) Once the document is uploaded, the status will change to Executed. > **Info — Note** > > This action cannot be undone. You can click on the **View Document** button to see the uploaded PDF document. The activity log will be updated. You can see; * The user who uploaded the signed document. * The date and time when the document was uploaded. The document status will change to Executed. All collaborators will receive a notification informing them that the document status has changed to Executed. --- # What is an Obligation? URL: https://knowledge.leegality.com/deal-collaboration/Obligations/obligations-overview > An obligation is a commitment that a contract creates for one of the parties. It can be a deadline, a deliverable, or a requirement. Renewal notices, data delet An obligation is a commitment that a contract creates for one of the parties. It can be a deadline, a deliverable, or a requirement. Renewal notices, data deletion requirements, insurance certificate submissions, and audit reporting deadlines are all obligations. The Obligations module tracks these commitments across your executed contracts. It records what each contract requires, when it falls due, and who is responsible. It then creates tasks so that someone acts before the deadline. You can let AI find obligations in the contract text, or you can add them yourself. ## How an Obligation Is Created An obligation reaches your list in one of three ways. | Route | What happens | | --- | --- | | **Automatic extraction** | When a contract reaches **Executed**, the AI reads it and flags the obligations it finds. This only runs if your organisation has turned on automatic extraction. See [Obligation Settings](https://knowledge.leegality.com/deal-collaboration/Obligations/Settings/obligation-settings). | | **Manual extraction** | You run extraction on a contract yourself, without waiting for the automatic run. | | **Manual creation** | You add the obligation yourself. See [Adding an Obligation](https://knowledge.leegality.com/deal-collaboration/Obligations/add-obligation). | Automatic extraction covers contracts executed in Deal Collaboration as well as older contracts you upload into it. Each has its own setting. Your organisation can also limit automatic extraction to contracts that have not expired, in which case expired contracts are skipped. Every obligation the AI finds shows the exact clause it came from, along with the AI's reasoning. You can check this against the contract before you rely on it. You can then mark it as **Verified**. Verifying is optional. When you mark an AI-extracted obligation as Verified, its source changes from AI-Assisted to Verified. It is a review step, not an extra flag alongside the original value. ## Obligation Lifecycle ```mermaid graph LR A["Obligation created"] --> B["Active"] B --> C["Task created before the due date"] C --> D["Completed or Expired"] B --> D D -.->|Reopen| B ``` ## Obligation and Task Status An obligation and its tasks have separate statuses. The obligation tracks the commitment. A task tracks one piece of work needed to meet it. **Obligation status** | Status | Meaning | | --- | --- | | **Active** | The commitment is still live. | | **Completed** | Marked as met. | | **Expired** | Marked as no longer applicable. | You can reopen an obligation that was closed by mistake. This activity is recorded for audit purposes. **Task status** | Status | Meaning | | --- | --- | | **Pending** | Created and waiting for action. | | **Resolved** | Completed. | | **Breached** | Not completed within its turnaround time. | | **Cancelled** | Withdrawn. This happens when the obligation is expired or deleted, or when an edit invalidates a task that nobody has acted on yet. | ## Tasks and Turnaround Time Tasks are optional. You set them up on the obligation itself or on the template. Two settings control the timing, and they do different things. - **Task creation date**: how many days before the due date the task is created. - **TAT (Turnaround Time)**: how many days the assignee then has to complete it. A task that is not completed within this window is **Breached**. The turnaround time cannot extend past the due date. If you need a longer turnaround time, create the task earlier. Repeating obligations create one task for each occurrence. The creation window cannot overlap the next occurrence, so tasks from different cycles never run at the same time. Tasks from earlier cycles can still sit at different statuses. See [Tasks and Notifications](https://knowledge.leegality.com/deal-collaboration/Obligations/add-obligation#tasks--notifications) for the full configuration, including TAT breach emails and repeat reminders. ## Conflicts {#conflicts} A conflict means that an obligation needs your attention, because its due date or task setup can no longer be trusted. Instead of acting on stale information, the module flags the obligation and waits for you to fix it. An obligation with a conflict shows a **Conflict** badge wherever it appears, including the obligations list, a contract's own obligations panel, and the Task Conflicts count on the [Dashboard](https://knowledge.leegality.com/deal-collaboration/Obligations/obligations-dashboard). | Conflict | What it means | | --- | --- | | **Reference date changed** | The linked reference variable was re-extracted and its value changed. The due date and any existing tasks still use the original date. | | **Reference variable has no value** | The linked reference variable is empty, so the due date cannot be calculated. | | **Variable not found on document** | The linked reference variable is not available on this document. | | **Task creation window missed** | The date on which the task should have been created has already passed. | | **Past due date detected** | The due date that the task was set up against is now in the past. | When you edit the obligation, the conflicts that your edit resolves are cleared. See [Finding and Fixing Conflicts](https://knowledge.leegality.com/deal-collaboration/Obligations/manage-obligations#finding-and-fixing-conflicts) for how to work through them. ## Related Pages - [Obligations Dashboard](https://knowledge.leegality.com/deal-collaboration/Obligations/obligations-dashboard) - [Managing Obligations](https://knowledge.leegality.com/deal-collaboration/Obligations/manage-obligations) - [Adding an Obligation](https://knowledge.leegality.com/deal-collaboration/Obligations/add-obligation) - [Obligation Settings](https://knowledge.leegality.com/deal-collaboration/Obligations/Settings/obligation-settings) --- # Obligations Dashboard URL: https://knowledge.leegality.com/deal-collaboration/Obligations/obligations-dashboard > The Obligations Dashboard shows how your obligations and their tasks are tracking across all your contracts. Use it to see where things stand. When you need the The Obligations Dashboard shows how your obligations and their tasks are tracking across all your contracts. Use it to see where things stand. When you need the full list, or need to act on an obligation, go to [Manage](https://knowledge.leegality.com/deal-collaboration/Obligations/manage-obligations). ![Obligations Dashboard](https://knowledge.leegality.com/img/DC_Obligations_Dashboard.png) ## What Each Part Shows 1. **Active with Due Date**: The number of active obligations that have a due date, across all your contracts. Obligations without a due date are not counted here, so a low number can mean due dates are missing rather than that there is little to do. 2. **My Active Obligations**: The number of active obligations assigned to you. Use this to see your own workload without filtering the full list. 3. **View obligations**: Opens the full list in [Manage](https://knowledge.leegality.com/deal-collaboration/Obligations/manage-obligations). 4. **Period selector**: Sets the reporting window. Choose **30D**, **3M**, **6M** or **1Y**, or set your own dates with **Custom range**. > **Info — Note** > > The period does not change the whole dashboard. It applies only to the **Completed** and **Expired** counts and to the trend chart. The two counts in the banner always show today's position, and the priority, category and task counts always cover all time. 5. **Completed**: Obligations marked as met during the selected period. Selecting this tile also draws its figures on the trend chart below. Click **View** to open these obligations in [Manage](https://knowledge.leegality.com/deal-collaboration/Obligations/manage-obligations). 6. **Expired**: Obligations marked as no longer applicable during the selected period. Expired is something a person sets. It does not happen on its own when a contract reaches its end date. Selecting this tile draws its figures on the trend chart instead. Click **View** to open these obligations in [Manage](https://knowledge.leegality.com/deal-collaboration/Obligations/manage-obligations). 7. **Trend chart**: Plots the selected tile month by month across the period, so you can see whether closure is keeping pace. If there is nothing to show, it reads *No data for this period*. 8. **By Priority**: Splits your obligations into Critical, High, Medium and Low. The four always appear in that order, and a priority with nothing against it shows as zero rather than disappearing, so the shape of the split stays readable. Click a bar to open those obligations in [Manage](https://knowledge.leegality.com/deal-collaboration/Obligations/manage-obligations). 9. **By Category**: Splits your obligations by [category](https://knowledge.leegality.com/deal-collaboration/Obligations/Settings/obligation-categories). Only the five largest categories appear on their own. Everything else is grouped into **Others**, which keeps the breakdown legible when you have many categories. Click a bar to open those obligations in [Manage](https://knowledge.leegality.com/deal-collaboration/Obligations/manage-obligations). **Others** is a grouping rather than a real category, so it cannot be opened. 10. **Obligation Tasks**: Four counts covering the tasks your obligations have generated. - **Ongoing**: created and waiting for action. - **Breached**: not completed within the turnaround time. - **Resolved**: completed. - **Task Conflicts**: obligations that need attention because their due date or task setup can no longer be trusted. See [Conflicts](https://knowledge.leegality.com/deal-collaboration/Obligations/obligations-overview#conflicts). Ongoing, Breached and Resolved count individual tasks. Task Conflicts counts obligations, so an obligation with several conflicts is counted once. Each count has a **View** link that opens the matching items in [Manage](https://knowledge.leegality.com/deal-collaboration/Obligations/manage-obligations). 11. **Export**: Downloads the dashboard as an Excel workbook. It contains a single **Overview** sheet with the summary in sections, covering active obligations, completed and expired, tasks, priority and category. > **Info — Note** > > If your access is limited to the documents assigned to you, every number on this page counts only those documents, matching what you see everywhere else in the module. ## Related Pages - [What is an Obligation?](https://knowledge.leegality.com/deal-collaboration/Obligations/obligations-overview) - [Managing Obligations](https://knowledge.leegality.com/deal-collaboration/Obligations/manage-obligations) - [Adding an Obligation](https://knowledge.leegality.com/deal-collaboration/Obligations/add-obligation) --- # Managing Obligations URL: https://knowledge.leegality.com/deal-collaboration/Obligations/manage-obligations > Manage is the working list of every obligation across your contracts. Use it to find an obligation, open it, and act on it, either one at a time or in bulk. Manage is the working list of every obligation across your contracts. Use it to find an obligation, open it, and act on it, either one at a time or in bulk. ## Opening the Obligations List 1. In the sidebar, click **Obligations**. 2. Click **Manage** to see the complete list of obligations. ## Columns The list always shows the **Obligation name**. You choose the rest through **Configure Columns**, and Status, Document Name, Next Due Date, Priority, Responsibility and Assignee are shown to begin with. | Column | What it shows | | :--- | :--- | | **Obligation name** | The obligation. Always shown, and cannot be hidden. Click it to open the obligation. | | **Status** | Active, Completed, or Expired. | | **Document Name** | The contract the obligation belongs to. | | **Deal Name** | The deal the contract sits in. | | **Counterparty** | The other party to the contract. | | **Category** | The obligation's [category](https://knowledge.leegality.com/deal-collaboration/Obligations/Settings/obligation-categories). | | **Next Due Date** | The next occurrence's due date. Click the column heading to sort on it. | | **Frequency** | One-time or Repeating. | | **Priority** | Critical, High, Medium, or Low. | | **Responsibility** | Us, Counter Party, or Third Party. | | **Assignee** | Who the obligation is assigned to. | | **Source** | AI-Assisted, Verified, or Manual. | | **Date Created** | When the obligation was created. Click the column heading to sort on it. | > **Info** > > An obligation carrying a conflict also shows a **Conflict** badge against its name. ## Searching and Filtering Use the search box to find an obligation by name. It also matches the document, deal and counterparty. Use **Filters** to narrow the list. You can filter by: - **Status**, **Priority**, **Category**, **Responsibility** and **Source**. - **Frequency**, to separate one-time obligations from repeating ones. - **Due Date**, to separate obligations that have a due date from those that do not. - **Due Date Range** and **Date Created**, using a relative range such as the next few weeks, or your own dates. - **Tasks**, to find obligations with a task configured, with a task conflict, or with no tasks at all. - **Survives Termination**. - **Document Name**, **Deal Name** or **Counterparty**, to narrow to one contract, deal or party. > **Tip — Finding what needs attention** > > Filter **Tasks** by **Task Conflict** to see obligations whose due date or task setup needs review. Filter **Due Date** by **No Due Date** to find obligations that were never given one. Before any obligations exist, the list reads *No obligations added yet. Create your first obligation to get started.* ## Finding and Fixing Conflicts {#finding-and-fixing-conflicts} A conflict means an obligation's due date or task setup can no longer be trusted, so the module flags it instead of acting on stale information. See [Conflicts](https://knowledge.leegality.com/deal-collaboration/Obligations/obligations-overview#conflicts) for what each type means. To work through them: 1. Filter **Tasks** by **Task Conflict**. The list then shows only obligations that need attention. 2. Click an obligation with a **Conflict** badge. The drawer opens and lists every conflict on it, under a heading that counts them, such as **2 conflicts detected**. Each one has a title and an explanation of what changed. 3. Click **Fix Conflict**. The obligation opens in edit mode. 4. Correct whatever the conflict describes. A changed reference date usually needs the due date confirming. A missed task creation window usually needs the task settings adjusting. 5. Click **Save**. The conflicts that your edit resolves are cleared. Any that remain stay on the obligation, so one with several conflicts may need more than one pass. > **Info — Note** > > If an obligation has a conflict, its tasks may not have been created at all. The obligation itself will say so: *Tasks have not been created due to conflict. To resolve, edit the obligation and configure task settings.* ## Actions Click an obligation to open it in a side drawer. The drawer shows its full detail, including the source clause, its schedule, its tasks, and any conflicts. Each obligation has its own address, so you can share a link to one. Act on an obligation from the drawer, or from the actions on its row. | Action | What it does | Good to know | | :--- | :--- | :--- | | **Edit** | This option changes the obligation's details, schedule, or task setup. | If you change the due date on a one-time obligation that already has an active task, you are asked to either **Keep existing task** or **Cancel and reschedule**. | | **Verify** | This option confirms an AI-extracted obligation. | This action appears only on AI-extracted obligations. The source changes from AI-Assisted to Verified. | | **Fix Conflict** | This option opens the obligation so that you can clear a conflict. | The obligation opens in edit mode. There is no separate conflict screen. | | **View Task** | This option opens the task that the obligation generated. | This action appears only when a task exists. | | **Create Task** | This option adds a task to an obligation that does not have one. | The obligation needs a due date before a task can be created. | | **Add Assignee** | This option assigns another user to the obligation. | The assignee receives task assignments and reminders. | | **Send Reminder** | This option sends a reminder to recipients that you choose. | You can add a note to the reminder. | | **Mark as Complete** | This option closes the obligation as met. | This closes all open and future tasks. You can add remarks and attachments. | | **Mark as Expired** | This option closes the obligation as no longer applicable. | You can add remarks and attachments. | | **Reopen** | This option returns a closed obligation to Active. | Tasks are not recreated. Reopening is tracked for audit purposes. | | **Delete** | This option removes the obligation. | Deleting is permanent. | Which actions you see depends on the state of the obligation and on your permissions. A completed obligation offers **Reopen** rather than **Mark as Complete**, and **Verify** appears only on an AI-extracted obligation. > **Caution — Important** > > Marking an obligation complete closes all its open and future tasks. You can reopen the obligation afterwards, but its tasks are not recreated. To start tracking it again, edit the obligation and turn task creation back on. ### Acting on Several Obligations at Once Select obligations with the checkboxes to open the bulk action bar. - **Verify** and **Add Assignee** sit on the bar itself. - **Send Reminder**, **Mark as Complete**, **Mark as Expired**, **Reopen** and **Delete** are in the overflow menu. You can act on up to 100 obligations at a time. Changing a filter keeps your selection. Navigating away clears it. **When an action is unavailable.** A bulk action only applies where it makes sense for every obligation you have selected, so some become unavailable depending on the mix. | Action | Needs | | :--- | :--- | | **Verify** | Every selected obligation to be AI-extracted. | | **Mark as Complete** | No selected obligation to be completed already. | | **Mark as Expired** | No selected obligation to be completed or expired already. | | **Reopen** | Every selected obligation to be closed. It is unavailable while any is still active. | > **Info — Note** > > If your access is limited to the documents assigned to you, this list shows obligations on those documents rather than the whole organisation. ## Related Pages - [What is an Obligation?](https://knowledge.leegality.com/deal-collaboration/Obligations/obligations-overview) - [Adding an Obligation](https://knowledge.leegality.com/deal-collaboration/Obligations/add-obligation) - [Obligations Dashboard](https://knowledge.leegality.com/deal-collaboration/Obligations/obligations-dashboard) - [Obligations in the Processing Hub](https://knowledge.leegality.com/deal-collaboration/Obligations/obligations-in-processing-hub) --- # Adding an Obligation URL: https://knowledge.leegality.com/deal-collaboration/Obligations/add-obligation > When you add an obligation, you are recording a commitment that one of your contracts creates, so that the module can track it on your behalf. You give the comm When you add an obligation, you are recording a commitment that one of your contracts creates, so that the module can track it on your behalf. You give the commitment a due date, say who is responsible for it, and decide whether it should raise a task and send reminders as that date approaches. Most obligations are found for you by AI when a contract is executed. You add one yourself when the commitment is not covered by a template, or when you would rather not wait for the next extraction run. You can only add an obligation to a contract that has already been executed, so a document at any earlier stage cannot be selected. You also need at least one obligation category, because every obligation belongs to one. See [Managing Obligation Categories](https://knowledge.leegality.com/deal-collaboration/Obligations/Settings/obligation-categories) if you have not set any up yet. > **Tip — Adding the same obligation again and again?** > > If a commitment appears across many of your contracts, set up an [obligation template](https://knowledge.leegality.com/deal-collaboration/Obligations/Settings/create-obligation-template) instead. The AI then finds it in every contract that matches, so you do not have to add it by hand each time. ## Opening the Add Obligation Form 1. In the sidebar, click **Obligations**. 2. Click **Manage**. The full list of obligations opens. 3. Click **+ Add Obligation**. The form opens at **Obligation Details**. You add an obligation in two steps. First you enter the obligation's own details. Then you set up the task and the notifications that go with it. ## Step 1: Obligation Details 1. Select the **Document Name**. This is the executed contract that the obligation belongs to, and it is required. 2. Enter an **Obligation Name**. This is required and can be up to 100 characters. 3. Add a **Description** of what the obligation requires. This is optional and can be up to 2,000 characters. 4. Add a **Source Clause**. This is the wording in the contract that creates the obligation, and it is optional. Click **Add from Document** to select the text, or open the PDF viewer. Obligations found by AI already include this. 5. Select a **Category**. This is required. 6. Set a **Priority**: **Critical**, **High**, **Medium**, or **Low**. This is optional. 7. Select the **Responsibility**, which is who the obligation belongs to. At least one is required, and you can select more than one: - **Us**: your own organisation. - **Counterparty**: the other party to the agreement. - **Third Party**: a party outside the agreement, such as a vendor or a regulator. 8. Set the **Assignee**. This is optional, and you can use either option or both: - **Assignee (by contract role)**: whoever holds a role on the contract, either **Business Negotiator**, **Legal Negotiator**, or **Initiator / Uploader**. See [Configure Collaborators](https://knowledge.leegality.com/deal-collaboration/Workflows/create-workflow#configure-collaborators). - **Assignee (by user)**: a specific user in your organisation. The assignee receives the task assignments and reminders. 9. Turn on **Survives termination** if the obligation still applies after the agreement ends. This is optional. 10. Choose how the due date is set, either **One-time** or **Scheduled**. You have to choose one. Fill in that tab: #### One-Time Use one of these two options. You cannot use both, because an obligation takes its due date from a single source. - **Link due date to reference variable**: the due date comes from a date field on the contract, such as its expiry date. Select a **Reference variable** from the dropdown, which lists date fields only. If there are none, click **Add new variable** to create one. - **Next Due Date**: pick a fixed date from the calendar. The due date cannot be in the past. > **Caution — Important** > > If you link the due date to a reference variable and that variable's value changes later, for example because the contract was re-extracted, any task that has already been created stays on the original due date. The obligation is flagged with a conflict so that you can review it and update the task settings. > > Do not assume that a changed contract date has been applied everywhere on its own. #### Scheduled 1. Enter a **Start Date**. This is when the cycle begins. > **Caution — Important** > > The first due date is not the start date. It falls one full interval after it. If you set a start date of 1 January and the obligation repeats every 3 months, the first due date is 1 April. 2. Set **Repeats**, using a number and a unit of days, weeks, months, or years. 3. Choose when it **Ends**: - A fixed number of occurrences, or an end date. The obligation stops once it reaches that point. - **Till Expiry**: the obligation keeps repeating with no fixed end. It stops only when someone marks it as expired. 11. Enter the **Resolution**, which describes what needs to be done to meet the obligation. This is optional. 12. Click **Next**. The **Tasks & Notifications** step opens. ## Step 2: Tasks & Notifications {#tasks--notifications} Creating a task is optional. To track the obligation without one, click **Save**. To create a task: 1. Turn on **Create task**. 2. In **Task creation date**, enter how many days before the due date the task should be created. 3. In **Turn around time (TAT)**, enter how many days the assignee then has to complete the task. > **Info — Note** > > These two settings do different things. The task creation date decides when the task appears. The TAT decides how long there is to finish it, counting from when it appears. A task that is not completed within the TAT window is breached. > > Because the TAT starts when the task is created, it cannot extend past the due date. If it does, either reduce the TAT or create the task earlier. 4. Turn on **Send TAT breach email notification** to alert recipients when a task breaches its TAT. This is optional. 5. Turn on **Repeat reminders** to send reminders after the first one, which always goes out. This is optional. Then set: - **Notify on**: when reminders are sent, either on task creation, on TAT Breach, or both. - **Repeats every**: how often the reminder repeats, in days. - **Ends after**: how many reminders to send before stopping. Select 1, 2, 3, 5, or 10. 6. Add **Additional notification recipient(s)** by searching for a user and selecting them. This is optional. 7. Click **Save**. The obligation is saved. It appears in [Manage](https://knowledge.leegality.com/deal-collaboration/Obligations/manage-obligations) with the status **Active** and the source **Manual**. If you set up a task, it is created on the date you chose, not immediately. ## Rules to Know - If you turn on **Create task**, the obligation needs a due date source. Without either a fixed due date or a linked reference variable, it will not save. - The task creation date must be in the future. If the due date is close, there may not be room to create the task before it. - On a scheduled obligation, the task creation window cannot overlap the next occurrence. The number of days before the due date cannot be more than the gap between two occurrences, so one cycle's task never collides with the next. ## Related Pages - [What is an Obligation?](https://knowledge.leegality.com/deal-collaboration/Obligations/obligations-overview) - [Managing Obligations](https://knowledge.leegality.com/deal-collaboration/Obligations/manage-obligations) - [Obligations Dashboard](https://knowledge.leegality.com/deal-collaboration/Obligations/obligations-dashboard) - [Creating an Obligation Template](https://knowledge.leegality.com/deal-collaboration/Obligations/Settings/create-obligation-template) > **Tip — Reference** > > See [Tasks](https://knowledge.leegality.com/deal-collaboration/tasks) for how the task is listed, tracked, and resolved. --- # Obligations in the Processing Hub URL: https://knowledge.leegality.com/deal-collaboration/Obligations/obligations-in-processing-hub > When the AI reads a contract for obligations, it does that work in the background rather than while you wait. Each contract gets its own extraction job, and the When the AI reads a contract for obligations, it does that work in the background rather than while you wait. Each contract gets its own extraction job, and the **Obligations** tab in the Processing Hub is where you follow those jobs. You can see which contracts have been read, which are still waiting, which failed and why, and which are ready for you to review. This is the page to come to when obligations you expected have not appeared. It tells you whether the contract was never read, was read and produced nothing, or ran into a problem. The other tabs in the Processing Hub track batches of uploads. The Obligations tab is different, because it shows one row for every contract rather than one row for every batch. > **Info — Note** > > A contract can only be read for obligations once it has been executed. Until then, no extraction job exists for it and it does not appear on this page. ## Opening the Obligations Tab 1. Go to the **Processing Hub**. 2. Open the **Obligations** tab. Every extraction job is listed, with the most recent first. Use the search box to find a job by contract name, and use **Filters** to narrow the list by status, by whether extraction was automatic or manual, by counterparty, or by when the job was queued or extracted. ## Columns | Column | What it shows | | :--- | :--- | | **Document Name** | This column shows the contract that the job ran on. You can click the name to open the contract. If the contract is no longer available to you, the column reads **Document unavailable**. | | **Counterparty** | This column shows the counterparty on the contract. It is hidden until you turn it on through **Configure Columns**. | | **Queued At** | This column shows when the job was accepted. The list is sorted by this column with the newest first, and it is the only column you can sort on. | | **Extracted At** | This column shows when extraction finished. It stays empty while the job is still running. | | **Extraction Source** | This column shows whether the job started on its own or because someone asked for it. It reads **Auto Triggered**, or **Manually Triggered** with the person's name below it. | | **Status** | This column shows where the job has reached. The statuses are explained below. | | **Obligations Found** | This column shows how many obligations were created against how many templates applied to the contract, written as `3/5`. It shows a dash when no template applied. | You can hide any column except Document Name, Queued At and Status. ## Extraction Statuses and What You Can Do A job moves through these states on its own. It starts as **Queued**, moves to **Processing** when a worker picks it up, and ends as **Completed**, **Failed** or **Skipped**. **Discarded** is the exception, because it only happens when someone cancels the job. What you can do to a job depends on where it has reached, and on your own permissions. An action may not be offered even when it is listed below. | Status | What it means | What you can do | | :--- | :--- | :--- | | **Queued** | The job has been accepted and is waiting its turn. Nothing has been read yet. | • **Refresh** brings the row up to date. • **Discard** cancels the job before it runs. | | **Processing** | The contract is being read now. The Obligations Found count can rise while the job sits in this state. | • **Refresh** brings the row up to date. • **Discard** cancels the job before it finishes. | | **Completed** | Every template that applied to the contract was evaluated and the job has finished. | • **Review** opens the obligations that were found. It reads **View Obligations** when every applicable template produced one. • **View failure reasons** appears if anything was recorded along the way. • **Re-extract** reads the contract again. | | **Failed** | One or more templates could not be extracted or saved. A reason is recorded for each one that failed. | • **Re-extract** reads the contract again. • **View failure reasons** explains what went wrong. | | **Skipped** | The job ended without reading the contract, for example because no template applied to it. | • **Re-extract** reads the contract again. • **View failure reasons** explains why it was skipped. • **Discard** removes it from your active list. | | **Discarded** | Someone cancelled the job, or it was skipped because an earlier run had already extracted obligations from this contract. Discarded jobs stay in the list so that you can see what happened. | • **Re-extract** reads the contract again. • **View failure reasons** explains why it was discarded. | A status of **Completed** means the reading has finished, not that anyone has checked the result. Reviewing and verifying happen on the obligation itself. See [Adding an Obligation](https://knowledge.leegality.com/deal-collaboration/Obligations/add-obligation). **Review** and **View Obligations** both take you to the contract's detail view, where the obligations are listed against the clauses they came from. **View failure reasons** records a reason for each template that failed, so a single job can list several. Discarded jobs use the same place to explain why they were discarded. > **Caution — Important** > > Re-extracting replaces the obligations already extracted from that contract. Anything a person edited or verified on those obligations is replaced along with them. ### Discarding a Job Discard a job when you do not want the contract read, for example because it was uploaded by mistake or is not one you need to track. 1. Select the entry in the list. 2. Click **Discard**. 3. Confirm when you are asked: > **Discard extraction job** > Are you sure you want to discard the extraction job for `{name}`? It will be marked as Discarded in the Processing Hub. The row is not removed from the list. It stays with a **Discarded** badge, and the reason is recorded with its failure reasons, so there is always a record of the decision. ## Downloading a Report Click **Download report** to export the list of extraction jobs. You can download every job, or only the jobs that match the filters you have applied. ## Related Pages - [What is an Obligation?](https://knowledge.leegality.com/deal-collaboration/Obligations/obligations-overview) - [Adding an Obligation](https://knowledge.leegality.com/deal-collaboration/Obligations/add-obligation) - [Obligation Settings](https://knowledge.leegality.com/deal-collaboration/Obligations/Settings/obligation-settings) --- # Obligation Library URL: https://knowledge.leegality.com/deal-collaboration/Obligations/Settings/obligation-library > The Obligation Library is where your obligation templates live. A template tells the AI what to look for in your contracts, and how each obligation it finds sho The Obligation Library is where your obligation templates live. A template tells the AI what to look for in your contracts, and how each obligation it finds should be set up, including when it falls due and who is responsible for it. Your organisation starts with a set of default templates covering common commitments, such as renewal notices and auto-renewal opt-outs. You can use these as they are, edit them to suit your contracts, or add your own alongside them. See [Creating an Obligation Template](https://knowledge.leegality.com/deal-collaboration/Obligations/Settings/create-obligation-template) for how to build one. ## Opening the Library 1. Go to **Settings**. 2. In the sidebar, click **Obligations**. 3. Open the **Library** tab. Your obligation templates are listed. ## Library Columns | Column | What it shows | | :--- | :--- | | **Obligation name** | This column shows the name of the template. It is always visible and cannot be hidden. | | **Category** | This column shows the [category](https://knowledge.leegality.com/deal-collaboration/Obligations/Settings/obligation-categories) that the template is grouped under. | | **Type** | This column shows whether the template is a **Default** one that came with the module, or a **Custom** one that your team created. | | **Due Date** | This column shows how the due date is worked out, either **Linked variable**, **Directly extracted**, or **Not configured**. | | **Scope** | This column shows the workflows and document templates that the template applies to. | | **Status** | This column shows whether the template is **Active** or **Disabled**. | You can add four more columns through **Configure Columns**: **Priority**, **Responsibility**, **Assignee**, and **Reference variable**. ## Row Actions Click the **Three Dots (⋮)** on an entry to: - **View:** Open the template's configuration in read-only mode. - **Edit:** Modify the template's configuration. - **Duplicate:** Create a copy of the template to use as a starting point for a new one. - **Disable:** Stop the module from extracting this obligation going forward, without deleting existing data. - **Enable:** Put a disabled template back into use. - **Delete:** Remove the template. > **Note — Some templates can't be deleted** > > Default templates cannot be deleted, so disable them instead. Their names cannot be changed either, although the rest of their configuration can be edited. > > A template cannot be enabled while its category is disabled. Enable the category first. Template names must be unique within your organization. Names are limited to 100 characters and descriptions to 2,000. ## Finding a Template Use the search box to find a template by name. To narrow the list further, use **Filters**. You can filter by category, status, priority, responsibility and type, as well as by the reference variable a template uses, the workflows and document templates in its scope, and who it is assigned to. ## Related Pages - [Creating an Obligation Template](https://knowledge.leegality.com/deal-collaboration/Obligations/Settings/create-obligation-template) - [Managing Obligation Categories](https://knowledge.leegality.com/deal-collaboration/Obligations/Settings/obligation-categories) - [Obligation Settings](https://knowledge.leegality.com/deal-collaboration/Obligations/Settings/obligation-settings) --- # Creating an Obligation Template URL: https://knowledge.leegality.com/deal-collaboration/Obligations/Settings/create-obligation-template > An obligation template tells the AI what to look for in your contracts, and how the obligations it finds should be set up. Create one for any commitment that re An obligation template tells the AI what to look for in your contracts, and how the obligations it finds should be set up. Create one for any commitment that recurs across contracts, so you don't add it by hand each time. You create a template in three steps. First you give it a name and say what it covers, under **Basic Details**. Then you set when the obligation falls due and whether it should raise a task, under **Due Date & Tasks**. Finally you choose which contracts it applies to, under **Scope**. You can move back to an earlier step at any point to change something. The template is saved when you click **Save Template** at the end, so set aside a few minutes to work through all three steps together. ## Before You Start - At least one **obligation category** must exist, since Category is required. See [Managing Obligation Categories](https://knowledge.leegality.com/deal-collaboration/Obligations/Settings/obligation-categories). - Know which contracts the template should apply to. You need the workflows or document templates in step 3. - To anchor due dates to a contract date, have the **date variable** in mind. You can create one during step 2. ## Opening the Template Form 1. Go to **Settings** and click **Obligations** in the sidebar. 2. Open the **Library** tab. 3. Click **+ Add Obligation Template**. The form opens at **Basic Details**. ## Step 1: Basic Details 1. Enter an **Obligation name**. This can be up to 100 characters and must be unique within your organisation. 2. Write a **Description** of what the obligation requires. Up to 2,000 characters. > **Tip — Write this for the AI, not for a colleague** > > The description is what the AI matches clauses against during extraction. Include the key terms a clause would use, which party is responsible, and any timing conditions. The more specific it is, the more accurate the extraction. > > Click **Refine description** to have AI rewrite what you've written in clearer wording. 3. Select a **Category**. Required. Click **Add new category** to create one without leaving the form. 4. Set a **Priority**: **Critical**, **High**, **Medium**, or **Low**. 5. Select the **Responsibility**, which is who the obligation belongs to. You can select more than one: - **Us**: your own organisation. - **Counterparty**: the other party to the agreement. - **Third Party**: a party outside the agreement, such as a vendor or a regulator. - **Any**: open-ended, for a clause that does not name a party. The AI uses this to find obligations belonging to the right party, so choose **Any** only when the clause genuinely leaves it open. 6. Add an **Assignee**, either way or both: - **By Contract Role**: whoever holds a role on the contract, either **Business Negotiator**, **Legal Negotiator**, or **Initiator**. See [Configure Collaborators](https://knowledge.leegality.com/deal-collaboration/Workflows/create-workflow#configure-collaborators). - **By User**: a specific user in your organisation. 7. Click **Continue**. ## Step 2: Due Date & Tasks This step is entirely optional. Leave **Extract due date** off and click **Continue** to skip it. The template then creates obligations with no due date. 1. Toggle on **Extract due date** to have the AI read the due date out of the contract. Two further toggles appear. ### Link Due Date to Reference Variable Use this when the due date should come from a date already on the contract, such as its expiry or renewal date, rather than from the clause text. 2. Toggle on **Link Due Date to Reference Variable**. 3. Select a **Reference variable** from the dropdown. Only **date**-type variables can be used, so the list shows only those. If there are none yet, the dropdown says so and prompts you to create one. 4. *(If you need a new one)* Click **Add new variable** and complete the **Add Custom Variable** pop-up: 1. Enter a **Variable Name**. 2. Select a **Variable Type**. 3. Enter a **prompt to generate description** and click **Generate Description** to have AI draft one, then **Insert** to accept it. You can also type the description yourself. 4. Enter a **Placeholder Text**. 5. Click **Save**. See [Adding an Obligation](https://knowledge.leegality.com/deal-collaboration/Obligations/add-obligation#step-1-obligation-details) for what happens when that variable's value later changes. ### Create Task 5. Turn on **Create task** to generate a task for every obligation this template creates, then set the task creation date, turnaround time, breach notifications and reminders. This is optional, and the settings are the same as on a single obligation. See [Tasks and Notifications](https://knowledge.leegality.com/deal-collaboration/Obligations/add-obligation#tasks--notifications). 6. Click **Continue**. ## Step 3: Scope Scope decides which contracts this template is extracted from, by combining **Workflows** and **Document Templates**. 1. For **Workflows**, choose **All** to include every workflow, or **Select individually** to pick specific ones. Multiple selection is allowed. 2. For **Document Templates**, choose **All** or **Select individually** the same way. 3. Choose how the two combine: - **AND**: only contracts matching both a selected workflow and a selected document template are processed. - **OR**: contracts matching either one are processed. > **Info — Worked example** > > With 5 workflows and 3 document templates selected: > > - **AND** extracts only from contracts that use one of those 5 workflows **and** one of those 3 templates. > - **OR** extracts from any contract matching either list. > > **AND** narrows the scope and **OR** widens it. Choose AND when an obligation only belongs in a particular kind of contract, such as confidentiality obligations inside NDAs. 4. Click **Save Template**. ## After You Save The template is **Active** immediately and applies to contracts extracted from that point on. It does not reach back over contracts already processed. From the [Library](https://knowledge.leegality.com/deal-collaboration/Obligations/Settings/obligation-library#row-actions) you can then edit, duplicate, disable, or delete it. Two limits to know: - A **default** template's name cannot be changed, and default templates cannot be deleted. Disable them instead. - A template cannot be **enabled** while its category is disabled. ## Related Pages - [Obligation Library](https://knowledge.leegality.com/deal-collaboration/Obligations/Settings/obligation-library) - [Managing Obligation Categories](https://knowledge.leegality.com/deal-collaboration/Obligations/Settings/obligation-categories) - [Adding an Obligation](https://knowledge.leegality.com/deal-collaboration/Obligations/add-obligation) --- # Managing Obligation Categories URL: https://knowledge.leegality.com/deal-collaboration/Obligations/Settings/obligation-categories > A category is the label you group obligations under, so that renewal commitments sit apart from compliance ones, audit ones, and so on. Every obligation templat A category is the label you group obligations under, so that renewal commitments sit apart from compliance ones, audit ones, and so on. Every obligation template belongs to exactly one category, and so does every obligation created from it. Categories are what the [Library](https://knowledge.leegality.com/deal-collaboration/Obligations/Settings/obligation-library) groups your templates by, and what you filter the obligations list and the [Dashboard](https://knowledge.leegality.com/deal-collaboration/Obligations/obligations-dashboard) breakdowns by. Getting them right early makes the rest of the module easier to read. Categories are flat, so you cannot nest one inside another. Your organisation starts with a set of default categories, and you can add your own alongside them. ## Opening Categories 1. Go to **Settings** and click **Obligations** in the sidebar. 2. Open the **Categories** tab. Your categories are listed. ## Adding a Category 1. Click **+ Add Category**. 2. Enter a **Category Name**. This can be up to 50 characters and must be unique within your organisation. 3. Add a **Description**. This can be up to 1,000 characters. > **Tip** > > Click **Refine description** to have AI rewrite your description in clearer wording. 4. Click **Save**. The category is **Active** straight away and can be selected on a template or an obligation immediately. ## Reading the Category List | Column | Description | | :--- | :--- | | **Category Name** | The name of the category. | | **Type** | Whether the category is a **Default** one shipped with the module, or a **Custom** one your team created. | | **Status** | Whether the category is **Active** or **Disabled**. | | **Description** | The description entered for the category. | Filter the list by **Type** (Default or Custom) and by **Status** (Active or Disabled). ## Managing a Category Hover over a category in the list to see its options. - **Edit Category** updates the category's name or description. Make your changes and click **Save**. A default category's name cannot be changed, although its description can be. - **Disable Category** takes the category out of use without deleting it. This is the safer choice when you no longer want a category to be selected but do not want to lose it. Keep in mind that a template cannot be enabled while its category is disabled. - **Enable Category** brings a disabled category back into use. If you need one of its templates back, enable the category first. See [Obligation Library](https://knowledge.leegality.com/deal-collaboration/Obligations/Settings/obligation-library#row-actions). - **Delete Category** removes the category for good. Deleting cannot be undone, and default categories cannot be deleted at all, so disable those instead. Disabling, enabling and deleting each ask you to confirm before the change is made. > **Warning — A category in use cannot be removed** > > A category with obligation templates mapped to it can be **neither deleted nor disabled**. Move those templates to another category first. ## Related Pages - [Obligation Library](https://knowledge.leegality.com/deal-collaboration/Obligations/Settings/obligation-library) - [Creating an Obligation Template](https://knowledge.leegality.com/deal-collaboration/Obligations/Settings/create-obligation-template) - [Obligation Settings](https://knowledge.leegality.com/deal-collaboration/Obligations/Settings/obligation-settings) --- # Obligation Settings URL: https://knowledge.leegality.com/deal-collaboration/Obligations/Settings/obligation-settings > Obligation Settings is where you decide when the AI should read your contracts and pull obligations out of them, without anyone having to ask it to. These setti Obligation Settings is where you decide when the AI should read your contracts and pull obligations out of them, without anyone having to ask it to. These settings apply to your whole organisation, so what you choose here affects every contract your team executes or uploads. Extraction only ever runs on contracts that have reached **Executed**. What these settings control is whether it runs on its own at that point, and which contracts it covers. You can still trigger extraction by hand at any time, and you can always add an obligation yourself. See [Adding an Obligation](https://knowledge.leegality.com/deal-collaboration/Obligations/add-obligation). If all four toggles are off, nothing is extracted automatically and every obligation in your organisation is created by hand. ## Opening Obligation Settings 1. Go to **Settings** and click **Obligations** in the sidebar. 2. Open the **Settings** tab. ## Extraction Triggers Four toggles control automatic extraction. All of them start off, so nothing is extracted automatically until someone turns them on. | Toggle | What it does | Good to know | | :--- | :--- | :--- | | **Auto-extract from contracts executed from a Workflow** | This toggle extracts obligations from contracts that complete execution through a Deal Collaboration workflow. | This covers the usual path, where a contract is signed inside the product. Extraction starts as soon as the contract reaches **Executed**. | | **Auto-extract from uploaded contracts outside a Workflow** | This toggle extracts obligations from contracts that you upload rather than execute in the product. | This is how you get obligations out of older contracts that were signed before you started using Deal Collaboration. | | **Let users decide on extraction for non-workflow uploads** | This toggle lets people choose whether to extract obligations each time they upload a contract, individually or in bulk. | The choice appears as its own toggle on the upload screen. See [Choosing Extraction When You Upload](#choosing-extraction-when-you-upload). | | **Skip auto-extraction for expired contracts** | This toggle leaves out contracts whose expiry date has already passed, so the AI only reads contracts that are still live. | Contracts with no expiry date, and those with perpetual or open-ended terms, are always processed. | > **Info — Note** > > There is no Save button. Each toggle takes effect as soon as you click it, and the toggle itself is your confirmation. If a change cannot be saved, the toggle returns to its previous position and you are told why. ### Choosing Extraction When You Upload When you upload contracts, the upload screen carries its own toggle, **Automatically extract obligations from the uploaded contracts**. It is on by default, so you can turn it off for a batch of contracts you do not want read. Turning it on here also overrides the organisation setting for that upload, so you can extract from a particular batch even when automatic extraction is switched off for uploads generally. ### What Happens After a Trigger Extraction runs in the background and never holds up the work that started it. Signing completes and uploads finish whether or not extraction succeeds, and a failure is recorded rather than shown to the person who uploaded. Contracts are sent for extraction in batches of up to 100. When **Skip auto-extraction for expired contracts** is on and the expiry date cannot be worked out from the contract, the contract is still sent, and the expiry is checked before it is read. Follow what happens next in [Obligations in the Processing Hub](https://knowledge.leegality.com/deal-collaboration/Obligations/obligations-in-processing-hub), which lists one row per contract and shows whether extraction is queued, running, finished or failed. > **Caution — Important** > > Re-extracting a contract replaces the obligations already extracted from it. Anything a person edited or verified on those obligations is replaced along with them. ## Related Pages - [What is an Obligation?](https://knowledge.leegality.com/deal-collaboration/Obligations/obligations-overview) - [Obligation Library](https://knowledge.leegality.com/deal-collaboration/Obligations/Settings/obligation-library) - [Managing Obligation Categories](https://knowledge.leegality.com/deal-collaboration/Obligations/Settings/obligation-categories) --- URL: https://knowledge.leegality.com/deal-collaboration/signing-journey # Sending a contract for eSign The contract status must be in the **Ready for Signing** in order to send it for eSigning. ### Roles and Responsibilities - **Initiator or Legal Negotiator:** Responsible for finalising documents and configuring eSigning. ## To Send contract for eSigning 1. A task will be assigned to Initiator/Legal Negotiator to Configure Signing. 2. On the Contract's detail page, click on **Configure Signing** button. 3. Select the **Document(s)** you wish to send for eSigning. > **Warning — Note** > > Proceeding further will convert the document to PDF, delete all comments, and accept changes made in tracked changes. This ensures that a clean document is sent for execution. 4. Click the **Finalise and Continue** button. 5. You will now be redirected to Leegality’s Document Execution platform. The contract that needs to be executed will automatically appear here. You will also have the option to affix stamps to the contract. 6. Click **Next** to add invitees. All the collaborators apart from the Counterparty POC will automatically be in CC. 7. Click on the **+ Add Invitee** button to add signers. 8. Add the Name, Email Address and/or Phone number of each signer. > **Tip** > > Explore advanced options such as signature types, security features, reference attachments for invitees, and more. Check out more about our [**Document Execution Platform**](https://knowledge.leegality.com/getting-started/sending-journey). 10. Click on the **Next** at the bottom right. 11. Set the signing coordinates where signers should place their signatures on the contract. 12. Click the **Send** button. Every invitee will receive a notification to sign the contract. All the relevant stakeholders like Reviewers, Business Negotiator and Legal Negotiator marked in CC will also get relevant notifications. To view the Signing details, click on the **View Document** button on the Contract's details page. Here, you can track the signing status of each invitee. --- URL: https://knowledge.leegality.com/deal-collaboration/tasks # Tasks The Tasks section in the DC software is a centralised place where users can manage and track their assigned tasks. Whenever a collaborator needs to perform an action, a task will be assigned to them. To access the Tasks section, click on **Tasks** in the left navigation menu. > **Info** > > Collaborators will receive a notification whenever a task is assigned to them. ## Task List Columns The Tasks list displays the following columns for each task: | Column | Description | | :--- | :--- | | **Task Name** | The name of the task assigned to the collaborator. | | **Task Type** | The kind of action the task requires, such as Review Document or Configure Signing. | | **Task Status** | The current stage of the task. | | **Due Date** | The date by which the task should be completed. | | **Counterparty** | The external party associated with the deal or document the task relates to. | | **Document Name** | The name of the document the task is linked to. | | **Date Initiated** | The date the task was created and assigned. | > **Tip — Reference** > > See [Task Statuses](#task-statuses) for what each status means, and [Common Tasks](#common-tasks) for the task types a collaborator may see. ## Task Statuses - **Pending Tasks:** Tasks needing your action. Click "Review" to go to the contract's detail page and complete the task. - **Completed Tasks:** Tasks that have been finished and no longer require any action. They are marked as "Resolved" in the system. - **Cancelled Tasks:** Tasks that have been aborted and no longer require any action. This occurs when the associated document is discarded. ## Common Tasks - **Send for External Review:** This means the internal review is complete and the document is ready for external review. - **Send for External Review or Sign:** Internal negotiation is complete. You need to either send the document for another external review or send it for signature. - **Configure Signing:** Negotiations are complete, and the document is ready to be sent for eSigning. - **Review Document:** Review the entire document. - **Review Variable:** Review specific variables in the document. - **Review Section:** Review specific sections in the document. - **Re-fill Value of Variable:** Update the values of specific variables. ## Find Tasks - **Search:** Use the search bar to find tasks by deal, counterparty, or document name. - **Filters:** Apply filters to narrow down the tasks based on Status. --- URL: https://knowledge.leegality.com/deal-collaboration/Collaboration/comparing-document-versions # Comparing Document Versions Comparing document versions ensures all changes can be identified and reviewed accurately. When you compare the two documents, all the changes are visible in track mode. ## To Compare Document Versions 1. On the Contract Details page, click on the **Compare Versions** icon at the top. 2. Select the two versions of the document you want to compare: the **Base version** and the **Revised version**. > **Info — Note** > > You can also download the previous versions from here. 3. The changes will be in track mode, showing inserted and deleted text. Carefully review the highlighted changes to ensure they are correct before approving them. Review the highlighted changes to ensure they are correct and acceptable. > **Info — Note** > > Whenever a document is modified, a new version of the document is saved. ## Example Scenario 1. The negotiator sends version 1 of the contract to the counterparty for external review. 2. The counterparty reviews the contract and sends back version 2 with their changes. 3. The negotiator compares version 1 (Base version) and version 2 (Revised version) using the Leegality Deal Collaboration’s comparison feature. 4. The software shows all changes made by the counterparty in version 2 compared to version 1 in track mode. 5. The negotiator reviews the changes, if the changes are acceptable, the negotiator can approve them. Otherwise, they can edit the document and send it for external review. By following these steps, users can effectively compare document versions, ensuring all changes are thoroughly reviewed and approved, maintaining the integrity and accuracy of the contract throughout the negotiation process. --- URL: https://knowledge.leegality.com/deal-collaboration/Collaboration/remarks # Remarks Remarks allow you to add notes or comments to a contract for internal purposes. Unlike [Comments](add-comments.mdx), Remarks are not linked to a specific part of the document and are not stage-dependent. They remain on the contract regardless of its current status. Remarks are available for all contracts and are useful for adding context, sharing internal notes, or attaching supporting files. > **Info — Key Points** > > - Remarks are for **internal purposes** only and add context to the contract. > - Remarks are **not stage-dependent** — they persist across all contract stages. > - Each remark supports up to **2,000 characters**. > - You can upload up to **5 attachments** per remark in various file formats. > - Remark activities are **not recorded** in the Activity Log. ## Add a Remark 1. Go to the **Contract Details Page**. 2. Navigate to the **Remarks** section. 3. Click **+Add Remark**. 4. In the popup: - Type your remark text (up to 2,000 characters). - **Tag users** by typing **@** followed by their name. The tagged user will receive an email notification about the remark. - **Upload Reference Attachment(s)** — add any supporting documents, screenshots, or spreadsheets for reference. Supported formats: **JPG, PNG, DOCX, TXT, CSV**. You can upload up to **5 files** per remark. - You can **rename uploaded files** by clicking the edit option before submitting. 5. Click **Add Remark** to submit. The remark will now be visible on the contract. ## View Remarks Anyone who has access to the contract can view all remarks. For remarks with reference attachments, you can: 1. Click the **Preview** button to preview the reference document. 2. Click the **Document** icon to download the attached reference document. > **Info — NOTE** > > You can sort remarks using the **Sort** icon. Available options: **Sort by Newest** and **Sort by Oldest**. ## Edit Remarks 1. Locate the remark you want to edit on the **Contract Details Page**. 2. Click on the **Edit** option on your remark. 3. Make your changes to the text, tags, or attachments. 4. Click **Save** to update the remark. ## Delete a Remark 1. Locate the remark you want to delete on the **Contract Details Page**. 2. Click on the **Delete** option on your remark. 3. Confirm the deletion when prompted. > **Info — NOTE** > > You can only edit or delete remarks that **you** created. Remarks created by other users cannot be deleted. --- URL: https://knowledge.leegality.com/deal-collaboration/Collaboration/add-comments # Add Comments Comments are a collaborative tool designed to enhance communication within the software, enabling users to collaborate effectively. 1. Go to the Contract Details Page and click on the **View Document** and then click on the **Comment** 💬 icon on the top right. 2. In the right panel, click on **+ Add Comment**. 3. There are two types of comments. a. **Internal Comment:** For the internal users and collaborators. All internal comments are deleted before the document is sent to the counterparty for signing. b. **External Comment:** For external stakeholders and counterparties. 4. You can also tag an individual in a comment, by mentioning their email address. For example `@person@email.com`. 5. Click on the **Comment** button. > **Info — Note** > > The individual mentioned in the comment will receive an email notification. Comments added to a contract will be visible to all collaborators. The person who added the comment can Resolve, Edit, and Delete it. --- URL: https://knowledge.leegality.com/deal-collaboration/Collaboration/manage-collaborators-and-reassignment # Manage And Reassign Collaborators The Manage Collaborators feature allows you to replace, add, or remove team members with specific roles at any stage of the deal negotiation process without discarding the document. This is particularly useful when a Legal Negotiator or Business Negotiator needs to change during an active deal. ## Access the collaborators modal 1. Open any document that is in a **pre-execution stage**. 2. Go to the **Document Details** page. 3. Click the **Share** icon (🔗) or the **Collaborators** section. 4. The collaborators modal opens, showing all collaborators associated with the document. ## Collaborator actions In the collaborators modal, click the **three dots (⋮)** next to any collaborator to see the available options: - **Replace**: Replace the current assignee with a new person - **Remove**: Remove the collaborator from the document ## Add a collaborator Add team members to view, comment on, or edit contracts based on their role. 1. In the collaborators modal, click **Add**. 2. Select the user you want to add. 3. Assign a role: - **Collaborator**: Basic access to view and comment - **Legal Negotiator (LN)**: Full legal workflow responsibilities - **Business Negotiator (BN)**: Business workflow responsibilities - **Pre-Sharing Reviewer (PSR)**: Access to assigned variables or sections 4. **Attach additional deal documents**: You can select which contracts of the specific deal the person should have access to. You can select multiple contracts by clicking the checkbox. This option is available only to the Collaborator role. When you are added as an LN or BN, you automatically get access according to your role. 5. Click **Add** to confirm. The collaborator will receive access to the contract based on their assigned role and underlying user permissions. > **Info — NOTE** > > Every collaborator receives at least 'share and comment' access. Business users with limited visibility will be able to view and comment on the contract even if they don't normally have access. ## How roles affect collaborator rights The rights a collaborator receives depend on both their assigned role and their underlying user role in the system. ### Admin users Adding an admin as a collaborator is redundant since they already have broad access to all contracts. ### Legal users When added as a collaborator, legal users gain edit access to the contract in addition to viewing and commenting rights. ### Business users Business users added as collaborators can view and comment on contracts. However, if a business user is assigned as a Legal Negotiator but their underlying role lacks edit permissions, they will not be able to edit the contract. ### Pre-Sharing Reviewers Pre-Sharing Reviewers have a limited role that is active only at the start of the contract, before it is shared with external parties. They are assigned specific variables or sections to fill in. Only one PSR can be assigned per variable. > **Info — Note** > > A user's underlying role determines their actual permissions. The collaborator role you assign cannot grant permissions beyond what their user role allows. ## Reassign Legal Negotiator or Business Negotiator Replace the current LN or BN with a different user to transfer workflow responsibilities. 1. Open the document and go to the **Document Details** page. 2. Click the **Share** icon (🔗) or **Collaborators** section. 3. Locate the current Legal Negotiator or Business Negotiator. 4. Click the **three dots (⋮)** next to their name. 5. Select **Replace**. 6. Choose the new user from the list. 7. Confirm the replacement. The newly assigned user will gain all responsibilities associated with the LN or BN role. > **Info — NOTE** > > - New assignees receive **immediate access** to the contract > - New assignees can view the **full activity and version history** > - Activity logs are **updated** to reflect the change > - The contract lifecycle is **not affected** — the contract remains at its current stage ## Reassign Pre-Sharing Reviewers Pre-Sharing Reviewers are assigned at the start of a contract to fill specific metadata or contract sections. Their role is active only **before the contract is shared** with external parties. > **Info — Note** > > - Only **one PSR can be assigned per variable** — no two users can review the same variable in a contract > - To assign a variable to a different PSR, you must first unassign it from the current PSR ### Replace a Pre-Sharing Reviewer To replace a PSR or reassign their variables: 1. Go to the **Collaborators** modal. 2. Click on the PSR you want to replace. 3. A popup opens showing their **Assigned Variables** and **Assigned Section(s)**. 4. You can either: - **Delete the user** to remove them entirely, or - **Uncheck specific variables** that you want to assign to another PSR 5. Optionally, change the name in the **Name** section to assign a different user. 6. Click **Replace** to confirm the changes. ### Add a new Pre-Sharing Reviewer To add a new PSR and assign variables: 1. Go to the **Collaborators** modal. 2. Click **Add**. 3. Select **Role** as **Pre-Sharing Reviewer**. 4. **Assign Variables**: Select one or more unassigned variables for the PSR to review. 5. **Assign Section(s)**: Select specific sections from the document for the PSR to review. 6. Click **Add** to confirm. > **Warning** > > You can only assign variables that are currently unassigned. If a variable is already assigned to another PSR, you must unassign it first before adding it to a new PSR. ## Bulk add collaborators across contracts Add collaborators across multiple contracts at once from the Contracts page. 1. Go to the **Contracts** page. 2. Select multiple contracts by checking the **checkboxes** next to each contract. 3. Click **+Add Collaborators** from the panel that appears above. 4. In the pop-up, under **Add User**, enter the name of the user you want to add as a collaborator. 5. Under **Select Role**, choose the role for the user: - **Legal Negotiator** - **Business Negotiator** - **Collaborator** 6. Click **Add** to confirm. The selected user will be added as a collaborator with the chosen role across all the selected contracts. > **Info — NOTE** > > The **Pre-Sharing Reviewer** role is not available for bulk add. To assign a PSR, use the single document flow described above. ## Remove a collaborator Collaborators can be removed when they no longer require access to the contract. 1. Open the collaborators modal from the **Share** icon (🔗). 2. Locate the collaborator you want to remove. 3. Click the **three dots (⋮)** next to their name. 4. Select **Remove**. 5. Confirm the removal. > **Warning — Minimum requirement** > > Every contract must have at least **1 Legal Negotiator** and **1 Business Negotiator**. You cannot remove a collaborator if it would leave the contract without a required role. ## Who can reassign collaborators Users with access to the contract can reassign collaborators. No special permissions are required beyond contract access. To learn more about the different collaborators and their entitlements, refer to the [Deal Negotiation Process](https://knowledge.leegality.com/deal-collaboration/deal-negotiation/deal-negotiation-process) page. --- URL: https://knowledge.leegality.com/deal-collaboration/Collaboration/offline-review # Offline Review The Offline Review option allows you to download a document, make changes offline, and then upload the edited document back into the software. Documents with the status *Internal Review, Ready for External Review* or *External Review* can be downloaded for offline review. To offline review a document: 1. **Download the document** 1. Click on the **Download** icon 2. Select **Download to Review** and click the **Download** button. 2. **Edit Document** 1. Make the necessary changes to the downloaded document. 3. **Upload Document** 1. Click on the **Upload** button. 2. Upload the edited document. 3. Click **Proceed.** During the offline review, other collaborators will see that the document is under Offline Review and who is performing the review. In addition to the collaborator who downloaded the document for Offline review, other collaborators with edit access can also upload the document and finish the offline review process. > **Info — Note** > > - Online editing is disabled for all collaborators until the offline review is completed. > - Variables and sections cannot be reviewed while the document is being reviewed offline. --- URL: https://knowledge.leegality.com/deal-collaboration/Collaboration/rename-document # Rename Document The Rename Document option allows you to update the document name at any stage of the collaboration — including after the contract has been Executed. This is useful when the document title needs to be corrected, standardised, or updated to reflect changes made during negotiation, without affecting the contract content or its execution status. 1. On the **Contracts** page, click on the document you want to rename. 2. Click the **Edit** ✏️ icon alongside the document name. 3. The document name becomes editable. Update the name as required. 4. Click **Save**. The document will be updated with the new name across the platform. The contract status and all existing data — collaborators, comments, versions, and signatures — remain unchanged. > **Info — Note** > > Renaming a document is available at every stage of the contract lifecycle, including the Executed stage. --- URL: https://knowledge.leegality.com/deal-collaboration/Collaboration/unlock-document # Unlock Document The Unlock Document option allows you to make changes to the document even after the document status is marked as Ready for Signing. Normally, once negotiations are complete and the contract is marked as Ready for Signing, the document is locked, and no further editing is allowed. However, there might be instances where last-minute changes are necessary before the contract goes for signing. In such cases, you can unlock the document and make the required changes. > **Info — Note** > > The user must have permission to Unlock the document and the Document Status should be Ready for Signing. 1. In the contract, click on the three dots (**…**). 2. Select the **Unlock Document** option. 3. Click **Confirm**. Once unlocked, collaborators with edit access can make changes to the document. The document status will change to Negotiation Internal. A task will be created for the Legal Negotiator to Review the document. After reviewing and approving the changes, the legal Negotiator can mark the document as Ready for Signing again. --- URL: https://knowledge.leegality.com/deal-collaboration/Leegality Word Add-in/word-plugin # Leegality Word Add-in The **Leegality Word Add-in** is your essential extension, integrating Deal Collaboration (DC) directly into Microsoft Word. It streamlines your entire contract lifecycle in one familiar interface, eliminating the need to switch applications. Post-initiation, you can perform most of your core document management, approval, and negotiation actions **directly from Word.** With the add-in, you can perform core Leegality actions without leaving Microsoft Word, including: * Securely accessing your Deal Collaboration account. * Browsing your assigned contracts and pending tasks. * Executing key actions like reviewing, **comparing versions**, uploading revisions, and **sharing the document** with internal and external stakeholders. * Maintaining visibility into document status and the **audit trail**. > **Info — NOTE** > > All the changes made using the Add-in are reflected in the DC platform in real-time. ## Getting Started ### Finding and Installing the Add-in If your organization has enabled the Leegality Word Add-in, it will be visible in your Microsoft Word application. 1. **Access the Add-in** * Open **Microsoft Word** and create or open a document. * Navigate to the **Home** tab on the ribbon. * Click the **Add-ins** button. 2. **Launch the Add-in** * Once installed by your IT team, the **Leegality** button will be visible on the Word ribbon. * Click this button to open the sidebar and begin using the Deal Collaboration features. > **Info — INFO** > > If you do not see the Add-in, it may not be enabled for your organization. To enable the Word Add-in, verify that your organization meets the requirements for centralized deployment. [Click to know more](https://learn.microsoft.com/en-us/microsoft-365/admin/manage/centralized-deployment-of-add-ins?view=o365-worldwide). ### Logging In ![Word Add-in sign in window](\img\DC-WordPlugin-Signin.PNG) 1. Once installed, open the Deal Collaboration Add-in. 2. Click **Sign In**. 3. Enter your Leegality credentials. 4. Click **Get Started** once the authentication is complete. > **Info — NOTE** > > Your authentication is saved, so you won't need to sign in every time you open Word until the session expires after the DC session time of **60 minutes**. --- URL: https://knowledge.leegality.com/deal-collaboration/Leegality Word Add-in/Review a Contract Using the Word Add-in # How to Review a Contract Using the Word Add-in This guide walks you through the simple steps to review (edit, comment, and then approve or reject) a contract directly within Microsoft Word using the Leegality Add-in. ![Word Add-in window](\img\Review-document.png) ### 1. Find the Contract: 1. Open the **Leegality Add-in** in the side panel. 2. You can view all pending actions from your end in the **Task List** (which is the same list seen in the DC browser). ![Task List](\img\My-Tasks.png) 3. Locate the contract needing your review in the **Contract List**. You can use **Filters** or **Search** if needed. You can also click on the task of your choice to route you to the contract. ### 2. Download for Review: ![Download for review](\img\Download-document.png) 1. Click the **Download icon** next to the contract name. This action is available during internal negotiation stages. 2. Check the box for **Enable offline review mode**. This prevents others from editing the contract on the Leegality platform while you work in Word. 3. The contract will open in your main Word window. ### 3. Make Your Edits & Comments: Use Microsoft Word's standard features to make changes: * Turn on **Track Changes** (**Review** tab) to clearly show your edits. * Add **Comments** (**Review** tab) to ask questions or provide feedback without changing the text directly. * Save the document periodically as you work, just like you would do in a Word document. > **Info — NOTE** > > Edits and comments made in Word are marked as **external** comments. If you want to use **internal** comments, please use the DC browser's online editor. ### 4. Upload Your Revised Version: The upload feature is unique; it automatically detects and uploads the document currently open in your Word window, eliminating the need for manual file selection. ![Upload document](\img\upload-document.png) 1. Once you've finished editing and commenting, go back to the **Leegality Add-in side panel**. 2. Click the **Upload** button. 3. Optional: You can optionally give this version a specific name. 4. This saves your edited Word document back to the Leegality platform as a new version and removes the offline lock if you enabled it. --- ## Extended Functionality in the Plugin ### AI Review In Word Add-In The **AI Review** feature is available in the Leegality Word Add-in, allowing you to efficiently assess documents for potential risks and compliance issues without leaving Microsoft Word. You can access AI Review directly from the right-side panel in the Add-in. ![AI review in Word Add in](\img\WordAddin-AIReview.png) #### Key Differences in Word Add-in The AI Review feature in Word Add-in offers unique advantages compared to the browser version: 1. **Open-Ended Document Review:** You can open any document directly in Word and use AI Review—no need to initiate it through the DC platform first. This provides greater flexibility for ad-hoc contract reviews. 2. **Insert Text with Track Changes:** When AI Review identifies issues (Not Met or Not Found cases) and provides suggested additions: * Click **Insert Text** to add the suggested clause directly into your Word document. * Click **Insert Text [Track Mode]** to add the suggestion with Track Changes enabled, making it easy to review and accept or reject the changes later. > **Info — NOTE** > > These insertion options are not available in the browser version. #### How to Use AI Review in Word Add-in 1. Open your document in Microsoft Word with the Leegality Add-in active. 2. In the right-side panel, locate and click on **AI Review** above the other features. 3. Select the Rule Set you wish to use for the review from the dropdown menu. 4. Click **Run** to start the AI Review process. 5. Review the results categorized as: * **Met:** Requirements fully satisfied * **Not Met:** Requirements found but need improvement * **Not Found:** Required clauses missing from the document 6. For **Not Met** and **Not Found** cases, use the **Insert Text** or **Insert Text [Track Mode]** buttons to add suggested clauses directly into your document. 7. Click **Re-run** after making changes to see updated results. > **Info — NOTE** > > For detailed information about AI Review functionality, see [AI Review](https://knowledge.leegality.com/deal-collaboration/deal-negotiation/ai-review). To learn how to create and manage Rule Sets, see [Rule Set Management](https://knowledge.leegality.com/deal-collaboration/Settings/rules-set). All other features available in the DC browser are also accessible in the Word Add-in, providing a consistent experience across platforms. ### Approve or Reject After uploading, the workflow buttons for the contract might become active in the side panel (depending on the contract stage and your permissions). * Click **Approve** if the contract (with your revisions, if any) is satisfactory for the current stage. * Click **Reject** if the contract requires significant changes from others before proceeding. This action advances the contract's stage on the Leegality platform. ### Comparing Document Versions Compare the currently open document (the Base Version) with any historical version uploaded to the DC platform. ![Compare documents](\img\Compare-document.png) 1. Click the **Compare icon** ($\approx$) in the side panel. 2. **Base version:** This is the version currently opened in your Word window. 3. **Revised version:** Select any one of the revised versions uploaded in DC under the contract to compare against. 4. Click **Run Compare**. The Add-in displays the changes between the current document and the selected revised version. ### Sharing a Document Share the latest document version with other collaborators on the contract (this mirrors the functionality in the DC platform). ![Share the Document](\img\share-document.png) 1. Click the **Share icon** ($\rightarrow$). 2. Select users from the organization's user list. 3. Attach additional deal documents, if any. 4. Optional: Provide any additional message you want to share. 5. Click **Share**. ### Viewing the Activity Log The **Activity Log** shows all actions logged in real-time, remaining consistent with the DC web platform audit trail. ![Activity log](\img\DC-Plugin-Activity log.PNG) > **Info — NOTE** > > All these features are also available in the DC platform, providing similar functionality. ### Additional Actions Depending on the contract stage, multiple options may appear. Click the **More** icon (⋮) to view all available actions. ![More actions](\img\More-actions.png) | Action | Description | | :--- | :--- | | **Discard** | Permanently deletes the document from the platform. Use this action with caution. This feature is always available. | | **Unlock document** | Manually removes the lock on the document, allowing others to access and edit it on the DC platform. | | **Upload signed documents** | Uploads the copy of the document back to the Deal Collaboration platform. | ### Advance Contract Workflow to DC You can move the document to the next stage of its pre-defined workflow (e.g., from 'Draft' to 'Awaiting Approval') directly from the Add-in, pushing the status update to the DC platform. | Action | Purpose | | :--- | :--- | | **Approve / Reject** | Used during internal review stages. | | **Send for External Review** | Moves the contract to the counterparty negotiation stage. Internal comments are automatically deleted before sharing. | | **Mark as Ready for Signing** | Moves the document to the final configuration stage. | These actions work the same in the browser and the plugin. The Word Add-in handles the collaboration and negotiation lifecycle but hands off specific final processes to the DC web platform. ![Configure signing window](\img\Configure-signing.png) > **Info — NOTE** > > Clicking the **Configure Signing** button will redirect the user to the specific configuration page on the DC web platform. Here, once you login, you will see your [configure signing](https://knowledge.leegality.com/deal-collaboration/signing-journey) journey. For E-Signing, users will be redirected from DC to the Document Execution platform. --- URL: https://knowledge.leegality.com/deal-collaboration/activity-logs # Activity Logs The Activity Logs page gives you a complete record of every action taken across your deals — who did what, when, and on which document. Use it to stay on top of your contract workflows and maintain a clear audit trail. ## How to Access Activity Logs 1. Sign in to your Deal Collaboration platform. 2. Select **Activity Logs** from the left navigation panel on the Deal Collaboration home page. ![DC Activity Log](https://knowledge.leegality.com/img/DC_ActivityLogs.png) The Activity Logs table displays the following information for each entry: | Column | What It Shows | | :---- | :---- | | **User** | Name and email address of the person who performed the action | | **Document Name** | Title of the document along with its unique Document ID | | **Action** | A description of what happened (e.g., "Document approved"), along with the exact date and time | | **Document Status** | A colour-coded badge showing the current stage of the document | ## Search Activities 1. Head to the **Search bar** at the top. 2. Type in a document name, Document ID, or any keyword from the Action column. The table will instantly filter to show matching results. ## Download Report To export your activity logs: 1. Click **Select Dates** to choose a time range. The available options are: Today, Yesterday, Last 7 days, Last 30 days, Last month, This month, All time, and Custom (pick a specific start and end date). 2. Click **Download Report** to export the logs as an `.xlsx` file. > **Tip** > > If you skip selecting a date range and directly click **Download Report**, it will export the all-time report by default. ## Refresh Click the **Refresh** button to pull in the latest activity. This is handy when you're actively monitoring a deal and want to see real-time updates. ## Document Status Reference Each log entry shows a status badge indicating where the document currently stands. Here's what each status means: | Status | What It Means | | :---- | :---- | | **Under Internal Review** | The document is being reviewed by your internal team | | **Ready for External Review** | Internal review is done — the document is ready to be shared with the counterparty | | **External Review** | The counterparty has received the document for their review | | **Negotiation Internal** | Your team is redlining or discussing changes internally | | **Negotiation External** | The document is in active negotiation with the counterparty | | **Ready for Signing** | Negotiation is complete — the document is ready to be sent for signatures | | **Sent for Signing** | Signature requests have been sent out to the signatories | | **Executed** | All parties have signed — the document is fully executed | | **Discarded** | The document process has been cancelled | --- URL: https://knowledge.leegality.com/deal-collaboration/Settings/global-variables # Global Variables Global variables are accessible to all users, allowing them to add these pre-built variables when [creating a template](https://knowledge.leegality.com/deal-collaboration/Templates/create-template). ## Types of Global Variables ### Default Variables These are system-defined variables that come pre-configured and cannot be edited. You can enable or disable these variables as needed, but their core definition remains unchanged. If the default terminology does not align with your organization's usage, you can assign an **alias**—a different name that fits your context. > **Info — Example** > > If the default variable is "Term" but your organization uses "Tenure," you can set "Tenure" as the alias for "Term." ### Custom Variables These variables can be created to fit your specific needs from the settings. You have complete control over custom variables, including the ability to edit or delete them at any time. Both Default and Custom variables are available for use in templates during the creation process. ## To create a Global Variable 1. Click **Settings** on the left. 2. Click on the **+ Add Custom Variable** button. 3. In the **Add Custom Variable** pop-up. - **Variable Name:** Enter a suitable variable name. - **Variable Type:** Select the variable type from available options. - **Placeholder Text:** Enter text to provide hints or examples of the expected input. 4. Click **Save**. --- URL: https://knowledge.leegality.com/deal-collaboration/Settings/rules-set # Rule Set ## What are Rule Sets? Rule Sets are collections of rules that guide AI in reviewing your contracts. Think of a Rule Set as a checklist and each Rule as an item on that checklist. When AI reviews your documents, it needs to know what to look for—specific clauses, conditions, terms, or compliance requirements. Rule Sets ensure the AI review is: - **Consistent** across all your documents - **Customized** to your organization's requirements - **Reusable** without reconfiguring for each document ## How Rule Sets and Rules Work Together Each Rule Set is a collection of related rules. One Rule Set can contain multiple Rules, allowing you to organize your review criteria logically. **Important Limits:** - Each Rule Set must contain **at least 1 rule** - Each Rule Set can contain **up to 50 rules** - You can create **unlimited** Rule Sets ## Create a Rule Set ### 1. Navigate to the Rule Set tab 1. From the **Settings** page, click the **Rule Set** tab. A table showing all configured rule sets appears. 2. Click **+ Add Rule Set** to begin creating a new rule set. ### 2. Enter rule set details 1. In the **Name** field, enter a unique name for the rule set. 2. In the **Description** field, provide a brief summary of the rule set's purpose. This is optional. 3. Click **Proceed**. A new window opens for you to define rules within the rule set. ## Add Rules to a Rule Set ### 1. Add a rule 1. Click **+ Add Rule**. A configuration panel appears on the right side of the screen. ### 2. Configure rule details 1. In the **Rule** field, define the condition or logic the AI will use to review the document. This is a mandatory field. 2. In the **Rule Description** field, provide a brief summary that explains the rule's purpose and scope. 3. In the **Suggested Clause** field, enter a recommended alternative clause to ensure compliance. You can modify this clause as needed before finalizing the contract. > **Info — Character Limits** > > Each field— **Rule, Rule Description**, and **Suggested Clause** —can accommodate up to 2000 characters. 4. Click **Save** to save the rule and return to the rule set overview page. > **Info — NOTE** > > A confirmation message, "Rule added successfully!" appears. 5. To add more rules, click **Add New Rule**. 6. Once you have added all rules, click **Finish** to complete the process. > **Tip — Best Practice** > > While **Rule Description** and **Suggested Clause** are optional, providing them clearly helps the AI deliver more accurate and actionable reviews. --- URL: https://knowledge.leegality.com/sign-station/introduction # Introduction to SignStation SignStation is a **self-hosted DocSigner utility** that lets your organisation apply its own eSign on large volumes of documents, such as invoices, policies and official letters. ## Built for High-Volume Organizations SignStation is meant for documents that only require your organisation’s signature and do not need your customer’s signature—documents like insurance policies, invoices and official letters. ## Why SignStation? Many enterprises sign large volumes of simple documents (invoices, policies, letters) every day. This is often handled either manually through shared DSC tokens—which is repetitive and time-consuming—or through generic DocSigner utilities that can be more complex and expensive than necessary for this specific use case. SignStation is designed to provide automated, server-side signing for these documents in a cost-efficient, secure way, while comfortably handling large daily volumes. ## The SignStation Advantage SignStation transforms the economics of digital signing through a **fixed yearly license model**: - **Pay Once, Sign Unlimited**: A single annual license fee covers unlimited signatures for the entire year. - **Massive Cost Savings**: Prospect to save a huge sum compared to pay-per-signature models. - **Predictable Expenditure**: No surprises—know your exact annual signing costs upfront. - **Self-Hosted Control**: Deploy on your own infrastructure for complete data sovereignty and security. ## How It Works SignStation operates on a simple principle: 1. **Purchase an annual license** for your organization 2. **Deploy the platform** on your own servers (self-hosted) 3. **Sign unlimited documents** throughout the license period using digital certificates 4. **Scale without limits**—no per-signature fees, no hidden costs ## The Impact By switching to SignStation, high-volume organizations achieve: - **Financial Efficiency** - **Operational Freedom** - **Budget Certainty** - **Enterprise Control** ## Next Steps Ready to get started? Head over to [Logging In](https://knowledge.leegality.com/sign-station/getting-started/logging-in) to access your SignStation account. --- URL: https://knowledge.leegality.com/sign-station/getting-started/logging-in # Logging In to SignStation Learn how to access your SignStation account and get started with document signing. > **Tip — New to SignStation?** > > If you're unfamiliar with SignStation, start with the [Introduction](https://knowledge.leegality.com/sign-station/introduction) to understand its features and benefits. ## Steps to Log In Open your web browser and navigate to the SignStation URL provided by your administrator. 1. Enter your **Email address** or **Phone number** in the login field 2. Enter your **Password** in the password field 3. Click the **Sign In** button to access your account > **Info — Admin Credentials** > > The initial admin credentials are provided by Leegality. Once logged in, the admin can create new users and assign them credentials (username and password). ## After Logging In Once you successfully log in, you'll be directed to the SignStation dashboard where you can begin managing licenses, certificates, and signing documents. **Next:** Learn about the [Dashboard Overview](https://knowledge.leegality.com/sign-station/getting-started/dashboard-overview) to familiarize yourself with the interface. --- URL: https://knowledge.leegality.com/sign-station/getting-started/dashboard-overview # Dashboard Overview The Dashboard functions as the application's control center, providing key statistics on signing activity, certificate status, and centralized navigation to all core features. ![Dashboard](\img\dashboard_overview_img.PNG) ## Application Header and Controls The static header provides essential global controls and user context. | Element | Description | |---------|-------------| | **Department Selection** | The **All Departments** dropdown displays the currently active department. A department must be selected before initiating any new document signing workflow. | | **Settings Icon** (⚙️) | Provides access to global application configuration settings, user preferences, and system management options. | | **Profile/User Icon** | Accesses user account management, including profile details and the application logout function. | ## Navigation Sidebar The sidebar provides immediate access to the primary functional modules of SignStation. | Link | Function | |------|----------| | **Sign New Document** (Button) | Initiates the three-step document signing workflow: Upload → Configure → Sign. | | **Home** | Navigates back to the current Dashboard view. | | **Documents** | Directs the user to the document management module for viewing transaction history and document status. | | **Certificates** | Navigates to the Certificate Manager for reviewing, adding, and modifying digital certificates. | ## Document Signing Statistics This section summarizes the volume of successful document signing activity across defined periods: - **Today**: Displays the total count of documents successfully signed on the current calendar day. - **Last 30 Days, Last 90 Days, Last 365 Days**: Show the rolling count of documents successfully signed within these respective historical windows. Each card includes a trend indicator reflecting performance compared to the previous period. The metric is based on final signed documents. ## Certificate Status Overview This area monitors the status and inventory of all digital certificates configured within the system: - **Total Certificates:** Reports the total number of certificates configured. The accompanying text indicates how many of these are currently **Configured** and active. - **Certificates Expiring Within Next 30 Days:** This critical warning indicator shows the count of active certificates scheduled to expire within the next 30 days. - **Review Certificates**: Provides direct navigation to the Certificate Manager for certificate maintenance. ## Recently Signed Documents This section functions as a quick-access activity log, displaying the most recent document signing transactions. Each entry lists the **File Name**, the **Signed By** user (who signed the document), the **Department** context, the **Certificate Name** used, and the **Date** of the successful signing. > **Tip** > > The **Show More** link, located in the top right, directs the user to the full Documents module for a complete transaction history. The section displays a fixed, recent number of entries. --- URL: https://knowledge.leegality.com/sign-station/getting-started/initial-setup # Initial Setup Guide This guide outlines the essential steps to set up SignStation for the first time. Follow these steps in order to ensure your organization is ready to start signing documents. > **Tip — Before You Start** > > Make sure you have received your license file from Leegality and gathered all necessary information about your organization's structure, users, and digital certificates. ## Step 1: Upload Your License Your SignStation instance requires a valid license file to activate and operate. This license file is provided by Leegality and should be uploaded first before any other configuration. **What You Need:** - License file from Leegality (`.lic` or similar format) Without an active license, you cannot access SignStation features. Once uploaded, verify that the license status shows as **ACTIVE**. 📖 **Learn More:** [Create a License](https://knowledge.leegality.com/sign-station/license-manager/create-license) ## Step 2: Create Departments Departments represent organizational units within SignStation and help organize users and control access to certificates. Think of them as divisions in your company structure like Legal, Finance, HR, or Operations. **What You Need:** - List of department names based on your organizational structure Start with at least one department. You can always add more later as your needs grow. Use clear, descriptive names that align with your document signing workflows. 📖 **Learn More:** [Department Management](https://knowledge.leegality.com/sign-station/user-management/department-management) ## Step 3: Create Roles Roles define permission levels and control what users can do within SignStation. Each role contains a set of entitlements (permissions) such as signing documents, managing certificates, creating users, or modifying system settings. **What You Need:** - Understanding of user responsibilities in your organization - Permission structure based on job functions Common roles include Super Admin (full access), Document Signer (basic signing permissions), Certificate Manager (certificate handling), and Department Admin (departmental oversight). Design roles based on job functions rather than individual users for easier management. 📖 **Learn More:** [Role Management](https://knowledge.leegality.com/sign-station/user-management/role-management) ## Step 4: Add Users Once departments and roles are configured, create user accounts for everyone who will access SignStation. Each user is assigned to one or more departments and given a specific role. **What You Need:** - User's full name and email address - Department assignment(s) for each user - Role assignment for each user - Initial passwords (can be set manually or auto-generated) Users must be marked as "Active" to log in. You can choose to set passwords manually or have the system generate secure passwords and email them automatically. 📖 **Learn More:** [User Management](https://knowledge.leegality.com/sign-station/user-management/user-management) ## Step 5: Add Digital Certificates Digital certificates are required to electronically sign documents. Each certificate is linked to a specific department, and users can only access certificates from their assigned departments. **What You Need:** - PFX/P12 certificate files in PKCS12 format - Certificate passwords (passkeys) - Department assignment for each certificate Certificates must be in .pfx or .p12 format, under 5MB, and not expired. Store certificate files and passwords securely, and never share passwords through unencrypted channels. 📖 **Learn More:** [Adding Certificates](https://knowledge.leegality.com/sign-station/certificate-management/adding-certificates) ## Step 6: Configure Settings (Optional) Customize SignStation with additional settings for notifications, security policies, and data retention. **Email Notifications:** Set up SMTP configuration to send notifications for events like user creation, document signing, and certificate expiry warnings. Learn more in [Notification Settings](https://knowledge.leegality.com/sign-station/notifications). **Security Policies:** Configure password requirements including minimum length, complexity rules, and special character requirements. Learn more in [System Settings](https://knowledge.leegality.com/sign-station/system-settings). **Data Retention:** Define how long signed documents, audit trails, and system logs are retained before automatic deletion. ## Verification Checklist Before starting production use, ensure: - [ ] License is uploaded and shows **ACTIVE** status - [ ] At least one department is created - [ ] At least one role is created with appropriate permissions - [ ] Admin user account is created and active - [ ] At least one digital certificate is uploaded and linked to a department - [ ] You can log in successfully with a user account - [ ] You can select a department from the header dropdown - [ ] Email notifications are configured (if required) ## Next Steps Once initial setup is complete, test the signing workflow by signing a test document to ensure everything works correctly. Train your users on how to log in and sign documents, and monitor certificate expiry dates to set up renewal reminders. **Ready to sign your first document?** Head to [Uploading Documents](https://knowledge.leegality.com/sign-station/signing-journey/signing-a-document/uploading-documents) to get started. ## Need Help? If you encounter issues during setup such as license validation errors, certificate upload problems, or user creation failures, contact Leegality support for assistance. --- URL: https://knowledge.leegality.com/sign-station/license-manager/create-license # Create a New License Before you can start using SignStation, you need to acquire a valid license from Leegality and upload it to your system. ## How to Obtain a License To obtain a new license or renew an existing license, contact our support team. They will assist you with license generation and provide the license file. > **Info** > > Our support team will guide you through the license acquisition process and ensure you receive the appropriate license file for your SignStation instance. ## Upload Your License to SignStation Once you receive your license file from our support team, follow these steps to upload and activate it: ### Steps to Upload License 1. Navigate to **License Manager** in the Settings menu 2. Click the **Create License** button 3. Upload the license file provided by our support team 4. Click **Create License** to activate ### License Activation After uploading: 1. The system will validate the license file 2. If valid, the license will be activated immediately 3. You'll see a success message confirming the license has been applied 4. The new license will appear in the License Management table with an **ACTIVE** status ## Understanding License Upload Errors If your license file upload is unsuccessful, you may encounter one of the following error messages. ### Common Error Messages | Error Message | Description | |---------------|-------------| | "Your license has expired. Please renew your license or contact support." | The license file has passed its expiration date. | | "License validation failed. The license may be invalid or corrupted. Please contact support." | License validation failed due to invalid JWT format, tampered file, invalid signature, public key mismatch, or file corruption. | | "You have reached the limit for [resource] in your current license. Please upgrade your license or contact support." | The current license has reached its capacity for a specific resource (such as signatures, users, or other features). | > **Info** > > If you encounter any of these errors, contact our support team with the error message. They will assist you in resolving the issue and provide a new license file if necessary. --- URL: https://knowledge.leegality.com/sign-station/license-manager/viewing-managing-license-status # Managing License Status The License Management page provides a comprehensive overview of all active and historical licenses applied to your SignStation instance, along with detailed usage statistics. This page helps you track license validity, monitor consumption, and ensure uninterrupted service. ## Accessing License Management To access the License Management page: 1. Click the **Settings** icon (⚙️) in the application header 2. In the left sidebar, click **License Manager** 3. The License Management page displays all your licenses. ## License Management Table The main view displays a table listing all licenses with the following information: | Field | Description | |-------|-------------| | **License ID** | The unique identifier for the license file. | | **Customer ID** | The identifier associated with the purchasing customer or organization. | | **Expiry Date** | The date the license will cease to be valid. | | **Status** | The current operational state of the license (e.g., Active, Expired). | | **License Type** | The specific tier or feature set enabled by the license. | | **Created At** | The date and time the license was uploaded to the system. | > **Tip** > > Keep track of the **Expiry Date** to ensure you renew your license before it expires, avoiding any service interruption. #### License Status Types The **Status** field indicates the following operational states: | Status | Description | |--------|-------------| | **ACTIVE** | The license is currently valid and fully operational. | | **SUSPENDED** | The license has been temporarily deactivated, typically due to administrative action. | | **REVOKED** | The license has been permanently canceled and cannot be used. | | **EXPIRED** | The license validity period has ended. | > **Warning** > > If your license shows **SUSPENDED**, **REVOKED**, or **EXPIRED**, contact your administrator or vendor immediately to resolve the issue and restore service. #### License Types The **License Type** field specifies the granted features: | License Type | Description | |--------------|-------------| | **Normal** (Standard License) | The primary license that provides the standard set of features and usage rights. | | **Topup** (Resource Topup) | Adds extra resources or capacity on top of an existing license. | | **Validity** (Validity Extension) | Extends the duration or expiration date of the current license. | | **Trial** (Trial License) | A temporary license for evaluating features before purchase. | | **Feature** (Feature License) | Unlocks specific add-on features beyond the standard license. | > **Info** > > You can have multiple licenses active simultaneously. For example, a NORMAL license for base operations plus a FEATURE license for premium capabilities. ## Viewing Usage Statistics To view detailed usage metrics for a specific license: ### Steps to Access Usage Statistics 1. Locate the desired license in the License Management table 2. Click the **three-dot menu** (⋮) associated with that license row 3. Select **View Usage Statistics** A **License Usage Statistics** pop-up window appears, displaying the current utilization metrics under this license: | Metric | Description | |--------|-------------| | **Number of Users** | Total users utilizing the license. | | **Number of Departments** | Total departments utilizing the license. | | **Number of Signatures** | Total signatures consumed under the license. | | **Number of Certificates** | Total certificates configured under the license. | > **Info — INFO** > > Usage statistics help you understand how your license is being consumed across your organization and plan for future capacity needs. ## Best Practices - **Monitor Expiry Dates**: Regularly check license expiry dates to avoid service disruptions. - **Track Usage Metrics**: Review usage statistics periodically to understand consumption patterns. - **Understand License Types**: Know which license types you have to maximize their benefits. - **Plan Renewals**: Contact your vendor well in advance of expiry to ensure timely license renewal. - **Watch for Status Changes**: Be alert to any status changes from ACTIVE to ensure continuous operation. --- URL: https://knowledge.leegality.com/sign-station/profile-management # Profile Settings The Profile section allows individual users to view their personal account information and manage their password. Access this section by selecting **Profile** from the sidebar. Users cannot modify their email address from this interface. ## Personal Info | Field | Description | |-------|-------------| | **Name** | The full name associated with the user account. | | **Username** | The user's email address, which serves as their login identifier. | | **Role** | The system role(s) assigned to the user, defining their permissions. | | **Departments** | A list of all organizational departments to which the user has been assigned access. | > **Info** > > Personal information displayed here is managed by your administrator. Contact your administrator if you need to update your role, or department assignments. #### Profile Restrictions The admin user **cannot** modify their own: - Email address - Username - Department assignment However, the admin user **can**: - Modify their own role assignments - Update other users' profile details (including email, name, roles, and departments) > **Warning — System Protection** > > To ensure continuous system access, at least one admin user must exist at all times. If you attempt to delete or demote the last remaining admin user, the system will prevent the action and display an error message: **"Cannot delete the last admin user"** ## Change Password To update the password for the current user account: 1. Click the **Change Password** button located in the "Personal Info" section. A "Change Password" pop-up window will appear. 2. Enter the following information: - **Current Password**: Enter your existing password in this field - **New Password**: Enter the desired new password. Ensure it meets the system's password policy requirements. - **Confirm New Password**: Re-enter the new password to confirm accuracy 3. Click **Save Changes** to update your password. - Click **Cancel** to dismiss the pop-up without making any changes > **Caution — Password Requirements** > > Your new password must comply with the organization's [password policy](https://knowledge.leegality.com/sign-station/system-settings). This may include minimum length, special characters, numbers, and uppercase letters. If your password doesn't meet these requirements, the system will display an error message. > **Tip — Security Best Practice** > > Change your password regularly and avoid reusing old passwords. Never share your password with others. --- URL: https://knowledge.leegality.com/sign-station/user-management # User Management User management controls access to the SignStation application, defining user credentials, permissions, Roles, and scope (Departments). To access the section, - Navigate to **Settings** section. - Select **User Management**. - Go to the **Users** section. This centralized interface allows administrators to create user accounts, assign roles and departments, manage passwords, and control account status. ## Adding a New User 1. Click the **Add User** button. A creation window will appear. 2. **Enter User Details:** - Enter the full **Name** of the user - Enter the user's primary **Email address** 3. **Configure Access:** - **Select Role**: Choose a single Role from the dropdown list. Roles define the user's permissions within the system. Refer to [Role Management](https://knowledge.leegality.com/sign-station/user-management/role-management) for configuration details. - **Select Departments**: Choose one or more Departments from the dropdown list to assign the user access scope. Refer to [Department Management](https://knowledge.leegality.com/sign-station/user-management/department-management) for configuration details. 4. **Set Credentials and Status:** - Enter the initial **Password** for the user - Ensure the **Enable Active User** option is checked to make the account immediately usable 5. Click **Add User** to finalize the creation of the new account ## Managing Existing Users The main Users section displays a list of configured users, their assigned roles, and departments. ### Searching and Filtering - **Search**: Use the Search bar to quickly locate a specific user by name or email - **Show Inactive User**: Check this box to display users whose accounts are currently disabled ### User Actions (More Options Menu) Click the **three-dot menu** (⋮) next to a user's entry to access the following management options: #### Edit User This option allows modification of user profile and status details: 1. Click **Edit** from the options. 2. Edit the fields as per your requirement. **Editable Fields:** - Update the user's **Name** - Update the user's **Email** - Change the assigned **Role** and **Department** 3. Toggle the user's account status by marking the user as **active** or **not active** 4. Click **Update User** after making changes. #### Set Password This option provides two methods for resetting a user's password: #### Set Manual Password Click this option to enter a custom password in the provided field. **Steps:** 1. Enter a custom password in the password field. 2. Optionally, check the **"Send email notification to user"** box to deliver the new password via email. 3. Click **Set Password** to apply the change, or **Cancel** to exit. > **Caution** > > Ensure manually set passwords meet your organization's security requirements. #### Generate System Password Click this option to generate a secure, randomized password. **Steps:** 1. The system automatically generates a secure password. 2. Click **Generate and Send Password** to automatically email the new password to the user. 3. Click **Cancel** to exit. > **Tip** > > System-generated passwords are cryptographically secure and meet security best practices. #### Delete User Clicking **Delete** removes the selected user account from SignStation. A confirmation prompt will appear before the deletion is executed. > **Warning** > > User deletion is permanent and cannot be undone. Ensure you no longer need this account before proceeding. --- URL: https://knowledge.leegality.com/sign-station/user-management/department-management # Department Management Department management allows administrators to create the organizational units used to scope user access and categorize documents. To Access this section, 1. Navigate to **Settings** menu. 2. Select **User Management** 3. Select the **Departments** tab. Departments help organize users and control access to resources within SignStation. ## Adding a New Department 1. Click the **+Add Department** button. A creation window will appear. 2. **Enter Department Name**: Provide a unique name for the new department (e.g., Finance, Legal). 3. Click **Add Department** to save the new department and add it to the list. - To exit without saving, click **Cancel** > **Caution — Error Handling** > > If the provided department name is already in use, the system displays an error message: **"Department with name '[Name]' already exist."** ## Managing Existing Departments The main view lists all configured departments in a table format. | Field | Description | |-------|-------------| | **Department** | The name of the organizational unit. | | **Users** | The total number of users currently assigned to this department. | | **Created** | The date and time the department was created in the system. | ### Department Actions (More Options Menu) Click the **three-dot menu** (⋮) next to a department's entry to access management options: #### Edit Department 1. Click **Edit Department**. A pop-up window will appear. 2. Modify the department's name as required. 3. Click **Update Department** to save the change, or click **Cancel** to revert and exit. #### Delete Department 1. Click **Delete Department**. A confirmation pop-up will appear. 2. Click **Delete** to permanently remove the department from the system. 3. Click **Cancel** to abort the deletion and return to the list. > **Danger — Warning** > > Deleting a department is permanent and cannot be undone. Ensure no critical users or documents are associated with this department before proceeding. --- URL: https://knowledge.leegality.com/sign-station/user-management/role-management # Role Management Role management defines permission sets (Entitlements) that dictate the specific actions users can perform within SignStation. To access this section, 1. Navigate to the **Settings** menu 2. Select **User Management** 3. Go to the **Roles** tab. Roles allow you to create customized permission sets that can be assigned to users based on their responsibilities. ## Adding a New Role To define a new custom role: 1. Click the **+Add Role** button. A creation window will appear. 2. **Enter Role Name**: Provide a descriptive name for the role (e.g., Document Uploader, Admin, Certificate Manager). 3. **Configure Entitlements**: Entitlements define the specific permissions granted to the role. - Review the dropdown list of available entitlements (actions) - Check the box next to any entitlement you wish to assign to this role - To assign all permissions, click **Assign All** - To clear all current selections, click **Unassign All** 4. Click **Add Role** to save the new role and make it available for assignment to users. > **Tip** > > Design roles based on job functions to simplify user management. For example, create separate roles for administrators, document signers, and certificate managers. ## Managing Existing Roles The Roles table displays all configured roles in your system with the following information: | Column | Description | |--------|-------------| | **ID** | Unique identifier for the role | | **Role** | Name of the role | | **Created** | Date and time when the role was created | ### Edit Role To modify an existing role: 1. Click the **three-dot menu** (⋮) next to the role you want to edit 2. Select **Edit Role** from the menu. An "Edit Role" pop-up window will appear. 3. In the Edit Role window, you can: - **Change Role Name**: Modify the name of the role - **Update Entitlements**: Add or remove permissions by checking or unchecking entitlements 4. Click **Update Role** to save your modifications - Click **Cancel** to discard changes and exit > **Info** > > Changes to role entitlements will immediately affect all users assigned to that role. --- URL: https://knowledge.leegality.com/sign-station/certificate-management/adding-certificates # Adding a Digital Certificate You can easily upload and link new digital certificates to your departments through the Certificates tab. This process makes the certificate available for use when signing documents associated with the chosen department. 1. Navigate to the **Certificates** tab and click the **+Add Certificate** button. A new pop-up window will appear. 2. Select the relevant **Department** from the dropdown list. This selection determines which documents can be signed using this specific certificate. > **Important** > > The department selection is necessary as it controls certificate access and usage permissions. 3. In the provided column, enter the certificate **Passkey**. Passkey is the password set when PKCS12 certificate was created. It decrypts the private key in the certificate file. This credential is required to protect and securely utilize the certificate during the signing process. 4. Next, you need to upload your **PFX certificate file**. **Requirements:** - File type: Only PKCS12 format (.p12 or .pfx files) - Max file size: 5MB > **Caution** > > Be sure you are uploading the correct file type (.pfx). Ensure your file meets the size requirements before uploading. 5. Click **Add Certificate** to securely upload the file and link the new certificate to the department you selected. Once the certificate is successfully added: - The certificate will be linked to the selected department - Users in that department can use this certificate for signing documents - The certificate will appear in the certificate dropdown during the signing process. > **Info — NOTE** > > You cannot set or change the certificate expiry date. The expiry date is built into the PFX file itself and will be automatically read from the certificate you upload. --- URL: https://knowledge.leegality.com/sign-station/certificate-management/managing-certificate # Review and Manage Certificates The Certificate Manager provides a comprehensive view and control interface for all linked digital certificates. You can review certificate details, update credentials, and manage certificate lifecycle. ## Access and Interface 1. Access the certificate list by selecting **Review Certificate** from the Dashboard. The main view displays a list of certificates, showing the following critical data points: - **ID**: The unique certificate identifier - **Type**: The certificate standard or classification - **Department**: The assigned organizational unit - **Expiry**: Days remaining until the certificate expires - **Status**: Current operational state (e.g., Active, Expired, Disabled) ## Locating Certificates Users can quickly find specific certificates using the search and filtering capabilities: * **Search**: Use the search bar to find certificates based on their **ID**, **Type**, or **Certificate Name**. * **Filters** 1. **Show disabled only**: Toggles the view to display only certificates currently marked as disabled 2. **Expiring soon**: Filters the list to show only certificates nearing their expiration date 3. **Department Filter**: Allows users to narrow the list to certificates associated with a specific configured department ## Management Actions Click the **More Options menu** (⋮) associated with a certificate to access management actions: ### View Certificate Details Selecting **View** opens a window displaying static certificate details: - Certificate ID - Type - Certificate Name - Created At - Valid To (Expiration date) - Department > **Info — NOTE** > > User can assign one certificate to more than one department. ### Edit Certificate Selecting **Edit** allows credential or file updates: - **Certificate ID**: This value is displayed for reference and cannot be modified. - **Password/Passkey**: Enter the new password required for future certificate use. - **Upload New Certificate File (Optional)**: Upload a new PFX file to replace the existing certificate. > **Info — NOTE** > > If a new certificate file is not uploaded, the existing certificate remains active and is updated with the newly provided password. ### Delete Certificate Selecting **Delete** permanently removes the certificate from the system: 1. A confirmation prompt will appear 2. Select **Delete** to confirm the removal 3. Select **Cancel** to abort the operation and retain the certificate > **Warning** > > Deleting a certificate is permanent and cannot be undone. Ensure you no longer need the certificate before proceeding. --- URL: https://knowledge.leegality.com/sign-station/signing-journey/signing-a-document/uploading-documents # Uploading Documents The first step in the signing journey is to upload the document you want to sign. This guide walks you through the complete document signing workflow. ## Document Signing Workflow Signing a document in SignStation follows a simple 4-step process: ![Signing Workflow](\img\Gemini_Generated_Image_i5q0i3i5q0i3i5q0.png) ### Before You Begin Make sure you have: - Selected a **department** from the header dropdown - At least one **digital certificate** configured for your department - A **PDF document** ready to sign ## Step 1: Upload Your Document 1. Click **Sign new Document** button to open the Sign Document window. > **Info — NOTE** > > Make sure to select a department from the dropdown list in the header before starting the document signing process. 2. Click **Start Document Signing** to proceed. 3. Upload PDF Document - Select and upload your PDF document - Upon successful upload, you will be redirected to the **Configure and Sign** window ## Next Steps After uploading your document, proceed to [Sign the Documents](https://knowledge.leegality.com/sign-station/signing-journey/signing-a-document/sign-the-documents) to configure and apply your digital signature. --- URL: https://knowledge.leegality.com/sign-station/signing-journey/signing-a-document/sign-the-documents # Sign the Documents After uploading your document, you'll configure the signature coordinates and certificate details before applying your digital signature. ## Configure and Sign Window Once your document is uploaded, the Configure and Sign window displays: - **Left side**: Preview of the uploaded document - **Right side panel**: Configuration options ## Configuration Steps ### 1. Place Coordinates Choose your preferred coordinate method for signature placement: - **Default Coordinates**: Places the signature at a predefined location on each page. The signature is automatically positioned at the bottom-left corner of every page in the document. Use this option for quick signing when precise placement isn't required. - **Drop Coordinates**: Allows you to manually place signatures anywhere on the document. Choose specific pages and exact positions for each signature. Use this option when you need precise control over signature placement. **Steps for Drop Coordinates:** 1. Click the coordinate placement button. 2. Navigate to where you want the coordinate to appear on the document. 3. Click to place the coordinate. 4. Repeat this process for each signature placement you need. **Download Coordinates:** - Click **Download coordinates** to export them as a JSON file - This file can be used for API calls to sign similar documents repeatedly - Saves time when signing multiple documents with the same signature placement > **Info — NOTE** > > You can only download coordinates if you choose the **Drop Coordinates** option. ### 2. Certificate & Sign Section Configure the following fields: * **Certificate** (Mandatory): Select a certificate from the dropdown list. The number of available certificates for the selected department will be displayed. * **Display Signer Name** (Optional): Enter the name to be displayed on the signature. * **Signer's Reason** (Optional): Enter the reason for signing the document (e.g., "Agreement approval", "Authorization"). * **Location of Signer** (Optional): Enter the geographical location where the document is being signed. ### 3. Sign the Document Once all required fields are configured, click **Sign Document** to apply your digital signature. ## Next Steps After signing, proceed to [Download Signed Documents](https://knowledge.leegality.com/sign-station/signing-journey/signing-a-document/download-signed-documents) to retrieve your signed document and audit trail. --- URL: https://knowledge.leegality.com/sign-station/signing-journey/signing-a-document/download-signed-documents # Download Signed Documents After successfully signing your document, you can review the signed document, download it along with the audit trail, and choose your next action. ## Signed Document View Once the signing process is complete, the signed document is displayed on the screen. ### Document Preview The signed document is shown in the main viewing area where you can review the applied signatures. ### Document Information Panel The right side panel displays all relevant details about the signed document: - **Uploaded by**: User who uploaded the document - **Signer name**: Name of the person who signed - **Department**: Department associated with the signing - **Date and Time**: When the document was signed - **Location**: Location where the document was signed - **Number of signatures placed**: Count of signatures applied - **Certificate**: Certificate used for signing - **Reason**: Reason provided for signing ### Download Options **Download Signed Document:** Click **Download Document** to save the signed PDF document to your local system. **Download Audit Trail**: Click **Download Audit Trail** to download a comprehensive audit trail of the document signing process. This includes: - Timestamp of each action - User details - Certificate information - Signature placement details > **Info — NOTE** > > The Download Audit Trail feature will not work if audit trail generation is not enabled in System Settings. Please ensure that **Document Audit Trails** is turned on in [System Settings](docs\sign-station\system-settings.md) under the Data & Audit tab. ### Navigation Options At any stage of the document signing, you can click the following navigation options: - **Back**: Click **Back** to return to the previous step (Configure and Sign window). - **Sign Another**: Click **Sign Another** to go directly to the Upload Document page to sign another document. - **Back to Home**: Click **Back to Home** to return to the Dashboard. --- URL: https://knowledge.leegality.com/sign-station/signing-journey/reviewing-documents # Reviewing Documents The Documents module provides a centralized list of all documents managed by the user, offering search, filtering, and status tracking for all signing transactions. ## Document Actions and Filtering Access this section by selecting **Documents** from the sidebar. The top section allows users to locate and filter documents: - **Select date range**: Allows filtering the document list based on the date the documents were uploaded or signed. - **Search documents...**: Provides a search bar to quickly find documents by Document Name. - **Status Filter**: A dropdown menu that filters the list by the document's current status (e.g., All Statuses, Signed, Failed). - **Certificate Filter**: A dropdown menu that filters the list to show only documents signed with a specific digital certificate. ## Document List Table The main table displays the filtered results, showing key details for each document. | Column | Description | |--------|-------------| | **Document Name** | The name of the uploaded PDF file. | | **Uploaded By** | The user who initiated the document upload, along with the date and time of the upload. | | **Status** | The current status of the document signing workflow (e.g., Signed). The date of the last status change is often included here. | | **Certificate** | The digital certificate used to sign the document. | ### Document Actions Each document row includes a **three-dot menu** (⋮) for additional actions: - **Download**: Allows you to download the signed document. - **Audit trail**: Provides access to download the audit trail for the document. --- URL: https://knowledge.leegality.com/sign-station/api-credentials # API Credentials API Credentials are essential for integrating with SignStation's API services. Before calling any API, you need to have a secret key that authenticates your application and ensures secure communication between your system and SignStation. 1. Navigate to **Settings** from the sidebar. 2. Select **API Credentials**. This section allows you to view, create, and manage all your API authentication credentials. ## Viewing API Credentials The API Credentials page displays a table showing all the credentials you have created. The table includes the following information: | Column | Description | |--------|-------------| | **Credential Name** | The unique name you assigned to the credential. | | **Client ID** | The unique identifier used to authenticate API requests. | | **Client Secret** | The secret key associated with the credential (hidden for security reasons). | | **Created At** | The date and time when the credential was created. | | **Status** | Indicates whether the credential is active or inactive. | ## Create Credential To create a new API credential for your application: 1. Click the **+Create Credential** button at the top of the API Credentials page. A pop-up window will appear. 2. **Enter Credential Name**: Provide a meaningful name for your credential. - **Important**: The credential name must be 6-64 characters long. - Only use alphanumeric characters, underscores (_), and hyphens (-). - Do not use spaces or special characters. 3. Click **Create Credential** to generate the secret key. 4. **Save Your Client Secret**: Once created, the client secret key will be displayed **only once**. - **Critical**: Make sure to copy and store it securely for later use. - You will not be able to view this secret again after closing the window. 5. Click **I have saved the credentials securely** to close the window and complete the process. > **Info — NOTE** > > The client secret is shown only once during creation. If you lose it, you will need to delete the credential and create a new one. ## More Options Each credential in the table has a three-dot menu (⋮) that provides additional actions: ### Copy Client ID Click this option to quickly copy the Client ID associated with the credential to your clipboard. This is useful when configuring API integrations. ### Delete Credentials Click this option to permanently delete the corresponding credential. Use this when a credential is no longer needed or has been compromised. > **Warning** > > Deleting a credential cannot be undone. Any applications using this credential will immediately lose API access. --- URL: https://knowledge.leegality.com/sign-station/audit-logs # Audit Logs The Audit Logs page provides a centralized record of all system events and user actions within the SignStation application. To access the section, 1. Navigate to **Settings** page. 2. Select **Audit Logs** from the sidebar. ### 1. Filtering and Date Range - **Date Range**: Users can filter the displayed events by selecting a custom date range using the **Select date range** option. This allows for focused analysis of activity during specific periods. - **Total Results**: The total number of records matching the current filter (or the entire history, if no filter is applied) is displayed (e.g., "Total 125 results"). ### 2. Audit Log Table The log table captures the details of every system action. Each column is sortable: | Column | Description | |--------|-------------| | **Created** | The date and time the event was recorded. | | **Action** | The type of activity that occurred (e.g., DEPARTMENT_ADDED, USER_CREATED, DOCUMENT_SIGNED). | | **User** | The user account responsible for initiating the action. | | **Details** | A summary description of the event, including the entity affected (e.g., "Department Test added successfully"). | | **IP Address** | The IP address from which the action was initiated. | > **Info** > > All columns in the audit log table are sortable, allowing you to organize events by date, action type, user, or IP address. ### 3. Export Logs The **Export Logs** button (located in the top right of the log table) allows administrators to download the displayed log data. **How it works:** - Clicking this button initiates a download of the log entries that currently match the applied **Date Range** filter - Logs are typically exported as a standard file format (e.g., CSV or JSON) for external analysis or long-term archiving > **Tip** > > Export logs regularly for compliance requirements and to maintain historical records beyond the system's retention period. ### View Details Each log entry includes a **three-dot menu** (⋮). **Steps to view event details:** 1. Click the three-dot menu next to a log entry 2. For specific actions, select the **View Details** option 3. A supplementary window opens, providing granular information about the specific event (e.g., the exact payload or parameters used when a user was created) > **Info — NOTE** > > Not all log entries may have detailed information available. The View Details option appears only for actions that contain additional granular data. --- URL: https://knowledge.leegality.com/sign-station/notifications # Notification Settings The Notification Settings module configures the global email notification system, including the email service provider details, the specific events that trigger notifications, and reminders for certificate expiration. Access this section by selecting **Notifications** from the sidebar. The settings are organized into three tabs: **Email Configuration**, **Notification Rules**, and **Certificate Reminders**. The email address configured here will be displayed as the sender on all outgoing notifications. ## 1. Email Configuration (SMTP Configuration) This tab is used to configure the external SMTP server details required for SignStation to send emails. | Field | Description | |-------|-------------| | **SMTP Host** | The hostname or IP address of the SMTP server (e.g., smtp.gmail.com). | | **SMTP Port** | The port number used to connect to the SMTP server (e.g., 587). | | **SMTP Username** | The username credential for authenticating with the SMTP server. | | **SMTP Password** | The password credential for authenticating with the SMTP server. | | **From Email** | The email address displayed as the sender on all outgoing notifications. | | **From Name** | The name displayed as the sender on all outgoing notifications (e.g., "Himanshu Kumar"). | | **Reply To** | The email address that receives replies to system notifications. | ### Security and Activation - **Use TLS encryption**: Toggle this option to encrypt the communication channel between SignStation and the SMTP server. - **Enable email notifications**: Toggle this option on to globally activate all email notifications configured in the other tabs. ### Actions - **Test Email**: Click to send a test email to verify the SMTP settings are correct. - **Save Configuration**: Click to save the entered SMTP server details. > **Tip** > > Always use the Test Email function after configuring SMTP settings to ensure emails are being sent correctly before enabling notifications system-wide. ## 2. Notification Rules This tab controls which specific system events trigger an email notification. Each rule can be toggled on or off globally. > **Warning — Important Setup Requirement** > > Before signing documents, ensure you have completed the following steps: > 1. **Configure Email Settings**: First, set up your SMTP configuration in the Email Configuration tab > 2. **Enable Notification Rules**: Then, enable the appropriate notification rules in this tab > > For document signing notifications, make sure to enable the **Document Signed** notification rule (notification type: DOCUMENT_SIGNED). Without this configuration, documents will still be signed successfully, but no email notifications will be sent to users. Following are the notification rules you can configure: | Notification Rule | Description | |-------------------|-------------| | **User Created** | Toggles notifications when a new user account is successfully provisioned. | | **User Deleted** | Toggles notifications when a user account is removed from the system. | | **Document Signed** | Toggles notifications upon the successful completion of a document signing workflow. | | **License Expiry Reminders** | Toggles notifications related to upcoming license expiration dates. | | **License Expired** | Toggles notifications when a license has officially expired. | | **Certificate Expired** | Toggles notifications when a configured certificate has officially expired. | > **Info** > > Enable only the notifications that are relevant to your organization to avoid email overload for administrators and users. ## 3. Certificate Reminders This tab configures the timing and recipients for notifications regarding upcoming certificate expiration. ### Certificate Expiry Reminders This section defines the lead time for reminders: - **Reminder Days**: Enter the number of days before expiration that the reminder email should be sent (e.g., entering "30" sends a reminder 30 days before expiration). - Click **+ Add Reminder** to save the configured reminder period. ### Reminder Recipients This section defines who receives the expiration notifications: **Notify Roles:** - Select the system roles (e.g., Admin, Certificate Manager) whose members should receive the certificate expiration reminders. **Additional Email Recipients:** - Enter specific email addresses in the input field and click the **+** button to add individual recipients who are not defined by a role. **Action:** Click **Save Reminder Settings** to apply all configuration changes made on this tab. > **Caution — Important** > > Ensure certificate expiry reminders are set with sufficient lead time to allow for certificate renewal and avoid service disruption. --- URL: https://knowledge.leegality.com/sign-station/system-settings # System Settings The System Settings module allows administrators to configure policies governing user security, data retention, and audit trail generation for the SignStation application. To Access this section, 1. Navigate to the sidebar and select **System Settings**. 2. The settings are organized into two primary tabs: **Security** and **Data & Audit**. ## Security The Security tab controls authentication and user credential requirements. ### A. Password Policy This section defines the structural requirements for all user passwords within the system. 1. **Minimum Password Length:** - Enter the minimum number of characters required for a user's password - This value must be 6 or more (Cannot be less than 6) 2. Specify **Password Requirements:** Toggle these options to enforce complexity rules: - **Require numbers**: Enforces the inclusion of at least one numeral (0-9) - **Require special characters**: Enforces the inclusion of at least one special symbol (e.g., !, @, #) - **Require uppercase letters**: Enforces the inclusion of at least one uppercase letter (A-Z) 3. Click **Save Password Policy** to apply changes system-wide. > **Tip** > > Implement strong password policies to enhance account security. Consider requiring a combination of numbers, special characters, and uppercase letters. ## Data & Audit The Data & Audit tab configures policies related to data lifecycle management and mandatory logging. ### A. Data Retention Policies These policies define automatic cleanup rules for system data after a specified period. The retention period is set in days. #### Signed Documents & Audit Trails - Turn this option on to activate retention rules for completed signed documents and their associated audit trails. - **Retention Period (days)**: Enter the number of days the documents and trails must be kept before automatic deletion. > **Caution** > > Setting a retention period will automatically delete documents and audit trails after the specified number of days. Ensure this complies with your organization's legal and compliance requirements. #### System Audit Logs - Turn this option on to activate retention rules for the general System Audit Logs. - **Retention Period (days)**: Enter the number of days the system logs must be retained. ### B. Audit Trail Configuration This section governs the mandatory generation of audit data for core operations. **Document Audit Trails:** Toggle this option on to ensure that a comprehensive audit trail is automatically generated and attached to every document signing operation performed in SignStation. > **Info — NOTE** > > Enabling document audit trails ensures full traceability of all signing operations, which is essential for regulatory compliance and dispute resolution. Click **Save Data & Audit Settings** to apply all changes made within this tab. --- # Leegality SignStation API URL: https://knowledge.leegality.com/sign-station/api/leegality-signstation-api > Welcome to the Leegality Sign Service (SignStation) API documentation. SignStation is Leegality's on-premise digital signing platform. This API lets you integrate every part of it — from signing documents with your own PKCS12 certificates to managing users, roles, audit logs, and notifications — directly into your applications and back-office systems. Welcome to the Leegality Sign Service (SignStation) API documentation. SignStation is Leegality's on-premise digital signing platform. This API lets you integrate every part of it — from signing documents with your own PKCS12 certificates to managing users, roles, audit logs, and notifications — directly into your applications and back-office systems. ## What can you do with this API? - **Sign documents** — Apply legally valid digital signatures, retrieve signed copies, and download audit trails for compliance. - **Manage certificates** — Upload, assign, and track expiry of PKCS12 (`.pfx` / `.p12`) certificates used for signing. - **Control access** — Create users and departments, define roles with granular entitlements (RBAC), and enforce password policies. - **Authenticate** — Use JWT Bearer tokens via user login, or OAuth2 client credentials for machine-to-machine integrations. - **Configure notifications** — Set up email rules for events such as certificate expiry, document completion, and more. - **Audit & comply** — Search detailed audit logs of every system action; configure retention and audit trail generation. - **Manage your license** — Install license files, view current status, and track usage statistics. ## Base URL SignStation is deployed on your own infrastructure, so the base URL is unique to your organisation. The reference instance used throughout this documentation is: `https://sign-station.theleegality.com` Replace it with your own SignStation host when making API calls. If you are unsure of your base URL, contact your SignStation administrator. ## Getting started 1. **Generate a token** — Call `/api/v1/auth/login` with your username and password to receive a JWT Bearer token. For machine-to-machine flows, use `/api/v1/auth/token` with OAuth2 client credentials. 2. **Authorise your requests** — Click **Authorize** on this page (or include the header `Authorization: Bearer ` in your client) to try out endpoints directly from the documentation. 3. **Explore by feature** — Each section in the left sidebar maps to one functional area of SignStation (Documents, Certificates, Users, Roles, and so on). Every endpoint includes request and response examples. For the dashboard equivalent of these flows, see [Logging In](https://knowledge.leegality.com/sign-station/getting-started/logging-in) and [API Credentials](https://knowledge.leegality.com/sign-station/api-credentials). ## Need help? Reach out to [support@leegality.com](mailto:support@leegality.com) for any questions about your integration or deployment. JWT Bearer token authentication. Use the login endpoint (/api/v1/auth/login) to get a token, then click 'Authorize' and enter: Bearer <your-jwt-token>
Security Scheme Type: http
HTTP Authorization Scheme: bearer
Bearer format: JWT
--- # AuditLog Controller URL: https://knowledge.leegality.com/sign-station/api/audit-log-controller.tag > AuditLog Controller The Audit Log API provides endpoints for searching and retrieving audit log entries within the SignStation platform. Audit logs capture a detailed record of system activities, user actions, and significant events for security, compliance, and troubleshooting purposes. All audit log operations are scoped to the authenticated user's organization. Use this API to search audit logs based on various criteria such as date range, user, action type, and more. For the dashboard view and filters, see [Audit Logs](https://knowledge.leegality.com/sign-station/audit-logs). ```mdx-code-block ``` --- # Auth Controller URL: https://knowledge.leegality.com/sign-station/api/auth-controller.tag > Auth Controller The Authentication API provides endpoints for user authentication, token generation, and user session management within the Sign Station platform. This API handles both user login (username/password) and OAuth2 client authentication flows. The `/auth/login` and `/auth/token` endpoints do not require authentication (they generate tokens). The `/auth/me` endpoint requires a valid JWT Bearer token obtained from login or token endpoint. **Token Generation:** Use `/auth/login` for user tokens or `/auth/token` for OAuth2 client tokens. For dashboard sign-in, see [Logging In](https://knowledge.leegality.com/sign-station/getting-started/logging-in); to generate OAuth2 client credentials from the dashboard, see [API Credentials](https://knowledge.leegality.com/sign-station/api-credentials). ```mdx-code-block ``` --- # Certificate Management URL: https://knowledge.leegality.com/sign-station/api/certificate-management.tag > Certificate Management The Certificate Management API allows you to upload, store, and assign the PKCS12-formatted certificates ($.pfx$ or $.p12$) required for legally valid digital signatures. These cryptographic credentials act as a digital seal, ensuring document integrity and proving the identity of the signer to comply with global standards like ISO or eIDAS. By using these endpoints to track expiry and manage department-level assignments, you ensure that your platform maintains the necessary credentials to perform secure, non-repudiable signing operations. See also [Adding a Digital Certificate](https://knowledge.leegality.com/sign-station/certificate-management/adding-certificates) and [Managing Certificates](https://knowledge.leegality.com/sign-station/certificate-management/managing-certificate) for the dashboard workflow. ```mdx-code-block ``` --- # Certificate Notification Configuration Controller URL: https://knowledge.leegality.com/sign-station/api/certificate-notification-configuration-controller.tag > Certificate Notification Configuration Controller The Certificate Notification Configuration API provides endpoints for managing certificate expiry notification settings within the Sign Station platform. This configuration allows organizations to define how and when notifications are sent regarding upcoming certificate expirations, ensuring timely renewals and minimizing disruptions to document signing processes. See also [Notifications](https://knowledge.leegality.com/sign-station/notifications) and [Managing Certificates](https://knowledge.leegality.com/sign-station/certificate-management/managing-certificate). ```mdx-code-block ``` --- URL: https://knowledge.leegality.com/sign-station/api/change-password # PUT /api/v1/users/change-password — Change user password Changes the password for the currently authenticated user. The new password must comply with the organization's password policy. **Authentication:** `X-Auth-Token` header required on every request. ## Request URL ``` PUT https://app1.leegality.com/api/api/v1/users/change-password ``` **Environments:** - Production: `https://app1.leegality.com/api/api/v1/users/change-password` - Sandbox: `https://sandbox.leegality.com/api/api/v1/users/change-password` --- ## Request Body **Content-Type:** `application/json` | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `currentPassword` | string | Yes | The current password of the user | `TestPassword@123` | | `newPassword` | string | Yes | The new password to set for the user | `NewPassword@123` | | `confirmPassword` | string | Yes | Confirmation of the new password | `NewPassword@123` | ### Sample Request ```json { "currentPassword": "TestPassword@123", "newPassword": "NewPassword@123", "confirmPassword": "NewPassword@123" } ``` --- ## Responses ### 200 — Password changed successfully | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `code` | string | No | Response code indicating success or failure | `LE_SS_002` | | `message` | string | No | Response message providing additional information | `Requested record has been deleted.` | | `data` | object | No | Additional data related to the response, if any. | — | ### 400 — Invalid request data or passwords don't match | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `code` | string | No | Top-level error code | `LE_ERR_SS_400` | | `errors` | array\ | No | List of error details See **ErrorDetailChangePassword400VO** below. | — | #### ErrorDetailChangePassword400VO | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `message` | string | No | Detailed error message | `New password and confirm password do not match` | | `path` | string | No | API path that generated the error | `/api/v1/users/change-password` | ### 401 — Current password is incorrect | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `code` | string | No | Top-level error code | `LE_ERR_SS_401` | | `errors` | array\ | No | List of error details See **ErrorDetailChangePassword401VO** below. | — | #### ErrorDetailChangePassword401VO Password change request | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `message` | string | No | Detailed error message | `Authentication failed. Invalid username or password.` | | `path` | string | No | API path that generated the error | `/api/v1/users/change-password` | | `code` | string | No | Specific error code | `LE_ERR_SS_301` | ### 500 — Internal server error | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `code` | string | No | Top-level error code | `LE_ERR_SS_500` | | `errors` | array\ | No | List of error details See **ErrorDetailToken500VO** below. | — | #### ErrorDetailToken500VO | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `message` | string | No | Detailed error message | `Internal Server Error` | | `path` | string | No | API path that generated the error | `null` | | `code` | string | No | Specific error code | `null` | ### Sample Response (200) ```json { "code": "LE_SS_002", "message": "Requested record has been deleted.", "data": {} } ``` --- URL: https://knowledge.leegality.com/sign-station/api/create-1 # POST /api/v1/certificates — Create new certificate Creates new certificate for the current user's organization. Certificate file should be uploaded as multipart/form-data. Supported format: .p12/.pfx (PKCS12) only (max size: 5MB) **Authentication:** `X-Auth-Token` header required on every request. ## Request URL ``` POST https://app1.leegality.com/api/api/v1/certificates ``` **Environments:** - Production: `https://app1.leegality.com/api/api/v1/certificates` - Sandbox: `https://sandbox.leegality.com/api/api/v1/certificates` --- ## Request Body **Content-Type:** `application/json` Certificate data including name, passkey, type, expiry, departmentId, enabled flag, and certificate file | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `passkey` | string | No | Passkey for the certificate file | `mySecretPasskey` | | `certificateFile` | string | No | Certificate file to be uploaded | `TestCertificate.leegality.com` | | `departmentId` | string | No | Associated department ID | — | | `enabled` | boolean | No | Indicates whether the certificate is enabled or disabled | — | ### Sample Request ```json { "passkey": "mySecretPasskey", "certificateFile": "TestCertificate.leegality.com", "departmentId": "string", "enabled": false } ``` --- ## Responses ### 201 — Certificate created successfully | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `data` | CertificateVO | No | See **CertificateVO** below. | — | #### CertificateVO | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `id` | string | No | Certificate unique identifier | `46d4e120-ed03-47cc-98c6-529bff3bbabc` | | `name` | string | No | Certificate name | `TestCertificate.leegality.com` | | `certificateType` | string | No | Type of the certificate Allowed: `PKCS12_PFX`, `PKCS12_HSM`, `PKCS11`. | — | | `expiry` | string | No | Certificate expiry date | — | | `createdAt` | string | No | The date and time when the certificate was created | — | | `departmentId` | string | No | Associated department ID | `18b45e41-5d8b-4417-bb83-1d769187aef9` | | `departmentName` | string | No | Associated department name | `HR` | ### 400 — Invalid request data or unsupported file format | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `code` | string | No | Top-level error code | `LE_ERR_SS_404` | | `errors` | array\ | No | List of error details See **ErrorDetailVO** below. | — | #### ErrorDetailVO | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `message` | string | No | Detailed error message | `Certificate with id 46d4e120-ed03-47cc-98c6-529bff3bbaba doe` | | `path` | string | No | API path that generated the error | `/api/v1/certificates/46d4e120-ed03-47cc-98c6-529bff3bbaba` | | `code` | string | No | Specific error code | `LE_ERR_SS_001` | ### 401 — Unauthorized - Invalid or expired token | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `code` | string | No | Top-level error code | `LE_ERR_SS_401` | | `errors` | array\ | No | List of error details See **ErrorDetail401Unauthorized** below. | — | #### ErrorDetail401Unauthorized | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `message` | string | No | Detailed error message | `Invalid or expired token` | | `path` | string | No | API path that generated the error | `/api/v1/*` | | `code` | string | No | Specific error code | `LE_ERR_SS_303` | ### 409 — Certificate already exists | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `code` | string | No | Top-level error code | `LE_ERR_SS_409` | | `errors` | array\ | No | List of error details See **ErrorDetailCreateCertificate409VO** below. | — | #### ErrorDetailCreateCertificate409VO | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `message` | string | No | Detailed error message | `Certificate with alias 'MyCertificate' already exists for or` | | `path` | string | No | API path that generated the error | `/api/v1/certificates` | | `code` | string | No | Specific error code | `LE_ERR_SS_1101` | ### 500 — Internal server error | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `code` | string | No | Top-level error code | `LE_ERR_SS_500` | | `errors` | array\ | No | List of error details See **ErrorDetailToken500VO** below. | — | #### ErrorDetailToken500VO | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `message` | string | No | Detailed error message | `Internal Server Error` | | `path` | string | No | API path that generated the error | `null` | | `code` | string | No | Specific error code | `null` | ### Sample Response (201) ```json { "data": { "id": "46d4e120-ed03-47cc-98c6-529bff3bbabc", "name": "TestCertificate.leegality.com", "certificateType": "PKCS12_PFX", "expiry": "string", "createdAt": "string", "departmentId": "18b45e41-5d8b-4417-bb83-1d769187aef9", "departmentName": "HR" } } ``` --- URL: https://knowledge.leegality.com/sign-station/api/create-config-1 # POST /api/v1/certificate-notification-config — Create new certificate notification configuration Creates new certificate notification configuration for the current user's organization **Authentication:** `X-Auth-Token` header required on every request. ## Request URL ``` POST https://app1.leegality.com/api/api/v1/certificate-notification-config ``` **Environments:** - Production: `https://app1.leegality.com/api/api/v1/certificate-notification-config` - Sandbox: `https://sandbox.leegality.com/api/api/v1/certificate-notification-config` --- ## Request Body **Content-Type:** `application/json` Certificate notification configuration data to create | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `reminderDays` | array\ | No | Days before expiry to send reminders | `2` | | `additionalEmailRecipients` | array\ | No | Additional email recipients for notifications | `anagha.babu@leegality.com` | | `notifyRoleIds` | array\ | No | Role IDs to be notified | `17d7949d-6fa9-4077-a76e-da349efe421b` | | `enabled` | boolean | No | Indicates whether the certificate notification is enabled | `true` | ### Sample Request ```json { "reminderDays": [ 2 ], "additionalEmailRecipients": [ "anagha.babu@leegality.com" ], "notifyRoleIds": [ "17d7949d-6fa9-4077-a76e-da349efe421b" ], "enabled": true } ``` --- ## Responses ### 201 — Certificate notification configuration created successfully | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `code` | string | No | Response status code | `LE_SS_001` | | `message` | string | No | Response message | `Your changes have been successfully saved.` | | `data` | CertificateNotificationConfigVO | No | See **CertificateNotificationConfigVO** below. | — | #### CertificateNotificationConfigVO | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `id` | string | No | Certificate notification configuration unique identifier | `6d8ff341-fe21-431e-9453-bb94959474b6` | | `reminderDays` | array\ | No | Days before expiry to send reminders | `2` | | `additionalEmailRecipients` | array\ | No | Additional email recipients for notifications | `anagha.babu@leegality.com` | | `enabled` | boolean | No | Indicates whether the certificate notification is enabled | `true` | | `createdAt` | string | No | The date and time when the certificate notification configuration was created | `2025-12-29T12:00:29.726603` | | `notifyRoles` | array\ | No | See **NotificationRoleVO** below. | — | ##### NotificationRoleVO | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `id` | string | No | Role ID. This is configured during the role creation. | `17d7949d-6fa9-4077-a76e-da349efe421b` | | `name` | string | No | Role name. E.g., "Admin", "User" etc. | `Test Role 12344` | | `createdAt` | string | No | The date and time when the role was created | `2025-11-13T14:05:34` | ### 400 — Invalid request data | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `code` | string | No | Top-level error code | `LE_ERR_SS_400` | | `errors` | array\ | No | List of error details See **ErrorDetailCreateCertificateNotificationConfig400VO** below. | — | #### ErrorDetailCreateCertificateNotificationConfig400VO | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `message` | string | No | Detailed error message | `Invalid value for field [additionalEmailRecipients], Invalid` | | `path` | string | No | API path that generated the error | `/api/v1/certificate-notification-config` | ### 401 — Unauthorized - Invalid or expired token | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `code` | string | No | Top-level error code | `LE_ERR_SS_401` | | `errors` | array\ | No | List of error details See **ErrorDetail401Unauthorized** below. | — | #### ErrorDetail401Unauthorized | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `message` | string | No | Detailed error message | `Invalid or expired token` | | `path` | string | No | API path that generated the error | `/api/v1/*` | | `code` | string | No | Specific error code | `LE_ERR_SS_303` | ### 404 — Role does not exist | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `code` | string | No | Top-level error code | `LE_ERR_SS_404` | | `errors` | array\ | No | List of error details See **ErrorDetailCreateCertificateNotificationConfig404VO** below. | — | #### ErrorDetailCreateCertificateNotificationConfig404VO | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `message` | string | No | Detailed error message | `Role does not exist.` | | `path` | string | No | API path that generated the error | `/api/v1/certificate-notification-config` | | `code` | string | No | Specific error code | `LE_ERR_SS_001` | ### 409 — Configuration already exists for organization | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `code` | string | No | Top-level error code | `LE_ERR_SS_409` | | `errors` | array\ | No | List of error details See **ErrorDetailCreateCertificateNotificationConfig409VO** below. | — | #### ErrorDetailCreateCertificateNotificationConfig409VO | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `message` | string | No | Detailed error message | `Certificate notification configuration already exists for or` | | `path` | string | No | API path that generated the error | `/api/v1/certificate-notification-config` | | `code` | string | No | Specific error code | `LE_ERR_SS_1202` | ### 500 — Internal server error | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `code` | string | No | Top-level error code | `LE_ERR_SS_500` | | `errors` | array\ | No | List of error details See **ErrorDetailToken500VO** below. | — | #### ErrorDetailToken500VO | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `message` | string | No | Detailed error message | `Internal Server Error` | | `path` | string | No | API path that generated the error | `null` | | `code` | string | No | Specific error code | `null` | ### Sample Response (201) ```json { "code": "LE_SS_001", "message": "Your changes have been successfully saved.", "data": { "id": "6d8ff341-fe21-431e-9453-bb94959474b6", "reminderDays": [ 2 ], "additionalEmailRecipients": [ "anagha.babu@leegality.com" ], "enabled": true, "createdAt": "2025-12-29T12:00:29.726603", "notifyRoles": [ { "id": "17d7949d-6fa9-4077-a76e-da349efe421b", "name": "Test Role 12344", "createdAt": "2025-11-13T14:05:34" } ] } } ``` --- URL: https://knowledge.leegality.com/sign-station/api/create-config # POST /api/v1/notification-config — Create new notification configuration Creates new notification configuration for the current user's organization **Authentication:** `X-Auth-Token` header required on every request. ## Request URL ``` POST https://app1.leegality.com/api/api/v1/notification-config ``` **Environments:** - Production: `https://app1.leegality.com/api/api/v1/notification-config` - Sandbox: `https://sandbox.leegality.com/api/api/v1/notification-config` --- ## Request Body **Content-Type:** `application/json` Notification configuration data to create | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `emailServerHost` | string | Yes | Email server host address | `smtp.example.com` | | `emailServerPort` | string | No | Email server port | `587` | | `username` | string | No | Username for email server authentication | `anagha.babu@leegality.com` | | `password` | string | No | Password for email server authentication | `NewPassword@123` | | `fromEmail` | string | No | Email address used in the 'From' field of outgoing emails | `testuser@leegality.com` | | `fromName` | string | No | Name used in the 'From' field of outgoing emails | `Leegality Test User` | | `replyTo` | string | No | Email address used in the 'Reply-To' field of outgoing emails | `testuser@leegality.com` | | `tlsEnabled` | boolean | No | Indicates whether TLS is enabled for email communication | `true` | | `enabled` | boolean | No | Indicates whether the notification configuration is enabled | — | ### Sample Request ```json { "emailServerHost": "smtp.example.com", "emailServerPort": "587", "username": "anagha.babu@leegality.com", "password": "NewPassword@123", "fromEmail": "testuser@leegality.com", "fromName": "Leegality Test User", "replyTo": "testuser@leegality.com", "tlsEnabled": true, "enabled": false } ``` --- ## Responses ### 201 — Notification configuration created successfully | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `code` | string | No | Response code indicating success or failure | `LE_SCS_SS_200` | | `message` | string | No | Response message providing additional information | `Notification configuration created successfully` | | `data` | NotificationConfigVO | No | See **NotificationConfigVO** below. | — | #### NotificationConfigVO | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `id` | string | No | Notification configuration unique identifier | `5e191ba4-3fe5-4dd4-ba7c-f2e9632c08c2` | | `emailServerHost` | string | No | Email server host address | `smtp.gmail.com` | | `emailServerPort` | string | No | Email server port | `587` | | `username` | string | No | Username for email server authentication | `himanshu.kumar@leegality.com` | | `password` | string | No | Password for email server authentication | `NewPassword@123` | | `fromEmail` | string | No | Email address used in the 'From' field of outgoing emails | `himanshu.kumar@leegality.com` | | `fromName` | string | No | Name used in the 'From' field of outgoing emails | `Himanshu Kumar` | | `replyTo` | string | No | Email address used in the 'Reply-To' field of outgoing emails | `himanshu.kumar@leegality.com` | | `tlsEnabled` | boolean | No | Indicates whether TLS is enabled for email communication | `true` | | `createdAt` | string | No | The date and time when the notification configuration was created | `2025-10-10T15:42:45` | | `enabled` | boolean | No | Indicates whether the notification configuration is enabled | `false` | ### 400 — Invalid request data | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `code` | string | No | Top-level error code | `LE_ERR_SS_400` | | `errors` | array\ | No | List of error details See **ErrorDetailCreateNotificationConfig400VO** below. | — | #### ErrorDetailCreateNotificationConfig400VO | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `message` | string | No | Detailed error message | `Invalid value for field [fromEmail], From email must be a va` | | `path` | string | No | API path that generated the error | `/api/v1/notification-config` | ### 401 — Unauthorized - Invalid or expired token | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `code` | string | No | Top-level error code | `LE_ERR_SS_401` | | `errors` | array\ | No | List of error details See **ErrorDetail401Unauthorized** below. | — | #### ErrorDetail401Unauthorized | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `message` | string | No | Detailed error message | `Invalid or expired token` | | `path` | string | No | API path that generated the error | `/api/v1/*` | | `code` | string | No | Specific error code | `LE_ERR_SS_303` | ### 409 — Configuration already exists for organization | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `code` | string | No | Top-level error code | `LE_ERR_SS_409` | | `errors` | array\ | No | List of error details See **ErrorDetailCreateNotificationConfig409VO** below. | — | #### ErrorDetailCreateNotificationConfig409VO | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `message` | string | No | Detailed error message | `Notification configuration for organization 'TestOrganizatio` | | `path` | string | No | API path that generated the error | `/api/v1/notification-config` | | `code` | string | No | Specific error code | `LE_ERR_SS_010` | ### 500 — Internal server error | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `code` | string | No | Top-level error code | `LE_ERR_SS_500` | | `errors` | array\ | No | List of error details See **ErrorDetailToken500VO** below. | — | #### ErrorDetailToken500VO | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `message` | string | No | Detailed error message | `Internal Server Error` | | `path` | string | No | API path that generated the error | `null` | | `code` | string | No | Specific error code | `null` | ### Sample Response (201) ```json { "code": "LE_SCS_SS_200", "message": "Notification configuration created successfully", "data": { "id": "5e191ba4-3fe5-4dd4-ba7c-f2e9632c08c2", "emailServerHost": "smtp.gmail.com", "emailServerPort": "587", "username": "himanshu.kumar@leegality.com", "password": "NewPassword@123", "fromEmail": "himanshu.kumar@leegality.com", "fromName": "Himanshu Kumar", "replyTo": "himanshu.kumar@leegality.com", "tlsEnabled": true, "createdAt": "2025-10-10T15:42:45", "enabled": false } } ``` --- URL: https://knowledge.leegality.com/sign-station/api/create-notification-rule # POST /api/v1/notification-rules — Create new notification rule Creates new notification rule for the current user's organization **Authentication:** `X-Auth-Token` header required on every request. ## Request URL ``` POST https://app1.leegality.com/api/api/v1/notification-rules ``` **Environments:** - Production: `https://app1.leegality.com/api/api/v1/notification-rules` - Sandbox: `https://sandbox.leegality.com/api/api/v1/notification-rules` --- ## Request Body **Content-Type:** `application/json` Notification rule data to create | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `ruleType` | string | Yes | Type of notification rule Allowed: `USER_CREATED`, `USER_DELETED`, `DOCUMENT_SIGNED`, `LICENSE_EXPIRY_REMINDER`, `LICENSE_EXPIRED`, `CERTIFICATE_EXPIRED`. | `USER_CREATED` | | `additionalEmailRecipients` | array\ | No | Additional email recipients for notifications | `anaghaputhur2018@gmail.com` | | `userIds` | array\ | No | User IDs to be notified | `0e663652-1198-4777-8139-3efeda8e1d77` | | `enabled` | boolean | No | Indicates whether the notification rule is enabled | `true` | ### Sample Request ```json { "ruleType": "USER_CREATED", "additionalEmailRecipients": [ "anaghaputhur2018@gmail.com" ], "userIds": [ "0e663652-1198-4777-8139-3efeda8e1d77" ], "enabled": true } ``` --- ## Responses ### 200 — OK | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `data` | NotificationRuleVO | No | See **NotificationRuleVO** below. | — | #### NotificationRuleVO | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `id` | string | No | Notification rule unique identifier | `a2787f6c-e00c-4bd9-ad34-ed88b8fcf54f` | | `ruleType` | string | No | Type of notification rule Allowed: `USER_CREATED`, `USER_DELETED`, `DOCUMENT_SIGNED`, `LICENSE_EXPIRY_REMINDER`, `LICENSE_EXPIRED`, `CERTIFICATE_EXPIRED`. | `USER_CREATED` | | `additionalEmailRecipients` | array\ | No | Additional email recipients for notifications | `anaghaputhur2018@gmail.com` | | `notifyUsers` | array\ | No | See **NotificationRuleUserVO** below. | — | | `enabled` | boolean | No | Indicates whether the notification rule is enabled | `true` | | `createdAt` | string | No | The date and time when the notification rule was created | `2025-10-10T15:47:41` | ##### NotificationRuleUserVO | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `id` | string | No | User unique identifier | `f6b0449d-b866-4647-b5c5-9ce765eb1184` | | `name` | string | No | Full name of the user | `Anagha Babu` | | `email` | string | No | Email address of the user | `anagha.babu@leegality.com` | | `active` | boolean | No | Indicates whether the user is active (enabled) or inactive (disabled) | `true` | | `enabled` | boolean | No | Indicates whether the user is enabled or disabled | `false` | ### 400 — Bad Request | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `code` | string | No | Top-level error code | `LE_ERR_SS_400` | | `errors` | array\ | No | List of error details See **ErrorDetailNotificationRule400VO** below. | — | #### ErrorDetailNotificationRule400VO | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `message` | string | No | Detailed error message | `Invalid request payload.` | | `path` | string | No | API path that generated the error | `/api/v1/notification-rules` | ### 401 — Unauthorized - Invalid or expired token | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `code` | string | No | Top-level error code | `LE_ERR_SS_401` | | `errors` | array\ | No | List of error details See **ErrorDetail401Unauthorized** below. | — | #### ErrorDetail401Unauthorized | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `message` | string | No | Detailed error message | `Invalid or expired token` | | `path` | string | No | API path that generated the error | `/api/v1/*` | | `code` | string | No | Specific error code | `LE_ERR_SS_303` | ### 409 — Conflict | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `code` | string | No | Top-level error code | `LE_ERR_SS_409` | | `errors` | array\ | No | List of error details See **ErrorDetailNotificationRule409VO** below. | — | #### ErrorDetailNotificationRule409VO | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `message` | string | No | Detailed error message | `USER_CREATED rule type already exists.` | | `path` | string | No | API path that generated the error | `/api/v1/notification-rules` | | `code` | string | No | Specific error code | `LE_ERR_SS_010` | ### 500 — Internal server error | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `code` | string | No | Top-level error code | `LE_ERR_SS_500` | | `errors` | array\ | No | List of error details See **ErrorDetailToken500VO** below. | — | #### ErrorDetailToken500VO | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `message` | string | No | Detailed error message | `Internal Server Error` | | `path` | string | No | API path that generated the error | `null` | | `code` | string | No | Specific error code | `null` | ### Sample Response (200) ```json { "data": { "id": "a2787f6c-e00c-4bd9-ad34-ed88b8fcf54f", "ruleType": "USER_CREATED", "additionalEmailRecipients": [ "anaghaputhur2018@gmail.com" ], "notifyUsers": [ { "id": "f6b0449d-b866-4647-b5c5-9ce765eb1184", "name": "Anagha Babu", "email": "anagha.babu@leegality.com", "active": true, "enabled": false } ], "enabled": true, "createdAt": "2025-10-10T15:47:41" } } ``` --- URL: https://knowledge.leegality.com/sign-station/api/create-o-auth-2-client # POST /api/v1/oauth2-clients — Create new OAuth2 client Creates new OAuth2 client for the current user's organization **Authentication:** `X-Auth-Token` header required on every request. ## Request URL ``` POST https://app1.leegality.com/api/api/v1/oauth2-clients ``` **Environments:** - Production: `https://app1.leegality.com/api/api/v1/oauth2-clients` - Sandbox: `https://sandbox.leegality.com/api/api/v1/oauth2-clients` --- ## Request Body **Content-Type:** `application/json` OAuth2 client data to create | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `clientId` | string | Yes | OAuth2 client identifier | `HS1cVm1fLDctBGvAyiu76MIr9PfIqSAl0t2dKHkwWknost8nFh6J5HOiM3SD` | ### Sample Request ```json { "clientId": "HS1cVm1fLDctBGvAyiu76MIr9PfIqSAl0t2dKHkwWknost8nFh6J5HOiM3SDM" } ``` --- ## Responses ### 201 — OAuth2 client created successfully | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `code` | string | No | Response status code | `LE_SS_001` | | `message` | string | No | Response message | `Your changes have been successfully saved.` | | `data` | OAuth2ClientVO | No | See **OAuth2ClientVO** below. | — | #### OAuth2ClientVO | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `id` | string | No | OAuth2 client unique identifier | `8c18cc0b-6251-490e-82ac-dfde6f4735c1` | | `clientId` | string | No | OAuth2 client identifier | `HS1cVm1fLDctBGvAyiu76MIr9PfIqSAl0t2dKHkwWknost8nFh6J5HOiM3SD` | | `clientSecret` | string | No | OAuth2 client secret | `SR2KJGnlodwZWBUNBubPRNYSqCW_TUTD4A8Vhf1t2aM` | | `state` | string | No | OAuth2 client state Allowed: `ACTIVE`, `SUSPENDED`. | `ACTIVE` | | `createdAt` | string | No | The date and time when the OAuth2 client was created | `2025-12-29T15:43:17.528673` | ### 400 — Invalid request data | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `code` | string | No | Top-level error code | `LE_ERR_SS_400` | | `errors` | array\ | No | List of error details See **ErrorDetailOAuth2Client400VO** below. | — | #### ErrorDetailOAuth2Client400VO | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `message` | string | No | Detailed error message | `Invalid value for field [clientId], Client ID must be 6-64 c` | | `path` | string | No | API path that generated the error | `/api/v1/oauth2-clients` | ### 401 — Unauthorized - Invalid or expired token | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `code` | string | No | Top-level error code | `LE_ERR_SS_401` | | `errors` | array\ | No | List of error details See **ErrorDetail401Unauthorized** below. | — | #### ErrorDetail401Unauthorized | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `message` | string | No | Detailed error message | `Invalid or expired token` | | `path` | string | No | API path that generated the error | `/api/v1/*` | | `code` | string | No | Specific error code | `LE_ERR_SS_303` | ### 409 — OAuth2 client already exists | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `code` | string | No | Top-level error code | `LE_ERR_SS_409` | | `errors` | array\ | No | List of error details See **ErrorDetailOAuth2Client409VO** below. | — | #### ErrorDetailOAuth2Client409VO | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `message` | string | No | Detailed error message | `OAuth2 client with ID 'QTw1RK-0lKoycG82K1S_V7O8Fs0YPQIoGJD7'` | | `path` | string | No | API path that generated the error | `/api/v1/oauth2-clients` | | `code` | string | No | Specific error code | `LE_ERR_SS_010` | ### 500 — Internal server error | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `code` | string | No | Top-level error code | `LE_ERR_SS_500` | | `errors` | array\ | No | List of error details See **ErrorDetailToken500VO** below. | — | #### ErrorDetailToken500VO | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `message` | string | No | Detailed error message | `Internal Server Error` | | `path` | string | No | API path that generated the error | `null` | | `code` | string | No | Specific error code | `null` | ### Sample Response (201) ```json { "code": "LE_SS_001", "message": "Your changes have been successfully saved.", "data": { "id": "8c18cc0b-6251-490e-82ac-dfde6f4735c1", "clientId": "HS1cVm1fLDctBGvAyiu76MIr9PfIqSAl0t2dKHkwWknost8nFh6J5HOiM3SDM", "clientSecret": "SR2KJGnlodwZWBUNBubPRNYSqCW_TUTD4A8Vhf1t2aM", "state": "ACTIVE", "createdAt": "2025-12-29T15:43:17.528673" } } ``` --- URL: https://knowledge.leegality.com/sign-station/api/create-password-policy # POST /api/v1/password-policy — Create new password policy This API creates a new password policy for the current user's organization. Each organization can have only one password policy and it is created during the initial setup. Subsequent updates should use the update endpoint. **Authentication:** `X-Auth-Token` header required on every request. ## Request URL ``` POST https://app1.leegality.com/api/api/v1/password-policy ``` **Environments:** - Production: `https://app1.leegality.com/api/api/v1/password-policy` - Sandbox: `https://sandbox.leegality.com/api/api/v1/password-policy` --- ## Request Body **Content-Type:** `application/json` Password policy data to create | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `minimumPasswordLength` | integer | Yes | Minimum length required for passwords | `8` | | `numbersRequired` | boolean | Yes | Indicates if numbers are required in passwords | `true` | | `specialCharactersRequired` | boolean | Yes | Indicates if special characters are required in passwords | `true` | | `uppercaseRequired` | boolean | Yes | Indicates if uppercase letters are required in passwords | `true` | ### Sample Request ```json { "minimumPasswordLength": 8, "numbersRequired": true, "specialCharactersRequired": true, "uppercaseRequired": true } ``` --- ## Responses ### 201 — Password policy created successfully | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `code` | string | No | Response code indicating success or failure | `LE_SS_001` | | `message` | string | No | Response message providing additional information | `Password policy created successfully` | | `data` | PasswordPolicyVO | No | See **PasswordPolicyVO** below. | — | #### PasswordPolicyVO | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `id` | string | No | Password policy unique identifier | `9ef35b27-86c8-4450-8807-317c37a61aae` | | `minimumPasswordLength` | integer | No | Minimum length required for passwords | `6` | | `numbersRequired` | boolean | No | Indicates if numbers are required in passwords | `false` | | `specialCharactersRequired` | boolean | No | Indicates if special characters are required in passwords | `false` | | `uppercaseRequired` | boolean | No | Indicates if uppercase letters are required in passwords | `true` | | `createdAt` | string | No | The date and time when the password policy was created | `2025-10-10T15:58:34` | ### 400 — Invalid request data | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `code` | string | No | Top-level error code | `LE_ERR_SS_400` | | `errors` | array\ | No | List of error details See **ErrorDetailPasswordPolicy400VO** below. | — | #### ErrorDetailPasswordPolicy400VO | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `message` | string | No | Detailed error message | `Invalid value for field [minimumPasswordLength], Minimum pas` | | `path` | string | No | API path that generated the error | `/api/v1/password-policy` | ### 401 — Unauthorized - Invalid or expired token | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `code` | string | No | Top-level error code | `LE_ERR_SS_401` | | `errors` | array\ | No | List of error details See **ErrorDetail401Unauthorized** below. | — | #### ErrorDetail401Unauthorized | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `message` | string | No | Detailed error message | `Invalid or expired token` | | `path` | string | No | API path that generated the error | `/api/v1/*` | | `code` | string | No | Specific error code | `LE_ERR_SS_303` | ### 409 — Password policy already exists for organization | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `code` | string | No | Top-level error code | `LE_ERR_SS_409` | | `errors` | array\ | No | List of error details See **ErrorDetailPasswordPolicy409VO** below. | — | #### ErrorDetailPasswordPolicy409VO | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `message` | string | No | Detailed error message | `Password policy for organization 'TestOrganization' already ` | | `path` | string | No | API path that generated the error | `/api/v1/password-policy` | | `code` | string | No | Specific error code | `LE_ERR_SS_010` | ### 500 — Internal server error | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `code` | string | No | Top-level error code | `LE_ERR_SS_500` | | `errors` | array\ | No | List of error details See **ErrorDetailToken500VO** below. | — | #### ErrorDetailToken500VO | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `message` | string | No | Detailed error message | `Internal Server Error` | | `path` | string | No | API path that generated the error | `null` | | `code` | string | No | Specific error code | `null` | ### Sample Response (201) ```json { "code": "LE_SS_001", "message": "Password policy created successfully", "data": { "id": "9ef35b27-86c8-4450-8807-317c37a61aae", "minimumPasswordLength": 6, "numbersRequired": false, "specialCharactersRequired": false, "uppercaseRequired": true, "createdAt": "2025-10-10T15:58:34" } } ``` --- URL: https://knowledge.leegality.com/sign-station/api/create-role # POST /api/v1/roles — Create new role Creates new role for the current user's organization **Authentication:** `X-Auth-Token` header required on every request. ## Request URL ``` POST https://app1.leegality.com/api/api/v1/roles ``` **Environments:** - Production: `https://app1.leegality.com/api/api/v1/roles` - Sandbox: `https://sandbox.leegality.com/api/api/v1/roles` --- ## Request Body **Content-Type:** `application/json` Role data to create | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `name` | string | Yes | Role name. E.g., "Admin", "User" etc. | — | | `entitlementIds` | array\ | No | Entitlement IDs to assign to the role | — | ### Sample Request ```json { "name": "string", "entitlementIds": [ "string" ] } ``` --- ## Responses ### 200 — Role created successfully | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `code` | string | No | Response code indicating success or failure | — | | `message` | string | No | Response message providing additional information | — | | `data` | RoleVO | No | See **RoleVO** below. | — | #### RoleVO | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `id` | string | No | Role ID. This is configured during the role creation. | `b0af5f43-7f34-4ea4-867a-10115642f354` | | `name` | string | No | Role name. E.g., "Admin", "User" etc. | `Admin` | | `createdAt` | string | No | The date and time when the role was created | `2025-12-15T10:20:30Z` | | `entitlements` | array\ | No | See **EntitlementVO** below. | — | ##### EntitlementVO | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `id` | string | No | Entitlement ID. This is configured in the system and cannot be changed. | `3fa85f64-5717-4562-b3fc-2c963f66afa6` | | `name` | string | No | Entitlement name. E.g., "DOCUMENT_SIGN","USER_MANAGEMENT" | `DOCUMENT_SIGN` | ### 400 — Invalid request data | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `code` | string | No | Top-level error code | `LE_ERR_SS_400` | | `errors` | array\ | No | List of error details See **ErrorDetailCreateRole400VO** below. | — | #### ErrorDetailCreateRole400VO | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `message` | string | No | Detailed error message | `Invalid value for field [name], Role name is required` | | `path` | string | No | API path that generated the error | `/api/v1/roles` | ### 401 — Unauthorized - Invalid or expired token | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `code` | string | No | Top-level error code | `LE_ERR_SS_401` | | `errors` | array\ | No | List of error details See **ErrorDetail401Unauthorized** below. | — | #### ErrorDetail401Unauthorized | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `message` | string | No | Detailed error message | `Invalid or expired token` | | `path` | string | No | API path that generated the error | `/api/v1/*` | | `code` | string | No | Specific error code | `LE_ERR_SS_303` | ### 409 — Role already exists | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `code` | string | No | Top-level error code | `LE_ERR_SS_409` | | `errors` | array\ | No | List of error details See **ErrorDetailCreateRole409VO** below. | — | #### ErrorDetailCreateRole409VO | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `message` | string | No | Detailed error message | `Role with name 'TestRole' already exist.` | | `path` | string | No | API path that generated the error | `/api/v1/roles` | | `code` | string | No | Specific error code | `LE_ERR_SS_010` | ### 500 — Internal server error | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `code` | string | No | Top-level error code | `LE_ERR_SS_500` | | `errors` | array\ | No | List of error details See **ErrorDetailToken500VO** below. | — | #### ErrorDetailToken500VO | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `message` | string | No | Detailed error message | `Internal Server Error` | | `path` | string | No | API path that generated the error | `null` | | `code` | string | No | Specific error code | `null` | ### Sample Response (200) ```json { "code": "string", "message": "string", "data": { "id": "b0af5f43-7f34-4ea4-867a-10115642f354", "name": "Admin", "createdAt": "2025-12-15T10:20:30Z", "entitlements": [ { "id": "3fa85f64-5717-4562-b3fc-2c963f66afa6", "name": "DOCUMENT_SIGN" } ] } } ``` --- URL: https://knowledge.leegality.com/sign-station/api/create-settings # POST /api/v1/settings — Create new settings Creates new settings for the current user's organization **Authentication:** `X-Auth-Token` header required on every request. ## Request URL ``` POST https://app1.leegality.com/api/api/v1/settings ``` **Environments:** - Production: `https://app1.leegality.com/api/api/v1/settings` - Sandbox: `https://sandbox.leegality.com/api/api/v1/settings` --- ## Request Body **Content-Type:** `application/json` Settings data to update | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `documentRetentionEnabled` | boolean | No | Indicates if document retention is enabled | `true` | | `documentRetentionPeriod` | integer | No | Document retention period in days | `100` | | `auditLogsRetentionEnabled` | boolean | No | Indicates if audit logs retention is enabled | `true` | | `auditLogsRetentionPeriod` | integer | No | Audit logs retention period in days | `100` | | `auditTrailGenerationEnabled` | boolean | No | Indicates if audit trail generation is enabled | `true` | ### Sample Request ```json { "documentRetentionEnabled": true, "documentRetentionPeriod": 100, "auditLogsRetentionEnabled": true, "auditLogsRetentionPeriod": 100, "auditTrailGenerationEnabled": true } ``` --- ## Responses ### 201 — Settings created successfully | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `code` | string | No | Response code indicating success or failure | `LE_SS_004` | | `message` | string | No | Response message providing additional information | `Settings updated successfully.` | | `data` | SettingsVO | No | See **SettingsVO** below. | — | #### SettingsVO | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `id` | string | No | Settings ID. This is configured during the settings creation. | `ed99d2dd-f44e-4278-a3e2-13a1ed2be13c` | | `documentRetentionEnabled` | boolean | No | Indicates if document retention is enabled | `true` | | `documentRetentionPeriod` | integer | No | Document retention period in days | `30` | | `auditLogsRetentionEnabled` | boolean | No | Indicates if audit logs retention is enabled | `true` | | `auditLogsRetentionPeriod` | integer | No | Audit logs retention period in days | `90` | | `auditTrailGenerationEnabled` | boolean | No | Indicates if audit trail generation is enabled | `true` | | `createdAt` | string | No | The date and time when the settings were created | `2025-12-08T15:28:26` | ### 401 — Unauthorized - Invalid or expired token | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `code` | string | No | Top-level error code | `LE_ERR_SS_401` | | `errors` | array\ | No | List of error details See **ErrorDetailSettings401VO** below. | — | #### ErrorDetailSettings401VO | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `message` | string | No | Detailed error message | `Invalid or expired token` | | `path` | string | No | API path that generated the error | `/api/v1/settings` | | `code` | string | No | Specific error code | `LE_ERR_SS_303` | ### 409 — Settings already exist for organization | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `code` | string | No | Top-level error code | `LE_ERR_SS_409` | | `errors` | array\ | No | List of error details See **ErrorDetailSettings409VO** below. | — | #### ErrorDetailSettings409VO | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `message` | string | No | Detailed error message | `Settings for organization 'TestOrganization' already exist.` | | `path` | string | No | API path that generated the error | `/api/v1/settings` | | `code` | string | No | Specific error code | `LE_ERR_SS_010` | ### 500 — Internal server error | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `code` | string | No | Top-level error code | `LE_ERR_SS_500` | | `errors` | array\ | No | List of error details See **ErrorDetailToken500VO** below. | — | #### ErrorDetailToken500VO | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `message` | string | No | Detailed error message | `Internal Server Error` | | `path` | string | No | API path that generated the error | `null` | | `code` | string | No | Specific error code | `null` | ### Sample Response (201) ```json { "code": "LE_SS_004", "message": "Settings updated successfully.", "data": { "id": "ed99d2dd-f44e-4278-a3e2-13a1ed2be13c", "documentRetentionEnabled": true, "documentRetentionPeriod": 30, "auditLogsRetentionEnabled": true, "auditLogsRetentionPeriod": 90, "auditTrailGenerationEnabled": true, "createdAt": "2025-12-08T15:28:26" } } ``` --- URL: https://knowledge.leegality.com/sign-station/api/create-user # POST /api/v1/users — Create new user Creates a new user for the current user's organization **Authentication:** `X-Auth-Token` header required on every request. ## Request URL ``` POST https://app1.leegality.com/api/api/v1/users ``` **Environments:** - Production: `https://app1.leegality.com/api/api/v1/users` - Sandbox: `https://sandbox.leegality.com/api/api/v1/users` --- ## Request Body **Content-Type:** `application/json` Updated user data | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `name` | string | Yes | Full name of the user | — | | `email` | string | Yes | Email address of the user | — | | `password` | string | No | Password for the user account | — | | `active` | boolean | No | Indicates whether the user is active (enabled) or inactive (disabled) | — | | `departmentIds` | array\ | No | List of department IDs the user belongs to | — | | `roleIds` | array\ | Yes | List of role IDs assigned to the user | — | ### Sample Request ```json { "name": "string", "email": "string", "password": "string", "active": false, "departmentIds": [ "string" ], "roleIds": [ "string" ] } ``` --- ## Responses ### 200 — OK | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `code` | string | No | Response status code | `LE_SS_001` | | `message` | string | No | Response message | `User retrieved successfully.` | | `data` | UserVO | No | See **UserVO** below. | — | #### UserVO | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `id` | string | No | User unique identifier | `37d14717-5c1a-44fe-9b8f-6d5184b09f06` | | `name` | string | No | Full name of the user | `John Doe` | | `email` | string | No | Email address of the user | `user@example.com` | | `active` | boolean | No | Indicates whether the user is active (enabled) or inactive (disabled) | `true` | | `enabled` | boolean | No | Indicates whether the user is enabled or disabled | `true` | | `createdAt` | string | No | The date and time when the user was created | `2025-12-15T10:20:30Z` | | `departments` | array\ | No | See **DepartmentVO** below. | — | | `roles` | array\ | No | See **RoleVO** below. | — | ##### DepartmentVO | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `id` | string | No | Department unique identifier | `3fa85f64-5717-4562-b3fc-2c963f66afa6` | | `name` | string | No | The department's name (e.g., "Human Resources"). | `Human Resources` | | `enabled` | boolean | No | Indicates whether the department is active or inactive. | `true` | | `createdAt` | string | No | The date and time when the department was created. | `2025-12-15T10:20:30Z` | | `totalUsers` | integer | No | Total number of users in the department. | `25` | ##### RoleVO | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `id` | string | No | Role ID. This is configured during the role creation. | `b0af5f43-7f34-4ea4-867a-10115642f354` | | `name` | string | No | Role name. E.g., "Admin", "User" etc. | `Admin` | | `createdAt` | string | No | The date and time when the role was created | `2025-12-15T10:20:30Z` | | `entitlements` | array\ | No | See **EntitlementVO** below. | — | ###### EntitlementVO | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `id` | string | No | Entitlement ID. This is configured in the system and cannot be changed. | `3fa85f64-5717-4562-b3fc-2c963f66afa6` | | `name` | string | No | Entitlement name. E.g., "DOCUMENT_SIGN","USER_MANAGEMENT" | `DOCUMENT_SIGN` | ### 400 — Invalid request data | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `code` | string | No | Top-level error code | `LE_ERR_SS_400` | | `errors` | array\ | No | List of error details See **ErrorDetailCreateUser400VO** below. | — | #### ErrorDetailCreateUser400VO | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `message` | string | No | Detailed error message | `Invalid value for field [email], Email is required` | | `path` | string | No | API path that generated the error | `/api/v1/users` | ### 401 — Unauthorized - Invalid or expired token | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `code` | string | No | Top-level error code | `LE_ERR_SS_401` | | `errors` | array\ | No | List of error details See **ErrorDetail401Unauthorized** below. | — | #### ErrorDetail401Unauthorized | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `message` | string | No | Detailed error message | `Invalid or expired token` | | `path` | string | No | API path that generated the error | `/api/v1/*` | | `code` | string | No | Specific error code | `LE_ERR_SS_303` | ### 409 — User with the given email already exists | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `code` | string | No | Top-level error code | `LE_ERR_SS_409` | | `errors` | array\ | No | List of error details See **ErrorDetailCreateUser409VO** below. | — | #### ErrorDetailCreateUser409VO | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `message` | string | No | Detailed error message | `User with email 'anagha.babu@leegality.com' already exist.` | | `path` | string | No | API path that generated the error | `/api/v1/users` | | `code` | string | No | Specific error code | `LE_ERR_SS_010` | ### 500 — Internal server error | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `code` | string | No | Top-level error code | `LE_ERR_SS_500` | | `errors` | array\ | No | List of error details See **ErrorDetailToken500VO** below. | — | #### ErrorDetailToken500VO | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `message` | string | No | Detailed error message | `Internal Server Error` | | `path` | string | No | API path that generated the error | `null` | | `code` | string | No | Specific error code | `null` | ### Sample Response (200) ```json { "code": "LE_SS_001", "message": "User retrieved successfully.", "data": { "id": "37d14717-5c1a-44fe-9b8f-6d5184b09f06", "name": "John Doe", "email": "user@example.com", "active": true, "enabled": true, "createdAt": "2025-12-15T10:20:30Z", "departments": [ { "id": "3fa85f64-5717-4562-b3fc-2c963f66afa6", "name": "Human Resources", "enabled": true, "createdAt": "2025-12-15T10:20:30Z", "totalUsers": 25 } ], "roles": [ { "id": "b0af5f43-7f34-4ea4-867a-10115642f354", "name": "Admin", "createdAt": "2025-12-15T10:20:30Z", "entitlements": [ { "id": "3fa85f64-5717-4562-b3fc-2c963f66afa6", "name": "DOCUMENT_SIGN" } ] } ] } } ``` --- URL: https://knowledge.leegality.com/sign-station/api/create # POST /api/v1/departments — Create new department This API creates a new department for the current user's organization. Note that department creation is subject to license limits. **Authentication:** `X-Auth-Token` header required on every request. ## Request URL ``` POST https://app1.leegality.com/api/api/v1/departments ``` **Environments:** - Production: `https://app1.leegality.com/api/api/v1/departments` - Sandbox: `https://sandbox.leegality.com/api/api/v1/departments` --- ## Request Body **Content-Type:** `application/json` | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `name` | string | Yes | The department name (e.g., "Human Resources"). Must be between 2 and 255 characters. | — | | `enabled` | boolean | No | Shows the status of the department. For an active department, the value is set to true; for an inactive department, it is set to false. | — | ### Sample Request ```json { "name": "string", "enabled": false } ``` --- ## Responses ### 200 — Department created successfully | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `code` | string | No | Response status code | — | | `message` | string | No | Response message | — | | `data` | DepartmentVO | No | See **DepartmentVO** below. | — | #### DepartmentVO | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `id` | string | No | Department unique identifier | `3fa85f64-5717-4562-b3fc-2c963f66afa6` | | `name` | string | No | The department's name (e.g., "Human Resources"). | `Human Resources` | | `enabled` | boolean | No | Indicates whether the department is active or inactive. | `true` | | `createdAt` | string | No | The date and time when the department was created. | `2025-12-15T10:20:30Z` | | `totalUsers` | integer | No | Total number of users in the department. | `25` | ### 400 — Invalid request data | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `code` | string | No | Response status code | — | | `message` | string | No | Response message | — | | `data` | DepartmentVO | No | See **DepartmentVO** below. | — | #### DepartmentVO | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `id` | string | No | Department unique identifier | `3fa85f64-5717-4562-b3fc-2c963f66afa6` | | `name` | string | No | The department's name (e.g., "Human Resources"). | `Human Resources` | | `enabled` | boolean | No | Indicates whether the department is active or inactive. | `true` | | `createdAt` | string | No | The date and time when the department was created. | `2025-12-15T10:20:30Z` | | `totalUsers` | integer | No | Total number of users in the department. | `25` | ### 401 — Unauthorized - Invalid or expired token | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `code` | string | No | Top-level error code | `LE_ERR_SS_401` | | `errors` | array\ | No | List of error details See **ErrorDetail401Unauthorized** below. | — | #### ErrorDetail401Unauthorized | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `message` | string | No | Detailed error message | `Invalid or expired token` | | `path` | string | No | API path that generated the error | `/api/v1/*` | | `code` | string | No | Specific error code | `LE_ERR_SS_303` | ### 409 — Department already exists | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `code` | string | No | Response status code | — | | `message` | string | No | Response message | — | | `data` | DepartmentVO | No | See **DepartmentVO** below. | — | #### DepartmentVO | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `id` | string | No | Department unique identifier | `3fa85f64-5717-4562-b3fc-2c963f66afa6` | | `name` | string | No | The department's name (e.g., "Human Resources"). | `Human Resources` | | `enabled` | boolean | No | Indicates whether the department is active or inactive. | `true` | | `createdAt` | string | No | The date and time when the department was created. | `2025-12-15T10:20:30Z` | | `totalUsers` | integer | No | Total number of users in the department. | `25` | ### 500 — Internal server error | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `code` | string | No | Top-level error code | `LE_ERR_SS_500` | | `errors` | array\ | No | List of error details See **ErrorDetailToken500VO** below. | — | #### ErrorDetailToken500VO | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `message` | string | No | Detailed error message | `Internal Server Error` | | `path` | string | No | API path that generated the error | `null` | | `code` | string | No | Specific error code | `null` | ### Sample Response (200) ```json { "code": "string", "message": "string", "data": { "id": "3fa85f64-5717-4562-b3fc-2c963f66afa6", "name": "Human Resources", "enabled": true, "createdAt": "2025-12-15T10:20:30Z", "totalUsers": 25 } } ``` --- URL: https://knowledge.leegality.com/sign-station/api/delete-1 # DELETE /api/v1/certificates/{id} — Delete certificate Deletes a certificate by its ID for the current user's organization **Authentication:** `X-Auth-Token` header required on every request. ## Request URL ``` DELETE https://app1.leegality.com/api/api/v1/certificates/{id} ``` **Environments:** - Production: `https://app1.leegality.com/api/api/v1/certificates/{id}` - Sandbox: `https://sandbox.leegality.com/api/api/v1/certificates/{id}` --- ## Parameters | Name | In | Required | Type | Description | Example | |------|----|----------|------|-------------|---------| | `id` | path | Yes | string | Certificate ID | — | --- ## Responses ### 200 — Certificate deleted successfully | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `code` | string | No | Response code indicating success or failure | `LE_SS_002` | | `message` | string | No | Response message providing additional information | `Requested record has been deleted.` | | `data` | object | No | Additional data related to the response, if any. | — | ### 401 — Unauthorized - Invalid or expired token | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `code` | string | No | Top-level error code | `LE_ERR_SS_401` | | `errors` | array\ | No | List of error details See **ErrorDetail401Unauthorized** below. | — | #### ErrorDetail401Unauthorized | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `message` | string | No | Detailed error message | `Invalid or expired token` | | `path` | string | No | API path that generated the error | `/api/v1/*` | | `code` | string | No | Specific error code | `LE_ERR_SS_303` | ### 404 — Certificate not found | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `code` | string | No | Top-level error code | `LE_ERR_SS_404` | | `errors` | array\ | No | List of error details See **ErrorDetailVO** below. | — | #### ErrorDetailVO | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `message` | string | No | Detailed error message | `Certificate with id 46d4e120-ed03-47cc-98c6-529bff3bbaba doe` | | `path` | string | No | API path that generated the error | `/api/v1/certificates/46d4e120-ed03-47cc-98c6-529bff3bbaba` | | `code` | string | No | Specific error code | `LE_ERR_SS_001` | ### 500 — Internal server error | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `code` | string | No | Top-level error code | `LE_ERR_SS_500` | | `errors` | array\ | No | List of error details See **ErrorDetailToken500VO** below. | — | #### ErrorDetailToken500VO | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `message` | string | No | Detailed error message | `Internal Server Error` | | `path` | string | No | API path that generated the error | `null` | | `code` | string | No | Specific error code | `null` | ### Sample Response (200) ```json { "code": "LE_SS_002", "message": "Requested record has been deleted.", "data": {} } ``` --- URL: https://knowledge.leegality.com/sign-station/api/delete-config # DELETE /api/v1/certificate-notification-config — Delete certificate notification configuration for current organization Deletes certificate notification configuration for the current user's organization **Authentication:** `X-Auth-Token` header required on every request. ## Request URL ``` DELETE https://app1.leegality.com/api/api/v1/certificate-notification-config ``` **Environments:** - Production: `https://app1.leegality.com/api/api/v1/certificate-notification-config` - Sandbox: `https://sandbox.leegality.com/api/api/v1/certificate-notification-config` --- ## Responses ### 200 — Certificate notification configuration deleted successfully | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `code` | string | No | Response code indicating success or failure | `LE_SS_002` | | `message` | string | No | Response message providing additional information | `Requested record has been deleted.` | | `data` | object | No | Additional data related to the response, if any. | — | ### 401 — Invalid or expired token | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `code` | string | No | Top-level error code | `LE_ERR_SS_401` | | `errors` | array\ | No | List of error details See **ErrorDetail401VO** below. | — | #### ErrorDetail401VO | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `message` | string | No | Detailed error message | `Invalid or expired token` | | `path` | string | No | API path that generated the error | `/api/v1/certificate-notification-config` | | `code` | string | No | Specific error code | `LE_ERR_SS_303` | ### 404 — Configuration not found | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `code` | string | No | Top-level error code | `LE_ERR_SS_404` | | `errors` | array\ | No | List of error details See **ErrorDetailDeleteCertificateNotificationConfig404VO** below. | — | #### ErrorDetailDeleteCertificateNotificationConfig404VO | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `message` | string | No | Detailed error message | `Configuration not found.` | | `path` | string | No | API path that generated the error | `/api/v1/certificate-notification-config` | | `code` | string | No | Specific error code | `LE_ERR_SS_1201` | ### 500 — Internal server error | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `code` | string | No | Top-level error code | `LE_ERR_SS_500` | | `errors` | array\ | No | List of error details See **ErrorDetailToken500VO** below. | — | #### ErrorDetailToken500VO | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `message` | string | No | Detailed error message | `Internal Server Error` | | `path` | string | No | API path that generated the error | `null` | | `code` | string | No | Specific error code | `null` | ### Sample Response (200) ```json { "code": "LE_SS_002", "message": "Requested record has been deleted.", "data": {} } ``` --- URL: https://knowledge.leegality.com/sign-station/api/delete-o-auth-2-client # DELETE /api/v1/oauth2-clients/{id} — Delete OAuth2 client Deletes OAuth2 client by ID for the current user's organization **Authentication:** `X-Auth-Token` header required on every request. ## Request URL ``` DELETE https://app1.leegality.com/api/api/v1/oauth2-clients/{id} ``` **Environments:** - Production: `https://app1.leegality.com/api/api/v1/oauth2-clients/{id}` - Sandbox: `https://sandbox.leegality.com/api/api/v1/oauth2-clients/{id}` --- ## Parameters | Name | In | Required | Type | Description | Example | |------|----|----------|------|-------------|---------| | `id` | path | Yes | string | OAuth2 client ID to be deleted. | — | --- ## Responses ### 200 — OAuth2 client deleted successfully | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `code` | string | No | Response status code | `LE_SS_004` | | `message` | string | No | Response message | `OAuth2 client updated successfully.` | ### 401 — Unauthorized - Invalid or expired token | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `code` | string | No | Top-level error code | `LE_ERR_SS_401` | | `errors` | array\ | No | List of error details See **ErrorDetail401Unauthorized** below. | — | #### ErrorDetail401Unauthorized | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `message` | string | No | Detailed error message | `Invalid or expired token` | | `path` | string | No | API path that generated the error | `/api/v1/*` | | `code` | string | No | Specific error code | `LE_ERR_SS_303` | ### 404 — OAuth2 client not found | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `code` | string | No | Top-level error code | `LE_ERR_SS_404` | | `errors` | array\ | No | List of error details See **ErrorDetailOAuth2Client404VO** below. | — | #### ErrorDetailOAuth2Client404VO | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `message` | string | No | Detailed error message | `OAuth2 Client with id a3a0e830-66b6-4845-bf1a-91e0966fb97a d` | | `path` | string | No | API path that generated the error | `/api/v1/oauth2-clients/a3a0e830-66b6-4845-bf1a-91e0966fb97a/` | | `code` | string | No | Specific error code | `LE_ERR_SS_001` | ### 500 — Internal server error | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `code` | string | No | Top-level error code | `LE_ERR_SS_500` | | `errors` | array\ | No | List of error details See **ErrorDetailToken500VO** below. | — | #### ErrorDetailToken500VO | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `message` | string | No | Detailed error message | `Internal Server Error` | | `path` | string | No | API path that generated the error | `null` | | `code` | string | No | Specific error code | `null` | ### Sample Response (200) ```json { "code": "LE_SS_004", "message": "OAuth2 client updated successfully." } ``` --- URL: https://knowledge.leegality.com/sign-station/api/delete-user # DELETE /api/v1/users/{id} — Delete user Soft deletes a user by ID (sets enabled=false). Prevents deletion of the last admin user. **Authentication:** `X-Auth-Token` header required on every request. ## Request URL ``` DELETE https://app1.leegality.com/api/api/v1/users/{id} ``` **Environments:** - Production: `https://app1.leegality.com/api/api/v1/users/{id}` - Sandbox: `https://sandbox.leegality.com/api/api/v1/users/{id}` --- ## Parameters | Name | In | Required | Type | Description | Example | |------|----|----------|------|-------------|---------| | `id` | path | Yes | string | ID of the user to be deleted. | — | --- ## Responses ### 200 — User disabled successfully | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `code` | string | No | Response code indicating success or failure | `LE_SS_002` | | `message` | string | No | Response message providing additional information | `Requested record has been deleted.` | | `data` | object | No | Additional data related to the response, if any. | — | ### 400 — Cannot delete the last admin user | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `code` | string | No | Top-level error code | `LE_ERR_SS_400` | | `errors` | array\ | No | List of error details See **ErrorDetailDeleteUser400VO** below. | — | #### ErrorDetailDeleteUser400VO | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `message` | string | No | Detailed error message | `Cannot delete the last admin user. The system must have at l` | | `path` | string | No | API path that generated the error | `/api/v1/users/{id}` | | `code` | string | No | Specific error code | `null` | ### 401 — Unauthorized - Invalid or expired token | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `code` | string | No | Top-level error code | `LE_ERR_SS_401` | | `errors` | array\ | No | List of error details See **ErrorDetail401Unauthorized** below. | — | #### ErrorDetail401Unauthorized | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `message` | string | No | Detailed error message | `Invalid or expired token` | | `path` | string | No | API path that generated the error | `/api/v1/*` | | `code` | string | No | Specific error code | `LE_ERR_SS_303` | ### 404 — User not found | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `code` | string | No | Top-level error code | `LE_ERR_SS_404` | | `errors` | array\ | No | List of error details See **ErrorDetailDeleteUser404VO** below. | — | #### ErrorDetailDeleteUser404VO | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `message` | string | No | Detailed error message | `f6b0449d-b866-4647-b5c5-9ce765eb1182 does not exist.` | | `path` | string | No | API path that generated the error | `/api/v1/users/f6b0449d-b866-4647-b5c5-9ce765eb1182` | | `code` | string | No | Specific error code | `LE_ERR_SS_001` | ### 500 — Internal server error | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `code` | string | No | Top-level error code | `LE_ERR_SS_500` | | `errors` | array\ | No | List of error details See **ErrorDetailToken500VO** below. | — | #### ErrorDetailToken500VO | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `message` | string | No | Detailed error message | `Internal Server Error` | | `path` | string | No | API path that generated the error | `null` | | `code` | string | No | Specific error code | `null` | ### Sample Response (200) ```json { "code": "LE_SS_002", "message": "Requested record has been deleted.", "data": {} } ``` --- URL: https://knowledge.leegality.com/sign-station/api/delete # DELETE /api/v1/departments/{id} — Delete department This API deletes a department by its ID for the current user's organization. Note that deleting a department actually disables it. **Authentication:** `X-Auth-Token` header required on every request. ## Request URL ``` DELETE https://app1.leegality.com/api/api/v1/departments/{id} ``` **Environments:** - Production: `https://app1.leegality.com/api/api/v1/departments/{id}` - Sandbox: `https://sandbox.leegality.com/api/api/v1/departments/{id}` --- ## Parameters | Name | In | Required | Type | Description | Example | |------|----|----------|------|-------------|---------| | `id` | path | Yes | string | The unique ID of the department to be deleted. | — | --- ## Responses ### 200 — Department disabled successfully | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `code` | string | No | Response code indicating success or failure | `LE_SS_002` | | `message` | string | No | Response message providing additional information | `Requested record has been deleted.` | | `data` | object | No | Additional data related to the response, if any. | — | ### 401 — Unauthorized - Invalid or expired token | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `code` | string | No | Top-level error code | `LE_ERR_SS_401` | | `errors` | array\ | No | List of error details See **ErrorDetail401Unauthorized** below. | — | #### ErrorDetail401Unauthorized | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `message` | string | No | Detailed error message | `Invalid or expired token` | | `path` | string | No | API path that generated the error | `/api/v1/*` | | `code` | string | No | Specific error code | `LE_ERR_SS_303` | ### 404 — Department not found | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `code` | string | No | Top-level error code | `LE_ERR_SS_404` | | `errors` | array\ | No | List of error details See **ErrorDetailDeleteDepartment404VO** below. | — | #### ErrorDetailDeleteDepartment404VO | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `message` | string | No | Detailed error message | `Department does not exist.` | | `path` | string | No | API path that generated the error | `/api/v1/departments/acd77746-6eb2-4ad3-9356-e9f12f7ef501` | | `code` | string | No | Specific error code | `LE_ERR_SS_001` | ### 500 — Internal server error | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `code` | string | No | Top-level error code | `LE_ERR_SS_500` | | `errors` | array\ | No | List of error details See **ErrorDetailToken500VO** below. | — | #### ErrorDetailToken500VO | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `message` | string | No | Detailed error message | `Internal Server Error` | | `path` | string | No | API path that generated the error | `null` | | `code` | string | No | Specific error code | `null` | ### Sample Response (200) ```json { "code": "LE_SS_002", "message": "Requested record has been deleted.", "data": {} } ``` --- # Department Controller URL: https://knowledge.leegality.com/sign-station/api/department-controller.tag > Department Controller The Department Management API provides endpoints for managing departments within an organization. Departments are used to organize users, certificates, and documents within the SignStation platform. All department operations are scoped to the authenticated user's organization. Use this API to create, retrieve, update and delete departments as needed. For the dashboard workflow, see [Department Management](https://knowledge.leegality.com/sign-station/user-management/department-management). ```mdx-code-block ``` --- # Documents URL: https://knowledge.leegality.com/sign-station/api/documents.tag > Documents The Document Management API provides endpoints for digitally signing documents, retrieving document information, downloading signed documents and audit trails, searching documents, and viewing document signing statistics. All document operations are organization-scoped and require proper authentication and authorization. For the dashboard signing journey, see [Uploading Documents](https://knowledge.leegality.com/sign-station/signing-journey/signing-a-document/uploading-documents), [Signing Documents](https://knowledge.leegality.com/sign-station/signing-journey/signing-a-document/sign-the-documents), [Reviewing Documents](https://knowledge.leegality.com/sign-station/signing-journey/reviewing-documents), and [Downloading Signed Documents](https://knowledge.leegality.com/sign-station/signing-journey/signing-a-document/download-signed-documents). ```mdx-code-block ``` --- # Entitlement Controller URL: https://knowledge.leegality.com/sign-station/api/entitlement-controller.tag > Entitlement Controller The Entitlement API provides read-only access to the system's permission definitions. Entitlements represent individual permissions or capabilities within the SignStation platform (e.g., `readDocument`, `writeUser`, `signDocument`). This API allows administrators and developers to discover available permissions when configuring Role-Based Access Control (RBAC) systems. Each entitlement corresponds to a specific action or resource access right. Entitlements are system-defined and cannot be created or modified via API; they are managed by system administrators. To see how entitlements are grouped into assignable roles, see [Role Management](https://knowledge.leegality.com/sign-station/user-management/role-management). ```mdx-code-block ``` --- URL: https://knowledge.leegality.com/sign-station/api/find-by-id-1 # GET /api/v1/certificates/{id} — Get certificate by ID The API retrieves a certificate by its ID for the current user's organization. It fetches the complete certificate information including name, type, expiry date, creation date, and department assignment. Note that the API does NOT return the actual certificate file or passkey (security reasons). **Authentication:** `X-Auth-Token` header required on every request. ## Request URL ``` GET https://app1.leegality.com/api/api/v1/certificates/{id} ``` **Environments:** - Production: `https://app1.leegality.com/api/api/v1/certificates/{id}` - Sandbox: `https://sandbox.leegality.com/api/api/v1/certificates/{id}` --- ## Parameters | Name | In | Required | Type | Description | Example | |------|----|----------|------|-------------|---------| | `id` | path | Yes | string | ID of the certificate to be retrieved. | — | --- ## Responses ### 200 — Certificate retrieved successfully | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `id` | string | No | Certificate unique identifier | `46d4e120-ed03-47cc-98c6-529bff3bbabc` | | `name` | string | No | Certificate name | `TestCertificate.leegality.com` | | `certificateType` | string | No | Type of the certificate Allowed: `PKCS12_PFX`, `PKCS12_HSM`, `PKCS11`. | — | | `expiry` | string | No | Certificate expiry date | — | | `createdAt` | string | No | The date and time when the certificate was created | — | | `departmentId` | string | No | Associated department ID | `18b45e41-5d8b-4417-bb83-1d769187aef9` | | `departmentName` | string | No | Associated department name | `HR` | ### 400 — Invalid UUID provided | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `code` | string | No | Top-level error code | `LE_ERR_SS_400` | | `errors` | array\ | No | List of error details See **ErrorDetailGetCertificate400VO** below. | — | #### ErrorDetailGetCertificate400VO | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `message` | string | No | Detailed error message | `Invalid UUID provided.` | | `path` | string | No | API path that generated the error | `/api/v1/certificates/invalid-id-123` | | `code` | string | No | Specific error code | `null` | ### 401 — Unauthorized - Invalid or expired token | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `code` | string | No | Top-level error code | `LE_ERR_SS_401` | | `errors` | array\ | No | List of error details See **ErrorDetailGetCertificate401VO** below. | — | #### ErrorDetailGetCertificate401VO | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `message` | string | No | Detailed error message | `Invalid or expired token` | | `path` | string | No | API path that generated the error | `/api/v1/certificates/{id}` | | `code` | string | No | Specific error code | `LE_ERR_SS_303` | ### 403 — Forbidden - Access denied | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `code` | string | No | Top-level error code | `LE_ERR_SS_403` | | `errors` | array\ | No | List of error details See **ErrorDetailGetCertificate403VO** below. | — | #### ErrorDetailGetCertificate403VO | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `message` | string | No | Detailed error message | `Access denied for the requested operation.` | | `path` | string | No | API path that generated the error | `/api/v1/certificates/{id}` | | `code` | string | No | Specific error code | `LE_ERR_SS_007` | ### 404 — Certificate not found | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `code` | string | No | Top-level error code | `LE_ERR_SS_404` | | `errors` | array\ | No | List of error details See **ErrorDetailVO** below. | — | #### ErrorDetailVO | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `message` | string | No | Detailed error message | `Certificate with id 46d4e120-ed03-47cc-98c6-529bff3bbaba doe` | | `path` | string | No | API path that generated the error | `/api/v1/certificates/46d4e120-ed03-47cc-98c6-529bff3bbaba` | | `code` | string | No | Specific error code | `LE_ERR_SS_001` | ### 500 — Internal server error | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `code` | string | No | Top-level error code | `LE_ERR_SS_500` | | `errors` | array\ | No | List of error details See **ErrorDetailToken500VO** below. | — | #### ErrorDetailToken500VO | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `message` | string | No | Detailed error message | `Internal Server Error` | | `path` | string | No | API path that generated the error | `null` | | `code` | string | No | Specific error code | `null` | ### Sample Response (200) ```json { "id": "46d4e120-ed03-47cc-98c6-529bff3bbabc", "name": "TestCertificate.leegality.com", "certificateType": "PKCS12_PFX", "expiry": "string", "createdAt": "string", "departmentId": "18b45e41-5d8b-4417-bb83-1d769187aef9", "departmentName": "HR" } ``` --- URL: https://knowledge.leegality.com/sign-station/api/find-by-id # GET /api/v1/departments/{id} — Get department by ID This API retrieves a department by its ID for the current user's organization. **Authentication:** `X-Auth-Token` header required on every request. ## Request URL ``` GET https://app1.leegality.com/api/api/v1/departments/{id} ``` **Environments:** - Production: `https://app1.leegality.com/api/api/v1/departments/{id}` - Sandbox: `https://sandbox.leegality.com/api/api/v1/departments/{id}` --- ## Parameters | Name | In | Required | Type | Description | Example | |------|----|----------|------|-------------|---------| | `id` | path | Yes | string | Provide the Department ID here. You can obtain this ID from the Search Departments API. | — | --- ## Responses ### 200 — Department retrieved successfully | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `code` | string | No | Response status code | — | | `message` | string | No | Response message | — | | `data` | DepartmentVO | No | See **DepartmentVO** below. | — | #### DepartmentVO | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `id` | string | No | Department unique identifier | `3fa85f64-5717-4562-b3fc-2c963f66afa6` | | `name` | string | No | The department's name (e.g., "Human Resources"). | `Human Resources` | | `enabled` | boolean | No | Indicates whether the department is active or inactive. | `true` | | `createdAt` | string | No | The date and time when the department was created. | `2025-12-15T10:20:30Z` | | `totalUsers` | integer | No | Total number of users in the department. | `25` | ### 401 — Unauthorized - Invalid or expired token | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `code` | string | No | Top-level error code | `LE_ERR_SS_401` | | `errors` | array\ | No | List of error details See **ErrorDetail401Unauthorized** below. | — | #### ErrorDetail401Unauthorized | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `message` | string | No | Detailed error message | `Invalid or expired token` | | `path` | string | No | API path that generated the error | `/api/v1/*` | | `code` | string | No | Specific error code | `LE_ERR_SS_303` | ### 404 — Department not found | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `code` | string | No | Top-level error code | `LE_ERR_SS_404` | | `errors` | array\ | No | List of error details See **ErrorDetailFindDepartmentById404VO** below. | — | #### ErrorDetailFindDepartmentById404VO | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `message` | string | No | Detailed error message | `Department does not exist.` | | `path` | string | No | API path that generated the error | `/api/v1/departments/5a626ba7-51ef-4042-92d8-7eec79640bc5` | | `code` | string | No | Specific error code | `LE_ERR_SS_001` | ### 500 — Internal server error | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `code` | string | No | Top-level error code | `LE_ERR_SS_500` | | `errors` | array\ | No | List of error details See **ErrorDetailToken500VO** below. | — | #### ErrorDetailToken500VO | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `message` | string | No | Detailed error message | `Internal Server Error` | | `path` | string | No | API path that generated the error | `null` | | `code` | string | No | Specific error code | `null` | ### Sample Response (200) ```json { "code": "string", "message": "string", "data": { "id": "3fa85f64-5717-4562-b3fc-2c963f66afa6", "name": "Human Resources", "enabled": true, "createdAt": "2025-12-15T10:20:30Z", "totalUsers": 25 } } ``` --- URL: https://knowledge.leegality.com/sign-station/api/generate-token # POST /api/v1/auth/token — OAuth2 Client Token Authenticates an OAuth2 client using client ID and client secret credentials. This API is designed for machine-to-machine (M2M) communication and programmatic API access. Returns a JWT access token associated with the user linked to the OAuth2 client. The token contains the user's permissions and can be used to make API calls on behalf of that user. **Authentication:** `X-Auth-Token` header required on every request. ## Request URL ``` POST https://app1.leegality.com/api/api/v1/auth/token ``` **Environments:** - Production: `https://app1.leegality.com/api/api/v1/auth/token` - Sandbox: `https://sandbox.leegality.com/api/api/v1/auth/token` --- ## Request Body **Content-Type:** `application/json` | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `clientId` | string | Yes | The client ID issued to the client during the registration process. | `TestAPISecretKey` | | `clientSecret` | string | Yes | The client secret issued to the client during the registration process. | `7wHdO0PBqujt63lrlDwf-kbfrI3sKhjHf5-psnNj8-c` | ### Sample Request ```json { "clientId": "TestAPISecretKey", "clientSecret": "7wHdO0PBqujt63lrlDwf-kbfrI3sKhjHf5-psnNj8-c" } ``` --- ## Responses ### 200 — OK | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `code` | string | No | Response code indicating success or failure of the token request. | `LE_SS_301` | | `message` | string | No | A message providing additional information about the token request. | `Authentication successful.` | | `data` | TokenVO | No | See **TokenVO** below. | — | #### TokenVO | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `accessToken` | string | No | JWT token to use in Authorization header as 'Bearer ' | `eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiJhZG1pbkBsZWVnYWxpdHkuY29tIiw` | | `tokenType` | string | No | Type of the token, typically "Bearer" for JWT tokens. | `Bearer` | | `expiresIn` | integer | No | Expiration time of the token in seconds. | `3600` | ### 400 — Invalid request - Client ID or Client Secret is blank | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `code` | string | No | Top-level error code | `LE_ERR_SS_400` | | `errors` | array\ | No | List of error details See **ErrorDetailToken400VO** below. | — | #### ErrorDetailToken400VO | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `message` | string | No | Detailed error message | `Invalid value for field [clientSecret], Client secret cannot` | | `path` | string | No | API path that generated the error | `/api/v1/auth/token` | ### 404 — OAuth2 Client not found | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `code` | string | No | Top-level error code | `LE_ERR_SS_404` | | `errors` | array\ | No | List of error details See **ErrorDetailToken404VO** below. | — | #### ErrorDetailToken404VO | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `message` | string | No | Detailed error message | `OAuth2 Client with client ID admin@leegality.com does not ex` | | `path` | string | No | API path that generated the error | `/api/v1/auth/token` | | `code` | string | No | Specific error code | `LE_ERR_SS_001` | ### 500 — Internal server error | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `code` | string | No | Top-level error code | `LE_ERR_SS_500` | | `errors` | array\ | No | List of error details See **ErrorDetailToken500VO** below. | — | #### ErrorDetailToken500VO | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `message` | string | No | Detailed error message | `Internal Server Error` | | `path` | string | No | API path that generated the error | `null` | | `code` | string | No | Specific error code | `null` | ### Sample Response (200) ```json { "code": "LE_SS_301", "message": "Authentication successful.", "data": { "accessToken": "eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiJhZG1pbkBsZWVnYWxpdHkuY29tIiwiaWF0IjoxNzY1NTI0NzA1LCJleHAiOjE3NjU1MjgzMDV9.v0dYZq57hlao2eHQY9l4bUxW6JnL3EUIpm21clU45F4", "tokenType": "Bearer", "expiresIn": 3600 } } ``` --- URL: https://knowledge.leegality.com/sign-station/api/get-audit-trail-document-s-3-presigned-url # GET /api/v1/documents/{id}/audit-trail-download-url — Get audit trail S3 presigned URL Get S3 presigned URL for downloading the audit trail PDF **Authentication:** `X-Auth-Token` header required on every request. ## Request URL ``` GET https://app1.leegality.com/api/api/v1/documents/{id}/audit-trail-download-url ``` **Environments:** - Production: `https://app1.leegality.com/api/api/v1/documents/{id}/audit-trail-download-url` - Sandbox: `https://sandbox.leegality.com/api/api/v1/documents/{id}/audit-trail-download-url` --- ## Parameters | Name | In | Required | Type | Description | Example | |------|----|----------|------|-------------|---------| | `id` | path | Yes | string | Document ID | — | --- ## Responses ### 200 — OK | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `code` | string | No | Response code indicating success or failure | — | | `message` | string | No | Response message providing additional information | — | | `data` | string | No | Response data as a string | — | ### 401 — Unauthorized - Invalid or expired token | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `code` | string | No | Top-level error code | `LE_ERR_SS_401` | | `errors` | array\ | No | List of error details See **ErrorDetail401Unauthorized** below. | — | #### ErrorDetail401Unauthorized | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `message` | string | No | Detailed error message | `Invalid or expired token` | | `path` | string | No | API path that generated the error | `/api/v1/*` | | `code` | string | No | Specific error code | `LE_ERR_SS_303` | ### 404 — Document not found | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `code` | string | No | Top-level error code | `LE_ERR_SS_404` | | `errors` | array\ | No | List of error details See **ErrorDetailGetAuditTrailDownloadUrl404VO** below. | — | #### ErrorDetailGetAuditTrailDownloadUrl404VO | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `message` | string | No | Detailed error message | `Document does not exist.` | | `path` | string | No | API path that generated the error | `/api/v1/documents/39aca76b-e720-4da8-8a08-234c19fe013C/audit` | | `code` | string | No | Specific error code | `LE_ERR_SS_001` | ### 500 — Internal server error | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `code` | string | No | Top-level error code | `LE_ERR_SS_500` | | `errors` | array\ | No | List of error details See **ErrorDetailToken500VO** below. | — | #### ErrorDetailToken500VO | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `message` | string | No | Detailed error message | `Internal Server Error` | | `path` | string | No | API path that generated the error | `null` | | `code` | string | No | Specific error code | `null` | ### Sample Response (200) ```json { "code": "string", "message": "string", "data": "string" } ``` --- URL: https://knowledge.leegality.com/sign-station/api/get-config-1 # GET /api/v1/certificate-notification-config — Get certificate notification configuration for current organization Retrieves certificate notification configuration for the current user's organization **Authentication:** `X-Auth-Token` header required on every request. ## Request URL ``` GET https://app1.leegality.com/api/api/v1/certificate-notification-config ``` **Environments:** - Production: `https://app1.leegality.com/api/api/v1/certificate-notification-config` - Sandbox: `https://sandbox.leegality.com/api/api/v1/certificate-notification-config` --- ## Responses ### 200 — Certificate notification configuration retrieved successfully | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `code` | string | No | Response status code | `LE_SS_001` | | `message` | string | No | Response message | `Your changes have been successfully saved.` | | `data` | CertificateNotificationConfigVO | No | See **CertificateNotificationConfigVO** below. | — | #### CertificateNotificationConfigVO | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `id` | string | No | Certificate notification configuration unique identifier | `6d8ff341-fe21-431e-9453-bb94959474b6` | | `reminderDays` | array\ | No | Days before expiry to send reminders | `2` | | `additionalEmailRecipients` | array\ | No | Additional email recipients for notifications | `anagha.babu@leegality.com` | | `enabled` | boolean | No | Indicates whether the certificate notification is enabled | `true` | | `createdAt` | string | No | The date and time when the certificate notification configuration was created | `2025-12-29T12:00:29.726603` | | `notifyRoles` | array\ | No | See **NotificationRoleVO** below. | — | ##### NotificationRoleVO | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `id` | string | No | Role ID. This is configured during the role creation. | `17d7949d-6fa9-4077-a76e-da349efe421b` | | `name` | string | No | Role name. E.g., "Admin", "User" etc. | `Test Role 12344` | | `createdAt` | string | No | The date and time when the role was created | `2025-11-13T14:05:34` | ### 401 — Unauthorized - Invalid or expired token | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `code` | string | No | Top-level error code | `LE_ERR_SS_401` | | `errors` | array\ | No | List of error details See **ErrorDetail401Unauthorized** below. | — | #### ErrorDetail401Unauthorized | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `message` | string | No | Detailed error message | `Invalid or expired token` | | `path` | string | No | API path that generated the error | `/api/v1/*` | | `code` | string | No | Specific error code | `LE_ERR_SS_303` | ### 404 — Configuration not found | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `code` | string | No | Top-level error code | `LE_ERR_SS_404` | | `errors` | array\ | No | List of error details See **ErrorDetailGetCertificateNotificationConfig404VO** below. | — | #### ErrorDetailGetCertificateNotificationConfig404VO | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `message` | string | No | Detailed error message | `Configuration not found.` | | `path` | string | No | API path that generated the error | `/api/v1/certificate-notification-config` | | `code` | string | No | Specific error code | `LE_ERR_SS_203` | ### 500 — Internal server error | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `code` | string | No | Top-level error code | `LE_ERR_SS_500` | | `errors` | array\ | No | List of error details See **ErrorDetailToken500VO** below. | — | #### ErrorDetailToken500VO | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `message` | string | No | Detailed error message | `Internal Server Error` | | `path` | string | No | API path that generated the error | `null` | | `code` | string | No | Specific error code | `null` | ### Sample Response (200) ```json { "code": "LE_SS_001", "message": "Your changes have been successfully saved.", "data": { "id": "6d8ff341-fe21-431e-9453-bb94959474b6", "reminderDays": [ 2 ], "additionalEmailRecipients": [ "anagha.babu@leegality.com" ], "enabled": true, "createdAt": "2025-12-29T12:00:29.726603", "notifyRoles": [ { "id": "17d7949d-6fa9-4077-a76e-da349efe421b", "name": "Test Role 12344", "createdAt": "2025-11-13T14:05:34" } ] } } ``` --- URL: https://knowledge.leegality.com/sign-station/api/get-config # GET /api/v1/notification-config — Get notification configuration for current organization Retrieves notification configuration for the current user's organization **Authentication:** `X-Auth-Token` header required on every request. ## Request URL ``` GET https://app1.leegality.com/api/api/v1/notification-config ``` **Environments:** - Production: `https://app1.leegality.com/api/api/v1/notification-config` - Sandbox: `https://sandbox.leegality.com/api/api/v1/notification-config` --- ## Responses ### 200 — Notification configuration retrieved successfully | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `code` | string | No | Response code indicating success or failure | `LE_SCS_SS_200` | | `message` | string | No | Response message providing additional information | `Notification configuration retrieved successfully` | | `data` | NotificationConfigVO | No | See **NotificationConfigVO** below. | — | #### NotificationConfigVO | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `id` | string | No | Notification configuration unique identifier | `5e191ba4-3fe5-4dd4-ba7c-f2e9632c08c2` | | `emailServerHost` | string | No | Email server host address | `smtp.gmail.com` | | `emailServerPort` | string | No | Email server port | `587` | | `username` | string | No | Username for email server authentication | `himanshu.kumar@leegality.com` | | `password` | string | No | Password for email server authentication | `NewPassword@123` | | `fromEmail` | string | No | Email address used in the 'From' field of outgoing emails | `himanshu.kumar@leegality.com` | | `fromName` | string | No | Name used in the 'From' field of outgoing emails | `Himanshu Kumar` | | `replyTo` | string | No | Email address used in the 'Reply-To' field of outgoing emails | `himanshu.kumar@leegality.com` | | `tlsEnabled` | boolean | No | Indicates whether TLS is enabled for email communication | `true` | | `createdAt` | string | No | The date and time when the notification configuration was created | `2025-10-10T15:42:45` | | `enabled` | boolean | No | Indicates whether the notification configuration is enabled | `false` | ### 401 — Unauthorized - Invalid or expired token | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `code` | string | No | Top-level error code | `LE_ERR_SS_401` | | `errors` | array\ | No | List of error details See **ErrorDetail401Unauthorized** below. | — | #### ErrorDetail401Unauthorized | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `message` | string | No | Detailed error message | `Invalid or expired token` | | `path` | string | No | API path that generated the error | `/api/v1/*` | | `code` | string | No | Specific error code | `LE_ERR_SS_303` | ### 404 — Configuration not found | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `code` | string | No | Top-level error code | `LE_ERR_SS_404` | | `errors` | array\ | No | List of error details See **ErrorDetailGetNotificationConfig404VO** below. | — | #### ErrorDetailGetNotificationConfig404VO | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `message` | string | No | Detailed error message | `Configuration not found.` | | `path` | string | No | API path that generated the error | `/api/v1/notification-config` | | `code` | string | No | Specific error code | `LE_ERR_SS_1301` | ### 500 — Internal server error | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `code` | string | No | Top-level error code | `LE_ERR_SS_500` | | `errors` | array\ | No | List of error details See **ErrorDetailToken500VO** below. | — | #### ErrorDetailToken500VO | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `message` | string | No | Detailed error message | `Internal Server Error` | | `path` | string | No | API path that generated the error | `null` | | `code` | string | No | Specific error code | `null` | ### Sample Response (200) ```json { "code": "LE_SCS_SS_200", "message": "Notification configuration retrieved successfully", "data": { "id": "5e191ba4-3fe5-4dd4-ba7c-f2e9632c08c2", "emailServerHost": "smtp.gmail.com", "emailServerPort": "587", "username": "himanshu.kumar@leegality.com", "password": "NewPassword@123", "fromEmail": "himanshu.kumar@leegality.com", "fromName": "Himanshu Kumar", "replyTo": "himanshu.kumar@leegality.com", "tlsEnabled": true, "createdAt": "2025-10-10T15:42:45", "enabled": false } } ``` --- URL: https://knowledge.leegality.com/sign-station/api/get-current-user # GET /api/v1/auth/me — Get Current User The API retrieves complete profile information for the currently authenticated user based on the JWT token in the Authorization header. Returns user details, organization, roles, permissions (authorities), and accessible departments. This endpoint is useful for validating tokens, refreshing user session data, and displaying user profile information in UI. **Authentication:** `X-Auth-Token` header required on every request. ## Request URL ``` GET https://app1.leegality.com/api/api/v1/auth/me ``` **Environments:** - Production: `https://app1.leegality.com/api/api/v1/auth/me` - Sandbox: `https://sandbox.leegality.com/api/api/v1/auth/me` --- ## Responses ### 200 — OK | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `code` | string | No | Response code indicating success or failure of the login request. | `LE_SS_301` | | `message` | string | No | A message providing additional information about the login request. | `Authentication successful.` | | `data` | LoginUserVO | No | See **LoginUserVO** below. | — | #### LoginUserVO | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `username` | string | No | The username of the logged-in user. | `admin@leegality.com` | | `name` | string | No | The full name of the logged-in user. | `TestUser123` | | `organization` | OrganizationVO | No | See **OrganizationVO** below. | — | | `accessToken` | string | No | JWT token to use in Authorization header as `Bearer | `eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiJhZG1pbkBsZWVnYWxpdHkuY29tIiw` | | `tokenType` | string | No | Type of the token, typically "Bearer" for JWT tokens. | `Bearer` | | `expiresIn` | integer | No | Expiration time of the token in seconds. | `3600` | | `authorities` | array\ | No | List of permissions/entitlements assigned through user's roles. | `writeCertificate,readNotificationRule,updateOAuth2Client,sea` | | `roles` | array\ | No | See **RoleVO** below. | — | | `departments` | array\ | No | See **DepartmentVO** below. | — | ##### OrganizationVO | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `id` | string | No | Organization unique identifier. | — | | `name` | string | No | Organization name. | `TestOrganization` | | `createdAt` | string | No | The date and time when the organization was created. | — | | `updatedAt` | string | No | The date and time when the organization was last updated. | — | | `enabled` | boolean | No | Indicates whether the organization is active or inactive. | — | ##### RoleVO | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `id` | string | No | Role ID. This is configured during the role creation. | `b0af5f43-7f34-4ea4-867a-10115642f354` | | `name` | string | No | Role name. E.g., "Admin", "User" etc. | `Admin` | | `createdAt` | string | No | The date and time when the role was created | `2025-12-15T10:20:30Z` | | `entitlements` | array\ | No | See **EntitlementVO** below. | — | ###### EntitlementVO | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `id` | string | No | Entitlement ID. This is configured in the system and cannot be changed. | `3fa85f64-5717-4562-b3fc-2c963f66afa6` | | `name` | string | No | Entitlement name. E.g., "DOCUMENT_SIGN","USER_MANAGEMENT" | `DOCUMENT_SIGN` | ##### DepartmentVO | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `id` | string | No | Department unique identifier | `3fa85f64-5717-4562-b3fc-2c963f66afa6` | | `name` | string | No | The department's name (e.g., "Human Resources"). | `Human Resources` | | `enabled` | boolean | No | Indicates whether the department is active or inactive. | `true` | | `createdAt` | string | No | The date and time when the department was created. | `2025-12-15T10:20:30Z` | | `totalUsers` | integer | No | Total number of users in the department. | `25` | ### 401 — Unauthorized - Invalid or expired token | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `code` | string | No | Top-level error code | `LE_ERR_SS_401` | | `errors` | array\ | No | List of error details See **ErrorDetail401Unauthorized** below. | — | #### ErrorDetail401Unauthorized | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `message` | string | No | Detailed error message | `Invalid or expired token` | | `path` | string | No | API path that generated the error | `/api/v1/*` | | `code` | string | No | Specific error code | `LE_ERR_SS_303` | ### 500 — Internal server error | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `code` | string | No | Top-level error code | `LE_ERR_SS_500` | | `errors` | array\ | No | List of error details See **ErrorDetailToken500VO** below. | — | #### ErrorDetailToken500VO | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `message` | string | No | Detailed error message | `Internal Server Error` | | `path` | string | No | API path that generated the error | `null` | | `code` | string | No | Specific error code | `null` | ### Sample Response (200) ```json { "code": "LE_SS_301", "message": "Authentication successful.", "data": { "username": "admin@leegality.com", "name": "TestUser123", "organization": { "id": "string", "name": "TestOrganization", "createdAt": "string", "updatedAt": "string", "enabled": false }, "accessToken": "eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiJhZG1pbkBsZWVnYWxpdHkuY29tIiwiaWF0IjoxNzY1NTI0NzA1LCJleHAiOjE3NjU1MjgzMDV9.v0dYZq57hlao2eHQY9l4bUxW6JnL3EUIpm21clU45F4", "tokenType": "Bearer", "expiresIn": 3600, "authorities": [ "writeCertificate", "readNotificationRule", "updateOAuth2Client", "searchDocument", "readEntitlement", "writeCertificateNotificationConfig", "deletePasswordPolicy", "writeDepartment", "deleteSettings", "readUser", "writeRoleEntitlement", "readDocument", "admin_deleteUser", "writeNotificationConfig", "readLicense", "writeSettings", "writeOrganization", "writeRole", "writeEmail", "deleteCertificateNotificationConfig", "deleteCertificate", "readSettings", "readOAuth2Client", "deleteRoleEntitlement", "readOrganization", "readCertificateNotificationConfig", "readRole", "readRoleEntitlement", "writeUser", "readPasswordPolicy", "readCertificate", "installLicense", "deleteNotificationConfig", "deleteRole", "readDepartment", "readAuditLog", "writeNotificationRule", "readNotificationConfig", "writePasswordPolicy", "admin_writeUser", "deleteDepartment", "deleteOAuth2Client", "signDocument", "writeOAuth2Client" ], "roles": [ { "id": "b0af5f43-7f34-4ea4-867a-10115642f354", "name": "Admin", "createdAt": "2025-12-15T10:20:30Z", "entitlements": [ { "id": "3fa85f64-5717-4562-b3fc-2c963f66afa6", "name": "DOCUMENT_SIGN" } ] } ], "departments": [ { "id": "3fa85f64-5717-4562-b3fc-2c963f66afa6", "name": "Human Resources", "enabled": true, "createdAt": "2025-12-15T10:20:30Z", "totalUsers": 25 } ] } } ``` --- URL: https://knowledge.leegality.com/sign-station/api/get-document-summary # GET /api/v1/documents/summary — Get document signing statistics Retrieve document signing statistics for different time periods. Optionally filter by department ID. **Authentication:** `X-Auth-Token` header required on every request. ## Request URL ``` GET https://app1.leegality.com/api/api/v1/documents/summary?departmentId={departmentId} ``` **Environments:** - Production: `https://app1.leegality.com/api/api/v1/documents/summary` - Sandbox: `https://sandbox.leegality.com/api/api/v1/documents/summary` --- ## Parameters | Name | In | Required | Type | Description | Example | |------|----|----------|------|-------------|---------| | `departmentId` | query | No | string | Department ID to filter documents by department | — | --- ## Responses ### 200 — OK | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `code` | string | No | Response code indicating success or failure | — | | `message` | string | No | Response message providing additional information | — | | `data` | DocumentSummaryDTO | No | Document signing statistics summary See **DocumentSummaryDTO** below. | — | #### DocumentSummaryDTO Document signing statistics summary | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `summary` | array\ | No | List of document signing statistics for different time periods See **SummaryDTO** below. | — | ##### SummaryDTO List of document signing statistics for different time periods | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `count` | integer | No | Number of documents signed in the specified time period | — | | `days` | integer | No | Time period in days for the document signing statistics | — | ### 401 — Unauthorized - Invalid or expired token | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `code` | string | No | Top-level error code | `LE_ERR_SS_401` | | `errors` | array\ | No | List of error details See **ErrorDetail401Unauthorized** below. | — | #### ErrorDetail401Unauthorized | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `message` | string | No | Detailed error message | `Invalid or expired token` | | `path` | string | No | API path that generated the error | `/api/v1/*` | | `code` | string | No | Specific error code | `LE_ERR_SS_303` | ### 500 — Internal server error | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `code` | string | No | Top-level error code | `LE_ERR_SS_500` | | `errors` | array\ | No | List of error details See **ErrorDetailToken500VO** below. | — | #### ErrorDetailToken500VO | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `message` | string | No | Detailed error message | `Internal Server Error` | | `path` | string | No | API path that generated the error | `null` | | `code` | string | No | Specific error code | `null` | ### Sample Response (200) ```json { "code": "string", "message": "string", "data": { "summary": [ { "count": 0, "days": 0 } ] } } ``` --- URL: https://knowledge.leegality.com/sign-station/api/get-document # GET /api/v1/documents/{id} — Get document by ID Retrieve document details by its unique identifier **Authentication:** `X-Auth-Token` header required on every request. ## Request URL ``` GET https://app1.leegality.com/api/api/v1/documents/{id} ``` **Environments:** - Production: `https://app1.leegality.com/api/api/v1/documents/{id}` - Sandbox: `https://sandbox.leegality.com/api/api/v1/documents/{id}` --- ## Parameters | Name | In | Required | Type | Description | Example | |------|----|----------|------|-------------|---------| | `id` | path | Yes | string | Document ID | — | --- ## Responses ### 200 — OK | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `code` | string | No | Response code indicating success or failure | `LE_SS_301` | | `message` | string | No | Response message providing additional information | `Document signed successfully.` | | `data` | DocumentVO | No | See **DocumentVO** below. | — | #### DocumentVO | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `id` | string | No | Document unique identifier | `5f8d0c2e-3a4b-4c6e-9f8e-2d3c4b5a6e7f` | | `name` | string | No | Name of the document | `TestDocument.pdf` | | `uploadedBy` | string | No | User ID of the person who uploaded the document | — | | `uploadedByName` | string | No | Name of the person who uploaded the document | `Test Signer` | | `department` | DepartmentVO | No | See **DepartmentVO** below. | — | | `status` | string | No | Current status of the document Allowed: `SUBMITTED`, `SIGNED`, `FAILED`. | — | | `signedAt` | string | No | The date and time when the document was signed | — | | `location` | string | No | Location where the document was signed | `Bangalore, India` | | `signerName` | string | No | Name of the signer | `Test Signer` | | `reason` | string | No | Reason for signing the document | `Testing signing via API` | | `createdAt` | string | No | The date and time when the document was created | — | | `enabled` | boolean | No | Indicates whether the document is enabled or disabled | — | | `certificate` | CertificateVO | No | See **CertificateVO** below. | — | ##### DepartmentVO | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `id` | string | No | Department unique identifier | `3fa85f64-5717-4562-b3fc-2c963f66afa6` | | `name` | string | No | The department's name (e.g., "Human Resources"). | `Human Resources` | | `enabled` | boolean | No | Indicates whether the department is active or inactive. | `true` | | `createdAt` | string | No | The date and time when the department was created. | `2025-12-15T10:20:30Z` | | `totalUsers` | integer | No | Total number of users in the department. | `25` | ##### CertificateVO | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `id` | string | No | Certificate unique identifier | `46d4e120-ed03-47cc-98c6-529bff3bbabc` | | `name` | string | No | Certificate name | `TestCertificate.leegality.com` | | `certificateType` | string | No | Type of the certificate Allowed: `PKCS12_PFX`, `PKCS12_HSM`, `PKCS11`. | — | | `expiry` | string | No | Certificate expiry date | — | | `createdAt` | string | No | The date and time when the certificate was created | — | | `departmentId` | string | No | Associated department ID | `18b45e41-5d8b-4417-bb83-1d769187aef9` | | `departmentName` | string | No | Associated department name | `HR` | ### 401 — Unauthorized - Invalid or expired token | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `code` | string | No | Top-level error code | `LE_ERR_SS_401` | | `errors` | array\ | No | List of error details See **ErrorDetail401Unauthorized** below. | — | #### ErrorDetail401Unauthorized | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `message` | string | No | Detailed error message | `Invalid or expired token` | | `path` | string | No | API path that generated the error | `/api/v1/*` | | `code` | string | No | Specific error code | `LE_ERR_SS_303` | ### 404 — Document not found | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `code` | string | No | Top-level error code | `LE_ERR_SS_404` | | `errors` | array\ | No | List of error details See **ErrorDetailGetDocument404VO** below. | — | #### ErrorDetailGetDocument404VO | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `message` | string | No | Detailed error message | `Document does not exist.` | | `path` | string | No | API path that generated the error | `/api/v1/documents/440d57e9-bfd6-407d-a282-cef01219a5a3` | | `code` | string | No | Specific error code | `LE_ERR_SS_001` | ### 500 — Internal server error | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `code` | string | No | Top-level error code | `LE_ERR_SS_500` | | `errors` | array\ | No | List of error details See **ErrorDetailToken500VO** below. | — | #### ErrorDetailToken500VO | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `message` | string | No | Detailed error message | `Internal Server Error` | | `path` | string | No | API path that generated the error | `null` | | `code` | string | No | Specific error code | `null` | ### Sample Response (200) ```json { "code": "LE_SS_301", "message": "Document signed successfully.", "data": { "id": "5f8d0c2e-3a4b-4c6e-9f8e-2d3c4b5a6e7f", "name": "TestDocument.pdf", "uploadedBy": "string", "uploadedByName": "Test Signer", "department": { "id": "3fa85f64-5717-4562-b3fc-2c963f66afa6", "name": "Human Resources", "enabled": true, "createdAt": "2025-12-15T10:20:30Z", "totalUsers": 25 }, "status": "SUBMITTED", "signedAt": "string", "location": "Bangalore, India", "signerName": "Test Signer", "reason": "Testing signing via API", "createdAt": "string", "enabled": false, "certificate": { "id": "46d4e120-ed03-47cc-98c6-529bff3bbabc", "name": "TestCertificate.leegality.com", "certificateType": "PKCS12_PFX", "expiry": "string", "createdAt": "string", "departmentId": "18b45e41-5d8b-4417-bb83-1d769187aef9", "departmentName": "HR" } } } ``` --- URL: https://knowledge.leegality.com/sign-station/api/get-entitlements # GET /api/v1/entitlements — Get entitlements for current organization Retrieves all entitlements for the current user's organization **Authentication:** `X-Auth-Token` header required on every request. ## Request URL ``` GET https://app1.leegality.com/api/api/v1/entitlements ``` **Environments:** - Production: `https://app1.leegality.com/api/api/v1/entitlements` - Sandbox: `https://sandbox.leegality.com/api/api/v1/entitlements` --- ## Responses ### 200 — Entitlements retrieved successfully | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `data` | array\ | No | See **EntitlementVO** below. | — | #### EntitlementVO | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `id` | string | No | Entitlement ID. This is configured in the system and cannot be changed. | `3fa85f64-5717-4562-b3fc-2c963f66afa6` | | `name` | string | No | Entitlement name. E.g., "DOCUMENT_SIGN","USER_MANAGEMENT" | `DOCUMENT_SIGN` | ### 401 — Unauthorized - Invalid or expired token | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `code` | string | No | Top-level error code | `LE_ERR_SS_401` | | `errors` | array\ | No | List of error details See **ErrorDetail401Unauthorized** below. | — | #### ErrorDetail401Unauthorized | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `message` | string | No | Detailed error message | `Invalid or expired token` | | `path` | string | No | API path that generated the error | `/api/v1/*` | | `code` | string | No | Specific error code | `LE_ERR_SS_303` | ### 500 — Internal server error | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `code` | string | No | Top-level error code | `LE_ERR_SS_500` | | `errors` | array\ | No | List of error details See **ErrorDetailToken500VO** below. | — | #### ErrorDetailToken500VO | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `message` | string | No | Detailed error message | `Internal Server Error` | | `path` | string | No | API path that generated the error | `null` | | `code` | string | No | Specific error code | `null` | ### Sample Response (200) ```json { "data": [ { "id": "3fa85f64-5717-4562-b3fc-2c963f66afa6", "name": "DOCUMENT_SIGN" } ] } ``` --- URL: https://knowledge.leegality.com/sign-station/api/get-expiring-soon # GET /api/v1/certificates/expiring-soon — Get certificates expiring soon Retrieves certificates that are expiring within the specified number of days for the current user's organization. Certificates are sorted by expiry date in ascending order (earliest expiring first). Only enabled certificates with expiry dates are included. **Authentication:** `X-Auth-Token` header required on every request. ## Request URL ``` GET https://app1.leegality.com/api/api/v1/certificates/expiring-soon?days={days}&departmentId={departmentId} ``` **Environments:** - Production: `https://app1.leegality.com/api/api/v1/certificates/expiring-soon` - Sandbox: `https://sandbox.leegality.com/api/api/v1/certificates/expiring-soon` --- ## Parameters | Name | In | Required | Type | Description | Example | |------|----|----------|------|-------------|---------| | `days` | query | No | integer | Number of days to check for expiring certificates (defaults to 30 days) | — | | `departmentId` | query | No | string | | — | --- ## Responses ### 200 — Expiring certificates retrieved successfully | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `data` | array\ | No | See **CertificateVO** below. | — | #### CertificateVO | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `id` | string | No | Certificate unique identifier | `46d4e120-ed03-47cc-98c6-529bff3bbabc` | | `name` | string | No | Certificate name | `TestCertificate.leegality.com` | | `certificateType` | string | No | Type of the certificate Allowed: `PKCS12_PFX`, `PKCS12_HSM`, `PKCS11`. | — | | `expiry` | string | No | Certificate expiry date | — | | `createdAt` | string | No | The date and time when the certificate was created | — | | `departmentId` | string | No | Associated department ID | `18b45e41-5d8b-4417-bb83-1d769187aef9` | | `departmentName` | string | No | Associated department name | `HR` | ### 400 — Invalid request parameters provided | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `code` | string | No | Top-level error code | `LE_ERR_SS_400` | | `errors` | array\ | No | List of error details See **ErrorDetailGetCertificatesExpiringSoon400VO** below. | — | #### ErrorDetailGetCertificatesExpiringSoon400VO | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `message` | string | No | Detailed error message | `Invalid request parameters provided.` | | `path` | string | No | API path that generated the error | `/api/v1/certificates/expiring-soon` | | `code` | string | No | Specific error code | `null` | ### 401 — Unauthorized - Invalid or expired token | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `code` | string | No | Top-level error code | `LE_ERR_SS_401` | | `errors` | array\ | No | List of error details See **ErrorDetailGetCertificatesExpiringSoon401VO** below. | — | #### ErrorDetailGetCertificatesExpiringSoon401VO | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `message` | string | No | Detailed error message | `Invalid or expired token` | | `path` | string | No | API path that generated the error | `/api/v1/certificates/expiring-soon` | | `code` | string | No | Specific error code | `LE_ERR_SS_303` | ### 500 — Internal server error | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `code` | string | No | Top-level error code | `LE_ERR_SS_500` | | `errors` | array\ | No | List of error details See **ErrorDetailToken500VO** below. | — | #### ErrorDetailToken500VO | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `message` | string | No | Detailed error message | `Internal Server Error` | | `path` | string | No | API path that generated the error | `null` | | `code` | string | No | Specific error code | `null` | ### Sample Response (200) ```json { "data": [ { "id": "46d4e120-ed03-47cc-98c6-529bff3bbabc", "name": "TestCertificate.leegality.com", "certificateType": "PKCS12_PFX", "expiry": "string", "createdAt": "string", "departmentId": "18b45e41-5d8b-4417-bb83-1d769187aef9", "departmentName": "HR" } ] } ``` --- URL: https://knowledge.leegality.com/sign-station/api/get-license-usage-stats # GET /api/v1/licenses/{licenseId}/usage-statistics — Get license usage statistics Get current usage statistics for all resources in the active license. Given a license ID, this API returns the current usage counts for various resources such as users, departments, certificates, and documents signed under that license. **Authentication:** `X-Auth-Token` header required on every request. ## Request URL ``` GET https://app1.leegality.com/api/api/v1/licenses/{licenseId}/usage-statistics ``` **Environments:** - Production: `https://app1.leegality.com/api/api/v1/licenses/{licenseId}/usage-statistics` - Sandbox: `https://sandbox.leegality.com/api/api/v1/licenses/{licenseId}/usage-statistics` --- ## Parameters | Name | In | Required | Type | Description | Example | |------|----|----------|------|-------------|---------| | `licenseId` | path | Yes | string | License ID for license lookup | — | --- ## Responses ### 200 — OK | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `code` | string | No | Response code indicating success or failure of the license usage stats request. | `LE_SS_200` | | `message` | string | No | A message providing additional information about the license usage stats request. | `License usage statistics retrieved successfully.` | | `data` | LicenseUsageStatsVO | No | See **LicenseUsageStatsVO** below. | — | #### LicenseUsageStatsVO | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `users` | ResourceUsageUsersVO | No | See **ResourceUsageUsersVO** below. | — | | `departments` | ResourceUsageDepartmentsVO | No | See **ResourceUsageDepartmentsVO** below. | — | | `signatures` | ResourceUsageSignaturesVO | No | See **ResourceUsageSignaturesVO** below. | — | | `certificates` | ResourceCertificatesUsageVO | No | See **ResourceCertificatesUsageVO** below. | — | ##### ResourceUsageUsersVO | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `current` | integer | No | Current number of active users | `233` | | `limit` | integer | No | Maximum number of users allowed by license | `1000` | ##### ResourceUsageDepartmentsVO | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `current` | integer | No | Current number of departments using this license | `23` | | `limit` | integer | No | Maximum number of departments allowed | `1000` | ##### ResourceUsageSignaturesVO | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `current` | integer | No | Current number of signatures used under this license. | `23` | | `limit` | integer | No | Maximum number of signatures allowed | `1000` | ##### ResourceCertificatesUsageVO | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `current` | integer | No | Current number of certificates | `23` | | `limit` | integer | No | Maximum number of certificates allowed | `1000` | ### 400 — License validation failed | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `code` | string | No | Top-level error code | `LE_ERR_SS_400` | | `errors` | array\ | No | List of error details See **ErrorDetailLicenseUsageStats400VO** below. | — | #### ErrorDetailLicenseUsageStats400VO | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `message` | string | No | Detailed error message | `License validation failed for the request.` | | `path` | string | No | API path that generated the error | `/api/v1/licenses/bd82845c-897b-4022-b5f7-679905c1979b/usage-` | | `code` | string | No | Specific error code | `LE_ERR_SS_008` | ### 401 — Unauthorized - Invalid or expired token | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `code` | string | No | Top-level error code | `LE_ERR_SS_401` | | `errors` | array\ | No | List of error details See **ErrorDetailLicenseUsageStats401VO** below. | — | #### ErrorDetailLicenseUsageStats401VO | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `message` | string | No | Detailed error message | `Invalid or expired token` | | `path` | string | No | API path that generated the error | `/api/v1/licenses/123456765RESAXCVBN54323456/usage-statistics` | | `code` | string | No | Specific error code | `LE_ERR_SS_303` | ### 403 — Forbidden - Access denied | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `code` | string | No | Top-level error code | `LE_ERR_SS_403` | | `errors` | array\ | No | List of error details See **ErrorDetailLicenseUsageStats403VO** below. | — | #### ErrorDetailLicenseUsageStats403VO | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `message` | string | No | Detailed error message | `Access denied for the requested operation.` | | `path` | string | No | API path that generated the error | `/api/v1/licenses/{licenseId}/usage-statistics` | | `code` | string | No | Specific error code | `LE_ERR_SS_007` | ### 500 — Internal server error | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `code` | string | No | Top-level error code | `LE_ERR_SS_500` | | `errors` | array\ | No | List of error details See **ErrorDetailToken500VO** below. | — | #### ErrorDetailToken500VO | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `message` | string | No | Detailed error message | `Internal Server Error` | | `path` | string | No | API path that generated the error | `null` | | `code` | string | No | Specific error code | `null` | ### Sample Response (200) ```json { "code": "LE_SS_200", "message": "License usage statistics retrieved successfully.", "data": { "users": { "current": 233, "limit": 1000 }, "departments": { "current": 23, "limit": 1000 }, "signatures": { "current": 23, "limit": 1000 }, "certificates": { "current": 23, "limit": 1000 } } } ``` --- URL: https://knowledge.leegality.com/sign-station/api/get-notification-rule-types # GET /api/v1/notification-rules/types — Get all notification rule types Retrieves all available notification rule types **Authentication:** `X-Auth-Token` header required on every request. ## Request URL ``` GET https://app1.leegality.com/api/api/v1/notification-rules/types ``` **Environments:** - Production: `https://app1.leegality.com/api/api/v1/notification-rules/types` - Sandbox: `https://sandbox.leegality.com/api/api/v1/notification-rules/types` --- ## Responses ### 200 — OK | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `code` | string | No | Response code indicating success or failure | `LE_SS_002` | | `message` | string | No | Response message providing additional information | `Requested record has been deleted.` | | `data` | array\ | No | See **NotificationRuleTypeVO** below. | `[object Object],[object Object],[object Object],[object Obje` | #### NotificationRuleTypeVO | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `type` | string | No | Type of notification rule Allowed: `USER_CREATED`, `USER_DELETED`, `DOCUMENT_SIGNED`, `LICENSE_EXPIRY_REMINDER`, `LICENSE_EXPIRED`, `CERTIFICATE_EXPIRED`. | `USER_CREATED` | | `label` | string | No | Human-readable label for the notification rule type | `User Created` | ### 401 — Unauthorized - Invalid or expired token | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `code` | string | No | Top-level error code | `LE_ERR_SS_401` | | `errors` | array\ | No | List of error details See **ErrorDetail401Unauthorized** below. | — | #### ErrorDetail401Unauthorized | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `message` | string | No | Detailed error message | `Invalid or expired token` | | `path` | string | No | API path that generated the error | `/api/v1/*` | | `code` | string | No | Specific error code | `LE_ERR_SS_303` | ### 500 — Internal server error | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `code` | string | No | Top-level error code | `LE_ERR_SS_500` | | `errors` | array\ | No | List of error details See **ErrorDetailToken500VO** below. | — | #### ErrorDetailToken500VO | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `message` | string | No | Detailed error message | `Internal Server Error` | | `path` | string | No | API path that generated the error | `null` | | `code` | string | No | Specific error code | `null` | ### Sample Response (200) ```json { "code": "LE_SS_002", "message": "Requested record has been deleted.", "data": [ { "type": "USER_CREATED", "label": "User Created" }, { "type": "USER_DELETED", "label": "User Deleted" }, { "type": "DOCUMENT_SIGNED", "label": "Document Signed" }, { "type": "LICENSE_EXPIRY_REMINDER", "label": "License Expiry Reminders" }, { "type": "LICENSE_EXPIRED", "label": "License Expired" }, { "type": "CERTIFICATE_EXPIRED", "label": "Certificate Expired" } ] } ``` --- URL: https://knowledge.leegality.com/sign-station/api/get-notification-rules # GET /api/v1/notification-rules — Get notification rules for current organization Retrieves all notification rules for the current user's organization **Authentication:** `X-Auth-Token` header required on every request. ## Request URL ``` GET https://app1.leegality.com/api/api/v1/notification-rules ``` **Environments:** - Production: `https://app1.leegality.com/api/api/v1/notification-rules` - Sandbox: `https://sandbox.leegality.com/api/api/v1/notification-rules` --- ## Responses ### 200 — OK | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `code` | string | No | Response code indicating success or failure | — | | `message` | string | No | Response message providing additional information | — | | `data` | array\ | No | See **NotificationRuleVO** below. | — | #### NotificationRuleVO | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `id` | string | No | Notification rule unique identifier | `a2787f6c-e00c-4bd9-ad34-ed88b8fcf54f` | | `ruleType` | string | No | Type of notification rule Allowed: `USER_CREATED`, `USER_DELETED`, `DOCUMENT_SIGNED`, `LICENSE_EXPIRY_REMINDER`, `LICENSE_EXPIRED`, `CERTIFICATE_EXPIRED`. | `USER_CREATED` | | `additionalEmailRecipients` | array\ | No | Additional email recipients for notifications | `anaghaputhur2018@gmail.com` | | `notifyUsers` | array\ | No | See **NotificationRuleUserVO** below. | — | | `enabled` | boolean | No | Indicates whether the notification rule is enabled | `true` | | `createdAt` | string | No | The date and time when the notification rule was created | `2025-10-10T15:47:41` | ##### NotificationRuleUserVO | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `id` | string | No | User unique identifier | `f6b0449d-b866-4647-b5c5-9ce765eb1184` | | `name` | string | No | Full name of the user | `Anagha Babu` | | `email` | string | No | Email address of the user | `anagha.babu@leegality.com` | | `active` | boolean | No | Indicates whether the user is active (enabled) or inactive (disabled) | `true` | | `enabled` | boolean | No | Indicates whether the user is enabled or disabled | `false` | ### 401 — Unauthorized - Invalid or expired token | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `code` | string | No | Top-level error code | `LE_ERR_SS_401` | | `errors` | array\ | No | List of error details See **ErrorDetail401Unauthorized** below. | — | #### ErrorDetail401Unauthorized | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `message` | string | No | Detailed error message | `Invalid or expired token` | | `path` | string | No | API path that generated the error | `/api/v1/*` | | `code` | string | No | Specific error code | `LE_ERR_SS_303` | ### 500 — Internal server error | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `code` | string | No | Top-level error code | `LE_ERR_SS_500` | | `errors` | array\ | No | List of error details See **ErrorDetailToken500VO** below. | — | #### ErrorDetailToken500VO | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `message` | string | No | Detailed error message | `Internal Server Error` | | `path` | string | No | API path that generated the error | `null` | | `code` | string | No | Specific error code | `null` | ### Sample Response (200) ```json { "code": "string", "message": "string", "data": [ { "id": "a2787f6c-e00c-4bd9-ad34-ed88b8fcf54f", "ruleType": "USER_CREATED", "additionalEmailRecipients": [ "anaghaputhur2018@gmail.com" ], "notifyUsers": [ { "id": "f6b0449d-b866-4647-b5c5-9ce765eb1184", "name": "Anagha Babu", "email": "anagha.babu@leegality.com", "active": true, "enabled": false } ], "enabled": true, "createdAt": "2025-10-10T15:47:41" } ] } ``` --- URL: https://knowledge.leegality.com/sign-station/api/get-o-auth-2-clients # GET /api/v1/oauth2-clients — Get OAuth2 clients for current organization Retrieves all OAuth2 clients for the current user's organization **Authentication:** `X-Auth-Token` header required on every request. ## Request URL ``` GET https://app1.leegality.com/api/api/v1/oauth2-clients ``` **Environments:** - Production: `https://app1.leegality.com/api/api/v1/oauth2-clients` - Sandbox: `https://sandbox.leegality.com/api/api/v1/oauth2-clients` --- ## Responses ### 200 — OAuth2 clients retrieved successfully | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `data` | array\ | No | See **OAuth2ClientVO** below. | `[object Object],[object Object],[object Object]` | #### OAuth2ClientVO | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `id` | string | No | OAuth2 client unique identifier | `8c18cc0b-6251-490e-82ac-dfde6f4735c1` | | `clientId` | string | No | OAuth2 client identifier | `HS1cVm1fLDctBGvAyiu76MIr9PfIqSAl0t2dKHkwWknost8nFh6J5HOiM3SD` | | `clientSecret` | string | No | OAuth2 client secret | `SR2KJGnlodwZWBUNBubPRNYSqCW_TUTD4A8Vhf1t2aM` | | `state` | string | No | OAuth2 client state Allowed: `ACTIVE`, `SUSPENDED`. | `ACTIVE` | | `createdAt` | string | No | The date and time when the OAuth2 client was created | `2025-12-29T15:43:17.528673` | ### 401 — Unauthorized - Invalid or expired token | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `code` | string | No | Top-level error code | `LE_ERR_SS_401` | | `errors` | array\ | No | List of error details See **ErrorDetail401Unauthorized** below. | — | #### ErrorDetail401Unauthorized | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `message` | string | No | Detailed error message | `Invalid or expired token` | | `path` | string | No | API path that generated the error | `/api/v1/*` | | `code` | string | No | Specific error code | `LE_ERR_SS_303` | ### 500 — Internal server error | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `code` | string | No | Top-level error code | `LE_ERR_SS_500` | | `errors` | array\ | No | List of error details See **ErrorDetailToken500VO** below. | — | #### ErrorDetailToken500VO | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `message` | string | No | Detailed error message | `Internal Server Error` | | `path` | string | No | API path that generated the error | `null` | | `code` | string | No | Specific error code | `null` | ### Sample Response (200) ```json { "data": [ { "id": "a3a0e830-66b6-4845-bf1a-91e0966fb97b", "clientId": "FinanceTest", "state": "ACTIVE", "createdAt": "2025-12-22T16:26:03" }, { "id": "e5abdc39-25be-4dc4-abf7-3f500fb3769d", "clientId": "MockDemoForWebsite", "state": "ACTIVE", "createdAt": "2025-12-11T11:02:34" }, { "id": "fb3533ef-f802-411d-a94c-84148daf1fde", "clientId": "TestingProdCredentials", "state": "ACTIVE", "createdAt": "2025-12-09T11:28:46" } ] } ``` --- URL: https://knowledge.leegality.com/sign-station/api/get-password-policy # GET /api/v1/password-policy — Get password policy for current organization Retrieves password policy for the current user's organization **Authentication:** `X-Auth-Token` header required on every request. ## Request URL ``` GET https://app1.leegality.com/api/api/v1/password-policy ``` **Environments:** - Production: `https://app1.leegality.com/api/api/v1/password-policy` - Sandbox: `https://sandbox.leegality.com/api/api/v1/password-policy` --- ## Responses ### 200 — Password policy retrieved successfully | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `data` | PasswordPolicyVO | No | See **PasswordPolicyVO** below. | — | #### PasswordPolicyVO | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `id` | string | No | Password policy unique identifier | `9ef35b27-86c8-4450-8807-317c37a61aae` | | `minimumPasswordLength` | integer | No | Minimum length required for passwords | `6` | | `numbersRequired` | boolean | No | Indicates if numbers are required in passwords | `false` | | `specialCharactersRequired` | boolean | No | Indicates if special characters are required in passwords | `false` | | `uppercaseRequired` | boolean | No | Indicates if uppercase letters are required in passwords | `true` | | `createdAt` | string | No | The date and time when the password policy was created | `2025-10-10T15:58:34` | ### 401 — Unauthorized - Invalid or expired token | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `code` | string | No | Top-level error code | `LE_ERR_SS_401` | | `errors` | array\ | No | List of error details See **ErrorDetail401Unauthorized** below. | — | #### ErrorDetail401Unauthorized | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `message` | string | No | Detailed error message | `Invalid or expired token` | | `path` | string | No | API path that generated the error | `/api/v1/*` | | `code` | string | No | Specific error code | `LE_ERR_SS_303` | ### 404 — Password policy not found | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `code` | string | No | Top-level error code | `LE_ERR_SS_404` | | `errors` | array\ | No | List of error details See **ErrorDetailGetPasswordPolicy404VO** below. | — | #### ErrorDetailGetPasswordPolicy404VO | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `message` | string | No | Detailed error message | `Password policy not found.` | | `path` | string | No | API path that generated the error | `/api/v1/password-policy` | | `code` | string | No | Specific error code | `LE_ERR_SS_203` | ### 500 — Internal server error | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `code` | string | No | Top-level error code | `LE_ERR_SS_500` | | `errors` | array\ | No | List of error details See **ErrorDetailToken500VO** below. | — | #### ErrorDetailToken500VO | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `message` | string | No | Detailed error message | `Internal Server Error` | | `path` | string | No | API path that generated the error | `null` | | `code` | string | No | Specific error code | `null` | ### Sample Response (200) ```json { "data": { "id": "9ef35b27-86c8-4450-8807-317c37a61aae", "minimumPasswordLength": 6, "numbersRequired": false, "specialCharactersRequired": false, "uppercaseRequired": true, "createdAt": "2025-10-10T15:58:34" } } ``` --- URL: https://knowledge.leegality.com/sign-station/api/get-role-by-id # GET /api/v1/roles/{id} — Get role by ID Retrieves role by ID with entitlements for the current user's organization **Authentication:** `X-Auth-Token` header required on every request. ## Request URL ``` GET https://app1.leegality.com/api/api/v1/roles/{id} ``` **Environments:** - Production: `https://app1.leegality.com/api/api/v1/roles/{id}` - Sandbox: `https://sandbox.leegality.com/api/api/v1/roles/{id}` --- ## Parameters | Name | In | Required | Type | Description | Example | |------|----|----------|------|-------------|---------| | `id` | path | Yes | string | Role ID to retrieve information for. | — | --- ## Responses ### 200 — OK | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `data` | RoleVO | No | See **RoleVO** below. | — | #### RoleVO | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `id` | string | No | Role ID. This is configured during the role creation. | `b0af5f43-7f34-4ea4-867a-10115642f354` | | `name` | string | No | Role name. E.g., "Admin", "User" etc. | `Admin` | | `createdAt` | string | No | The date and time when the role was created | `2025-12-15T10:20:30Z` | | `entitlements` | array\ | No | See **EntitlementVO** below. | — | ##### EntitlementVO | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `id` | string | No | Entitlement ID. This is configured in the system and cannot be changed. | `3fa85f64-5717-4562-b3fc-2c963f66afa6` | | `name` | string | No | Entitlement name. E.g., "DOCUMENT_SIGN","USER_MANAGEMENT" | `DOCUMENT_SIGN` | ### 401 — Unauthorized - Invalid or expired token | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `code` | string | No | Top-level error code | `LE_ERR_SS_401` | | `errors` | array\ | No | List of error details See **ErrorDetail401Unauthorized** below. | — | #### ErrorDetail401Unauthorized | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `message` | string | No | Detailed error message | `Invalid or expired token` | | `path` | string | No | API path that generated the error | `/api/v1/*` | | `code` | string | No | Specific error code | `LE_ERR_SS_303` | ### 500 — Internal server error | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `code` | string | No | Top-level error code | `LE_ERR_SS_500` | | `errors` | array\ | No | List of error details See **ErrorDetailToken500VO** below. | — | #### ErrorDetailToken500VO | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `message` | string | No | Detailed error message | `Internal Server Error` | | `path` | string | No | API path that generated the error | `null` | | `code` | string | No | Specific error code | `null` | ### Sample Response (200) ```json { "data": { "id": "b0af5f43-7f34-4ea4-867a-10115642f354", "name": "Admin", "createdAt": "2025-12-15T10:20:30Z", "entitlements": [ { "id": "3fa85f64-5717-4562-b3fc-2c963f66afa6", "name": "DOCUMENT_SIGN" } ] } } ``` --- URL: https://knowledge.leegality.com/sign-station/api/get-roles # GET /api/v1/roles — Get roles for current organization Retrieves all roles for the current user's organization **Authentication:** `X-Auth-Token` header required on every request. ## Request URL ``` GET https://app1.leegality.com/api/api/v1/roles ``` **Environments:** - Production: `https://app1.leegality.com/api/api/v1/roles` - Sandbox: `https://sandbox.leegality.com/api/api/v1/roles` --- ## Responses ### 200 — OK | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `data` | array\ | No | See **RoleVO** below. | — | #### RoleVO | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `id` | string | No | Role ID. This is configured during the role creation. | `b0af5f43-7f34-4ea4-867a-10115642f354` | | `name` | string | No | Role name. E.g., "Admin", "User" etc. | `Admin` | | `createdAt` | string | No | The date and time when the role was created | `2025-12-15T10:20:30Z` | | `entitlements` | array\ | No | See **EntitlementVO** below. | — | ##### EntitlementVO | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `id` | string | No | Entitlement ID. This is configured in the system and cannot be changed. | `3fa85f64-5717-4562-b3fc-2c963f66afa6` | | `name` | string | No | Entitlement name. E.g., "DOCUMENT_SIGN","USER_MANAGEMENT" | `DOCUMENT_SIGN` | ### 401 — Unauthorized - Invalid or expired token | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `code` | string | No | Top-level error code | `LE_ERR_SS_401` | | `errors` | array\ | No | List of error details See **ErrorDetailGetRoles401VO** below. | — | #### ErrorDetailGetRoles401VO | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `message` | string | No | Detailed error message | `Invalid or expired token` | | `path` | string | No | API path that generated the error | `/api/v1/roles` | | `code` | string | No | Specific error code | `LE_ERR_SS_303` | ### 500 — Internal server error | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `code` | string | No | Top-level error code | `LE_ERR_SS_500` | | `errors` | array\ | No | List of error details See **ErrorDetailToken500VO** below. | — | #### ErrorDetailToken500VO | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `message` | string | No | Detailed error message | `Internal Server Error` | | `path` | string | No | API path that generated the error | `null` | | `code` | string | No | Specific error code | `null` | ### Sample Response (200) ```json { "data": [ { "id": "b0af5f43-7f34-4ea4-867a-10115642f354", "name": "Admin", "createdAt": "2025-12-15T10:20:30Z", "entitlements": [ { "id": "3fa85f64-5717-4562-b3fc-2c963f66afa6", "name": "DOCUMENT_SIGN" } ] } ] } ``` --- URL: https://knowledge.leegality.com/sign-station/api/get-settings # GET /api/v1/settings — Get settings for current organization Retrieves settings for the current user's organization **Authentication:** `X-Auth-Token` header required on every request. ## Request URL ``` GET https://app1.leegality.com/api/api/v1/settings ``` **Environments:** - Production: `https://app1.leegality.com/api/api/v1/settings` - Sandbox: `https://sandbox.leegality.com/api/api/v1/settings` --- ## Responses ### 200 — Settings retrieved successfully | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `data` | SettingsVO | No | See **SettingsVO** below. | — | #### SettingsVO | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `id` | string | No | Settings ID. This is configured during the settings creation. | `ed99d2dd-f44e-4278-a3e2-13a1ed2be13c` | | `documentRetentionEnabled` | boolean | No | Indicates if document retention is enabled | `true` | | `documentRetentionPeriod` | integer | No | Document retention period in days | `30` | | `auditLogsRetentionEnabled` | boolean | No | Indicates if audit logs retention is enabled | `true` | | `auditLogsRetentionPeriod` | integer | No | Audit logs retention period in days | `90` | | `auditTrailGenerationEnabled` | boolean | No | Indicates if audit trail generation is enabled | `true` | | `createdAt` | string | No | The date and time when the settings were created | `2025-12-08T15:28:26` | ### 401 — Unauthorized - Invalid or expired token | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `code` | string | No | Top-level error code | `LE_ERR_SS_401` | | `errors` | array\ | No | List of error details See **ErrorDetail401Unauthorized** below. | — | #### ErrorDetail401Unauthorized | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `message` | string | No | Detailed error message | `Invalid or expired token` | | `path` | string | No | API path that generated the error | `/api/v1/*` | | `code` | string | No | Specific error code | `LE_ERR_SS_303` | ### 404 — Settings not found | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `code` | string | No | Top-level error code | `LE_ERR_SS_404` | | `errors` | array\ | No | List of error details See **ErrorDetailGetSettings404VO** below. | — | #### ErrorDetailGetSettings404VO | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `message` | string | No | Detailed error message | `Settings not found for organization 57270dc1-681d-4cd9-9268-` | | `path` | string | No | API path that generated the error | `/api/v1/settings` | | `code` | string | No | Specific error code | `LE_ERR_SS_203` | ### 500 — Internal server error | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `code` | string | No | Top-level error code | `LE_ERR_SS_500` | | `errors` | array\ | No | List of error details See **ErrorDetailToken500VO** below. | — | #### ErrorDetailToken500VO | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `message` | string | No | Detailed error message | `Internal Server Error` | | `path` | string | No | API path that generated the error | `null` | | `code` | string | No | Specific error code | `null` | ### Sample Response (200) ```json { "data": { "id": "ed99d2dd-f44e-4278-a3e2-13a1ed2be13c", "documentRetentionEnabled": true, "documentRetentionPeriod": 30, "auditLogsRetentionEnabled": true, "auditLogsRetentionPeriod": 90, "auditTrailGenerationEnabled": true, "createdAt": "2025-12-08T15:28:26" } } ``` --- URL: https://knowledge.leegality.com/sign-station/api/get-signed-document-s-3-presigned-url # GET /api/v1/documents/{id}/document-download-url — Get signed document S3 presigned URL Get S3 presigned URL for downloading the signed document PDF **Authentication:** `X-Auth-Token` header required on every request. ## Request URL ``` GET https://app1.leegality.com/api/api/v1/documents/{id}/document-download-url ``` **Environments:** - Production: `https://app1.leegality.com/api/api/v1/documents/{id}/document-download-url` - Sandbox: `https://sandbox.leegality.com/api/api/v1/documents/{id}/document-download-url` --- ## Parameters | Name | In | Required | Type | Description | Example | |------|----|----------|------|-------------|---------| | `id` | path | Yes | string | Document ID to retrieve download URL for. | — | --- ## Responses ### 200 — OK | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `code` | string | No | Response code indicating success or failure | — | | `message` | string | No | Response message providing additional information | — | | `data` | string | No | Response data as a string | — | ### 401 — Unauthorized - Invalid or expired token | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `code` | string | No | Top-level error code | `LE_ERR_SS_401` | | `errors` | array\ | No | List of error details See **ErrorDetail401Unauthorized** below. | — | #### ErrorDetail401Unauthorized | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `message` | string | No | Detailed error message | `Invalid or expired token` | | `path` | string | No | API path that generated the error | `/api/v1/*` | | `code` | string | No | Specific error code | `LE_ERR_SS_303` | ### 404 — Document not found | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `code` | string | No | Top-level error code | `LE_ERR_SS_404` | | `errors` | array\ | No | List of error details See **ErrorDetailGetDocumentDownloadUrl404VO** below. | — | #### ErrorDetailGetDocumentDownloadUrl404VO | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `message` | string | No | Detailed error message | `Document does not exist.` | | `path` | string | No | API path that generated the error | `/api/v1/documents/39aca76b-e720-4da8-8a08-234c19fe013c/docum` | | `code` | string | No | Specific error code | `LE_ERR_SS_001` | ### 500 — Internal server error | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `code` | string | No | Top-level error code | `LE_ERR_SS_500` | | `errors` | array\ | No | List of error details See **ErrorDetailToken500VO** below. | — | #### ErrorDetailToken500VO | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `message` | string | No | Detailed error message | `Internal Server Error` | | `path` | string | No | API path that generated the error | `null` | | `code` | string | No | Specific error code | `null` | ### Sample Response (200) ```json { "code": "string", "message": "string", "data": "string" } ``` --- URL: https://knowledge.leegality.com/sign-station/api/get-summary # GET /api/v1/certificates/summary — Get certificate summary Retrieves certificate summary statistics for the current user's organization including total certificates, active certificates (not expired and enabled), and certificates expiring within the specified number of days (defaults to 30 days) **Authentication:** `X-Auth-Token` header required on every request. ## Request URL ``` GET https://app1.leegality.com/api/api/v1/certificates/summary?days={days}&departmentId={departmentId} ``` **Environments:** - Production: `https://app1.leegality.com/api/api/v1/certificates/summary` - Sandbox: `https://sandbox.leegality.com/api/api/v1/certificates/summary` --- ## Parameters | Name | In | Required | Type | Description | Example | |------|----|----------|------|-------------|---------| | `days` | query | No | integer | Number of days to check for expiring certificates (defaults to 30 days) | — | | `departmentId` | query | No | string | | — | --- ## Responses ### 200 — Certificate summary retrieved successfully | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `code` | string | No | Response code indicating success or failure | — | | `message` | string | No | Response message providing additional information | — | | `data` | CertificateSummaryVO | No | See **CertificateSummaryVO** below. | — | #### CertificateSummaryVO | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `totalCertificates` | integer | No | Total number of certificates in the system | — | | `totalActiveCertificates` | integer | No | Total number of active (enabled) certificates | — | | `totalExpiringSoonCertificates` | integer | No | Total number of certificates that are expiring soon | — | ### 400 — Invalid UUID provided | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `code` | string | No | Top-level error code | `LE_ERR_SS_400` | | `errors` | array\ | No | List of error details See **ErrorDetailGetCertificateSummary400VO** below. | — | #### ErrorDetailGetCertificateSummary400VO | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `message` | string | No | Detailed error message | `Invalid UUID provided.` | | `path` | string | No | API path that generated the error | `/api/v1/certificates/summary` | | `code` | string | No | Specific error code | `null` | ### 401 — Unauthorized - Invalid or expired token | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `code` | string | No | Top-level error code | `LE_ERR_SS_401` | | `errors` | array\ | No | List of error details See **ErrorDetailGetCertificateSummary401VO** below. | — | #### ErrorDetailGetCertificateSummary401VO | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `message` | string | No | Detailed error message | `Invalid or expired token` | | `path` | string | No | API path that generated the error | `/api/v1/certificates/summary` | | `code` | string | No | Specific error code | `LE_ERR_SS_303` | ### 500 — Internal server error | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `code` | string | No | Top-level error code | `LE_ERR_SS_500` | | `errors` | array\ | No | List of error details See **ErrorDetailToken500VO** below. | — | #### ErrorDetailToken500VO | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `message` | string | No | Detailed error message | `Internal Server Error` | | `path` | string | No | API path that generated the error | `null` | | `code` | string | No | Specific error code | `null` | ### Sample Response (200) ```json { "code": "string", "message": "string", "data": { "totalCertificates": 0, "totalActiveCertificates": 0, "totalExpiringSoonCertificates": 0 } } ``` --- URL: https://knowledge.leegality.com/sign-station/api/get-user-by-id # GET /api/v1/users/{id} — Get user by ID Retrieves a specific user by ID **Authentication:** `X-Auth-Token` header required on every request. ## Request URL ``` GET https://app1.leegality.com/api/api/v1/users/{id} ``` **Environments:** - Production: `https://app1.leegality.com/api/api/v1/users/{id}` - Sandbox: `https://sandbox.leegality.com/api/api/v1/users/{id}` --- ## Parameters | Name | In | Required | Type | Description | Example | |------|----|----------|------|-------------|---------| | `id` | path | Yes | string | ID of the user to retrieve | — | --- ## Responses ### 200 — User retrieved successfully | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `code` | string | No | Response status code | `LE_SS_001` | | `message` | string | No | Response message | `User retrieved successfully.` | | `data` | UserVO | No | See **UserVO** below. | — | #### UserVO | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `id` | string | No | User unique identifier | `37d14717-5c1a-44fe-9b8f-6d5184b09f06` | | `name` | string | No | Full name of the user | `John Doe` | | `email` | string | No | Email address of the user | `user@example.com` | | `active` | boolean | No | Indicates whether the user is active (enabled) or inactive (disabled) | `true` | | `enabled` | boolean | No | Indicates whether the user is enabled or disabled | `true` | | `createdAt` | string | No | The date and time when the user was created | `2025-12-15T10:20:30Z` | | `departments` | array\ | No | See **DepartmentVO** below. | — | | `roles` | array\ | No | See **RoleVO** below. | — | ##### DepartmentVO | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `id` | string | No | Department unique identifier | `3fa85f64-5717-4562-b3fc-2c963f66afa6` | | `name` | string | No | The department's name (e.g., "Human Resources"). | `Human Resources` | | `enabled` | boolean | No | Indicates whether the department is active or inactive. | `true` | | `createdAt` | string | No | The date and time when the department was created. | `2025-12-15T10:20:30Z` | | `totalUsers` | integer | No | Total number of users in the department. | `25` | ##### RoleVO | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `id` | string | No | Role ID. This is configured during the role creation. | `b0af5f43-7f34-4ea4-867a-10115642f354` | | `name` | string | No | Role name. E.g., "Admin", "User" etc. | `Admin` | | `createdAt` | string | No | The date and time when the role was created | `2025-12-15T10:20:30Z` | | `entitlements` | array\ | No | See **EntitlementVO** below. | — | ###### EntitlementVO | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `id` | string | No | Entitlement ID. This is configured in the system and cannot be changed. | `3fa85f64-5717-4562-b3fc-2c963f66afa6` | | `name` | string | No | Entitlement name. E.g., "DOCUMENT_SIGN","USER_MANAGEMENT" | `DOCUMENT_SIGN` | ### 401 — Unauthorized - Invalid or expired token | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `code` | string | No | Top-level error code | `LE_ERR_SS_401` | | `errors` | array\ | No | List of error details See **ErrorDetail401Unauthorized** below. | — | #### ErrorDetail401Unauthorized | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `message` | string | No | Detailed error message | `Invalid or expired token` | | `path` | string | No | API path that generated the error | `/api/v1/*` | | `code` | string | No | Specific error code | `LE_ERR_SS_303` | ### 404 — User not found | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `code` | string | No | Top-level error code | `LE_ERR_SS_404` | | `errors` | array\ | No | List of error details See **ErrorDetailGetUserById404VO** below. | — | #### ErrorDetailGetUserById404VO | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `message` | string | No | Detailed error message | `f6b0449d-b866-4647-b5c5-9ce765eb1183 does not exist.` | | `path` | string | No | API path that generated the error | `/api/v1/users/f6b0449d-b866-4647-b5c5-9ce765eb1183` | | `code` | string | No | Specific error code | `LE_ERR_SS_001` | ### 500 — Internal server error | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `code` | string | No | Top-level error code | `LE_ERR_SS_500` | | `errors` | array\ | No | List of error details See **ErrorDetailToken500VO** below. | — | #### ErrorDetailToken500VO | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `message` | string | No | Detailed error message | `Internal Server Error` | | `path` | string | No | API path that generated the error | `null` | | `code` | string | No | Specific error code | `null` | ### Sample Response (200) ```json { "code": "LE_SS_001", "message": "User retrieved successfully.", "data": { "id": "37d14717-5c1a-44fe-9b8f-6d5184b09f06", "name": "John Doe", "email": "user@example.com", "active": true, "enabled": true, "createdAt": "2025-12-15T10:20:30Z", "departments": [ { "id": "3fa85f64-5717-4562-b3fc-2c963f66afa6", "name": "Human Resources", "enabled": true, "createdAt": "2025-12-15T10:20:30Z", "totalUsers": 25 } ], "roles": [ { "id": "b0af5f43-7f34-4ea4-867a-10115642f354", "name": "Admin", "createdAt": "2025-12-15T10:20:30Z", "entitlements": [ { "id": "3fa85f64-5717-4562-b3fc-2c963f66afa6", "name": "DOCUMENT_SIGN" } ] } ] } } ``` --- URL: https://knowledge.leegality.com/sign-station/api/install-license # POST /api/v1/licenses — Upload and install a license Use this API to Upload a license file and install it into the SignStation system. **Authentication:** `X-Auth-Token` header required on every request. ## Request URL ``` POST https://app1.leegality.com/api/api/v1/licenses ``` **Environments:** - Production: `https://app1.leegality.com/api/api/v1/licenses` - Sandbox: `https://sandbox.leegality.com/api/api/v1/licenses` --- ## Request Body **Content-Type:** `application/json` | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `file` | string | Yes | License upload data with file. The license file must contain JWT (JSON Web Token) formatted data. You can use any file extension you prefer including .jwt, .lic, or .txt. | `TestLicense.lic` | ### Sample Request ```json { "file": "TestLicense.lic" } ``` --- ## Responses ### 200 — OK | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `code` | string | No | Response code indicating success or failure of the license upload. | — | | `message` | string | No | A message providing additional information about the license upload. | — | | `data` | LicenseVO | No | See **LicenseVO** below. | — | #### LicenseVO | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `licenseId` | string | No | Unique identifier for the license. | — | | `customerId` | string | No | Unique identifier for the customer associated with the license. | — | | `expiry` | string | No | Expiration date of the license in ISO 8601 format. | — | | `status` | string | No | Current status of the license (e.g., ACTIVE, EXPIRED). | — | | `licenseType` | string | No | Type of the license (e.g., ACTIVE, TRIAL) | — | | `createdAt` | string | No | The date and time when the license was created. | — | | `updatedAt` | string | No | The date and time when the license was last updated. | — | | `enabled` | boolean | No | Indicates whether the license is currently enabled or disabled. | — | ### 400 — License validation failed | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `code` | string | No | Top-level error code | `LE_ERR_SS_400` | | `errors` | array\ | No | List of error details See **ErrorDetailLicense400VO** below. | — | #### ErrorDetailLicense400VO | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `message` | string | No | Detailed error message | `License validation failed for the request.` | | `path` | string | No | API path that generated the error | `/api/v1/licenses` | | `code` | string | No | Specific error code | `LE_ERR_SS_008` | ### 401 — Authentication failed | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `code` | string | No | Top-level error code | `LE_ERR_SS_401` | | `errors` | array\ | No | List of error details See **ErrorDetailLicense401VO** below. | — | #### ErrorDetailLicense401VO | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `message` | string | No | Detailed error message | `Authentication failed. Please check your credentials.` | | `path` | string | No | API path that generated the error | `/api/v1/licenses` | | `code` | string | No | Specific error code | `LE_ERR_SS_301` | ### 500 — Internal server error | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `code` | string | No | Top-level error code | `LE_ERR_SS_500` | | `errors` | array\ | No | List of error details See **ErrorDetailToken500VO** below. | — | #### ErrorDetailToken500VO | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `message` | string | No | Detailed error message | `Internal Server Error` | | `path` | string | No | API path that generated the error | `null` | | `code` | string | No | Specific error code | `null` | ### Sample Response (200) ```json { "code": "string", "message": "string", "data": { "licenseId": "string", "customerId": "string", "expiry": "2024-01-01", "status": "string", "licenseType": "string", "createdAt": "string", "updatedAt": "string", "enabled": false } } ``` --- # License Management URL: https://knowledge.leegality.com/sign-station/api/license-management.tag > License Management The License Management API allows administrators to install license files, view current status, and track usage statistics through a set of dedicated endpoints. To activate your system, you must upload a license file containing a cryptographically signed JSON Web Token (JWT). While the file must contain this specific string, you can use any file extension you prefer—such as .lic, .txt, or .jwt—as the system reads the internal data rather than the filename. For the dashboard walkthrough, see [Create a New License](https://knowledge.leegality.com/sign-station/license-manager/create-license) and [Viewing & Managing License Status](https://knowledge.leegality.com/sign-station/license-manager/viewing-managing-license-status). ```mdx-code-block ``` --- URL: https://knowledge.leegality.com/sign-station/api/login # POST /api/v1/auth/login — User Login This API Authenticates a user using username (email) and password credentials. Upon successful authentication, returns a JWT access token along with complete user profile including roles, permissions (authorities), departments, and organization information. The token must be included in subsequent API requests as a Bearer token in the Authorization header. No additional permissions are required to access this endpoint. **Authentication:** `X-Auth-Token` header required on every request. ## Request URL ``` POST https://app1.leegality.com/api/api/v1/auth/login ``` **Environments:** - Production: `https://app1.leegality.com/api/api/v1/auth/login` - Sandbox: `https://sandbox.leegality.com/api/api/v1/auth/login` --- ## Request Body **Content-Type:** `application/json` | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `username` | string | Yes | The username of the user trying to log in. | `admin@leegality.com` | | `password` | string | Yes | The password of the user trying to log in. | `Strong@Passw0rd` | ### Sample Request ```json { "username": "admin@leegality.com", "password": "Strong@Passw0rd" } ``` --- ## Responses ### 200 — OK | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `code` | string | No | Response code indicating success or failure of the login request. | `LE_SS_301` | | `message` | string | No | A message providing additional information about the login request. | `Authentication successful.` | | `data` | LoginUserVO | No | See **LoginUserVO** below. | — | #### LoginUserVO | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `username` | string | No | The username of the logged-in user. | `admin@leegality.com` | | `name` | string | No | The full name of the logged-in user. | `TestUser123` | | `organization` | OrganizationVO | No | See **OrganizationVO** below. | — | | `accessToken` | string | No | JWT token to use in Authorization header as `Bearer | `eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiJhZG1pbkBsZWVnYWxpdHkuY29tIiw` | | `tokenType` | string | No | Type of the token, typically "Bearer" for JWT tokens. | `Bearer` | | `expiresIn` | integer | No | Expiration time of the token in seconds. | `3600` | | `authorities` | array\ | No | List of permissions/entitlements assigned through user's roles. | `writeCertificate,readNotificationRule,updateOAuth2Client,sea` | | `roles` | array\ | No | See **RoleVO** below. | — | | `departments` | array\ | No | See **DepartmentVO** below. | — | ##### OrganizationVO | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `id` | string | No | Organization unique identifier. | — | | `name` | string | No | Organization name. | `TestOrganization` | | `createdAt` | string | No | The date and time when the organization was created. | — | | `updatedAt` | string | No | The date and time when the organization was last updated. | — | | `enabled` | boolean | No | Indicates whether the organization is active or inactive. | — | ##### RoleVO | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `id` | string | No | Role ID. This is configured during the role creation. | `b0af5f43-7f34-4ea4-867a-10115642f354` | | `name` | string | No | Role name. E.g., "Admin", "User" etc. | `Admin` | | `createdAt` | string | No | The date and time when the role was created | `2025-12-15T10:20:30Z` | | `entitlements` | array\ | No | See **EntitlementVO** below. | — | ###### EntitlementVO | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `id` | string | No | Entitlement ID. This is configured in the system and cannot be changed. | `3fa85f64-5717-4562-b3fc-2c963f66afa6` | | `name` | string | No | Entitlement name. E.g., "DOCUMENT_SIGN","USER_MANAGEMENT" | `DOCUMENT_SIGN` | ##### DepartmentVO | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `id` | string | No | Department unique identifier | `3fa85f64-5717-4562-b3fc-2c963f66afa6` | | `name` | string | No | The department's name (e.g., "Human Resources"). | `Human Resources` | | `enabled` | boolean | No | Indicates whether the department is active or inactive. | `true` | | `createdAt` | string | No | The date and time when the department was created. | `2025-12-15T10:20:30Z` | | `totalUsers` | integer | No | Total number of users in the department. | `25` | ### 401 — Authentication failed - Invalid username or password | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `code` | string | No | Top-level error code | `LE_ERR_SS_401` | | `errors` | array\ | No | List of error details See **ErrorDetailLogin401VO** below. | — | #### ErrorDetailLogin401VO | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `message` | string | No | Detailed error message | `Authentication failed. Invalid username or password.` | | `path` | string | No | API path that generated the error | `/api/v1/auth/login` | | `code` | string | No | Specific error code | `LE_ERR_SS_301` | ### 500 — Internal server error | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `code` | string | No | Top-level error code | `LE_ERR_SS_500` | | `errors` | array\ | No | List of error details See **ErrorDetailToken500VO** below. | — | #### ErrorDetailToken500VO | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `message` | string | No | Detailed error message | `Internal Server Error` | | `path` | string | No | API path that generated the error | `null` | | `code` | string | No | Specific error code | `null` | ### Sample Response (200) ```json { "code": "LE_SS_301", "message": "Authentication successful.", "data": { "username": "admin@leegality.com", "name": "TestUser123", "organization": { "id": "string", "name": "TestOrganization", "createdAt": "string", "updatedAt": "string", "enabled": false }, "accessToken": "eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiJhZG1pbkBsZWVnYWxpdHkuY29tIiwiaWF0IjoxNzY1NTI0NzA1LCJleHAiOjE3NjU1MjgzMDV9.v0dYZq57hlao2eHQY9l4bUxW6JnL3EUIpm21clU45F4", "tokenType": "Bearer", "expiresIn": 3600, "authorities": [ "writeCertificate", "readNotificationRule", "updateOAuth2Client", "searchDocument", "readEntitlement", "writeCertificateNotificationConfig", "deletePasswordPolicy", "writeDepartment", "deleteSettings", "readUser", "writeRoleEntitlement", "readDocument", "admin_deleteUser", "writeNotificationConfig", "readLicense", "writeSettings", "writeOrganization", "writeRole", "writeEmail", "deleteCertificateNotificationConfig", "deleteCertificate", "readSettings", "readOAuth2Client", "deleteRoleEntitlement", "readOrganization", "readCertificateNotificationConfig", "readRole", "readRoleEntitlement", "writeUser", "readPasswordPolicy", "readCertificate", "installLicense", "deleteNotificationConfig", "deleteRole", "readDepartment", "readAuditLog", "writeNotificationRule", "readNotificationConfig", "writePasswordPolicy", "admin_writeUser", "deleteDepartment", "deleteOAuth2Client", "signDocument", "writeOAuth2Client" ], "roles": [ { "id": "b0af5f43-7f34-4ea4-867a-10115642f354", "name": "Admin", "createdAt": "2025-12-15T10:20:30Z", "entitlements": [ { "id": "3fa85f64-5717-4562-b3fc-2c963f66afa6", "name": "DOCUMENT_SIGN" } ] } ], "departments": [ { "id": "3fa85f64-5717-4562-b3fc-2c963f66afa6", "name": "Human Resources", "enabled": true, "createdAt": "2025-12-15T10:20:30Z", "totalUsers": 25 } ] } } ``` --- # Notification Config Controller URL: https://knowledge.leegality.com/sign-station/api/notification-config-controller.tag > Notification Config Controller The Notification Configuration API provides endpoints for managing notification settings within the Sign Station platform. This configuration allows organizations to define global notification preferences, such as email server settings, default sender information, and other notification-related parameters. For the dashboard workflow, see [Notifications](https://knowledge.leegality.com/sign-station/notifications). ```mdx-code-block ``` --- # Notification Rule Controller URL: https://knowledge.leegality.com/sign-station/api/notification-rule-controller.tag > Notification Rule Controller The Notification Rules API provides endpoints to configure and manage notification rules for various system events within the Sign Station platform. These rules determine which events trigger email notifications, who receives them, and whether the notifications are enabled for your organization. For the dashboard workflow, see [Notifications](https://knowledge.leegality.com/sign-station/notifications). ```mdx-code-block ``` --- # OAuth2 Client Controller URL: https://knowledge.leegality.com/sign-station/api/o-auth-2-client-controller.tag > OAuth2 Client Controller The OAuth2 Client Management API provides endpoints for managing OAuth2 clients within the SignStation platform. OAuth2 clients are applications or services that can authenticate and interact with the SignStation API on behalf of users or organizations. This API allows administrators to create, retrieve, update, and delete OAuth2 clients, as well as manage their credentials and permissions. To create and manage client credentials from the dashboard, see [API Credentials](https://knowledge.leegality.com/sign-station/api-credentials). ```mdx-code-block ``` --- URL: https://knowledge.leegality.com/sign-station/api/partial-update # PATCH /api/v1/users/me — Update current user Updates the authenticated user **Authentication:** `X-Auth-Token` header required on every request. ## Request URL ``` PATCH https://app1.leegality.com/api/api/v1/users/me ``` **Environments:** - Production: `https://app1.leegality.com/api/api/v1/users/me` - Sandbox: `https://sandbox.leegality.com/api/api/v1/users/me` --- ## Request Body **Content-Type:** `application/json` | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `name` | string | No | Full name of the user | — | ### Sample Request ```json { "name": "string" } ``` --- ## Responses ### 200 — User updated successfully | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `code` | string | No | Response status code | `LE_SS_001` | | `message` | string | No | Response message | `User retrieved successfully.` | | `data` | UserVO | No | See **UserVO** below. | — | #### UserVO | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `id` | string | No | User unique identifier | `37d14717-5c1a-44fe-9b8f-6d5184b09f06` | | `name` | string | No | Full name of the user | `John Doe` | | `email` | string | No | Email address of the user | `user@example.com` | | `active` | boolean | No | Indicates whether the user is active (enabled) or inactive (disabled) | `true` | | `enabled` | boolean | No | Indicates whether the user is enabled or disabled | `true` | | `createdAt` | string | No | The date and time when the user was created | `2025-12-15T10:20:30Z` | | `departments` | array\ | No | See **DepartmentVO** below. | — | | `roles` | array\ | No | See **RoleVO** below. | — | ##### DepartmentVO | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `id` | string | No | Department unique identifier | `3fa85f64-5717-4562-b3fc-2c963f66afa6` | | `name` | string | No | The department's name (e.g., "Human Resources"). | `Human Resources` | | `enabled` | boolean | No | Indicates whether the department is active or inactive. | `true` | | `createdAt` | string | No | The date and time when the department was created. | `2025-12-15T10:20:30Z` | | `totalUsers` | integer | No | Total number of users in the department. | `25` | ##### RoleVO | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `id` | string | No | Role ID. This is configured during the role creation. | `b0af5f43-7f34-4ea4-867a-10115642f354` | | `name` | string | No | Role name. E.g., "Admin", "User" etc. | `Admin` | | `createdAt` | string | No | The date and time when the role was created | `2025-12-15T10:20:30Z` | | `entitlements` | array\ | No | See **EntitlementVO** below. | — | ###### EntitlementVO | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `id` | string | No | Entitlement ID. This is configured in the system and cannot be changed. | `3fa85f64-5717-4562-b3fc-2c963f66afa6` | | `name` | string | No | Entitlement name. E.g., "DOCUMENT_SIGN","USER_MANAGEMENT" | `DOCUMENT_SIGN` | ### 400 — Invalid request data | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `code` | string | No | Top-level error code | `LE_ERR_SS_400` | | `errors` | array\ | No | List of error details See **ErrorDetailPartialUpdate400VO** below. | — | #### ErrorDetailPartialUpdate400VO | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `message` | string | No | Detailed error message | `Invalid value for field [name], Name must be between 2 and 1` | | `path` | string | No | API path that generated the error | `/api/v1/users/me` | ### 401 — Unauthorized - Invalid or expired token | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `code` | string | No | Top-level error code | `LE_ERR_SS_401` | | `errors` | array\ | No | List of error details See **ErrorDetail401Unauthorized** below. | — | #### ErrorDetail401Unauthorized | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `message` | string | No | Detailed error message | `Invalid or expired token` | | `path` | string | No | API path that generated the error | `/api/v1/*` | | `code` | string | No | Specific error code | `LE_ERR_SS_303` | ### 500 — Internal server error | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `code` | string | No | Top-level error code | `LE_ERR_SS_500` | | `errors` | array\ | No | List of error details See **ErrorDetailToken500VO** below. | — | #### ErrorDetailToken500VO | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `message` | string | No | Detailed error message | `Internal Server Error` | | `path` | string | No | API path that generated the error | `null` | | `code` | string | No | Specific error code | `null` | ### Sample Response (200) ```json { "code": "LE_SS_001", "message": "User retrieved successfully.", "data": { "id": "37d14717-5c1a-44fe-9b8f-6d5184b09f06", "name": "John Doe", "email": "user@example.com", "active": true, "enabled": true, "createdAt": "2025-12-15T10:20:30Z", "departments": [ { "id": "3fa85f64-5717-4562-b3fc-2c963f66afa6", "name": "Human Resources", "enabled": true, "createdAt": "2025-12-15T10:20:30Z", "totalUsers": 25 } ], "roles": [ { "id": "b0af5f43-7f34-4ea4-867a-10115642f354", "name": "Admin", "createdAt": "2025-12-15T10:20:30Z", "entitlements": [ { "id": "3fa85f64-5717-4562-b3fc-2c963f66afa6", "name": "DOCUMENT_SIGN" } ] } ] } } ``` --- # Password Policy Controller URL: https://knowledge.leegality.com/sign-station/api/password-policy-controller.tag > Password Policy Controller The Password Policy API enables organizations to configure and enforce password strength requirements for their users. Administrators can define rules such as minimum password length, requirements for numbers, special characters, and uppercase letters. Each organization has one password policy that applies to all users within that organization. The API provides endpoints to create, retrieve, and update password policy configurations. Password policies are automatically enforced during user creation and password change operations. For the dashboard configuration, see [System Settings](https://knowledge.leegality.com/sign-station/system-settings). ```mdx-code-block ``` --- URL: https://knowledge.leegality.com/sign-station/api/reset-password # PUT /api/v1/users/{id}/reset-password — Reset password for user Resets the password for the specified user. The password must comply with the organization's password policy. Returns the reset password. **Authentication:** `X-Auth-Token` header required on every request. ## Request URL ``` PUT https://app1.leegality.com/api/api/v1/users/{id}/reset-password ``` **Environments:** - Production: `https://app1.leegality.com/api/api/v1/users/{id}/reset-password` - Sandbox: `https://sandbox.leegality.com/api/api/v1/users/{id}/reset-password` --- ## Parameters | Name | In | Required | Type | Description | Example | |------|----|----------|------|-------------|---------| | `id` | path | Yes | string | ID of the user whose password is to be reset | — | --- ## Request Body **Content-Type:** `application/json` Password data | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `password` | string | Yes | The new password to set for the user | — | ### Sample Request ```json { "password": "string" } ``` --- ## Responses ### 200 — Password reset successfully | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `code` | string | No | Response status code | `LE_SS_702` | | `message` | string | No | Response message | `Password changed successfully.` | ### 400 — Invalid request data | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `code` | string | No | Top-level error code | `LE_ERR_SS_400` | | `errors` | array\ | No | List of error details See **ErrorDetailResetPassword400VO** below. | — | #### ErrorDetailResetPassword400VO | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `message` | string | No | Detailed error message | `Invalid value for field [password], Password cannot be blank` | | `path` | string | No | API path that generated the error | `/api/v1/users/f6b0449d-b866-4647-b5c5-9ce765eb1184/reset-pas` | ### 401 — Unauthorized - Invalid or expired token | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `code` | string | No | Top-level error code | `LE_ERR_SS_401` | | `errors` | array\ | No | List of error details See **ErrorDetail401Unauthorized** below. | — | #### ErrorDetail401Unauthorized | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `message` | string | No | Detailed error message | `Invalid or expired token` | | `path` | string | No | API path that generated the error | `/api/v1/*` | | `code` | string | No | Specific error code | `LE_ERR_SS_303` | ### 403 — Access denied | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `code` | string | No | Top-level error code | `LE_ERR_SS_403` | | `errors` | array\ | No | List of error details See **ErrorDetailResetPassword403VO** below. | — | #### ErrorDetailResetPassword403VO | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `message` | string | No | Detailed error message | `Access denied for the requested operation.` | | `path` | string | No | API path that generated the error | `/api/v1/users/{id}/reset-password` | | `code` | string | No | Specific error code | `LE_ERR_SS_007` | ### 404 — User not found | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `code` | string | No | Top-level error code | `LE_ERR_SS_404` | | `errors` | array\ | No | List of error details See **ErrorDetailResetPassword404VO** below. | — | #### ErrorDetailResetPassword404VO | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `message` | string | No | Detailed error message | `f6b0449d-b866-4647-b5c5-9ce765eb1183 does not exist.` | | `path` | string | No | API path that generated the error | `/api/v1/users/f6b0449d-b866-4647-b5c5-9ce765eb1183` | | `code` | string | No | Specific error code | `LE_ERR_SS_001` | ### 500 — Internal server error | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `code` | string | No | Top-level error code | `LE_ERR_SS_500` | | `errors` | array\ | No | List of error details See **ErrorDetailToken500VO** below. | — | #### ErrorDetailToken500VO | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `message` | string | No | Detailed error message | `Internal Server Error` | | `path` | string | No | API path that generated the error | `null` | | `code` | string | No | Specific error code | `null` | ### Sample Response (200) ```json { "code": "LE_SS_702", "message": "Password changed successfully." } ``` --- # Role Controller URL: https://knowledge.leegality.com/sign-station/api/role-controller.tag > Role Controller The Role Management API enables administrators to create, manage, and configure user roles within the SignStation platform. Roles serve as containers for entitlements (permissions) and can be assigned to users to grant specific access rights across the system. This API supports Role-Based Access Control (RBAC) implementation, allowing organizations to define granular permission structures. For the dashboard walkthrough, see [Role Management](https://knowledge.leegality.com/sign-station/user-management/role-management). ```mdx-code-block ``` --- URL: https://knowledge.leegality.com/sign-station/api/search-audit-logs # POST /api/v1/audit-logs/search — Search audit logs Search audit logs for the current user's organization using advanced search criteria **Authentication:** `X-Auth-Token` header required on every request. ## Request URL ``` POST https://app1.leegality.com/api/api/v1/audit-logs/search ``` **Environments:** - Production: `https://app1.leegality.com/api/api/v1/audit-logs/search` - Sandbox: `https://sandbox.leegality.com/api/api/v1/audit-logs/search` --- ## Request Body **Content-Type:** `application/json` Search criteria including filters, sorting, and pagination | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `filter` | Filter Request Schema | No | Filter Request Schema represents the group of parameters which filters the records. See **Filter Request Schema** below. | — | | `sort` | array\ | No | Sort Request Schema list represents the group of parameters which sorts the records. See **Sort Request Schema** below. | — | | `limit` | integer | No | Limit represents the maximum number of records to be displayed per page. | `10` | | `page` | integer | No | Page represents the current page index to display records starting from 0. | `0` | #### Filter Request Schema Filter Request Schema represents the group of parameters which filters the records. | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `field` | string | No | Field represents the field on which operator would be applied. | `Audit Trail (2).pdf` | | `operator` | string | Yes | Operator represents the condition which would be applied for searching. Allowed: `EQ`, `NEQ`, `IN`, `NOT_IN`, `IS_NULL`, `NOT_NULL`, `AND`, `OR`, `GT`, `LT`, `GTE`, `LTE`, `BETWEEN`, `LIKE`. | — | | `value` | array\ | No | Value represents the value of the field which would be searched within the records. | — | | `filters` | array\ | No | List of filters represents filters to be applied if the operator used is AND or OR | — | #### Sort Request Schema Sort Request Schema list represents the group of parameters which sorts the records. | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `field` | string | Yes | Field represents the field on which sorting would be applied. | `createdAt` | | `direction` | string | No | Direction represents the order in which sorting would be applied. Allowed: `ASC`, `DESC`. | — | ### Sample Request ```json { "filter": { "field": "Audit Trail (2).pdf", "operator": "EQ", "value": [ {} ], "filters": [ "value" ] }, "sort": [ { "field": "createdAt", "direction": "ASC" } ], "limit": 10, "page": 0 } ``` --- ## Responses ### 200 — Audit logs found successfully Search response for audit logs with pagination | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `data` | array\ | No | See **AuditLogSearchItemVO** below. | — | | `pagination` | Pagination Response Schema | No | See **Pagination Response Schema** below. | — | #### AuditLogSearchItemVO Audit log item in search results | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `id` | string | No | Audit log unique identifier | `00fdf214-83fe-4070-ba93-32c03c6dfd24` | | `details` | string | No | Detailed description of the audit log event | `Department Testing Department added successfully by TestUser` | | `action` | string | No | Type of action performed | `DEPARTMENT_ADDED` | | `userId` | string | No | User ID who performed the action | `e6823fbf-7af8-4e73-8bdb-429a11671871` | | `username` | string | No | Username of the user who performed the action | `TestUser123` | | `sourceIp` | string | No | Source IP address from where the action was performed | `10.10.4.227` | | `userAgent` | string | No | User agent string of the client | `Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/` | | `logTime` | string | No | Time when the log was created | `2025-12-09T11:26:19` | | `enabled` | boolean | No | Whether the audit log is enabled | `true` | | `createdAt` | string | No | Audit log creation date and time | `2025-12-09T11:26:19` | | `updatedAt` | string | No | Audit log last update date and time | `2025-12-09T11:26:19` | #### Pagination Response Schema | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `limit` | integer | No | Limit represents the maximum number of records to be displayed per page. | `10` | | `page` | integer | No | Page represents the current page index to display records starting from 0. | `0` | | `total` | integer | No | Total represents the total number of records fetched. | `50` | ### 400 — Invalid search criteria | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `code` | string | No | Top-level error code | `LE_ERR_SS_400` | | `errors` | array\ | No | List of error details See **ErrorDetailSearchAuditLogs400VO** below. | — | #### ErrorDetailSearchAuditLogs400VO | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `message` | string | No | Detailed error message | `Invalid value for field [filters], must not be null` | | `path` | string | No | API path that generated the error | `/api/v1/audit-logs/search` | | `code` | string | No | Specific error code | `null` | ### 401 — Unauthorized - Invalid or expired token | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `code` | string | No | Top-level error code | `LE_ERR_SS_401` | | `errors` | array\ | No | List of error details See **ErrorDetail401Unauthorized** below. | — | #### ErrorDetail401Unauthorized | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `message` | string | No | Detailed error message | `Invalid or expired token` | | `path` | string | No | API path that generated the error | `/api/v1/*` | | `code` | string | No | Specific error code | `LE_ERR_SS_303` | ### 500 — Internal server error | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `code` | string | No | Top-level error code | `LE_ERR_SS_500` | | `errors` | array\ | No | List of error details See **ErrorDetailToken500VO** below. | — | #### ErrorDetailToken500VO | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `message` | string | No | Detailed error message | `Internal Server Error` | | `path` | string | No | API path that generated the error | `null` | | `code` | string | No | Specific error code | `null` | ### Sample Response (200) ```json { "data": [ { "id": "00fdf214-83fe-4070-ba93-32c03c6dfd24", "details": "Department Testing Department added successfully by TestUser123.", "action": "DEPARTMENT_ADDED", "userId": "e6823fbf-7af8-4e73-8bdb-429a11671871", "username": "TestUser123", "sourceIp": "10.10.4.227", "userAgent": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/123.0.0.0 Safari/537.36", "logTime": "2025-12-09T11:26:19", "enabled": true, "createdAt": "2025-12-09T11:26:19", "updatedAt": "2025-12-09T11:26:19" } ], "pagination": { "limit": 10, "page": 0, "total": 50 } } ``` --- URL: https://knowledge.leegality.com/sign-station/api/search-certificates # POST /api/v1/certificates/search — Search certificates Search certificates for the current user's organization using advanced search criteria **Authentication:** `X-Auth-Token` header required on every request. ## Request URL ``` POST https://app1.leegality.com/api/api/v1/certificates/search ``` **Environments:** - Production: `https://app1.leegality.com/api/api/v1/certificates/search` - Sandbox: `https://sandbox.leegality.com/api/api/v1/certificates/search` --- ## Request Body **Content-Type:** `application/json` Search criteria including filters, sorting, and pagination | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `filter` | Filter Request Schema | No | Filter Request Schema represents the group of parameters which filters the records. See **Filter Request Schema** below. | — | | `sort` | array\ | No | Sort Request Schema list represents the group of parameters which sorts the records. See **Sort Request Schema** below. | — | | `limit` | integer | No | Limit represents the maximum number of records to be displayed per page. | `10` | | `page` | integer | No | Page represents the current page index to display records starting from 0. | `0` | #### Filter Request Schema Filter Request Schema represents the group of parameters which filters the records. | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `field` | string | No | Field represents the field on which operator would be applied. | `Audit Trail (2).pdf` | | `operator` | string | Yes | Operator represents the condition which would be applied for searching. Allowed: `EQ`, `NEQ`, `IN`, `NOT_IN`, `IS_NULL`, `NOT_NULL`, `AND`, `OR`, `GT`, `LT`, `GTE`, `LTE`, `BETWEEN`, `LIKE`. | — | | `value` | array\ | No | Value represents the value of the field which would be searched within the records. | — | | `filters` | array\ | No | List of filters represents filters to be applied if the operator used is AND or OR | — | #### Sort Request Schema Sort Request Schema list represents the group of parameters which sorts the records. | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `field` | string | Yes | Field represents the field on which sorting would be applied. | `createdAt` | | `direction` | string | No | Direction represents the order in which sorting would be applied. Allowed: `ASC`, `DESC`. | — | ### Sample Request ```json { "filter": { "field": "Audit Trail (2).pdf", "operator": "EQ", "value": [ {} ], "filters": [ "value" ] }, "sort": [ { "field": "createdAt", "direction": "ASC" } ], "limit": 10, "page": 0 } ``` --- ## Responses ### 200 — Certificates found successfully | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `data` | array\ | No | See **CertificateSearchItemVO** below. | — | | `pagination` | Pagination Response Schema | No | See **Pagination Response Schema** below. | — | #### CertificateSearchItemVO Certificate item in search results | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `id` | string | No | Certificate unique identifier | `37d14717-5c1a-44fe-9b8f-6d5184b09f06` | | `name` | string | No | Certificate name | `*.leegality.com` | | `certificateType` | string | No | Type of certificate | `PKCS12_PFX` | | `expiry` | string | No | Certificate expiry date and time | `2026-09-12T12:53:04` | | `createdAt` | string | No | Certificate creation date and time | `2025-10-14T20:38:06` | | `departmentId` | string | No | Department unique identifier | `a2906183-8b02-4aa3-9d27-e5ba3efef203` | | `departmentName` | string | No | Department name | `HR` | #### Pagination Response Schema | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `limit` | integer | No | Limit represents the maximum number of records to be displayed per page. | `10` | | `page` | integer | No | Page represents the current page index to display records starting from 0. | `0` | | `total` | integer | No | Total represents the total number of records fetched. | `50` | ### 400 — Invalid search criteria | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `code` | string | No | Top-level error code | `LE_ERR_SS_400` | | `errors` | array\ | No | List of error details See **ErrorDetailSearchCertificates400VO** below. | — | #### ErrorDetailSearchCertificates400VO | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `message` | string | No | Detailed error message | `Invalid value for field [filter.filters], [field, filters]` | | `path` | string | No | API path that generated the error | `/api/v1/certificates/search` | ### 401 — Unauthorized - Invalid or expired token | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `code` | string | No | Top-level error code | `LE_ERR_SS_401` | | `errors` | array\ | No | List of error details See **ErrorDetailSearchCertificates401VO** below. | — | #### ErrorDetailSearchCertificates401VO | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `message` | string | No | Detailed error message | `Invalid or expired token` | | `path` | string | No | API path that generated the error | `/api/v1/certificates/search` | | `code` | string | No | Specific error code | `LE_ERR_SS_303` | ### 500 — Internal server error | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `code` | string | No | Top-level error code | `LE_ERR_SS_500` | | `errors` | array\ | No | List of error details See **ErrorDetailToken500VO** below. | — | #### ErrorDetailToken500VO | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `message` | string | No | Detailed error message | `Internal Server Error` | | `path` | string | No | API path that generated the error | `null` | | `code` | string | No | Specific error code | `null` | ### Sample Response (200) ```json { "data": [ { "id": "37d14717-5c1a-44fe-9b8f-6d5184b09f06", "name": "*.leegality.com", "certificateType": "PKCS12_PFX", "expiry": "2026-09-12T12:53:04", "createdAt": "2025-10-14T20:38:06", "departmentId": "a2906183-8b02-4aa3-9d27-e5ba3efef203", "departmentName": "HR" } ], "pagination": { "limit": 10, "page": 0, "total": 50 } } ``` --- URL: https://knowledge.leegality.com/sign-station/api/search-departments # POST /api/v1/departments/search — Search departments Search departments for the current user's organization using the API. Advanced search criteria can be specified in the request body. **Authentication:** `X-Auth-Token` header required on every request. ## Request URL ``` POST https://app1.leegality.com/api/api/v1/departments/search ``` **Environments:** - Production: `https://app1.leegality.com/api/api/v1/departments/search` - Sandbox: `https://sandbox.leegality.com/api/api/v1/departments/search` --- ## Request Body **Content-Type:** `application/json` Search criteria including filters, sorting, and pagination | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `filter` | Filter Request Schema | No | Filter Request Schema represents the group of parameters which filters the records. See **Filter Request Schema** below. | — | | `sort` | array\ | No | Sort Request Schema list represents the group of parameters which sorts the records. See **Sort Request Schema** below. | — | | `limit` | integer | No | Limit represents the maximum number of records to be displayed per page. | `10` | | `page` | integer | No | Page represents the current page index to display records starting from 0. | `0` | #### Filter Request Schema Filter Request Schema represents the group of parameters which filters the records. | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `field` | string | No | Field represents the field on which operator would be applied. | `Audit Trail (2).pdf` | | `operator` | string | Yes | Operator represents the condition which would be applied for searching. Allowed: `EQ`, `NEQ`, `IN`, `NOT_IN`, `IS_NULL`, `NOT_NULL`, `AND`, `OR`, `GT`, `LT`, `GTE`, `LTE`, `BETWEEN`, `LIKE`. | — | | `value` | array\ | No | Value represents the value of the field which would be searched within the records. | — | | `filters` | array\ | No | List of filters represents filters to be applied if the operator used is AND or OR | — | #### Sort Request Schema Sort Request Schema list represents the group of parameters which sorts the records. | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `field` | string | Yes | Field represents the field on which sorting would be applied. | `createdAt` | | `direction` | string | No | Direction represents the order in which sorting would be applied. Allowed: `ASC`, `DESC`. | — | ### Sample Request ```json { "filter": { "field": "Audit Trail (2).pdf", "operator": "EQ", "value": [ {} ], "filters": [ "value" ] }, "sort": [ { "field": "createdAt", "direction": "ASC" } ], "limit": 10, "page": 0 } ``` --- ## Responses ### 200 — Departments found successfully | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `data` | array\ | No | See **CertificateSearchItemVO** below. | — | | `pagination` | Pagination Response Schema | No | See **Pagination Response Schema** below. | — | #### CertificateSearchItemVO Certificate item in search results | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `id` | string | No | Certificate unique identifier | `37d14717-5c1a-44fe-9b8f-6d5184b09f06` | | `name` | string | No | Certificate name | `*.leegality.com` | | `certificateType` | string | No | Type of certificate | `PKCS12_PFX` | | `expiry` | string | No | Certificate expiry date and time | `2026-09-12T12:53:04` | | `createdAt` | string | No | Certificate creation date and time | `2025-10-14T20:38:06` | | `departmentId` | string | No | Department unique identifier | `a2906183-8b02-4aa3-9d27-e5ba3efef203` | | `departmentName` | string | No | Department name | `HR` | #### Pagination Response Schema | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `limit` | integer | No | Limit represents the maximum number of records to be displayed per page. | `10` | | `page` | integer | No | Page represents the current page index to display records starting from 0. | `0` | | `total` | integer | No | Total represents the total number of records fetched. | `50` | ### 400 — Invalid search criteria | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `data` | array\ | No | See **CertificateSearchItemVO** below. | — | | `pagination` | Pagination Response Schema | No | See **Pagination Response Schema** below. | — | #### CertificateSearchItemVO Certificate item in search results | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `id` | string | No | Certificate unique identifier | `37d14717-5c1a-44fe-9b8f-6d5184b09f06` | | `name` | string | No | Certificate name | `*.leegality.com` | | `certificateType` | string | No | Type of certificate | `PKCS12_PFX` | | `expiry` | string | No | Certificate expiry date and time | `2026-09-12T12:53:04` | | `createdAt` | string | No | Certificate creation date and time | `2025-10-14T20:38:06` | | `departmentId` | string | No | Department unique identifier | `a2906183-8b02-4aa3-9d27-e5ba3efef203` | | `departmentName` | string | No | Department name | `HR` | #### Pagination Response Schema | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `limit` | integer | No | Limit represents the maximum number of records to be displayed per page. | `10` | | `page` | integer | No | Page represents the current page index to display records starting from 0. | `0` | | `total` | integer | No | Total represents the total number of records fetched. | `50` | ### 401 — Unauthorized - Invalid or expired token | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `code` | string | No | Top-level error code | `LE_ERR_SS_401` | | `errors` | array\ | No | List of error details See **ErrorDetail401Unauthorized** below. | — | #### ErrorDetail401Unauthorized | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `message` | string | No | Detailed error message | `Invalid or expired token` | | `path` | string | No | API path that generated the error | `/api/v1/*` | | `code` | string | No | Specific error code | `LE_ERR_SS_303` | ### 500 — Internal server error | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `code` | string | No | Top-level error code | `LE_ERR_SS_500` | | `errors` | array\ | No | List of error details See **ErrorDetailToken500VO** below. | — | #### ErrorDetailToken500VO | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `message` | string | No | Detailed error message | `Internal Server Error` | | `path` | string | No | API path that generated the error | `null` | | `code` | string | No | Specific error code | `null` | ### Sample Response (200) ```json { "data": [ { "id": "37d14717-5c1a-44fe-9b8f-6d5184b09f06", "name": "*.leegality.com", "certificateType": "PKCS12_PFX", "expiry": "2026-09-12T12:53:04", "createdAt": "2025-10-14T20:38:06", "departmentId": "a2906183-8b02-4aa3-9d27-e5ba3efef203", "departmentName": "HR" } ], "pagination": { "limit": 10, "page": 0, "total": 50 } } ``` --- URL: https://knowledge.leegality.com/sign-station/api/search-documents # POST /api/v1/documents/search — Search documents Search documents for the current user's organization using advanced search criteria **Authentication:** `X-Auth-Token` header required on every request. ## Request URL ``` POST https://app1.leegality.com/api/api/v1/documents/search ``` **Environments:** - Production: `https://app1.leegality.com/api/api/v1/documents/search` - Sandbox: `https://sandbox.leegality.com/api/api/v1/documents/search` --- ## Request Body **Content-Type:** `application/json` Search criteria including filters, sorting, and pagination | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `filter` | Filter Request Schema | No | Filter Request Schema represents the group of parameters which filters the records. See **Filter Request Schema** below. | — | | `sort` | array\ | No | Sort Request Schema list represents the group of parameters which sorts the records. See **Sort Request Schema** below. | — | | `limit` | integer | No | Limit represents the maximum number of records to be displayed per page. | `10` | | `page` | integer | No | Page represents the current page index to display records starting from 0. | `0` | #### Filter Request Schema Filter Request Schema represents the group of parameters which filters the records. | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `field` | string | No | Field represents the field on which operator would be applied. | `Audit Trail (2).pdf` | | `operator` | string | Yes | Operator represents the condition which would be applied for searching. Allowed: `EQ`, `NEQ`, `IN`, `NOT_IN`, `IS_NULL`, `NOT_NULL`, `AND`, `OR`, `GT`, `LT`, `GTE`, `LTE`, `BETWEEN`, `LIKE`. | — | | `value` | array\ | No | Value represents the value of the field which would be searched within the records. | — | | `filters` | array\ | No | List of filters represents filters to be applied if the operator used is AND or OR | — | #### Sort Request Schema Sort Request Schema list represents the group of parameters which sorts the records. | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `field` | string | Yes | Field represents the field on which sorting would be applied. | `createdAt` | | `direction` | string | No | Direction represents the order in which sorting would be applied. Allowed: `ASC`, `DESC`. | — | ### Sample Request ```json { "filter": { "field": "Audit Trail (2).pdf", "operator": "EQ", "value": [ {} ], "filters": [ "value" ] }, "sort": [ { "field": "createdAt", "direction": "ASC" } ], "limit": 10, "page": 0 } ``` --- ## Responses ### 200 — Documents found successfully | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `data` | array\ | No | See **CertificateSearchItemVO** below. | — | | `pagination` | Pagination Response Schema | No | See **Pagination Response Schema** below. | — | #### CertificateSearchItemVO Certificate item in search results | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `id` | string | No | Certificate unique identifier | `37d14717-5c1a-44fe-9b8f-6d5184b09f06` | | `name` | string | No | Certificate name | `*.leegality.com` | | `certificateType` | string | No | Type of certificate | `PKCS12_PFX` | | `expiry` | string | No | Certificate expiry date and time | `2026-09-12T12:53:04` | | `createdAt` | string | No | Certificate creation date and time | `2025-10-14T20:38:06` | | `departmentId` | string | No | Department unique identifier | `a2906183-8b02-4aa3-9d27-e5ba3efef203` | | `departmentName` | string | No | Department name | `HR` | #### Pagination Response Schema | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `limit` | integer | No | Limit represents the maximum number of records to be displayed per page. | `10` | | `page` | integer | No | Page represents the current page index to display records starting from 0. | `0` | | `total` | integer | No | Total represents the total number of records fetched. | `50` | ### 400 — Invalid search criteria ### 401 — Unauthorized - Invalid or expired token | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `code` | string | No | Top-level error code | `LE_ERR_SS_401` | | `errors` | array\ | No | List of error details See **ErrorDetail401Unauthorized** below. | — | #### ErrorDetail401Unauthorized | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `message` | string | No | Detailed error message | `Invalid or expired token` | | `path` | string | No | API path that generated the error | `/api/v1/*` | | `code` | string | No | Specific error code | `LE_ERR_SS_303` | ### 500 — Internal server error ### Sample Response (200) ```json { "data": [ { "id": "37d14717-5c1a-44fe-9b8f-6d5184b09f06", "name": "*.leegality.com", "certificateType": "PKCS12_PFX", "expiry": "2026-09-12T12:53:04", "createdAt": "2025-10-14T20:38:06", "departmentId": "a2906183-8b02-4aa3-9d27-e5ba3efef203", "departmentName": "HR" } ], "pagination": { "limit": 10, "page": 0, "total": 50 } } ``` --- URL: https://knowledge.leegality.com/sign-station/api/search-licenses # POST /api/v1/licenses/search — Search licenses Search licenses for the current user's organization using advanced search criteria **Authentication:** `X-Auth-Token` header required on every request. ## Request URL ``` POST https://app1.leegality.com/api/api/v1/licenses/search ``` **Environments:** - Production: `https://app1.leegality.com/api/api/v1/licenses/search` - Sandbox: `https://sandbox.leegality.com/api/api/v1/licenses/search` --- ## Request Body **Content-Type:** `application/json` Search criteria including filters, sorting, and pagination | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `filter` | Filter Request Schema | No | Filter Request Schema represents the group of parameters which filters the records. See **Filter Request Schema** below. | — | | `sort` | array\ | No | Sort Request Schema list represents the group of parameters which sorts the records. See **Sort Request Schema** below. | — | | `limit` | integer | No | Limit represents the maximum number of records to be displayed per page. | `10` | | `page` | integer | No | Page represents the current page index to display records starting from 0. | `0` | #### Filter Request Schema Filter Request Schema represents the group of parameters which filters the records. | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `field` | string | No | Field represents the field on which operator would be applied. | `Audit Trail (2).pdf` | | `operator` | string | Yes | Operator represents the condition which would be applied for searching. Allowed: `EQ`, `NEQ`, `IN`, `NOT_IN`, `IS_NULL`, `NOT_NULL`, `AND`, `OR`, `GT`, `LT`, `GTE`, `LTE`, `BETWEEN`, `LIKE`. | — | | `value` | array\ | No | Value represents the value of the field which would be searched within the records. | — | | `filters` | array\ | No | List of filters represents filters to be applied if the operator used is AND or OR | — | #### Sort Request Schema Sort Request Schema list represents the group of parameters which sorts the records. | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `field` | string | Yes | Field represents the field on which sorting would be applied. | `createdAt` | | `direction` | string | No | Direction represents the order in which sorting would be applied. Allowed: `ASC`, `DESC`. | — | ### Sample Request ```json { "filter": { "field": "Audit Trail (2).pdf", "operator": "EQ", "value": [ {} ], "filters": [ "value" ] }, "sort": [ { "field": "createdAt", "direction": "ASC" } ], "limit": 10, "page": 0 } ``` --- ## Responses ### 200 — OK | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `data` | array\ | No | See **CertificateSearchItemVO** below. | — | | `pagination` | Pagination Response Schema | No | See **Pagination Response Schema** below. | — | #### CertificateSearchItemVO Certificate item in search results | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `id` | string | No | Certificate unique identifier | `37d14717-5c1a-44fe-9b8f-6d5184b09f06` | | `name` | string | No | Certificate name | `*.leegality.com` | | `certificateType` | string | No | Type of certificate | `PKCS12_PFX` | | `expiry` | string | No | Certificate expiry date and time | `2026-09-12T12:53:04` | | `createdAt` | string | No | Certificate creation date and time | `2025-10-14T20:38:06` | | `departmentId` | string | No | Department unique identifier | `a2906183-8b02-4aa3-9d27-e5ba3efef203` | | `departmentName` | string | No | Department name | `HR` | #### Pagination Response Schema | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `limit` | integer | No | Limit represents the maximum number of records to be displayed per page. | `10` | | `page` | integer | No | Page represents the current page index to display records starting from 0. | `0` | | `total` | integer | No | Total represents the total number of records fetched. | `50` | ### 400 — Invalid search criteria | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `code` | string | No | Top-level error code | `LE_ERR_SS_400` | | `errors` | array\ | No | List of error details See **ErrorDetailSearchLicenses400VO** below. | — | #### ErrorDetailSearchLicenses400VO | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `message` | string | No | Detailed error message | `Invalid value for field [filter.filters], [field, filters]` | | `path` | string | No | API path that generated the error | `/api/v1/licenses/search` | ### 401 — Unauthorized - Invalid or expired token | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `code` | string | No | Top-level error code | `LE_ERR_SS_401` | | `errors` | array\ | No | List of error details See **ErrorDetailSearchLicenses401VO** below. | — | #### ErrorDetailSearchLicenses401VO | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `message` | string | No | Detailed error message | `Invalid or expired token` | | `path` | string | No | API path that generated the error | `/api/v1/licenses/search` | | `code` | string | No | Specific error code | `LE_ERR_SS_303` | ### 500 — Internal server error | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `code` | string | No | Top-level error code | `LE_ERR_SS_500` | | `errors` | array\ | No | List of error details See **ErrorDetailToken500VO** below. | — | #### ErrorDetailToken500VO | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `message` | string | No | Detailed error message | `Internal Server Error` | | `path` | string | No | API path that generated the error | `null` | | `code` | string | No | Specific error code | `null` | ### Sample Response (200) ```json { "data": [ { "id": "37d14717-5c1a-44fe-9b8f-6d5184b09f06", "name": "*.leegality.com", "certificateType": "PKCS12_PFX", "expiry": "2026-09-12T12:53:04", "createdAt": "2025-10-14T20:38:06", "departmentId": "a2906183-8b02-4aa3-9d27-e5ba3efef203", "departmentName": "HR" } ], "pagination": { "limit": 10, "page": 0, "total": 50 } } ``` --- URL: https://knowledge.leegality.com/sign-station/api/search-users # POST /api/v1/users/search — Search users Search users for the current user's organization using advanced search criteria **Authentication:** `X-Auth-Token` header required on every request. ## Request URL ``` POST https://app1.leegality.com/api/api/v1/users/search ``` **Environments:** - Production: `https://app1.leegality.com/api/api/v1/users/search` - Sandbox: `https://sandbox.leegality.com/api/api/v1/users/search` --- ## Request Body **Content-Type:** `application/json` Search criteria including filters, sorting, and pagination | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `filter` | Filter Request Schema | No | Filter Request Schema represents the group of parameters which filters the records. See **Filter Request Schema** below. | — | | `sort` | array\ | No | Sort Request Schema list represents the group of parameters which sorts the records. See **Sort Request Schema** below. | — | | `limit` | integer | No | Limit represents the maximum number of records to be displayed per page. | `10` | | `page` | integer | No | Page represents the current page index to display records starting from 0. | `0` | #### Filter Request Schema Filter Request Schema represents the group of parameters which filters the records. | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `field` | string | No | Field represents the field on which operator would be applied. | `Audit Trail (2).pdf` | | `operator` | string | Yes | Operator represents the condition which would be applied for searching. Allowed: `EQ`, `NEQ`, `IN`, `NOT_IN`, `IS_NULL`, `NOT_NULL`, `AND`, `OR`, `GT`, `LT`, `GTE`, `LTE`, `BETWEEN`, `LIKE`. | — | | `value` | array\ | No | Value represents the value of the field which would be searched within the records. | — | | `filters` | array\ | No | List of filters represents filters to be applied if the operator used is AND or OR | — | #### Sort Request Schema Sort Request Schema list represents the group of parameters which sorts the records. | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `field` | string | Yes | Field represents the field on which sorting would be applied. | `createdAt` | | `direction` | string | No | Direction represents the order in which sorting would be applied. Allowed: `ASC`, `DESC`. | — | ### Sample Request ```json { "filter": { "field": "Audit Trail (2).pdf", "operator": "EQ", "value": [ {} ], "filters": [ "value" ] }, "sort": [ { "field": "createdAt", "direction": "ASC" } ], "limit": 10, "page": 0 } ``` --- ## Responses ### 200 — Users found successfully | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `data` | array\ | No | See **CertificateSearchItemVO** below. | — | | `pagination` | Pagination Response Schema | No | See **Pagination Response Schema** below. | — | #### CertificateSearchItemVO Certificate item in search results | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `id` | string | No | Certificate unique identifier | `37d14717-5c1a-44fe-9b8f-6d5184b09f06` | | `name` | string | No | Certificate name | `*.leegality.com` | | `certificateType` | string | No | Type of certificate | `PKCS12_PFX` | | `expiry` | string | No | Certificate expiry date and time | `2026-09-12T12:53:04` | | `createdAt` | string | No | Certificate creation date and time | `2025-10-14T20:38:06` | | `departmentId` | string | No | Department unique identifier | `a2906183-8b02-4aa3-9d27-e5ba3efef203` | | `departmentName` | string | No | Department name | `HR` | #### Pagination Response Schema | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `limit` | integer | No | Limit represents the maximum number of records to be displayed per page. | `10` | | `page` | integer | No | Page represents the current page index to display records starting from 0. | `0` | | `total` | integer | No | Total represents the total number of records fetched. | `50` | ### 400 — Invalid search criteria | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `code` | string | No | Top-level error code | `LE_ERR_SS_400` | | `errors` | array\ | No | List of error details See **ErrorDetailSearchUsers400VO** below. | — | #### ErrorDetailSearchUsers400VO | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `message` | string | No | Detailed error message | `Invalid value for field [filter.filters], [field, filters]` | | `path` | string | No | API path that generated the error | `/api/v1/users/search` | ### 401 — Unauthorized - Invalid or expired token | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `code` | string | No | Top-level error code | `LE_ERR_SS_401` | | `errors` | array\ | No | List of error details See **ErrorDetail401Unauthorized** below. | — | #### ErrorDetail401Unauthorized | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `message` | string | No | Detailed error message | `Invalid or expired token` | | `path` | string | No | API path that generated the error | `/api/v1/*` | | `code` | string | No | Specific error code | `LE_ERR_SS_303` | ### 500 — Internal server error | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `code` | string | No | Top-level error code | `LE_ERR_SS_500` | | `errors` | array\ | No | List of error details See **ErrorDetailToken500VO** below. | — | #### ErrorDetailToken500VO | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `message` | string | No | Detailed error message | `Internal Server Error` | | `path` | string | No | API path that generated the error | `null` | | `code` | string | No | Specific error code | `null` | ### Sample Response (200) ```json { "data": [ { "id": "37d14717-5c1a-44fe-9b8f-6d5184b09f06", "name": "*.leegality.com", "certificateType": "PKCS12_PFX", "expiry": "2026-09-12T12:53:04", "createdAt": "2025-10-14T20:38:06", "departmentId": "a2906183-8b02-4aa3-9d27-e5ba3efef203", "departmentName": "HR" } ], "pagination": { "limit": 10, "page": 0, "total": 50 } } ``` --- # Settings Controller URL: https://knowledge.leegality.com/sign-station/api/settings-controller.tag > Settings Controller The Settings Management API provides endpoints for managing organization-level settings in the SignStation platform. Settings control various aspects of the system including document retention, audit log retention, and audit trail generation. Each organization has one settings configuration. Use this API to create, retrieve, update, and manage settings for the authenticated user's organization. For the dashboard equivalent, see [System Settings](https://knowledge.leegality.com/sign-station/system-settings). ```mdx-code-block ``` --- URL: https://knowledge.leegality.com/sign-station/api/sign # POST /api/v1/documents/sign — Sign a new document Sign a new document with metadata including name, department, and file **Authentication:** `X-Auth-Token` header required on every request. ## Request URL ``` POST https://app1.leegality.com/api/api/v1/documents/sign ``` **Environments:** - Production: `https://app1.leegality.com/api/api/v1/documents/sign` - Sandbox: `https://sandbox.leegality.com/api/api/v1/documents/sign` --- ## Request Body **Content-Type:** `application/json` Document sign data with file upload | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `name` | string | Yes | Name of the document to be signed | `TestDocument.pdf` | | `file` | string | Yes | Document file to be signed | `null` | | `departmentId` | string | Yes | Department ID for the document | `18b45e41-5d8b-4417-bb83-1d769187aef9` | | `certificateId` | string | Yes | Certificate ID to be used for signing the document | `46d4e120-ed03-47cc-98c6-529bff3bbabc` | | `signatureCoordinates` | array\ | No | See **SignatureCoordinateDTO** below. | — | | `signerName` | string | No | Name of the signer to be displayed on the document | `Test Signer` | | `location` | string | No | Location to be displayed on the document | `Bangalore, India` | | `reason` | string | No | Reason for signing to be displayed on the document | `Testing signing via API` | #### SignatureCoordinateDTO | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `xcoordinate` | number | Yes | X coordinate for the signature placement on the page | `10` | | `ycoordinate` | number | Yes | Y coordinate for the signature placement on the page | `20` | | `pageNumber` | integer | Yes | Page number where the signature should be placed | `1` | | `width` | number | No | Width of the signature image | `200` | | `height` | number | No | Height of the signature image | `100` | ### Sample Request ```json { "name": "TestDocument.pdf", "file": null, "departmentId": "18b45e41-5d8b-4417-bb83-1d769187aef9", "certificateId": "46d4e120-ed03-47cc-98c6-529bff3bbabc", "signatureCoordinates": [ { "xcoordinate": 10, "ycoordinate": 20, "pageNumber": 1, "width": 200, "height": 100 } ], "signerName": "Test Signer", "location": "Bangalore, India", "reason": "Testing signing via API" } ``` --- ## Responses ### 200 — OK | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `code` | string | No | Response code indicating success or failure | `LE_SS_301` | | `message` | string | No | Response message providing additional information | `Document signed successfully.` | | `data` | DocumentVO | No | See **DocumentVO** below. | — | #### DocumentVO | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `id` | string | No | Document unique identifier | `5f8d0c2e-3a4b-4c6e-9f8e-2d3c4b5a6e7f` | | `name` | string | No | Name of the document | `TestDocument.pdf` | | `uploadedBy` | string | No | User ID of the person who uploaded the document | — | | `uploadedByName` | string | No | Name of the person who uploaded the document | `Test Signer` | | `department` | DepartmentVO | No | See **DepartmentVO** below. | — | | `status` | string | No | Current status of the document Allowed: `SUBMITTED`, `SIGNED`, `FAILED`. | — | | `signedAt` | string | No | The date and time when the document was signed | — | | `location` | string | No | Location where the document was signed | `Bangalore, India` | | `signerName` | string | No | Name of the signer | `Test Signer` | | `reason` | string | No | Reason for signing the document | `Testing signing via API` | | `createdAt` | string | No | The date and time when the document was created | — | | `enabled` | boolean | No | Indicates whether the document is enabled or disabled | — | | `certificate` | CertificateVO | No | See **CertificateVO** below. | — | ##### DepartmentVO | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `id` | string | No | Department unique identifier | `3fa85f64-5717-4562-b3fc-2c963f66afa6` | | `name` | string | No | The department's name (e.g., "Human Resources"). | `Human Resources` | | `enabled` | boolean | No | Indicates whether the department is active or inactive. | `true` | | `createdAt` | string | No | The date and time when the department was created. | `2025-12-15T10:20:30Z` | | `totalUsers` | integer | No | Total number of users in the department. | `25` | ##### CertificateVO | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `id` | string | No | Certificate unique identifier | `46d4e120-ed03-47cc-98c6-529bff3bbabc` | | `name` | string | No | Certificate name | `TestCertificate.leegality.com` | | `certificateType` | string | No | Type of the certificate Allowed: `PKCS12_PFX`, `PKCS12_HSM`, `PKCS11`. | — | | `expiry` | string | No | Certificate expiry date | — | | `createdAt` | string | No | The date and time when the certificate was created | — | | `departmentId` | string | No | Associated department ID | `18b45e41-5d8b-4417-bb83-1d769187aef9` | | `departmentName` | string | No | Associated department name | `HR` | ### 401 — Unauthorized - Invalid or expired token | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `code` | string | No | Top-level error code | `LE_ERR_SS_401` | | `errors` | array\ | No | List of error details See **ErrorDetail401Unauthorized** below. | — | #### ErrorDetail401Unauthorized | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `message` | string | No | Detailed error message | `Invalid or expired token` | | `path` | string | No | API path that generated the error | `/api/v1/*` | | `code` | string | No | Specific error code | `LE_ERR_SS_303` | ### 500 — Internal server error | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `code` | string | No | Top-level error code | `LE_ERR_SS_500` | | `errors` | array\ | No | List of error details See **ErrorDetailToken500VO** below. | — | #### ErrorDetailToken500VO | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `message` | string | No | Detailed error message | `Internal Server Error` | | `path` | string | No | API path that generated the error | `null` | | `code` | string | No | Specific error code | `null` | ### Sample Response (200) ```json { "code": "LE_SS_301", "message": "Document signed successfully.", "data": { "id": "5f8d0c2e-3a4b-4c6e-9f8e-2d3c4b5a6e7f", "name": "TestDocument.pdf", "uploadedBy": "string", "uploadedByName": "Test Signer", "department": { "id": "3fa85f64-5717-4562-b3fc-2c963f66afa6", "name": "Human Resources", "enabled": true, "createdAt": "2025-12-15T10:20:30Z", "totalUsers": 25 }, "status": "SUBMITTED", "signedAt": "string", "location": "Bangalore, India", "signerName": "Test Signer", "reason": "Testing signing via API", "createdAt": "string", "enabled": false, "certificate": { "id": "46d4e120-ed03-47cc-98c6-529bff3bbabc", "name": "TestCertificate.leegality.com", "certificateType": "PKCS12_PFX", "expiry": "string", "createdAt": "string", "departmentId": "18b45e41-5d8b-4417-bb83-1d769187aef9", "departmentName": "HR" } } } ``` --- URL: https://knowledge.leegality.com/sign-station/api/toggle-o-auth-2-client-state # PATCH /api/v1/oauth2-clients/{id}/toggle-state — Toggle OAuth2 client state Toggles OAuth2 client state between ACTIVE and SUSPENDED for the current user's organization **Authentication:** `X-Auth-Token` header required on every request. ## Request URL ``` PATCH https://app1.leegality.com/api/api/v1/oauth2-clients/{id}/toggle-state ``` **Environments:** - Production: `https://app1.leegality.com/api/api/v1/oauth2-clients/{id}/toggle-state` - Sandbox: `https://sandbox.leegality.com/api/api/v1/oauth2-clients/{id}/toggle-state` --- ## Parameters | Name | In | Required | Type | Description | Example | |------|----|----------|------|-------------|---------| | `id` | path | Yes | string | OAuth2 client ID of which you want to toggle the state. | — | --- ## Responses ### 200 — OAuth2 client state toggled successfully | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `code` | string | No | Response status code | `LE_SS_004` | | `message` | string | No | Response message | `OAuth2 client updated successfully.` | | `data` | OAuth2ClientToggleStateVO | No | See **OAuth2ClientToggleStateVO** below. | — | #### OAuth2ClientToggleStateVO | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `id` | string | No | OAuth2 client unique identifier | `a3a0e830-66b6-4845-bf1a-91e0966fb97b` | | `clientId` | string | No | OAuth2 client identifier | `FinanceTest` | | `state` | string | No | OAuth2 client state Allowed: `ACTIVE`, `SUSPENDED`. | `SUSPENDED` | | `createdAt` | string | No | The date and time when the OAuth2 client was created | `2025-12-22T16:26:03` | ### 401 — Unauthorized - Invalid or expired token | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `code` | string | No | Top-level error code | `LE_ERR_SS_401` | | `errors` | array\ | No | List of error details See **ErrorDetail401Unauthorized** below. | — | #### ErrorDetail401Unauthorized | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `message` | string | No | Detailed error message | `Invalid or expired token` | | `path` | string | No | API path that generated the error | `/api/v1/*` | | `code` | string | No | Specific error code | `LE_ERR_SS_303` | ### 404 — OAuth2 client not found | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `code` | string | No | Top-level error code | `LE_ERR_SS_404` | | `errors` | array\ | No | List of error details See **ErrorDetailOAuth2Client404VO** below. | — | #### ErrorDetailOAuth2Client404VO | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `message` | string | No | Detailed error message | `OAuth2 Client with id a3a0e830-66b6-4845-bf1a-91e0966fb97a d` | | `path` | string | No | API path that generated the error | `/api/v1/oauth2-clients/a3a0e830-66b6-4845-bf1a-91e0966fb97a/` | | `code` | string | No | Specific error code | `LE_ERR_SS_001` | ### 500 — Internal server error | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `code` | string | No | Top-level error code | `LE_ERR_SS_500` | | `errors` | array\ | No | List of error details See **ErrorDetailToken500VO** below. | — | #### ErrorDetailToken500VO | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `message` | string | No | Detailed error message | `Internal Server Error` | | `path` | string | No | API path that generated the error | `null` | | `code` | string | No | Specific error code | `null` | ### Sample Response (200) ```json { "code": "LE_SS_004", "message": "OAuth2 client updated successfully.", "data": { "id": "a3a0e830-66b6-4845-bf1a-91e0966fb97b", "clientId": "FinanceTest", "state": "SUSPENDED", "createdAt": "2025-12-22T16:26:03" } } ``` --- URL: https://knowledge.leegality.com/sign-station/api/update-1 # PUT /api/v1/certificates/{id} — Update certificate Updates an existing certificate for the current user's organization. Certificate file upload is optional - if not provided, the existing certificate file will be retained. Supported format: .p12/.pfx (PKCS12) only (max size: 5MB) **Authentication:** `X-Auth-Token` header required on every request. ## Request URL ``` PUT https://app1.leegality.com/api/api/v1/certificates/{id} ``` **Environments:** - Production: `https://app1.leegality.com/api/api/v1/certificates/{id}` - Sandbox: `https://sandbox.leegality.com/api/api/v1/certificates/{id}` --- ## Parameters | Name | In | Required | Type | Description | Example | |------|----|----------|------|-------------|---------| | `id` | path | Yes | string | Certificate ID | — | --- ## Request Body **Content-Type:** `application/json` Certificate data including name, passkey, type, expiry, departmentId, enabled flag, and certificate file | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `passkey` | string | No | Passkey for the certificate file | `mySecretPasskey` | | `certificateFile` | string | No | Certificate file to be uploaded | `TestCertificate.leegality.com` | | `departmentId` | string | No | Associated department ID | — | | `enabled` | boolean | No | Indicates whether the certificate is enabled or disabled | — | ### Sample Request ```json { "passkey": "mySecretPasskey", "certificateFile": "TestCertificate.leegality.com", "departmentId": "string", "enabled": false } ``` --- ## Responses ### 200 — Certificate updated successfully | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `code` | string | No | Response status code | `null` | | `message` | string | No | Response message | `null` | | `data` | CertificateVO | No | See **CertificateVO** below. | — | #### CertificateVO | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `id` | string | No | Certificate unique identifier | `46d4e120-ed03-47cc-98c6-529bff3bbabc` | | `name` | string | No | Certificate name | `TestCertificate.leegality.com` | | `certificateType` | string | No | Type of the certificate Allowed: `PKCS12_PFX`, `PKCS12_HSM`, `PKCS11`. | — | | `expiry` | string | No | Certificate expiry date | — | | `createdAt` | string | No | The date and time when the certificate was created | — | | `departmentId` | string | No | Associated department ID | `18b45e41-5d8b-4417-bb83-1d769187aef9` | | `departmentName` | string | No | Associated department name | `HR` | ### 400 — Invalid request data or unsupported file format | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `code` | string | No | Top-level error code | `LE_ERR_SS_400` | | `errors` | array\ | No | List of error details See **ErrorDetail400VO** below. | — | #### ErrorDetail400VO | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `message` | string | No | Detailed error message | `Invalid request parameter: days must be a positive integer.` | ### 401 — Unauthorized - Invalid or expired token | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `code` | string | No | Top-level error code | `LE_ERR_SS_401` | | `errors` | array\ | No | List of error details See **ErrorDetail401Unauthorized** below. | — | #### ErrorDetail401Unauthorized | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `message` | string | No | Detailed error message | `Invalid or expired token` | | `path` | string | No | API path that generated the error | `/api/v1/*` | | `code` | string | No | Specific error code | `LE_ERR_SS_303` | ### 404 — Certificate not found | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `code` | string | No | Top-level error code | `LE_ERR_SS_404` | | `errors` | array\ | No | List of error details See **ErrorDetailVO** below. | — | #### ErrorDetailVO | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `message` | string | No | Detailed error message | `Certificate with id 46d4e120-ed03-47cc-98c6-529bff3bbaba doe` | | `path` | string | No | API path that generated the error | `/api/v1/certificates/46d4e120-ed03-47cc-98c6-529bff3bbaba` | | `code` | string | No | Specific error code | `LE_ERR_SS_001` | ### 500 — Internal server error | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `code` | string | No | Top-level error code | `LE_ERR_SS_500` | | `errors` | array\ | No | List of error details See **ErrorDetailToken500VO** below. | — | #### ErrorDetailToken500VO | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `message` | string | No | Detailed error message | `Internal Server Error` | | `path` | string | No | API path that generated the error | `null` | | `code` | string | No | Specific error code | `null` | ### Sample Response (200) ```json { "code": null, "message": null, "data": { "id": "46d4e120-ed03-47cc-98c6-529bff3bbabc", "name": "TestCertificate.leegality.com", "certificateType": "PKCS12_PFX", "expiry": "string", "createdAt": "string", "departmentId": "18b45e41-5d8b-4417-bb83-1d769187aef9", "departmentName": "HR" } } ``` --- URL: https://knowledge.leegality.com/sign-station/api/update-config-1 # PUT /api/v1/certificate-notification-config — Update certificate notification configuration Updates certificate notification configuration for the current user's organization **Authentication:** `X-Auth-Token` header required on every request. ## Request URL ``` PUT https://app1.leegality.com/api/api/v1/certificate-notification-config ``` **Environments:** - Production: `https://app1.leegality.com/api/api/v1/certificate-notification-config` - Sandbox: `https://sandbox.leegality.com/api/api/v1/certificate-notification-config` --- ## Request Body **Content-Type:** `application/json` Certificate notification configuration data to create | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `reminderDays` | array\ | No | Days before expiry to send reminders | `2` | | `additionalEmailRecipients` | array\ | No | Additional email recipients for notifications | `anagha.babu@leegality.com` | | `notifyRoleIds` | array\ | No | Role IDs to be notified | `17d7949d-6fa9-4077-a76e-da349efe421b` | | `enabled` | boolean | No | Indicates whether the certificate notification is enabled | `true` | ### Sample Request ```json { "reminderDays": [ 2 ], "additionalEmailRecipients": [ "anagha.babu@leegality.com" ], "notifyRoleIds": [ "17d7949d-6fa9-4077-a76e-da349efe421b" ], "enabled": true } ``` --- ## Responses ### 200 — Certificate notification configuration updated successfully | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `code` | string | No | Response status code | `LE_SS_001` | | `message` | string | No | Response message | `Your changes have been successfully saved.` | | `data` | CertificateNotificationConfigVO | No | See **CertificateNotificationConfigVO** below. | — | #### CertificateNotificationConfigVO | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `id` | string | No | Certificate notification configuration unique identifier | `6d8ff341-fe21-431e-9453-bb94959474b6` | | `reminderDays` | array\ | No | Days before expiry to send reminders | `2` | | `additionalEmailRecipients` | array\ | No | Additional email recipients for notifications | `anagha.babu@leegality.com` | | `enabled` | boolean | No | Indicates whether the certificate notification is enabled | `true` | | `createdAt` | string | No | The date and time when the certificate notification configuration was created | `2025-12-29T12:00:29.726603` | | `notifyRoles` | array\ | No | See **NotificationRoleVO** below. | — | ##### NotificationRoleVO | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `id` | string | No | Role ID. This is configured during the role creation. | `17d7949d-6fa9-4077-a76e-da349efe421b` | | `name` | string | No | Role name. E.g., "Admin", "User" etc. | `Test Role 12344` | | `createdAt` | string | No | The date and time when the role was created | `2025-11-13T14:05:34` | ### 400 — Invalid request data | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `code` | string | No | Top-level error code | `LE_ERR_SS_400` | | `errors` | array\ | No | List of error details See **ErrorDetailUpdateCertificateNotificationConfig400VO** below. | — | #### ErrorDetailUpdateCertificateNotificationConfig400VO | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `message` | string | No | Detailed error message | `Invalid value for field [additionalEmailRecipients], Invalid` | | `path` | string | No | API path that generated the error | `/api/v1/certificate-notification-config` | ### 401 — Unauthorized - Invalid or expired token | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `code` | string | No | Top-level error code | `LE_ERR_SS_401` | | `errors` | array\ | No | List of error details See **ErrorDetail401Unauthorized** below. | — | #### ErrorDetail401Unauthorized | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `message` | string | No | Detailed error message | `Invalid or expired token` | | `path` | string | No | API path that generated the error | `/api/v1/*` | | `code` | string | No | Specific error code | `LE_ERR_SS_303` | ### 404 — Role not found | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `code` | string | No | Top-level error code | `LE_ERR_SS_404` | | `errors` | array\ | No | List of error details See **ErrorDetailUpdateCertificateNotificationConfig404VO** below. | — | #### ErrorDetailUpdateCertificateNotificationConfig404VO | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `message` | string | No | Detailed error message | `Role does not exist.` | | `path` | string | No | API path that generated the error | `/api/v1/certificate-notification-config` | | `code` | string | No | Specific error code | `LE_ERR_SS_001` | ### 500 — Internal server error | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `code` | string | No | Top-level error code | `LE_ERR_SS_500` | | `errors` | array\ | No | List of error details See **ErrorDetailToken500VO** below. | — | #### ErrorDetailToken500VO | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `message` | string | No | Detailed error message | `Internal Server Error` | | `path` | string | No | API path that generated the error | `null` | | `code` | string | No | Specific error code | `null` | ### Sample Response (200) ```json { "code": "LE_SS_001", "message": "Your changes have been successfully saved.", "data": { "id": "6d8ff341-fe21-431e-9453-bb94959474b6", "reminderDays": [ 2 ], "additionalEmailRecipients": [ "anagha.babu@leegality.com" ], "enabled": true, "createdAt": "2025-12-29T12:00:29.726603", "notifyRoles": [ { "id": "17d7949d-6fa9-4077-a76e-da349efe421b", "name": "Test Role 12344", "createdAt": "2025-11-13T14:05:34" } ] } } ``` --- URL: https://knowledge.leegality.com/sign-station/api/update-config # PUT /api/v1/notification-config — Update notification configuration Updates notification configuration for the current user's organization **Authentication:** `X-Auth-Token` header required on every request. ## Request URL ``` PUT https://app1.leegality.com/api/api/v1/notification-config ``` **Environments:** - Production: `https://app1.leegality.com/api/api/v1/notification-config` - Sandbox: `https://sandbox.leegality.com/api/api/v1/notification-config` --- ## Request Body **Content-Type:** `application/json` Notification configuration data to create | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `emailServerHost` | string | Yes | Email server host address | `smtp.example.com` | | `emailServerPort` | string | No | Email server port | `587` | | `username` | string | No | Username for email server authentication | `anagha.babu@leegality.com` | | `password` | string | No | Password for email server authentication | `NewPassword@123` | | `fromEmail` | string | No | Email address used in the 'From' field of outgoing emails | `testuser@leegality.com` | | `fromName` | string | No | Name used in the 'From' field of outgoing emails | `Leegality Test User` | | `replyTo` | string | No | Email address used in the 'Reply-To' field of outgoing emails | `testuser@leegality.com` | | `tlsEnabled` | boolean | No | Indicates whether TLS is enabled for email communication | `true` | | `enabled` | boolean | No | Indicates whether the notification configuration is enabled | — | ### Sample Request ```json { "emailServerHost": "smtp.example.com", "emailServerPort": "587", "username": "anagha.babu@leegality.com", "password": "NewPassword@123", "fromEmail": "testuser@leegality.com", "fromName": "Leegality Test User", "replyTo": "testuser@leegality.com", "tlsEnabled": true, "enabled": false } ``` --- ## Responses ### 200 — Notification configuration updated successfully | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `code` | string | No | Response code indicating success or failure | `LE_SCS_SS_200` | | `message` | string | No | Response message providing additional information | `Notification configuration updated successfully` | | `data` | NotificationConfigVO | No | See **NotificationConfigVO** below. | — | #### NotificationConfigVO | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `id` | string | No | Notification configuration unique identifier | `5e191ba4-3fe5-4dd4-ba7c-f2e9632c08c2` | | `emailServerHost` | string | No | Email server host address | `smtp.gmail.com` | | `emailServerPort` | string | No | Email server port | `587` | | `username` | string | No | Username for email server authentication | `himanshu.kumar@leegality.com` | | `password` | string | No | Password for email server authentication | `NewPassword@123` | | `fromEmail` | string | No | Email address used in the 'From' field of outgoing emails | `himanshu.kumar@leegality.com` | | `fromName` | string | No | Name used in the 'From' field of outgoing emails | `Himanshu Kumar` | | `replyTo` | string | No | Email address used in the 'Reply-To' field of outgoing emails | `himanshu.kumar@leegality.com` | | `tlsEnabled` | boolean | No | Indicates whether TLS is enabled for email communication | `true` | | `createdAt` | string | No | The date and time when the notification configuration was created | `2025-10-10T15:42:45` | | `enabled` | boolean | No | Indicates whether the notification configuration is enabled | `false` | ### 400 — Invalid request data | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `code` | string | No | Top-level error code | `LE_ERR_SS_400` | | `errors` | array\ | No | List of error details See **ErrorDetailUpdateNotificationConfig400VO** below. | — | #### ErrorDetailUpdateNotificationConfig400VO | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `message` | string | No | Detailed error message | `Invalid value for field [replyTo], Reply to must be a valid ` | | `path` | string | No | API path that generated the error | `/api/v1/notification-config` | ### 401 — Unauthorized - Invalid or expired token | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `code` | string | No | Top-level error code | `LE_ERR_SS_401` | | `errors` | array\ | No | List of error details See **ErrorDetail401Unauthorized** below. | — | #### ErrorDetail401Unauthorized | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `message` | string | No | Detailed error message | `Invalid or expired token` | | `path` | string | No | API path that generated the error | `/api/v1/*` | | `code` | string | No | Specific error code | `LE_ERR_SS_303` | ### 404 — Configuration not found | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `code` | string | No | Top-level error code | `LE_ERR_SS_404` | | `errors` | array\ | No | List of error details See **ErrorDetailUpdateNotificationConfig404VO** below. | — | #### ErrorDetailUpdateNotificationConfig404VO | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `message` | string | No | Detailed error message | `Configuration not found.` | | `path` | string | No | API path that generated the error | `/api/v1/notification-config` | | `code` | string | No | Specific error code | `LE_ERR_SS_1301` | ### 500 — Internal server error | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `code` | string | No | Top-level error code | `LE_ERR_SS_500` | | `errors` | array\ | No | List of error details See **ErrorDetailToken500VO** below. | — | #### ErrorDetailToken500VO | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `message` | string | No | Detailed error message | `Internal Server Error` | | `path` | string | No | API path that generated the error | `null` | | `code` | string | No | Specific error code | `null` | ### Sample Response (200) ```json { "code": "LE_SCS_SS_200", "message": "Notification configuration updated successfully", "data": { "id": "5e191ba4-3fe5-4dd4-ba7c-f2e9632c08c2", "emailServerHost": "smtp.gmail.com", "emailServerPort": "587", "username": "himanshu.kumar@leegality.com", "password": "NewPassword@123", "fromEmail": "himanshu.kumar@leegality.com", "fromName": "Himanshu Kumar", "replyTo": "himanshu.kumar@leegality.com", "tlsEnabled": true, "createdAt": "2025-10-10T15:42:45", "enabled": false } } ``` --- URL: https://knowledge.leegality.com/sign-station/api/update-notification-rule # PUT /api/v1/notification-rules/{id} — Update notification rule Updates notification rule by ID for the current user's organization **Authentication:** `X-Auth-Token` header required on every request. ## Request URL ``` PUT https://app1.leegality.com/api/api/v1/notification-rules/{id} ``` **Environments:** - Production: `https://app1.leegality.com/api/api/v1/notification-rules/{id}` - Sandbox: `https://sandbox.leegality.com/api/api/v1/notification-rules/{id}` --- ## Parameters | Name | In | Required | Type | Description | Example | |------|----|----------|------|-------------|---------| | `id` | path | Yes | string | Notification rule ID to be updated. | — | --- ## Request Body **Content-Type:** `application/json` Notification rule data to create | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `ruleType` | string | Yes | Type of notification rule Allowed: `USER_CREATED`, `USER_DELETED`, `DOCUMENT_SIGNED`, `LICENSE_EXPIRY_REMINDER`, `LICENSE_EXPIRED`, `CERTIFICATE_EXPIRED`. | `USER_CREATED` | | `additionalEmailRecipients` | array\ | No | Additional email recipients for notifications | `anaghaputhur2018@gmail.com` | | `userIds` | array\ | No | User IDs to be notified | `0e663652-1198-4777-8139-3efeda8e1d77` | | `enabled` | boolean | No | Indicates whether the notification rule is enabled | `true` | ### Sample Request ```json { "ruleType": "USER_CREATED", "additionalEmailRecipients": [ "anaghaputhur2018@gmail.com" ], "userIds": [ "0e663652-1198-4777-8139-3efeda8e1d77" ], "enabled": true } ``` --- ## Responses ### 200 — Notification rule updated successfully | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `code` | string | No | Response code indicating success or failure | `LE_SS_004` | | `message` | string | No | Response message providing additional information | `Notification rule updated successfully.` | | `data` | NotificationRuleVO | No | See **NotificationRuleVO** below. | — | #### NotificationRuleVO | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `id` | string | No | Notification rule unique identifier | `a2787f6c-e00c-4bd9-ad34-ed88b8fcf54f` | | `ruleType` | string | No | Type of notification rule Allowed: `USER_CREATED`, `USER_DELETED`, `DOCUMENT_SIGNED`, `LICENSE_EXPIRY_REMINDER`, `LICENSE_EXPIRED`, `CERTIFICATE_EXPIRED`. | `USER_CREATED` | | `additionalEmailRecipients` | array\ | No | Additional email recipients for notifications | `anaghaputhur2018@gmail.com` | | `notifyUsers` | array\ | No | See **NotificationRuleUserVO** below. | — | | `enabled` | boolean | No | Indicates whether the notification rule is enabled | `true` | | `createdAt` | string | No | The date and time when the notification rule was created | `2025-10-10T15:47:41` | ##### NotificationRuleUserVO | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `id` | string | No | User unique identifier | `f6b0449d-b866-4647-b5c5-9ce765eb1184` | | `name` | string | No | Full name of the user | `Anagha Babu` | | `email` | string | No | Email address of the user | `anagha.babu@leegality.com` | | `active` | boolean | No | Indicates whether the user is active (enabled) or inactive (disabled) | `true` | | `enabled` | boolean | No | Indicates whether the user is enabled or disabled | `false` | ### 400 — Invalid request data | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `code` | string | No | Top-level error code | `LE_ERR_SS_400` | | `errors` | array\ | No | List of error details See **ErrorDetailNotificationRuleUpdate400VO** below. | — | #### ErrorDetailNotificationRuleUpdate400VO | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `message` | string | No | Detailed error message | `Invalid request payload.` | | `path` | string | No | API path that generated the error | `/api/v1/notification-rules/a2787f6c-e00c-4bd9-ad34-ed88b8fcf` | ### 401 — Unauthorized - Invalid or expired token | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `code` | string | No | Top-level error code | `LE_ERR_SS_401` | | `errors` | array\ | No | List of error details See **ErrorDetail401Unauthorized** below. | — | #### ErrorDetail401Unauthorized | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `message` | string | No | Detailed error message | `Invalid or expired token` | | `path` | string | No | API path that generated the error | `/api/v1/*` | | `code` | string | No | Specific error code | `LE_ERR_SS_303` | ### 500 — Internal server error | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `code` | string | No | Top-level error code | `LE_ERR_SS_500` | | `errors` | array\ | No | List of error details See **ErrorDetailToken500VO** below. | — | #### ErrorDetailToken500VO | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `message` | string | No | Detailed error message | `Internal Server Error` | | `path` | string | No | API path that generated the error | `null` | | `code` | string | No | Specific error code | `null` | ### Sample Response (200) ```json { "code": "LE_SS_004", "message": "Notification rule updated successfully.", "data": { "id": "a2787f6c-e00c-4bd9-ad34-ed88b8fcf54f", "ruleType": "USER_CREATED", "additionalEmailRecipients": [ "anaghaputhur2018@gmail.com" ], "notifyUsers": [ { "id": "f6b0449d-b866-4647-b5c5-9ce765eb1184", "name": "Anagha Babu", "email": "anagha.babu@leegality.com", "active": true, "enabled": false } ], "enabled": true, "createdAt": "2025-10-10T15:47:41" } } ``` --- URL: https://knowledge.leegality.com/sign-station/api/update-password-policy # PUT /api/v1/password-policy — Update password policy Updates password policy for the current user's organization. You can update the policy as many times as needed. **Authentication:** `X-Auth-Token` header required on every request. ## Request URL ``` PUT https://app1.leegality.com/api/api/v1/password-policy ``` **Environments:** - Production: `https://app1.leegality.com/api/api/v1/password-policy` - Sandbox: `https://sandbox.leegality.com/api/api/v1/password-policy` --- ## Request Body **Content-Type:** `application/json` Password policy data to create | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `minimumPasswordLength` | integer | Yes | Minimum length required for passwords | `8` | | `numbersRequired` | boolean | Yes | Indicates if numbers are required in passwords | `true` | | `specialCharactersRequired` | boolean | Yes | Indicates if special characters are required in passwords | `true` | | `uppercaseRequired` | boolean | Yes | Indicates if uppercase letters are required in passwords | `true` | ### Sample Request ```json { "minimumPasswordLength": 8, "numbersRequired": true, "specialCharactersRequired": true, "uppercaseRequired": true } ``` --- ## Responses ### 200 — Password policy updated successfully | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `code` | string | No | Response code indicating success or failure | `LE_SCS_SS_200` | | `message` | string | No | Response message providing additional information | `Password policy updated successfully` | | `data` | PasswordPolicyVO | No | See **PasswordPolicyVO** below. | — | #### PasswordPolicyVO | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `id` | string | No | Password policy unique identifier | `9ef35b27-86c8-4450-8807-317c37a61aae` | | `minimumPasswordLength` | integer | No | Minimum length required for passwords | `6` | | `numbersRequired` | boolean | No | Indicates if numbers are required in passwords | `false` | | `specialCharactersRequired` | boolean | No | Indicates if special characters are required in passwords | `false` | | `uppercaseRequired` | boolean | No | Indicates if uppercase letters are required in passwords | `true` | | `createdAt` | string | No | The date and time when the password policy was created | `2025-10-10T15:58:34` | ### 400 — Invalid request data | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `code` | string | No | Top-level error code | `LE_ERR_SS_400` | | `errors` | array\ | No | List of error details See **ErrorDetailPasswordPolicyUpdate400VO** below. | — | #### ErrorDetailPasswordPolicyUpdate400VO | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `message` | string | No | Detailed error message | `Invalid request payload.` | | `path` | string | No | API path that generated the error | `/api/v1/password-policy` | ### 401 — Unauthorized - Invalid or expired token | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `code` | string | No | Top-level error code | `LE_ERR_SS_401` | | `errors` | array\ | No | List of error details See **ErrorDetail401Unauthorized** below. | — | #### ErrorDetail401Unauthorized | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `message` | string | No | Detailed error message | `Invalid or expired token` | | `path` | string | No | API path that generated the error | `/api/v1/*` | | `code` | string | No | Specific error code | `LE_ERR_SS_303` | ### 500 — Internal server error | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `code` | string | No | Top-level error code | `LE_ERR_SS_500` | | `errors` | array\ | No | List of error details See **ErrorDetailToken500VO** below. | — | #### ErrorDetailToken500VO | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `message` | string | No | Detailed error message | `Internal Server Error` | | `path` | string | No | API path that generated the error | `null` | | `code` | string | No | Specific error code | `null` | ### Sample Response (200) ```json { "code": "LE_SCS_SS_200", "message": "Password policy updated successfully", "data": { "id": "9ef35b27-86c8-4450-8807-317c37a61aae", "minimumPasswordLength": 6, "numbersRequired": false, "specialCharactersRequired": false, "uppercaseRequired": true, "createdAt": "2025-10-10T15:58:34" } } ``` --- URL: https://knowledge.leegality.com/sign-station/api/update-role # PUT /api/v1/roles/{id} — Update role Updates role by ID for the current user's organization **Authentication:** `X-Auth-Token` header required on every request. ## Request URL ``` PUT https://app1.leegality.com/api/api/v1/roles/{id} ``` **Environments:** - Production: `https://app1.leegality.com/api/api/v1/roles/{id}` - Sandbox: `https://sandbox.leegality.com/api/api/v1/roles/{id}` --- ## Parameters | Name | In | Required | Type | Description | Example | |------|----|----------|------|-------------|---------| | `id` | path | Yes | string | Role ID to be updated | — | --- ## Request Body **Content-Type:** `application/json` Role data to create | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `name` | string | Yes | Role name. E.g., "Admin", "User" etc. | — | | `entitlementIds` | array\ | No | Entitlement IDs to assign to the role | — | ### Sample Request ```json { "name": "string", "entitlementIds": [ "string" ] } ``` --- ## Responses ### 200 — Role updated successfully | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `code` | string | No | Response code indicating success or failure | — | | `message` | string | No | Response message providing additional information | — | | `data` | RoleVO | No | See **RoleVO** below. | — | #### RoleVO | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `id` | string | No | Role ID. This is configured during the role creation. | `b0af5f43-7f34-4ea4-867a-10115642f354` | | `name` | string | No | Role name. E.g., "Admin", "User" etc. | `Admin` | | `createdAt` | string | No | The date and time when the role was created | `2025-12-15T10:20:30Z` | | `entitlements` | array\ | No | See **EntitlementVO** below. | — | ##### EntitlementVO | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `id` | string | No | Entitlement ID. This is configured in the system and cannot be changed. | `3fa85f64-5717-4562-b3fc-2c963f66afa6` | | `name` | string | No | Entitlement name. E.g., "DOCUMENT_SIGN","USER_MANAGEMENT" | `DOCUMENT_SIGN` | ### 400 — Invalid request payload | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `code` | string | No | Top-level error code | `LE_ERR_SS_400` | | `errors` | array\ | No | List of error details See **ErrorDetailUpdateRole400VO** below. | — | #### ErrorDetailUpdateRole400VO | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `message` | string | No | Detailed error message | `Invalid request payload.` | | `path` | string | No | API path that generated the error | `/api/v1/roles/51f93ec7-c06a-4fe1-a8b1-eaf7a1c0fb5e` | ### 401 — Unauthorized - Invalid or expired token | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `code` | string | No | Top-level error code | `LE_ERR_SS_401` | | `errors` | array\ | No | List of error details See **ErrorDetail401Unauthorized** below. | — | #### ErrorDetail401Unauthorized | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `message` | string | No | Detailed error message | `Invalid or expired token` | | `path` | string | No | API path that generated the error | `/api/v1/*` | | `code` | string | No | Specific error code | `LE_ERR_SS_303` | ### 404 — Role or Entitlement not found | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `code` | string | No | Top-level error code | `LE_ERR_SS_404` | | `errors` | array\ | No | List of error details See **ErrorDetailUpdateRole404VO** below. | — | #### ErrorDetailUpdateRole404VO | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `message` | string | No | Detailed error message | `Entitlement with id null does not exist.` | | `path` | string | No | API path that generated the error | `/api/v1/roles/51f93ec7-c06a-4fe1-a8b1-eaf7a1c0fb5e` | | `code` | string | No | Specific error code | `LE_ERR_SS_001` | ### 500 — Internal server error | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `code` | string | No | Top-level error code | `LE_ERR_SS_500` | | `errors` | array\ | No | List of error details See **ErrorDetailToken500VO** below. | — | #### ErrorDetailToken500VO | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `message` | string | No | Detailed error message | `Internal Server Error` | | `path` | string | No | API path that generated the error | `null` | | `code` | string | No | Specific error code | `null` | ### Sample Response (200) ```json { "code": "string", "message": "string", "data": { "id": "b0af5f43-7f34-4ea4-867a-10115642f354", "name": "Admin", "createdAt": "2025-12-15T10:20:30Z", "entitlements": [ { "id": "3fa85f64-5717-4562-b3fc-2c963f66afa6", "name": "DOCUMENT_SIGN" } ] } } ``` --- URL: https://knowledge.leegality.com/sign-station/api/update-settings # PUT /api/v1/settings — Update settings Updates settings for the current user's organization **Authentication:** `X-Auth-Token` header required on every request. ## Request URL ``` PUT https://app1.leegality.com/api/api/v1/settings ``` **Environments:** - Production: `https://app1.leegality.com/api/api/v1/settings` - Sandbox: `https://sandbox.leegality.com/api/api/v1/settings` --- ## Request Body **Content-Type:** `application/json` Settings data to update | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `documentRetentionEnabled` | boolean | No | Indicates if document retention is enabled | `true` | | `documentRetentionPeriod` | integer | No | Document retention period in days | `100` | | `auditLogsRetentionEnabled` | boolean | No | Indicates if audit logs retention is enabled | `true` | | `auditLogsRetentionPeriod` | integer | No | Audit logs retention period in days | `100` | | `auditTrailGenerationEnabled` | boolean | No | Indicates if audit trail generation is enabled | `true` | ### Sample Request ```json { "documentRetentionEnabled": true, "documentRetentionPeriod": 100, "auditLogsRetentionEnabled": true, "auditLogsRetentionPeriod": 100, "auditTrailGenerationEnabled": true } ``` --- ## Responses ### 200 — Settings updated successfully | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `code` | string | No | Response code indicating success or failure | `LE_SS_004` | | `message` | string | No | Response message providing additional information | `Settings updated successfully.` | | `data` | SettingsVO | No | See **SettingsVO** below. | — | #### SettingsVO | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `id` | string | No | Settings ID. This is configured during the settings creation. | `ed99d2dd-f44e-4278-a3e2-13a1ed2be13c` | | `documentRetentionEnabled` | boolean | No | Indicates if document retention is enabled | `true` | | `documentRetentionPeriod` | integer | No | Document retention period in days | `30` | | `auditLogsRetentionEnabled` | boolean | No | Indicates if audit logs retention is enabled | `true` | | `auditLogsRetentionPeriod` | integer | No | Audit logs retention period in days | `90` | | `auditTrailGenerationEnabled` | boolean | No | Indicates if audit trail generation is enabled | `true` | | `createdAt` | string | No | The date and time when the settings were created | `2025-12-08T15:28:26` | ### 400 — Invalid request data | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `code` | string | No | Top-level error code | `LE_ERR_SS_400` | | `errors` | array\ | No | List of error details See **ErrorDetailSettings400VO** below. | — | #### ErrorDetailSettings400VO | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `message` | string | No | Detailed error message | `Invalid request payload.` | | `path` | string | No | API path that generated the error | `/api/v1/settings` | ### 401 — Unauthorized - Invalid or expired token | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `code` | string | No | Top-level error code | `LE_ERR_SS_401` | | `errors` | array\ | No | List of error details See **ErrorDetail401Unauthorized** below. | — | #### ErrorDetail401Unauthorized | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `message` | string | No | Detailed error message | `Invalid or expired token` | | `path` | string | No | API path that generated the error | `/api/v1/*` | | `code` | string | No | Specific error code | `LE_ERR_SS_303` | ### 404 — Settings not found | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `code` | string | No | Top-level error code | `LE_ERR_SS_404` | | `errors` | array\ | No | List of error details See **ErrorDetailUpdateSettings404VO** below. | — | #### ErrorDetailUpdateSettings404VO | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `message` | string | No | Detailed error message | `Settings not found for organization 57270dc1-681d-4cd9-9268-` | | `path` | string | No | API path that generated the error | `/api/v1/settings` | | `code` | string | No | Specific error code | `LE_ERR_SS_203` | ### 500 — Internal server error | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `code` | string | No | Top-level error code | `LE_ERR_SS_500` | | `errors` | array\ | No | List of error details See **ErrorDetailToken500VO** below. | — | #### ErrorDetailToken500VO | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `message` | string | No | Detailed error message | `Internal Server Error` | | `path` | string | No | API path that generated the error | `null` | | `code` | string | No | Specific error code | `null` | ### Sample Response (200) ```json { "code": "LE_SS_004", "message": "Settings updated successfully.", "data": { "id": "ed99d2dd-f44e-4278-a3e2-13a1ed2be13c", "documentRetentionEnabled": true, "documentRetentionPeriod": 30, "auditLogsRetentionEnabled": true, "auditLogsRetentionPeriod": 90, "auditTrailGenerationEnabled": true, "createdAt": "2025-12-08T15:28:26" } } ``` --- URL: https://knowledge.leegality.com/sign-station/api/update-user # PATCH /api/v1/users/{id} — Update user Updates an existing user by ID. Prevents removing admin role from the last admin user. **Authentication:** `X-Auth-Token` header required on every request. ## Request URL ``` PATCH https://app1.leegality.com/api/api/v1/users/{id} ``` **Environments:** - Production: `https://app1.leegality.com/api/api/v1/users/{id}` - Sandbox: `https://sandbox.leegality.com/api/api/v1/users/{id}` --- ## Parameters | Name | In | Required | Type | Description | Example | |------|----|----------|------|-------------|---------| | `id` | path | Yes | string | ID of the user to be updated. | — | --- ## Request Body **Content-Type:** `application/json` Updated user data | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `name` | string | Yes | Full name of the user | — | | `email` | string | Yes | Email address of the user | — | | `password` | string | No | Password for the user account | — | | `active` | boolean | No | Indicates whether the user is active (enabled) or inactive (disabled) | — | | `departmentIds` | array\ | No | List of department IDs the user belongs to | — | | `roleIds` | array\ | Yes | List of role IDs assigned to the user | — | ### Sample Request ```json { "name": "string", "email": "string", "password": "string", "active": false, "departmentIds": [ "string" ], "roleIds": [ "string" ] } ``` --- ## Responses ### 200 — User updated successfully | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `code` | string | No | Response status code | `LE_SS_001` | | `message` | string | No | Response message | `User retrieved successfully.` | | `data` | UserVO | No | See **UserVO** below. | — | #### UserVO | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `id` | string | No | User unique identifier | `37d14717-5c1a-44fe-9b8f-6d5184b09f06` | | `name` | string | No | Full name of the user | `John Doe` | | `email` | string | No | Email address of the user | `user@example.com` | | `active` | boolean | No | Indicates whether the user is active (enabled) or inactive (disabled) | `true` | | `enabled` | boolean | No | Indicates whether the user is enabled or disabled | `true` | | `createdAt` | string | No | The date and time when the user was created | `2025-12-15T10:20:30Z` | | `departments` | array\ | No | See **DepartmentVO** below. | — | | `roles` | array\ | No | See **RoleVO** below. | — | ##### DepartmentVO | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `id` | string | No | Department unique identifier | `3fa85f64-5717-4562-b3fc-2c963f66afa6` | | `name` | string | No | The department's name (e.g., "Human Resources"). | `Human Resources` | | `enabled` | boolean | No | Indicates whether the department is active or inactive. | `true` | | `createdAt` | string | No | The date and time when the department was created. | `2025-12-15T10:20:30Z` | | `totalUsers` | integer | No | Total number of users in the department. | `25` | ##### RoleVO | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `id` | string | No | Role ID. This is configured during the role creation. | `b0af5f43-7f34-4ea4-867a-10115642f354` | | `name` | string | No | Role name. E.g., "Admin", "User" etc. | `Admin` | | `createdAt` | string | No | The date and time when the role was created | `2025-12-15T10:20:30Z` | | `entitlements` | array\ | No | See **EntitlementVO** below. | — | ###### EntitlementVO | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `id` | string | No | Entitlement ID. This is configured in the system and cannot be changed. | `3fa85f64-5717-4562-b3fc-2c963f66afa6` | | `name` | string | No | Entitlement name. E.g., "DOCUMENT_SIGN","USER_MANAGEMENT" | `DOCUMENT_SIGN` | ### 400 — Invalid request data or attempting to remove admin role from the last admin user | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `code` | string | No | Top-level error code | `LE_ERR_SS_400` | | `errors` | array\ | No | List of error details See **ErrorDetailUpdateUser400VO** below. | — | #### ErrorDetailUpdateUser400VO | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `message` | string | No | Detailed error message | `Invalid value for field [email], Email must be valid` | | `path` | string | No | API path that generated the error | `/api/v1/users/{id}` | | `code` | string | No | Specific error code | `null` | ### 401 — Unauthorized - Invalid or expired token | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `code` | string | No | Top-level error code | `LE_ERR_SS_401` | | `errors` | array\ | No | List of error details See **ErrorDetail401Unauthorized** below. | — | #### ErrorDetail401Unauthorized | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `message` | string | No | Detailed error message | `Invalid or expired token` | | `path` | string | No | API path that generated the error | `/api/v1/*` | | `code` | string | No | Specific error code | `LE_ERR_SS_303` | ### 404 — User not found | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `code` | string | No | Top-level error code | `LE_ERR_SS_404` | | `errors` | array\ | No | List of error details See **ErrorDetailUpdateUser404VO** below. | — | #### ErrorDetailUpdateUser404VO | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `message` | string | No | Detailed error message | `Role does not exist.` | | `path` | string | No | API path that generated the error | `/api/v1/users/f6b0449d-b866-4647-b5c5-9ce765eb1184` | | `code` | string | No | Specific error code | `LE_ERR_SS_001` | ### 409 — Email already exists | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `code` | string | No | Top-level error code | `LE_ERR_SS_409` | | `errors` | array\ | No | List of error details See **ErrorDetailUpdateUser409VO** below. | — | #### ErrorDetailUpdateUser409VO | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `message` | string | No | Detailed error message | `User with email 'existing@example.com' already exists.` | | `path` | string | No | API path that generated the error | `/api/v1/users/{id}` | | `code` | string | No | Specific error code | `LE_ERR_SS_701` | ### 500 — Internal server error | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `code` | string | No | Top-level error code | `LE_ERR_SS_500` | | `errors` | array\ | No | List of error details See **ErrorDetailToken500VO** below. | — | #### ErrorDetailToken500VO | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `message` | string | No | Detailed error message | `Internal Server Error` | | `path` | string | No | API path that generated the error | `null` | | `code` | string | No | Specific error code | `null` | ### Sample Response (200) ```json { "code": "LE_SS_001", "message": "User retrieved successfully.", "data": { "id": "37d14717-5c1a-44fe-9b8f-6d5184b09f06", "name": "John Doe", "email": "user@example.com", "active": true, "enabled": true, "createdAt": "2025-12-15T10:20:30Z", "departments": [ { "id": "3fa85f64-5717-4562-b3fc-2c963f66afa6", "name": "Human Resources", "enabled": true, "createdAt": "2025-12-15T10:20:30Z", "totalUsers": 25 } ], "roles": [ { "id": "b0af5f43-7f34-4ea4-867a-10115642f354", "name": "Admin", "createdAt": "2025-12-15T10:20:30Z", "entitlements": [ { "id": "3fa85f64-5717-4562-b3fc-2c963f66afa6", "name": "DOCUMENT_SIGN" } ] } ] } } ``` --- URL: https://knowledge.leegality.com/sign-station/api/update # PUT /api/v1/departments/{id} — Update department Updates an existing department for the current user's organization. The request body requires all department properties, even if only updating one. **Authentication:** `X-Auth-Token` header required on every request. ## Request URL ``` PUT https://app1.leegality.com/api/api/v1/departments/{id} ``` **Environments:** - Production: `https://app1.leegality.com/api/api/v1/departments/{id}` - Sandbox: `https://sandbox.leegality.com/api/api/v1/departments/{id}` --- ## Parameters | Name | In | Required | Type | Description | Example | |------|----|----------|------|-------------|---------| | `id` | path | Yes | string | Department ID to be updated | — | --- ## Request Body **Content-Type:** `application/json` | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `name` | string | Yes | The updated department name (e.g., "Human Resources"). Must be between 2 and 255 characters. | — | | `enabled` | boolean | No | Shows the updated status of the department. For an active department, the value is set to true; for an inactive department, it is set to false. | — | ### Sample Request ```json { "name": "string", "enabled": false } ``` --- ## Responses ### 200 — Department updated successfully | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `code` | string | No | Response status code | — | | `message` | string | No | Response message | — | | `data` | DepartmentVO | No | See **DepartmentVO** below. | — | #### DepartmentVO | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `id` | string | No | Department unique identifier | `3fa85f64-5717-4562-b3fc-2c963f66afa6` | | `name` | string | No | The department's name (e.g., "Human Resources"). | `Human Resources` | | `enabled` | boolean | No | Indicates whether the department is active or inactive. | `true` | | `createdAt` | string | No | The date and time when the department was created. | `2025-12-15T10:20:30Z` | | `totalUsers` | integer | No | Total number of users in the department. | `25` | ### 400 — Invalid request data | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `code` | string | No | Top-level error code | `LE_ERR_SS_400` | | `errors` | array\ | No | List of error details See **ErrorDetailUpdateDepartment400VO** below. | — | #### ErrorDetailUpdateDepartment400VO | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `message` | string | No | Detailed error message | `Invalid value for field [name], Department name must be betw` | | `path` | string | No | API path that generated the error | `/api/v1/departments/{id}` | | `code` | string | No | Specific error code | `null` | ### 401 — Unauthorized - Invalid or expired token | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `code` | string | No | Top-level error code | `LE_ERR_SS_401` | | `errors` | array\ | No | List of error details See **ErrorDetail401Unauthorized** below. | — | #### ErrorDetail401Unauthorized | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `message` | string | No | Detailed error message | `Invalid or expired token` | | `path` | string | No | API path that generated the error | `/api/v1/*` | | `code` | string | No | Specific error code | `LE_ERR_SS_303` | ### 404 — Department not found | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `code` | string | No | Top-level error code | `LE_ERR_SS_404` | | `errors` | array\ | No | List of error details See **ErrorDetailUpdateDepartment404VO** below. | — | #### ErrorDetailUpdateDepartment404VO | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `message` | string | No | Detailed error message | `Department does not exist.` | | `path` | string | No | API path that generated the error | `/api/v1/departments/acd77746-6eb2-4ad3-9356-e9f12f7ef502` | | `code` | string | No | Specific error code | `LE_ERR_SS_001` | ### 500 — Internal server error | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `code` | string | No | Top-level error code | `LE_ERR_SS_500` | | `errors` | array\ | No | List of error details See **ErrorDetailToken500VO** below. | — | #### ErrorDetailToken500VO | Field | Type | Required | Description | Example | |-------|------|----------|-------------|---------| | `message` | string | No | Detailed error message | `Internal Server Error` | | `path` | string | No | API path that generated the error | `null` | | `code` | string | No | Specific error code | `null` | ### Sample Response (200) ```json { "code": "string", "message": "string", "data": { "id": "3fa85f64-5717-4562-b3fc-2c963f66afa6", "name": "Human Resources", "enabled": true, "createdAt": "2025-12-15T10:20:30Z", "totalUsers": 25 } } ``` --- # User Management URL: https://knowledge.leegality.com/sign-station/api/user-management.tag > User Management The User Management API provides endpoints for managing users within an organization. Users are individuals who can log in to the SignStation platform and perform various actions based on their assigned roles and permissions. All user operations are scoped to the authenticated user's organization. Use this API to create, retrieve, update, and delete users as needed. For the dashboard workflow, see [User Management](https://knowledge.leegality.com/sign-station/user-management). ```mdx-code-block ``` --- URL: https://knowledge.leegality.com/ai-readable # A Guide for LLMs and AI This knowledge base is built on a JavaScript framework — fetching a page URL returns an empty HTML shell, not readable content. To make it fully accessible to AI tools and crawlers, every page is also published as a plain `.txt` file containing clean markdown. Base URL: `https://knowledge.leegality.com` ### Available Resources | Resource | Full URL | Notes | |----------|----------|-------| | **Page index** | [`https://knowledge.leegality.com/llms.txt`](https://knowledge.leegality.com/llms.txt) | Index of all pages. Each line: `[Title](url.txt): description`. Start here. | | **Full content** | [`https://knowledge.leegality.com/llms-full.txt`](https://knowledge.leegality.com/llms-full.txt) | All pages concatenated. Fetch once to load the entire knowledge base into context. | | **Per-page content** | `https://knowledge.leegality.com/.txt` | Append `.txt` to any page URL. Example: [`/document-execution/api/create-an-e-signing-request.txt`](https://knowledge.leegality.com/document-execution/api/create-an-e-signing-request.txt) | | **OpenAPI spec** | [`https://knowledge.leegality.com/openapi.json`](https://knowledge.leegality.com/openapi.json) | OpenAPI 3.0 spec for the full REST API. | --- ### How AI should read this knowledge base 1. Fetch `https://knowledge.leegality.com/llms.txt` — this gives you a structured index of every page with titles, `.txt` links, and descriptions. 2. From the index, fetch individual `.txt` URLs for the pages you need. Each `.txt` file is the full page content as plain markdown, served as `text/plain`. 3. For API integration, fetch `https://knowledge.leegality.com/openapi.json` for the complete OpenAPI 3.0 spec. 4. To load everything at once, fetch `https://knowledge.leegality.com/llms-full.txt` instead of steps 1–2. > **Why `.txt` and not `.md`?** Both exist, but `.md` files are served as binary downloads (`application/octet-stream`) — browsers and AI tools can't read them inline. `.txt` files are served as `text/plain` and are readable directly. --- ### How to use it **With Claude, ChatGPT, or any LLM:** Paste a `.txt` URL directly into your conversation. Example: ``` https://knowledge.leegality.com/document-execution/api/create-an-e-signing-request.txt ``` **With Cursor:** Use `@Docs` → add `https://knowledge.leegality.com/llms.txt`. Cursor will index all pages and make them available as context. **With any HTTP client:** ```bash # Get the full knowledge base in one request curl https://knowledge.leegality.com/llms-full.txt # Get a specific page curl https://knowledge.leegality.com/document-execution/getting-started/create-an-account.txt ``` --- ### On every page Each doc page has a **Copy page** button in the top-right corner. It copies that page's markdown directly to your clipboard — ready to paste into any AI tool. The dropdown also has **View markdown** (opens the `.txt` in browser) and **Download markdown** (saves the `.md` file locally). --- URL: https://knowledge.leegality.com # Introduction to Document Execution Everything your business needs to digitize document execution process, all under one roof. ## Explore Leegality [Getting Started Start using Leegality for eSigning](https://knowledge.leegality.com/category/getting-started) [Templates Create reusable Templates for frequent document journeys](https://knowledge.leegality.com/document-execution/template) [Stamps Affix digital stamps to documents](https://knowledge.leegality.com/document-execution/stamps) [Account Configure account level setting](https://knowledge.leegality.com/category/settings) [Manage Documents Efficiently manage documents you have sent and received](https://knowledge.leegality.com/document-execution/manage-documents/overview) [Workflows Create Workflows to automate the sending journey process](https://knowledge.leegality.com/document-execution/workflows/overview) --- URL: https://knowledge.leegality.com/document-execution/api/sdks/authentication # Sender Login When you set `auth: true` in `journeyOptions`, the sender must log in to their Leegality account inside the popup before the journey starts. This is the stronger of the two authentication paths — the sender actively proves their identity, rather than relying on the signed URL alone. ## When to use it | `auth` | What happens | Security level | |---|---|---| | `false` (default) | The signed URL is the credential. Whoever holds the URL can open the journey immediately. | The client vouched for this sender when it created the draft. | | `true` | The sender must log in. The account they log into must match the `email` in `journeyOptions`. | The sender actively proves their identity. | Use `auth: true` when you need to confirm the person at the keyboard is the intended sender — not just someone who obtained the link. ## What happens inside the popup The entire login flow happens **inside the popup window** and is handled entirely by Leegality. Your page does nothing — no redirects, no token management, no extra code. Here is what happens step by step: 1. The SDK opens the popup with the signed URL. 2. The popup calls Leegality's boot endpoint. Because `auth: true` is encoded in the URL, the boot response comes back with `outcome: "AUTHENTICATION_REQUIRED"` instead of `outcome: "AUTHENTICATED"`. 3. The popup redirects to Leegality's login page. If you provided an `email` in `journeyOptions`, the email field is pre-filled (but editable). 4. The sender logs in with their credentials. 5. On successful login, the popup redirects back to the original signed URL with a login token. 6. The boot endpoint is called again, this time with the login token. If the logged-in email matches the one in the URL, the response comes back with `outcome: "AUTHENTICATED"` and the journey begins. > **Info — The login uses PKCE** > > The login flow uses PKCE (Proof Key for Code Exchange), the standard OAuth mechanism for browser apps that cannot keep a client secret. This is all handled internally — you do not need to understand or implement PKCE. ## What your code needs to do Nothing. The `auth` option is set at draft creation and the rest is automatic: ```json { "workflowId": "", "journeyOptions": { "auth": true, "email": "sender@example.com" } } ``` Your `onEvent` callback works identically whether `auth` is `true` or `false`. The events are the same — the only difference is that the sender sees a login screen before the journey starts. ## Login failures If the login fails (the sender cancels, enters wrong credentials, or the code exchange fails), your `onEvent` callback receives an `ERROR` event: ```json { "type": "ERROR", "data": { "journeyId": "mg7x2k0p-1", "workflowRunContextId": null, "lastPage": null, "errors": [ { "errorCode": "access_denied", "errorMessage": "Request failed with status code 400" } ], "source": "leegality-sdk", "timestamp": "05-10-2026 13:45:07" } } ``` The `errorCode` is the OAuth code from the auth server — `access_denied` (sender cancelled), `invalid_grant` (code exchange failed), or `auth_failed` (the return URL was corrupted). All are terminal — create a fresh draft to try again. ## Email enforcement When `auth: true` is set with an `email`, the boot endpoint verifies that the logged-in account matches the email encoded in the signed URL. If they do not match, the boot call returns a 403 and the journey does not start. The sender sees an error and your callback receives an `ERROR` event. This means: - The `email` field pre-fills the login form but does **not** lock it — the sender can type a different address. - If they log in with a different address, the 403 stops them. ## Re-issue warning When you [re-issue a URL](https://knowledge.leegality.com/document-execution/api/sdks/draft-api#re-issue-a-url), the `auth` option is **not** remembered from the original create call. If you omit it on re-issue, it falls back to the department default (typically `false`), meaning anyone with the new URL can open the journey without logging in. Always re-supply `auth: true` when re-issuing URLs for drafts that require sender login. --- URL: https://knowledge.leegality.com/document-execution/api/sdks/draft-api # Draft API The Draft API creates a pack draft on your backend and returns a **signed launch URL** that the SDK opens in a popup. Your org API token stays on your server — the browser never sees it. ## Create a draft ``` POST https:///document-infrastructure/api/v4/pack/draft Authorization: Bearer Content-Type: application/json ``` ### Request body ```json { "workflowId": "0499d58e-6336-420a-bc96-52ec5671aabb", "journeyOptions": { "expiresIn": 60, "auth": false, "email": null, "successScreenAutoCloseMs": 3000, "okButtonLabel": "OK", "okButtonVisible": true } } ``` | Field | Required | Description | |---|---|---| | `workflowId` | Yes | The v4 workflow to create the draft from. Get this from the Leegality dashboard. | | `journeyOptions` | No | Controls for the SDK popup window. Omit the entire block and every default applies. | ### journeyOptions These options travel inside the signed URL and cannot be tampered with on the client side. | Option | Type | Default | Description | |---|---|---|---| | `expiresIn` | number | — | Minutes until the launch URL expires. After expiry, the popup shows an expired screen. | | `auth` | boolean | `false` | `false` — the signed URL is the credential and the journey opens immediately. `true` — the sender must log in inside the popup before the journey starts. See [Sender Login](https://knowledge.leegality.com/document-execution/api/sdks/authentication). | | `email` | string | `null` | The sender's email. When `auth` is `true`, this is pre-filled on the login screen and the logged-in account must match it. | | `successScreenAutoCloseMs` | number | `3000` | How long the success screen shows before the popup closes itself, in milliseconds. Range: 0–60000. Set `0` to disable auto-close (the sender clicks the OK button instead). | | `okButtonLabel` | string | `"OK"` | Text on the success screen button. Maximum 32 characters, rendered as-is. | | `okButtonVisible` | boolean | `true` | Set `false` to hide the button and rely on auto-close alone. | ### Response ``` HTTP 201 ``` ```json { "code": "SUCCESS", "message": "Draft created", "data": { "url": "https://workflow.leegality.com/workflow/embedded-run?exp=1789622610&credentialId=v1&signature=phiQV9QGmVlD...&d=eyJ3b3JrZm...", "workflowRunContextId": "f896e856-47df-4ef7-8d98-c261542b1a0d" } } ``` | Field | Description | |---|---| | `data.url` | The signed launch URL. Pass this to `LeegalitySenderSDK.open()` untouched. | | `data.workflowRunContextId` | Unique identifier for this draft. Use it to re-issue URLs or correlate with webhooks. | ### The signed URL The URL contains four query parameters: `exp`, `credentialId`, `signature`, and `d`. Together they authenticate the request and carry your journey options to the popup. > **Danger — Do not modify the URL** > > The HMAC signature covers the query string byte-for-byte. Adding, removing, re-encoding, or reordering any parameter invalidates it. Treat the URL as one opaque string. ## Re-issue a URL If the launch URL expires or is lost, you can get a fresh one for the **same** draft. This mints a new URL with a new expiry and signature — the draft itself is unchanged. ``` GET https:///document-infrastructure/api/v4/pack/journey-url ?workflowRunContextId=f896e856-47df-4ef7-8d98-c261542b1a0d &auth=false &expiresIn=60 &successScreenAutoCloseMs=3000 &okButtonLabel=OK &okButtonVisible=true Authorization: Bearer ``` Journey options are passed as query parameters, not in a request body. ### Response ``` HTTP 200 ``` ```json { "code": "SUCCESS", "message": "Journey URL issued", "data": { "url": "https://workflow.leegality.com/workflow/embedded-run?exp=1790287814&..." } } ``` > **Warning — Journey options do not carry over from the create call** > > When you re-issue a URL, any option you omit falls back to the **department default** — not to what you sent when creating the draft. A draft created with `auth: true` and re-issued without it yields a URL that anyone holding it can open without logging in. > > Keep the options you sent alongside the `workflowRunContextId` in your own store, and repeat them on every re-issue. ## Environment hosts | Environment | Gateway host (Draft API) | |---|---| | Production | `https://gateway.leegality.com` | | Sandbox | `https://sandbox-gateway.leegality.com` | | Preprod | `https://preprod-gateway.leegality.com` | Use the gateway that matches the SDK script environment your page loads. See [SDK Reference](https://knowledge.leegality.com/document-execution/api/sdks/sdk-reference) for the script URLs. --- URL: https://knowledge.leegality.com/document-execution/api/sdks/events # Lifecycle Events The SDK delivers six lifecycle events to your `onEvent` callback as `{ type, data }`. The **type alone** tells you whether the journey is over — you never need to inspect `data.errors` to decide what to do next. ## Common fields Five fields are present on **every** event, regardless of type: | Field | Type | Description | |---|---|---| | `journeyId` | string | Identifies this journey. Always present, even on events that fire before the journey has a server-side identity. | | `workflowRunContextId` | string or `null` | The pack this event belongs to. `null` on events that fire before the session starts (boot failures, login failures, early cancellation). | | `lastPage` | string or `null` | The step the sender was on — `"Create"`, `"Invitee"`, or `"Finalise"`. `null` if the journey had not rendered yet. | | `source` | string | Always `"leegality-sdk"`. | | `timestamp` | string | `dd-MM-yyyy HH:mm:ss` in IST. Same format and timezone as Leegality's webhooks. | ## Events ### COMPLETED **Terminal.** The sender finished the journey and the pack was sent. ```json { "type": "COMPLETED", "data": { "journeyId": "mg7x2k0p-1", "workflowRunContextId": "a3f1...", "lastPage": "Finalise", "source": "leegality-sdk", "timestamp": "05-10-2026 13:45:07" } } ``` **What to do:** Store `workflowRunContextId` — it is your reference for this pack. --- ### SUBMISSION_PENDING **Terminal.** The pack was submitted but processing is taking longer than the 30-second wait window. The popup closes and the final result arrives on your webhook, not through the SDK. ```json { "type": "SUBMISSION_PENDING", "data": { "journeyId": "mg7x2k0p-1", "workflowRunContextId": "a3f1...", "lastPage": "Finalise", "source": "leegality-sdk", "timestamp": "05-10-2026 13:45:07" } } ``` **What to do:** Treat the pack as in-progress. Poll or wait for the webhook to confirm the outcome. --- ### SUBMISSION_FAILED **Not terminal.** The send was attempted and failed, but the sender is **still in the popup**. The send button becomes **Retry Send** — a `COMPLETED` can still arrive on the same journey. ```json { "type": "SUBMISSION_FAILED", "data": { "journeyId": "mg7x2k0p-1", "workflowRunContextId": "a3f1...", "lastPage": "Finalise", "errors": [ { "errorCode": "submission_failed", "errorMessage": "" } ], "source": "leegality-sdk", "timestamp": "05-10-2026 13:45:07" } } ``` **What to do:** Log the error for support, but **do not close the pack off**. The sender may retry and succeed. --- ### ERROR **Terminal.** The journey could not start, or it broke mid-flight. This is unrelated to submission — it means the session itself failed. The `errorCode` is either the **gateway's own code** (when the server named the failure) or one of these SDK-specific codes: | errorCode | When it fires | |---|---| | `boot_failed` | The boot call got no usable response. The journey never rendered. | | `handshake_failed` | The popup was not opened through the SDK (pasted URL, bookmark, forwarded link). | | `auth_failed` | The `auth: true` login returned with a state mismatch or missing code. | | `journey_token_invalidated` | A 401 during the journey with no specific error code from the server. | | `invalid_grant`, `access_denied` | OAuth errors from the login flow (sender cancelled login, code exchange failed). | | Gateway codes (e.g. `LE_ERR_SU_CMP_410`) | Server-side failures — expired link, pack already sent, etc. | Example (boot failure): ```json { "type": "ERROR", "data": { "journeyId": "mg7x2k0p-1", "workflowRunContextId": null, "lastPage": null, "errors": [ { "errorCode": "boot_failed", "errorMessage": "The journey could not be started." } ], "source": "leegality-sdk", "timestamp": "05-10-2026 13:45:07" } } ``` **What to do:** Create a fresh draft for this sender. Errors before boot have no `workflowRunContextId` — use the one from your own Draft API response. --- ### CANCELLED **Terminal.** The sender closed the popup before an outcome was reported. `lastPage` identifies the step they were on. ```json { "type": "CANCELLED", "data": { "journeyId": "mg7x2k0p-1", "workflowRunContextId": "a3f1...", "lastPage": "Invitee", "source": "leegality-sdk", "timestamp": "05-10-2026 13:45:07" } } ``` **What to do:** Use `lastPage` to understand where the sender dropped off. This event fires **only** when no outcome was reported first — closing the success or error screen is the sender dismissing a finished journey, not abandoning one. > **Info — CANCELLED can arrive with null fields** > > If the popup was closed before the journey started (or the close message was dropped), both `workflowRunContextId` and `lastPage` are `null`. The close is real either way — the SDK detected it through the window handle. --- ### VALIDATION_FAILED **Not terminal — informational only.** The sender pressed Proceed with fields still invalid. They are still on the page fixing things. ```json { "type": "VALIDATION_FAILED", "data": { "journeyId": "mg7x2k0p-1", "workflowRunContextId": "a3f1...", "lastPage": "Invitee", "errors": [ { "errorCode": "invitees/0/email", "errorMessage": "Required" } ], "source": "leegality-sdk", "timestamp": "05-10-2026 13:45:07" } } ``` **What to do:** Nothing required. The `errorCode` on this event is the **field path**, not an error identifier — useful for analytics if you want to track which fields trip senders up. ## Event flow summary | Event | Terminal? | The sender... | Your app should... | |---|---|---|---| | `COMPLETED` | Yes | Finished and sent the pack | Store the reference ID | | `SUBMISSION_PENDING` | Yes | Submitted, but result is still processing | Wait for the webhook | | `SUBMISSION_FAILED` | No | Can retry in the popup | Keep the pack open | | `ERROR` | Yes | Cannot continue this journey | Create a fresh draft | | `CANCELLED` | Yes | Closed the popup | Optionally re-engage later | | `VALIDATION_FAILED` | No | Is still fixing fields | No action needed | --- URL: https://knowledge.leegality.com/document-execution/api/sdks/overview # Sender SDK The Sender SDK lets you embed Leegality's v4 document-sending journey directly into your application. Instead of redirecting users to the Leegality dashboard, the journey runs inside a popup window on your page — your users never leave your app. ## How it works The integration has three layers: | Layer | Who builds it | What it does | |---|---|---| | **Client backend** (server-to-server) | You | Calls the Draft API with the pack configuration and gets back a **signed launch URL** | | **Client page** (browser) | You + Leegality's script | Loads one ` ``` This defines one global: `LeegalitySenderSDK`, with one method: `open()`. ## Step 3 — Open the journey on a click Call `open()` inside a button's click handler. Pass the launch URL and a callback. ```js const sendBtn = document.getElementById('send-btn'); let launchUrl = null; // Fetch the URL BEFORE the click (see note below) async function prepare() { const res = await fetch('/api/leegality/draft', { method: 'POST' }); const json = await res.json(); launchUrl = json.url; sendBtn.disabled = false; } prepare(); // Open on click — no await between the click and open() sendBtn.addEventListener('click', () => { const session = LeegalitySenderSDK.open({ url: launchUrl, onEvent: handleEvent, }); }); ``` > **Warning — Call open() synchronously inside the click handler** > > Browsers block popups that cannot be traced back to a user action. An `await` between the click and the `open()` call breaks that trace. Fetch the launch URL before the click, then call `open()` directly inside the handler. ## Step 4 — Handle events Your `onEvent` callback receives `{ type, data }` for every lifecycle event. The `type` alone tells you whether the journey is over. ```js function handleEvent({ type, data }) { switch (type) { case 'COMPLETED': // The pack was sent. Store the reference ID. console.log('Sent:', data.workflowRunContextId); break; case 'SUBMISSION_PENDING': // Still processing. The result arrives on your webhook. console.log('Processing:', data.workflowRunContextId); break; case 'SUBMISSION_FAILED': // The send failed, but the sender can retry in the popup. // Do NOT close off the pack — a COMPLETED may still arrive. console.log('Failed, retryable:', data.errors[0].errorMessage); break; case 'ERROR': // Terminal. The journey could not start or died mid-flight. // Create a fresh draft to try again. console.log('Error:', data.errors[0].errorCode); break; case 'CANCELLED': // The sender closed the popup before finishing. console.log('Cancelled on step:', data.lastPage); break; case 'VALIDATION_FAILED': // Informational — the sender is still on the page. console.log('Fields need fixing:', data.errors.length); break; } } ``` ## Complete example One self-contained HTML file. Save it, serve it over HTTP, and click the button. ```html Leegality Sender SDK — minimal integration 


  
  

  


```

## Next steps

- [Draft API](https://knowledge.leegality.com/document-execution/api/sdks/draft-api) — journeyOptions, re-issuing URLs, and the full request/response reference
- [SDK Reference](https://knowledge.leegality.com/document-execution/api/sdks/sdk-reference) — the `open()` method in detail, return value, and popup behaviour
- [Lifecycle Events](https://knowledge.leegality.com/document-execution/api/sdks/events) — all six events with exact payloads

---

URL: https://knowledge.leegality.com/document-execution/api/sdks/sdk-reference

# SDK Reference

The Sender SDK is a single JavaScript file hosted by Leegality. It defines one global (`LeegalitySenderSDK`) with one method (`open()`). No npm install, no build step, no framework requirement.

## Loading the script

Add the script tag for the environment matching your backend's gateway host.

```html

```

| Environment | Script URL |
|---|---|
| Production | `https://workflow.leegality.com/sdk/v1/leegality-sender-sdk.js` |
| Sandbox | `https://sandbox-workflow.leegality.com/sdk/v1/leegality-sender-sdk.js` |
| Preprod | `https://preprod-workflow.leegality.com/sdk/v1/leegality-sender-sdk.js` |

The script exposes `window.LeegalitySenderSDK` as soon as it loads.

## `LeegalitySenderSDK.open(options)`

Opens the sending journey in a popup window and subscribes to its lifecycle events.

### Parameters

| Parameter | Type | Required | Description |
|---|---|---|---|
| `url` | string | Yes | The signed launch URL from the [Draft API](https://knowledge.leegality.com/document-execution/api/sdks/draft-api). Pass it through untouched — the SDK validates that the four signed parameters (`exp`, `credentialId`, `signature`, `d`) are present and warns in the console if any are missing, but never edits the URL. |
| `onEvent` | function | Yes | Called as `onEvent(envelope, messageEvent)` whenever a lifecycle event arrives. `envelope` is `{ type, data }`. See [Lifecycle Events](https://knowledge.leegality.com/document-execution/api/sdks/events) for the full list. Only messages from the popup window, from Leegality's origin, stamped with `source: 'leegality-sdk'`, reach this callback. |

### Return value

`open()` returns an object with three properties:

| Property | Type | Description |
|---|---|---|
| `tab` | `Window` or `null` | The popup window handle. `null` means the browser blocked the popup (see [Popup blocking](#popup-blocking)). The window is cross-origin, so `tab.closed` is the main thing you can read from it. |
| `journeyId` | string | Identifies this journey. Available immediately when `open()` returns and echoed on every event as `data.journeyId`. Client-side only — the server never sees it. Use it to map events back to your records, especially before `workflowRunContextId` exists. |
| `close()` | function | Stops listening for events and closes the popup if it is still open. Safe to call more than once. Closing a live journey is a cancellation — the sender loses progress and you receive a `CANCELLED` event, so leave it to the sender unless you have a specific reason. |

### Example

```js
const session = LeegalitySenderSDK.open({
  url: draft.data.url,
  onEvent: (envelope) => {
    console.log(envelope.type, envelope.data);
  },
});

// session.tab       → the popup window (null if blocked)
// session.journeyId → echoed on every event
// session.close()   → stop listening + close the window
```

## Popup window

The SDK opens the journey in a popup window sized at 1440 x 900 pixels, centred on the current screen. The size is fixed — the journey screens are not responsive.

### Popup blocking

Browsers block popups they cannot trace to a user action. If there is an `await` between the user's click and the `open()` call, the browser treats it as an unsolicited popup and blocks it.

**The fix:** fetch the launch URL **before** the click, then call `open()` synchronously inside the click handler.

```js
let launchUrl = null;

// Fetch first
async function prepare() {
  const res = await fetch('/api/leegality/draft', { method: 'POST' });
  launchUrl = (await res.json()).url;
}
prepare();

// Open on click — no await between click and open()
button.addEventListener('click', () => {
  const session = LeegalitySenderSDK.open({
    url: launchUrl,
    onEvent: handleEvent,
  });
});
```

If `session.tab` comes back `null`, the popup was blocked. Prompt the user to allow popups for your domain.

## Multiple journeys

Each `open()` call is independent — its own popup window, its own events. A journey's events reach only the `onEvent` callback it was opened with.

```js
const journeys = new Map();

function launch(url, documentName) {
  const session = LeegalitySenderSDK.open({ url, onEvent: handleEvent });
  journeys.set(session.journeyId, { session, documentName });
}

function handleEvent(envelope) {
  const journey = journeys.get(envelope.data.journeyId);
  if (!journey) return;

  if (envelope.type === 'COMPLETED') {
    markRowComplete(journey.documentName);
    journeys.delete(envelope.data.journeyId);
  }
}
```

> **Info — Two windows at 1440 x 900 overlap almost completely**
>
> The popup size is fixed, so a second journey opens on top of the first. If senders need to work on several at once, communicate this in your own UI — the SDK cannot arrange the windows.

---

URL: https://knowledge.leegality.com/document-execution/customisation/custom-sender-email

# Custom Sender Email

By default, invitee emails come from a generic Leegality address such as **`noreply@leegality.com`**. With **Custom Sender Email**, you can replace this with a branded address — either a custom prefix on the Leegality domain or your own domain entirely — so your organisation appears as the sender. The display name shown in recipients' inboxes is your **brand name**.

> **Info — Available on request**
>
> Custom Sender Email is configured by Leegality support. See [How to enable](#how-to-enable) below.

## Types of Custom Sender Email

#### Custom prefix on @leegality.com

Replace the default `noreply` prefix with one of your own while keeping the Leegality domain.

For example, **`noreply@leegality.com`** can be changed to **`xyzcompany@leegality.com`**. Any prefix can be used.

#### Your own domain

Send emails from your own domain instead of **`@leegality.com`**. This allows organisations to maintain trust by sending emails from their verified email domains. For example, **`loans@xyzbank.com`**.

This option requires some DNS configuration on your end.

## How to enable

Email [support@leegality.com](mailto:support@leegality.com) with the following details:

- Email address to be configured, for example **`loans@xyzbank.com`**
- Org ID where the domain should be configured
- Environment (Production and/or UAT)

## See also

- [Custom Subdomain](https://knowledge.leegality.com/document-execution/customisation/custom-subdomain)
- [Branding](https://knowledge.leegality.com/document-execution/settings/Department/branding)

---

URL: https://knowledge.leegality.com/document-execution/customisation/custom-subdomain

# Custom Subdomain

By default, users access the Leegality Document Execution dashboard at **`dashboard.leegality.com`**. With **Custom Subdomain**, you can replace this with a branded subdomain such as **`xyzbank.leegality.com`**, where `xyzbank` is the subdomain you want to use — giving your end users a consistent, branded login experience.

> **Info — Available on request — Production only**
>
> Custom Subdomain is configured by Leegality support and is available only for production accounts.

## How to enable

Email [support@leegality.com](mailto:support@leegality.com) with the following details:

- Subdomain to be configured, for example **`xyzbank.leegality.com`**
- Org ID where the subdomain should be configured

## See also

- [Custom Sender Email](https://knowledge.leegality.com/document-execution/customisation/custom-sender-email)
- [Branding](https://knowledge.leegality.com/document-execution/settings/Department/branding)

---

URL: https://knowledge.leegality.com/document-execution/esign-type/aadhaar

# Aadhaar eSign

Aadhaar eSign is a type of electronic signature in India that uses a person's Aadhaar number to verify their identity and sign documents digitally. It is considered legally valid and enforceable in India under the Information Technology Act, 2000.

## Types of Aadhaar eSign

- OTP
- Biometric Thumb
- Iris
- Face

## Use Aadhaar eSign

#### V3 Workflow

During the invite configuration, you need to set the signature type for each invitee by following these steps:

1. In the Invitee card, hover over the **Signature type** dropdown.
2. Toggle ON the **Aadhaar** option.
3. A panel will appear on the right. Choose the Aadhaar eSign method(s) you wish to enable for the invitee. Available options include:
  - OTP
  - Biometric Thumb Scan
  - Iris Scan
  - Face
4. Toggle on **Verify details with Certificate Details** (Optional). Fields to enable are:
  - Verify Name
  - Smart Name Verification
  - Year of Birth
  - Title
  - PIN Code
  - State
  - Gender
  Toggle on the adjacent switch to enable any of the fields listed above.
  **Note:** Enabling a variable automatically makes the verification mandatory for that field.
5. Once selections are made, click **Save** to apply the changes.

#### Workflow Creation

During the invite configuration, you need to set the signature type for each invitee by following these steps:

1. In the Invitee card, hover over the **Signature type** dropdown.
2. Toggle ON the **Aadhaar** option.
3. A panel will appear on the right. Choose the Aadhaar eSign method(s) you wish to enable for the invitee. Available options include:
  - OTP
  - Biometric Thumb Scan
  - Iris Scan
  - Face
  **Note:** At least one eSign method must be enabled by the workflow creator.
4. Toggle on **Verify details with Certificate Details** (Optional). Fields to enable are:
  - Verify Name
  - Smart Name Verification
  - Year of Birth
  - Title
  - PIN Code
  - State
  - Gender
  Toggle on the adjacent switch to enable any of the fields listed above.
  **Note:** Enabling a variable automatically makes the verification mandatory for that field.
5. Once selections are made, click **Save** to apply the changes.

The workflow runner cannot disable this if enabled by the workflow creator, and vice versa.

#### V4 Workflow

To configure Aadhaar eSign for an invitee in a V4 workflow:

1. Expand the **eSign Types** section and enable the **Aadhaar eSign** toggle.
2. Enable the Aadhaar eSign method(s) you want to allow for the invitee:
  - OTP on Phone
  - Biometric Thumb Scan
  - Iris Scan
  - Face Authentication
3. **Set retry attempts** (optional): Enable the **Set retry attempts** toggle, then select the number of attempts from the **Set attempts** dropdown. You can configure a minimum of **0** and a maximum of **10** attempts.

#### Workflow Creation

To configure Aadhaar eSign for an invitee in a V4 workflow:

1. Expand the **eSign Types** section and enable the **Aadhaar eSign** toggle.
2. Enable the Aadhaar eSign method(s) you want to allow for the invitee:
  - OTP on Phone
  - Biometric Thumb Scan
  - Iris Scan
  - Face Authentication
3. **Set retry attempts** (optional): Enable the **Set retry attempts** toggle, then select the number of attempts from the **Set attempts** dropdown. You can configure a minimum of **0** and a maximum of **10** attempts.

> **Info — Note**
>
> If multiple Aadhaar eSign methods are selected, the signer can use any one of the available options to sign the document.

## Signing a Document Using Aadhaar eSign

The signer may receive the invitation to sign the document via Email, SMS, or WhatsApp, based on the sender's configuration.

#### OTP

The Aadhaar eSign **OTP** journey on **Protean** and **CVL** carries your organization's branding. If a **[branding profile](https://knowledge.leegality.com/document-execution/settings/Department/branding)** is configured, your brand logo and colour are applied automatically for a consistent signing experience. If no branding is configured, signers see the default Leegality experience.

1. Click the **Sign** button in the email or use the **Signing Link** received via SMS or WhatsApp.
2. Preview the document and click **Proceed**.
3. Select the Aadhaar eSign method (**OTP on Phone**) and continue.
4. Agree to the consent terms and click **Sign Document**.
5. You will be redirected to eSign Service Provider (ESP) page, such as Protean, CVL, or Verasys.
6. On the ESP page:
  - Enter your **Aadhaar Number/VID**.
  - Select the *I agree to the Terms & Conditions* consent checkbox.
  - Click **Get OTP** to receive an OTP on your registered mobile number.
7. Enter the OTP and click **Verify OTP**.

Once the OTP is verified, the document will be signed successfully.

If the invitee's phone number is linked to their Aadhaar, they can receive the OTP via a phone call. The **Resend via Call** button will appear on the OTP screen 30 seconds after the first code is sent.

#### Biometric Scan

### Prerequisites for Aadhaar Biometric Signing

#### 1. UIDAI-Approved L1 Biometric Device

You must use one of the following **UIDAI-approved L1** devices:

- **Mantra** MFS110 (L1)
- **Startek** FM220U L1
- **Morpho** MSO 1300 E3 L1
- **Precision** PB1000
- **Evolute** Falcon Plus L1

##### What is an L1 Biometric Device?

An **L1 biometric device** is a secure authentication device approved by UIDAI where the capture, encryption, and signing of biometric data happen entirely **inside a tamper-proof hardware environment**.

This is done through a **Trusted Execution Environment (TEE)**, ensuring that:

- Raw biometric data never leaves the device.
- The host OS or applications cannot access unencrypted biometric data.
- Spoofing or unauthorised access is prevented.

This level of security is **mandatory** for all new biometric devices used in the Aadhaar ecosystem.

#### 2. Software Requirements

**For Windows:**

- Install the **Registered Device (RD) services** specific to your biometric device model.

**For Android:**

- Install the **Leegality Helper App**.
- Install the **Registered Device (RD) services** specific to your biometric device model. You can easily find them on Play Store.

On Android, biometric signing requires the **Leegality Helper App** to be installed and the signing link to be opened **from within** that app. If the biometric device is connected but the page still shows *"No device connected"*, check that:

- The **Leegality Helper App** is installed on the device.
- The signing link was opened **inside** the Leegality Helper App, and not directly in a browser or another app.

### Signing a Document Using Aadhaar Biometric

1. Click the **Sign** button in the email or the **Signing Link** received via SMS or WhatsApp.
2. Preview the document and click **Proceed**.
3. Select **Biometric Scan** as the Aadhaar eSign method.
4. Agree to the consent terms and click **Sign Document**.
5. You will be redirected to an eSign Service Provider (ESP) page, such as NSDL (Protean), CDSL, or Verasys.
6. On the ESP page:
  - The system will automatically detect the biometric device.
  - Once detected, enter your **Aadhaar Number/VID**.
  - Check the **Consent** box and click **Capture**.
  - Place your finger on the biometric device and click **OK**.
7. After capturing the fingerprint, a pop-up will confirm the capture with the message *"Fingerprint captured successfully."*
8. Click **OK** to return to the Leegality page with a confirmation message.

#### Face

### Prerequisites for Signing

Aadhaar Face eSign is supported only on Android devices. Ensure the following apps are downloaded and installed from the Google Play Store:

- Leegality Helper
- AadhaarFaceRD

### Signing a Document Using Aadhaar Face

1. Open the **Leegality Helper** app and tap **Continue to Sign Link Upload**.
2. Paste the eSigning link from email, WhatsApp, or SMS, then tap **Proceed to Sign**.
3. Review the document and tap **Proceed**.
4. Select **Face Authentication** as the signing method and tap **Proceed**.
5. Agree to the consent and tap **Sign Document**.
6. You will be redirected to NSDL (Protean) for Aadhaar Face eSign.
7. Tap **OK** to accept NSDL’s Terms and Conditions.
8. Enter your **Aadhaar Number/VID**.
9. Check the consent box and tap **Capture Face Details**.
10. Follow the on-screen instructions and tap **Proceed**.
11. The front camera will open. Blink your eyes for successful capture.
12. Upon successful capture, a pop-up will confirm with "Face captured successfully." Tap **OK** to continue.
13. Tap **Submit**.

You will be redirected back to the Leegality Helper app with a success message: *The document(s) have been signed successfully.*

#### Iris

### Prerequisites for Aadhaar Iris Signing

#### Hardware

You must use one of the following UIDAI-approved iris scanners:



                
                    
BrandModel

                
                
                    
iriShieldMK2120UL

                    
MantraMIS100V2

                
            


#### Software



                
                    
PlatformSetup

                
                
                    

                        Windows
                        
                            
    
                                
  1. Install the Registered Device (RD) services specific to your iris scanner model.
    2. 
                                
  2. Plug in the device and start the signing process.
    3. 
                            

                        		
                    

                    

                        Android
                        
                            
    
                                
  1. Install the Registered Device (RD) services specific to your iris scanner model from the Play Store.
    2. 
                                
  2. Install the Leegality Helper App.
    3. 
                                
  3. Open the signing journey inside the Leegality Helper App.
    4. 
                            

                        		
                    

                
            


Aadhaar Iris eSign is currently not available on macOS.

### Signing a Document Using Aadhaar Iris

1. Click the **Sign** button in the email or the **Signing Link** received via SMS or WhatsApp. On Android, open the link inside the **Leegality Helper** app.
2. Preview the document and click **Proceed**.
3. Select **Iris Scan** as the Aadhaar eSign method.
4. Agree to the consent terms and click **Sign Document**.
5. You will be redirected to an eSign Service Provider (ESP) page, such as NSDL (Protean), CDSL, or Verasys.
6. On the ESP page:
  - The system will automatically detect the iris scanner.
  - Once detected, enter your **Aadhaar Number/VID**.
  - Check the **Consent** box and click **Capture**.
  - Position your eyes in front of the scanner and follow the on-screen instructions.
7. After capturing the iris, a pop-up will confirm the capture with the message *"Iris captured successfully."*
8. Click **OK** to return to the Leegality page with a confirmation message.

## ESP Errors During Aadhaar Signing

This section lists common errors you may encounter on the eSign Service Provider (ESP) page while signing documents using Aadhaar eSign, along with their causes and solutions.



  
    

      Problem
      Error Message on ESP
      Cause
      Solution
    

  
  
    

      
        OTP request limit exceeded
      
      
        NSDL

        "Failure: You have exceeded Send/Resend OTP Limit. Please try again!"
      		
      
        The signer requested more than three OTPs without submitting any.
        
 
A signer can request up to three OTPs. Attempting to request a fourth will result in an error.
      		
      
        Restart the eSign process from Leegality platform. System will automatically route to an available ESP.
      
    

    

      
        CDSL

        "The eSign Service Provider (ESP) could not complete the eSign request. Message from ESP – OTP Validation Limit Exceeded"
      		
    

    

      
        Invalid OTP entered repeatedly
      
      
        On ESP Page:

        "Invalid OTP! Please enter correct OTP which was received. X attempt(s) remaining for submitting the OTP."
        

        After 3 failed attempts (redirected to Leegality):

        "The eSign Service Provider (ESP) could not complete the eSign request. Message from ESP – Invalid OTP. No Of Retry Attempt Exhausted!!"
      		
      
        The signer submitted an incorrect OTP three times consecutively.
        


        Each signer gets three attempts to enter the correct OTP before the session is terminated.
      		
      
        Restart the signing process using the signing link.
      
    

    

      
        Expired Virtual ID (VID) used during signing
      
      
        On ESP Page:

        "Expired VID is used in input"
      		
      
        The 16-digit Virtual ID (VID) entered, or saved in the browser/application, has expired.
        


        Aadhaar VIDs are temporary and expire after a certain period or when a new VID is generated.
      		
      
        Enter a valid VID to proceed, or use the Aadhaar number directly instead.
        


        To generate a new VID:
        
    
          
  1. Visit myaadhaar.uidai.gov.in or open the mAadhaar app.
    2. 
          
  2. Go to the VID Generator service.
    3. 
          
  3. Log in using the Aadhaar number and the OTP sent to the registered mobile number.
    4. 
          
  4. Select Generate VID to receive a new 16-digit VID via SMS.
    5. 
        

      		
    

    

      
        Face authentication failure
      
      
        On ESP Page:

        "authentication failed! please contact admin"
      		
      
        Intermittent issue with Face authentication on the ESP.
      
      
        Retry after some time. This is typically a transient error and resolves on its own.
      
    

    

      
        OTP not received
      
      
        On ESP Page:

        "Error in generating OTP request! unable to generate OTP."
      		
      
        Intermittent issue on the ESP's end.
      
      
        Close the current session and try again after some time. 

 If the issue persists, contact support@leegality.com.
      		
    

    

      
        Signer's email/mobile not linked to Aadhaar
      
      
        Message from ESP:

        "Aadhaar number does not have both email ID and mobile number"
      		
      
        The ESP requires at least one contact detail (mobile number or email ID) to be registered with UIDAI/Aadhaar for OTP delivery. This error indicates that the signer does not have the required details linked.
      
      
        Verify and update Aadhaar details before retrying the eSign process.
      
    

  



---

URL: https://knowledge.leegality.com/document-execution/esign-type/aadhaar/signature-certificate-verifier

# Signature Certificate Verifier

The Signature Certificate Verifier feature allows the sender (Leegality Customer) to configure certain details of the intended signer and compares the details filled in by the sender and the details received in the Digital Signature Certificate after signing.

- In case, the details provided by the sender match the details received in the certificate - the signature is successful.
- In case, the details provided by the sender do not match the details received in the certificate - Leegality rejects the signature.

A Digital Signature Certificate has the below-mentioned details which get verified if the verifier is turned on while sending the document.

- Verify invitee name
- Enable smart name verification 
- Invitee pin code
- Invitee year of birth
- Invitee last 4 Aadhaar digits
- Invitee state
- State
- Invitee gender

> **Info — Note**
>
> Leegality’s action towards a verification failure by default is to reject the signature although, you can choose to accept a signature even after a verification failure

## Set up Certificate Verifier in the new document flow

1. Once on the Invite page after creating the document.
2. Select the signature type Aadhar/DSC/Cloud DSC/Nesl Esign and click on the "gear" icon
3. Enter the values for the verification parameter which needs to be verified from the signer’s certificate while signing the document.

> **Info — Note**
>
> None of the parameters are mandatory for the certificate verifier to work i.e. you can configure any number of parameters out of the available options for verification

During the signing of the document, if the certificate details do not match with the Digital signature certificate, the signer will get the below error message.

> **Info — Note**
>
> - If the signing of the document is failed due to the verification details not matching the Digital signature certificate, the Esigns credit will be debited from the account.
>     - If the stamps are affixed, it will be moved to reserve and will be consumed if the signer has signed the documents, else will be credited back to the account.

## Set up Certificate Verifier in the Workflow

1. While creating the workflow, select the type of sign as Aadhaar/ DSC Token/ Cloud DSC/ Nesl Sign and click on the "gear" icon
2. In the resulting side menu, enable “Verify details with Certificate Details”

Enable the verification parameter(s) that need to be verified - These parameters will be configurable while running the workflow

You can also mark parameters as mandatory - These parameters will have to be mandatorily configured while running the workflow.

> **Info — Note**
>
> These parameters will have to be mandatorily configured in Esign setting.

## Running the workflow with Verification parameters enabled

Once the workflow is configured with the required verification parameters enabled.

1. Run the required workflow and upload the document that has to be signed.
2. Enter the invitee(s) email address and Name then click on the "gear" icon for the signature type selected while configuring the workflow.

Once the invitee details are filled, enter the values of verification parameters for each invitee that will be matched with their Digital signature Certificate used while signing.

If the signature has failed due to the verification parameter does not match with the Digital signature certificate, the details can be viewed in “Failed” under “My Desk”

## Troubleshooting Certificate Mismatch

When the signer's Aadhaar certificate does not match the details configured by the sender, Leegality rejects the signature. This is most often caused by a name mismatch (e.g., initials vs. full name, nickname vs. legal name) or an incorrect year of birth, PIN code, or last 4 Aadhaar digits.

To resolve, ask the signer for their Aadhaar-registered details exactly as they appear on the card. You can also edit the invitee details on the document details page to match, and re-send the invitation.

> **Tip**
>
> Enable **smart name verification** to allow minor name variations (e.g., expanded initials) without triggering a mismatch.

---

# _delete-on-complete

URL: https://knowledge.leegality.com/document-execution/leegality-features/document-level/_delete-on-complete



---

URL: https://knowledge.leegality.com/document-execution/leegality-features/invitee-level/notifications

# Invitee Notifications

Leegality sends notifications to invitees at key stages of the document signing journey via [Email](https://knowledge.leegality.com/document-execution/leegality-features/invitee-level/notifications/email-notifications), [SMS](https://knowledge.leegality.com/document-execution/leegality-features/invitee-level/notifications/sms-notifications), and [WhatsApp](https://knowledge.leegality.com/document-execution/leegality-features/invitee-level/notifications/whatspp-notifications) — based on what is configured for each invitee.

## Optional Notifications

These notifications are sent only if the respective channel (Email, SMS, or WhatsApp) is enabled for the invitee:

- Sign or review invitation notification
- Expiry notification
- Re-activation notification
- Deletion notifications
- Reminder notifications before expiry
- Sign or review completion notification

### Reminder Notifications

Reminder notifications are sent automatically **3, 2, and 1 day(s) before** the document signing link expires. They are delivered via whichever channels (Email, SMS, WhatsApp) are enabled for the invitee.

## Mandatory Notifications

These notifications are always sent to invitees, regardless of whether Email or SMS notifications are enabled or disabled in the invitee-level settings:

- **Document completion notification** — Sent to all invitees after everyone has signed the document. Includes the completed document and audit trail PDF.
- **eSign confirmation** — Sent immediately after an invitee signs the document, confirming their eSignature.
- **OTP for signature** — Delivered during signing via Virtual Sign or Aadhaar eSign, for identity verification before applying the signature.
- **Security verification OTP** — Sent when the signer undergoes 1-Factor or 2-Factor Authentication as part of the signing process.

---

URL: https://knowledge.leegality.com/document-execution/leegality-features/invitee-level/security/send-raw-document-link

#  Send document download link with all OTP email and messages

Enabling this security feature, a link to the raw pdf document will be sent in all the OTP verification email’s/messages.

---

URL: https://knowledge.leegality.com/document-execution/leegality-features/signature-coordinate

# Signature Coordinate

The **Signature Coordinates** functionality allows you to configure the exact placement of signatures on the document being sent for signing.  

## Steps to Configure Signature Coordinates

1. After configuring the invitee(s), proceed to the **Finalize** page.
> **Info — Note**
>
> By default, the signature coordinates will be placed on the bottom-left on every page in the document.
2. You can **Set Custom Coordinates:**  
   - Click **Custom Coordinates** to enable placement mode. The cursor will change to the Leegality logo when hovering over the document.
   - Click on the desired location in the document where the signature is to be placed.  
3. **Assign Signer:** Select the appropriate signer for the signature from the dropdown menu within the signature box.  
4. **Apply to All Pages:** To apply the signature placement across all pages of the document, click the **All** option.  
5. **Clear Coordinates:** To delete any configured custom coordinates, click **Clear Coordinates**.  
6. **Send Document:** Once the signature coordinates are set, click the **Send** button to send the document to the invitee(s).  

> **Warning — Placement Cannot Be Changed After Sending**
>
> Signature placement is locked in at the time of sending. If coordinates are incorrect, they cannot be edited mid-flight — the fix is to **cancel the document** and re-send it with the correct coordinates configured upfront.

> **Info — Note**
>
> If any invitee does not have "Custom Coordinates" configured, their signatures will automatically be placed in the bottom-left corner (default placement) of every page. Review this before sending.

---

URL: https://knowledge.leegality.com/document-execution/nesl/Overview

# NeSL Integration via Leegality

Leegality is an official **TSP (Technology Service Provider)** partner of **NeSL (National E-Governance Services Ltd.)**, enabling clients to use NeSL’s eSign and DDE (Digital Document Execution) services **without directly integrating with NeSL**.

This overview explains the benefits of onboarding NeSL through Leegality, how Leegality handles NeSL configuration, and how to get started.

## What Is NeSL?

**NeSL** is India’s first **Information Utility (IU)** under the **Insolvency and Bankruptcy Code, 2016 (IBC)**. It serves two key roles:

* **NeSL as an IU**: Maintains verified records of debt transactions, which can be used as legal evidence during insolvency resolution proceedings.
* **NeSL as a DDE Platform**: Allows digital execution of loan and debt documents. Note: Even when DDE is used, **IU submission is still required** (though fees may be waived for some cases).

## Why Use NeSL via Leegality?

#### **Single API Integration** 

    Leegality consolidates **all 6 NeSL APIs** (e.g., return API, transaction status API) into **one API**. This means clients only need to integrate once—with Leegality—and can go live in as little as **2 days**.

#### **No-Code Flow Available**

    No developer integration needed: Use the **Dashboard + Excel upload** route to kickstart NeSL DDE immediately.

#### **Nationwide Stamp Coverage**

    With NeSL integration and Leegality’s **BharatStamp**, your documents can be executed with e-stamp paper across **all Indian states**, even where NeSL stamping is not directly supported.

#### **Enhanced Security & Flexibility**

    Get more than just NeSL eSign. Leegality lets you layer advanced features like:

  * Face capture
  * GPS location capture
  * Reviewers
  * Multiple eSign types

#### **Unified Dashboard**

    Perform any of the NeSL flow from a single dashboard.

  * Lending (individual or non-individual)
  * Non-lending
  * eBG (electronic Bank Guarantee)

---

URL: https://knowledge.leegality.com/document-execution/nesl/details-page

# NeSL Document - Details Page

The **Details Page** in Leegality provides essential tools to track and manage a document after it has been sent. When a document includes **NeSL invitees**, certain details and actions behave differently to comply with NeSL's strict signing flow.

This guide covers the **information displayed** on the Details Page for NeSL documents, followed by the **actions** that are allowed, restricted, or modified.

## Document Overview

The top section of the Details Page shows high-level information about the document:

* **Document ID:** Unique identifier for the document
* **NeSL Transaction ID:** The transaction ID assigned by NeSL
* **Status:** Overall document status — e.g., Under Progress, Completed

## Invitee Details

Below the document overview, all invitees are listed with individual cards. Each invitee card displays:

* **Name** of the invitee
* **Contact** — Email and/or phone number
* **NeSL Tag** — Indicates that the invitee has a NeSL eSign type

Clicking the **Details** button on an invitee card reveals additional information:

| Field | Description |
| --- | --- |
| **Invitation Date** | Date the signing invitation was sent |
| **Sign Date** | Date the invitee completed signing |
| **Status** | Current status of the invitee's invitation |
| **Signed Using** | The eSign method used — e.g., NeSL eSign |
| **Sign Subtype** | The authentication subtype — OTP, Biometric, Face, eToken, or Iris |

> **Info — Note**
>
> **Sign Subtype:** NeSL shares this information only for clients explicitly enabled by them — it is not available for all transactions. The subtype will be shown only when available in NeSL's Transaction Data API.

## Invitee-Specific Actions

* **Resend Leegality Invitation:** Clicking **Resend Notification** re-sends **only the Leegality invitation** to the invitee.
* **View Reference Attachments:** Check any **reference attachments** uploaded by the sender at the time of document setup.
* **View Notification Logs:** A detailed record of all notifications sent to invitees.

## Document-Wide Actions

* **Copy Document URL:** Copies the document’s URL for easy sharing or quick access.
* **Delete Document:**
    Deleting a document in Leegality **does not cancel** the NeSL signing invitation.

    However:

    * If an invitee attempts to sign using the **Leegality link**, they will be **blocked**.
    * Invitees with an active Leegality invitation will receive a **revocation notification**.
* **View NeSL Form:** Use this option to **review the NeSL form details** submitted during document creation. Helpful when validating signer information or troubleshooting errors.

## Retry to Resolve NeSL Errors

If the document encounters a NeSL-related error, a **Retry** option will appear. Clicking **Retry** attempts to **resubmit the failed request** to NeSL.

> **Warning — 50-call combined limit per document**
>
> The **Refresh** and **Retry** actions on the Details Page and the `refreshNeslDocument=true` parameter on the **[Check Document Details API](https://knowledge.leegality.com/document-execution/api/check-document-details)** share a combined limit of **50 calls per document**.
> 
> Once the limit is reached on a document, further Refresh/Retry attempts (dashboard) and `refreshNeslDocument=true` calls (API) on that document will be blocked.

### Supported Error Codes

* ER404
* ER403
* ER500
* ER414
* ER502
* ER503
* ER504
* ER500API
* ER00P9
* ER00FI

## Blocked Actions for NeSL Documents

### Manual Activation of Invitations

You cannot manually activate invitations until all NeSL invitees have signed. This ensures that no other eSigns are completed before NeSL eSigns, which is a strict requirement from NeSL.

Once **all NeSL invitees have signed** , you can manually activate **remaining non-NeSL invitations**.

### Marking Document as Complete

You **cannot mark a document as complete** while any signing invitation is still pending for a NeSL invitee.

### Editing Certain Fields

For documents involving NeSL signers, some fields become non-editable after sending.

| Field                       | Editable |
| --------------------------- | -------- |
| Name                        | ✅ Yes    |
| Notification Settings       | ✅ Yes    |
| Custom Message              | ✅ Yes    |
| Reference Attachment        | ✅ Yes    |
| Email Address and Phone No. | ❌ No     |
| eSign Type                  | ❌ No     |
| NeSL Form Details           | ❌ No     |

---

URL: https://knowledge.leegality.com/document-execution/nesl/enable-nesl-esign

# Enable NeSL eSign in Leegality

To use NeSL eSign and eStamping features via Leegality, clients must first share their NeSL configuration details via secure email. Once Leegality sets up the profile, clients can enable NeSL eSign and begin using it.

## Step 1: Share NeSL Configuration Details

Before enabling NeSL eSign, your organization must share specific credentials and configuration parameters with Leegality. These are required to initiate secure API communication with NeSL on your behalf.

> **Tip — Important**
>
> Details are collected from clients via a **secure email**.

Once received, Leegality will configure your **NeSL Profile**.

### NeSL Profile in Leegality

The **NeSL Profile** tab displays all configured credentials. These fields are **read-only** and set up by Leegality after receiving the necessary details via a secure channel.

To access NeSL Profile:

1. Click on the **Setting ⚙️** icon on the top right corner.  
2. Go to **Department > NeSL eSign Config**.

Click **Details** next to the relevant profile on the right to view the configured information.

| Field                            | Description                                                                                                                                                                 |
| -------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Service Name**                 | Specifies the NeSL service type – *Lending*, *Non-Lending*, or *eBG*                                                                                                        |
| **Path ID (Encryption Key ID)**  | Generated by Leegality. Used in `certificate.properties` to enable NeSL signing via the Leegality utility ([link](https://gitlab.leegality.com/leegality-public/docsigner)) |
| **NeSL API Key**                 | API key issued by NeSL                                                                                                                                                      |
| **Client ID**                    | NeSL-issued Client ID                                                                                                                                                       |
| **Username**                     | NeSL portal username                                                                                                                                                        |
| **Password**                     | NeSL portal password                                                                                                                                                        |
| **NeSL Expiry Timeline**         | Default document expiry timeline configured in your NeSL account                                                                                                            |
| **Additional Encryption Key ID** | Required for sending notification payloads (especially for eBG flows)                                                                                                       |

> **Info**
>
> Please inform Leegality of any changes to these credentials in advance to avoid errors or disruptions.

## Step 2: Enable NeSL eSign in Your Account

Once your NeSL profile has been successfully configured by Leegality, follow the steps below to enable or disable NeSL eSign in your account.

1. Click the **Settings ⚙️** icon in the top-right corner of the Leegality dashboard.
2. Navigate to **Department > eSignature**.
3. Locate **NeSL eSign** in the list of available eSign types and toggle it ON.

Click the adjacent **Gear ⚙️** icon to configure **certificate verification** settings, if required.

---

URL: https://knowledge.leegality.com/document-execution/nesl/error-troubleshooting

# NeSL Error Troubleshooting

| Error Code | Description | Context | Recommended Action |
| :---- | :---- | :---- | :---- |
| **ER00P9** | We encountered a temporary issue while processing your request. This may be due to NeSL server downtime. | Temporary outage at NeSL’s end. | **Sender**: Use the **Retry** button on the Details Page after a few minutes. |
| **ER00CP** | Your session expired—likely due to extended idle time or a network issue. | Session timeout on the signer’s side. | **Signer**: Reopen the signing link received via email, SMS, or WhatsApp to restart the process. |
| **ER00CP** (Response URL rejected) | NeSL rejected the response/callback URL configured for the eSign flow. | The response URL on the Leegality side has not been whitelisted on NeSL's environment, or the URL registered with NeSL does not match the URL being passed at runtime. | **Sender**: Contact Leegality Support (support@leegality.com) to align the response URL with NeSL. |
| **ER00P19** | The certificate configuration appears to be incorrect. | The certificate details stored in Leegality are not mapped correctly with NeSL. | **Sender**: Contact Leegality Support (support@leegality.com) to verify your certificate setup. Support will escalate to NeSL if required. |
| **ER00P21** | Un Authorized to do only Estamp transaction. | Can occur when NeSL is experiencing a network issue. | **Sender**: Retry after some time. If the issue persists, contact Leegality Support (support@leegality.com) with the document ID. |
| **ER00J18** | Invalid PAN format. Ensure it matches the legal constitution (**e.g.**, 'P' for individuals). | PAN/legal constitution mismatch. | **Sender**: Validate PAN and legal constitution of the signer. 

 Re-initiate the signing with corrected details. |
| **ER00J101** | Incorrect eSign coordinates detected on the document. | The document is not A4-sized, or the sign coordinates are incorrectly configured. | **Sender**: Re-initiate the document with A4 page size and valid coordinates for all NeSL signers. |
| **ER00J104** | Incorrect Article Code selected for the transaction. | The Article Code in the request is wrong, or the Article Code list has not been updated (added/removed) for the state. | **Sender**: Verify and select the correct Article Code, then re-initiate the transaction. 

 If the correct Article Code is already selected, contact Leegality Support (support@leegality.com) to check whether the Article Code list needs to be updated. |
| **ER00J229** | Article Sub Code is mandatory or invalid for the request. | The Article Code or Article Sub Code being passed in the request is either invalid or not applicable for the given state. | **Sender**: Refer to the NeSL communique for the valid Digital Article Code and Article Sub Code applicable for the state, and pass the correct values in the request JSON before retrying. |
| **ER00J150** | Invalid CrdtSubTyp. | The credit subtype selected does not match the expected value for Hybrid eBG. | **Sender**: Contact Leegality Support (support@leegality.com) with the document ID for the failed transaction. Support will escalate to NeSL to confirm the correct CrdtSubType values for your account configuration. |
| **ER00J81** | Invalid sequence number for creditor/subsequent participant in the request. | The `seqno` field for the creditor party in the NeSL eBG JSON payload is missing or does not match the sequence number configured with NeSL for the subsequent participant. | **Sender**: Contact Leegality Support (support@leegality.com) so the ticket can be looped in with NeSL for resolution. |
| **ER00E9** | Issue during eStamping. This is likely temporary. | Problem at the state eStamping portal (e.g., SHCIL). | **Sender**: Resubmit the transaction with a new txnID — most ER00E9 failures clear on a single retry. 

 If the retry also fails, capture both txnIDs and the full NeSL response, and escalate to Leegality Support (support@leegality.com) with both txnIDs. |
| **ER00E09** | eStamping failed during document execution. This is likely temporary. | Intermittent fluctuations at the respective state eStamp application. | **Signer**: Retry using the **same** signing link to continue the execution process. A new link or transaction is not required. 

 If the issue persists, contact Leegality Support (support@leegality.com). |
| **ER00E15** | NeSL eStamping was only partially completed for the transaction. | The stamping flow did not finish end-to-end on NeSL's side, leaving the stamp in an incomplete state. | **Sender**: Click the **Refresh Document** button on the document Details Page in the Leegality dashboard. 

 If the issue persists after refreshing, contact Leegality Support (support@leegality.com). |
| **ER00E01** | eSign process failed due to a temporary issue with UIDAI. | UIDAI servers are intermittently unresponsive. | **Signer**: Retry after a few minutes. |
| **ER00B01** | Insufficient stamp balance in your NeSL wallet. | The state-specific NeSL wallet lacks sufficient balance. | **Sender**: Contact NeSL to check and top up the relevant state account. |
| **ER00ST** | Your session expired—likely due to inactivity or a network issue. | Session timeout while on NeSL Signing Pages. | **Signer**: Use the signing link to initiate the signing process. |
| **ER00MS** | Session Already Exist. An active NeSL eSign session already exists for this transaction. | The signer has an open session that has not been properly closed, or a retry is attempted before the previous session times out. | Wait for 180 seconds (3 minutes) before trying again, and then log in / retry. 

 If the issue persists, contact Leegality Support (support@leegality.com) with the NeSL Reference ID. Support will escalate to NeSL to clear the stale session. Once cleared, the signer can re-initiate the eSign process. |
| **ER00E13** | Maharashtra eStamping is not enabled for your organization. | Your organization isn’t onboarded for Maharashtra eStamping. | **Sender**: Complete onboarding using [this guide](https://nesl.co.in/wp-content/uploads/2023/09/Communique-92-Ease-of-onboarding-documentation-for-Maharashtra-paperless-10D-e-stamp-certificate.pdf). |
| **ER500API** | Temporary system issue prevented request completion. | NeSL failed to respond to an API call. | **Sender**: Use the **Retry** button on the Details Page. 

 **Signer:** Retry after some time. |
| **ER502** | System issue encountered. Please retry. | NeSL’s systems are temporarily unavailable. | **Sender**: Use **Retry** on the Details Page. 

 **Signer:** Retry after a few minutes. |
| **ER00E04** | It appears the Aadhaar card used for signing doesn't have a linked mobile number or email ID. | Aadhaar is not linked with mobile number or email. | **Signer**: Retry using the correct Aadhaar number. |
| **ER00J137 / ER00J176** | Duplicate loan number detected. | A previously used loan number is being reused. | **Sender**: Use a unique loan number to re-initiate the transaction. |
| **ER00S8** | Duplicate transaction details. | Caused by refreshing the document multiple times. | **Sender**: Use the **Refresh Document** button only once. |
| **ER00J1** | Invalid JSON structure. | Payload mismatch; often occurs in sandbox. | **Sender**:  
- Create a new transaction. 
- In case of recurrence, contact your tech team to extract payload and escalate to NeSL. 
- Include complete context: date, time, environment, sender name, transaction ID. |
| **ER00D1** | Not able to decrypt the request. | Issue decrypting the request on NeSL's end. | **Sender**: Contact Leegality Support (support@leegality.com) for assistance. |
| **VENDOR_CLIENT_ERROR** (`nesl.participants.equal.nesl.invitees`) | Participants should be equal to NeSL invitees. | The number of participants in `neslData.participants` does not match the number of invitees configured with the NeSL eSign type — either fewer or more participants were added. | **Sender**: 
1. Count the invitees configured with the **NeSL eSign type** in `invitees`. 
2. Ensure `neslData.participants` has **exactly that many** participant objects. 

 Also verify that the **first participant** has `"contactRelation": "DEBTOR"`, and that all mandatory participant fields are populated correctly. |
| **Internal server error**  | Error on signing link click. | Occurs when F2F Signing is enabled. | **Sender**: Disable the **“Enable Leegality signing link for first invitee”** option under: _*Accounts > Department > eSignature > NeSL > Settings*._ |
| **Internal Server Error** | General error during refresh or document creation. | Server/network issue at NeSL. | **Sender**: Retry the action (refresh or create). If the issue persists, escalate to NeSL. |
| **ERR\_EMPTY\_RESPONSE** | Signer sees an unresponsive page when clicking the signing link. | NeSL sent a broken eSign URL with a `null` value. | **Sender**: Raise the issue with NeSL, referencing the `Get_Esign_Link` API’s invalid response. |
| **ER00P1** - Response URL is Missing 
 **ER00P2** - ClientID is Missing 
 **ER00P3** - Authorization is Missing 
 **ER00P4** - API key is Missing 
 **ER00P5** -MetaData is Missing 
 **ER00P7** - ResponseURL should not be null 
 **ER00P8** - ClientID should not be null 
 **ER00P9** - API-key and client should be valid 
 **ER00P10** - MetaData should not be null 
 **ER00P11** - API-Key should be Valid 
 **ER00P12** - Authorization should not be null 
 **ER00P13** - Invalid ClientID 
 **ER00P14** - Unable to write JSON 
 **ER00P15** - Invalid MetaData 
 **ER00P17** or **ER00P16** - Invalid Authorization | Multiple API configuration errors (e.g., missing keys, metadata, etc.). | Either incorrect API setup or NeSL is experiencing issues. | **New Sender**: Verify API setup in Admin Panel.  

 **Existing Sender:** Raise a ticket with NeSL confirming correct setup. |
| **Max limit reached for Submitter Txn ID \+ Loan No.** | Limit exceeded (50) for Refresh API calls. | Too many refresh attempts for the same combination. | **Sender**:  
 1. Request limit increase from NeSL. 
 2. Instruct signers not to refresh excessively. 
 3. Retry once the cap is lifted. |
| **Error 1: Successfully updated document** | Temporary issue that resolves automatically. | Minor, transient issue at NeSL’s end. | **Signer**: Retry after some time. |
| **OTP Not Received (Co-Applicant)** | Signer reports not receiving the NeSL SMS-OTP, though NeSL confirms delivery. | OTP is often delivered successfully but fails to reach the device — incorrect number, network issues, or SMS-blocking apps. | **Sender**: Verify the mobile number in the request matches the signer's device. 

 **Signer**: Retrigger the OTP (multiple attempts are allowed) and check Spam/Junk folders. |

---

URL: https://knowledge.leegality.com/document-execution/nesl/nesl-errors

# Documents with NeSL Errors

The NeSL Errors tab provides a consolidated view of documents that encountered errors during NeSL processing. From here, you can identify the type of error and, where applicable, resolve it directly from the dashboard.

1. Click **Documents** on the top bar.
2. Open the **Quick Access** dropdown in the left sidebar.
3. Select **NeSL Errors**.

> **Tip — Who sees what**
>
> - **Senders** see documents sent by them.
> - **Admins** see all documents in the account.

> **Info**
>
> NeSL documents with certificate verification failure are not included here. These appear in the **Failed** tab along with other certificate verification failure cases.

## Error categories

Errors are grouped into three categories. Each category determines what action (if any) is available.

### Temporary Submission Issue

The document was not submitted to NeSL successfully due to an intermittent issue at NeSL's end.

**Action:** Retry the NeSL submission.

**Example error codes:** ER502, ER500API, ER00P9, ER00FI

### NeSL Update Failed

After creation, the latest document status could not be updated due to an intermittent issue at NeSL's end (e.g., a stamping update that did not complete).

**Action:** Refresh the document status from NeSL.

**Example error codes:** ER00E9, ER00CP, ER00E14

### Other Errors

Any other errors where no retry or refresh action is available.

**Examples:** Invalid field-level errors, duplicate transaction errors

## Search and filter

- **Search** by NeSL Transaction ID, document name, or document ID.
- **Filter** by error category or creation date.

---

URL: https://knowledge.leegality.com/document-execution/nesl/nesl-features/_leegality-certificate-verification

# NeSL - Leegality Certificate Verification

## Verification Parameters

* Name  
* Gender  
* Year of birth  
* Pincode  
* State  
* Last 4 digits of the Aadhaar

## Acceptance Condition

* **Accept but respond with result:** The signing journey will be continued but the verification results will be shown in the response.  
* **Accept but pause the signing journey:** The signing journey will pause for non-NeSL invitees that are next in the signing order. The document will not be activated, and they will not receive the eSign invitation.

## Verification Type

Smart Name Verification

* AI-based name matching  
* Text-based name matching

**Match Threshold:** Minimum match percentage in order to proceed.

Acceptance Condition

* Accept but respond with the result
* Reject if fails

---

URL: https://knowledge.leegality.com/document-execution/nesl/nesl-features/ebg-event-reviewer

# NeSL eBG Event Reviewers

The **eBG Event Reviewer feature** allows users to:

- **Assign Reviewers:** Designate specific users to review and accept/reject the event request.  
- **View Event Details:** Access detailed information about the event request raised via the NeSL IU portal  
- **Approve or Reject Requests:** Take action on the requests directly within the Leegality platform.

This integration ensures that banks can process eBG events efficiently without document uploading, even for actions like cancellations.

### Who is a Reviewer?

A Reviewer is a designated user responsible for evaluating and making decisions (either accept or reject) on event requests related to Electronic Bank Guarantees (eBGs). These events may include actions such as amendments, invocations, cancellations, or closures.

## How to add an eBG Event Reviewer

1. Click on the **Settings ⚙️** icon in the top right corner.
2. Go to **Department > NeSL eSign Config**.
3. Select the **eBG Event Reviewers** tab.
4. Select the event type from the left.  
5. Click on the **+ Add** button.  
6. Enter the reviewer’s name and email address.  
7. Click on the **✓** icon.

## How to accept or reject eBG event request

On the **Dashboard**, click the **eBG notifications** option in the left panel

1. Click on the **Three Dots** and select **Review Request**.  
2. Here, you can view:  
   * Request Details  
   * Supporting Document  
   * Participants  
   * eBG Details  
3. After reviewing, you can either **Accept** or **Reject** the request.

---

URL: https://knowledge.leegality.com/document-execution/nesl/nesl-features/nesl-aadhaar-validation

# NeSL Aadhaar Validation

NeSL Aadhaar validation enables the sender to verify a NeSL invitee's details before they eSign a document. The details provided by the sender in the NeSL form (or Excel) during the sending process are cross-checked against the invitee's information at NeSL.

To get this feature enabled, please reach out to us at support@leegality.com.

To check if NeSL Validation is enabled for your account, 

1. Click on the settings icon in the right corner.  
2. From left, select **Department > NeSL Config**.  
3. Click **Details** of the appropriate **NeSL Profile**.

The **NeSL Aadhaar Validation** will be enabled. 

> This information is for reference only and cannot be edited from the dashboard.

> **Warning — These checks cannot be bypassed**
>
> If NeSL enables this functionality for an organisation and a specific registration type (Lending, Non-Lending, or eBG), validation checks become mandatory for all documents and invitees under that registration type.

## Sending Journey

If NeSL validation is enabled, the following invitee details are verified:

* **Name:** Must have at least a 75% match.  
* **Year of birth:** Requires an exact match.  
* **Gender:** Requires an exact match.

> **Warning — Mandatory Fields**
>
> The sender must fill out all Name, Year of Birth, and Gender in the NeSL form during the sending journey.

When NeSL Aadhaar validation is active, the NeSL Aadhaar validation is performed first, followed by Leegality Aadhaar verification (if enabled).

## NeSL Aadhaar Validation Results in Signing Journey

### ✅ Validation Successful

* If the invitee's details match, NeSL validation will succeed, and the signing journey will continue smoothly.  
* If Leegality Aadhaar verification is enabled, it will take place after NeSL validation, allowing the signing journey to proceed as usual.

### ❌ Validation Fail

* If the invitee's details do not match and NeSL validation fails, the invitee’s signature will not be applied to the document, and the signing URL will expire for only the invitee with failed validation.   
* The signing journey will continue for any other NeSL invitees (if present), as NeSL does not allow the signing journey to be paused mid-process.  
* Once all NeSL invitees are signed, the signing journey will pause for non-NeSL invitees that are next in the signing order. The document will not be activated, and they will not receive the eSign invitation.

In case of NeSL validation failure, the sender needs to send the document again with the correct NeSL invitee details.

## NeSL Validation with Leegality Aadhaar validation

| NeSL Aadhaar Validation | Leegality Validation | Leegality Validation’s acceptance condition 

 (*In case of failure, allow the NeSL invitee to sign, but:*) | Can Invitee Sign? | Does Invitation Expires? | Signing Journey — Pause or Continue |
| :---- | :---- | :---- | :---- | :---- | :---- |
| Pass | Pass | Respond with result  
 Or 
  Pause Signing Journey | Yes | No | Continue |
| Pass | Fail | Respond with result | Yes | No | Continue |
| Pass | Fail | Pause Signing Journey | Yes | No | Pause |
| Fail | Will not be checked | Respond with result  
 Or 
  Pause Signing Journey | No | Yes | The journey will **Continue for NeSL signers only**. If there are non-NeSL signers in the signing order then the journey will be paused for them. |

---

URL: https://knowledge.leegality.com/document-execution/nesl/nesl-features/nesl-form

# NeSL Form

When sending a document for NeSL eSign, you are also required to upload key data to the NeSL Information Utility (IU). This includes details related to the document details, invitee and party details, stamp duty, and any security or collateral involved.

## Methods to Fill the NeSL Form

1. **Dashboard Form:** A guided, section-wise form opens directly within the Leegality interface. Each section is listed on the left panel, with corresponding fields on the right.
2. **Excel Upload:** Download Leegality’s preformatted Excel template, fill in the required data, and upload the completed sheet.

> **Warning — Note**
>
> Based on the selected Registration Type, some fields in the form will be mandatory while others remain optional.

## NeSL Form Field Reference Table

The table below provides a comprehensive list of all fields used in the NeSL Form across different registration types. For each field, you’ll find:

- **Field Name:** The label used in the form
- **Description:** What the field captures
- **Validation Rules:** Any input restrictions or logic applied
- **Mandatory/Optional:** Whether the field is required or not based on context

---

URL: https://knowledge.leegality.com/document-execution/nesl/nesl-features/nesl-invitation-expiry

# NeSL Invitation Expiry

The expiry duration for NeSL eSign invitations is fixed. By default, this duration is fixed to 240 hours (10 days).

Regardless of any expiry settings configured under the **Signing Journey Options**, NeSL invitations will always adhere to the fixed expiry timeline defined at the NeSL level.

> **Warning — Fixed Expiry Timeline**
>
> The NeSL eSign invitation will always expire after 10 days (240 hours). If a client needs a different expiry duration for NeSL eSign invitations, they must raise a request directly with NeSL.

For non-NeSL invitees in the document, the expiry duration of the signing link will follow the configuration set under **Signing Journey Options > Expiry of signing link**.

---

URL: https://knowledge.leegality.com/document-execution/nesl/nesl-features/nesl-multi-stamping

# NeSL Multi Stamping

The **Multi Stamping** feature in NeSL DDE allows you to affix **multiple e-stamp papers** to a **single composite document** during the digital signing process.

This functionality is primarily used when a single document covers **multiple distinct transactions or aspects**, each of which attracts stamp duty under a **different article code** of the state's stamp act.

## Sending Journey: Configure NeSL Stamping

Follow these steps to enable and set up multiple NeSL stamp papers:

1. Click **Signing Journey Options** at the bottom left of the document creation screen.  
2. Configure the Number of Stamp Papers.  
   * The **Number of Stamp Papers** toggle is enabled by default.  
   * Enter the number of stamp papers you want to affix.  
3. Click **Save**, then **Next** to continue.

### Fill Stamp & Invitee Details

You will be prompted to fill in the NeSL stamp and invitee details:

- Either **upload an Excel template** with the required data  
- Or **fill in the details directly** via the dashboard

Depending on the number of stamp papers configured under **Signing journey options \> Number of Stamp Papers**, the equivalent number of stamp details have to be filled. For example, Stamp 1 Details, Stamp 2 Details, and so on.

---

URL: https://knowledge.leegality.com/document-execution/nesl/nesl-features/nesl-parties

# NeSL Parties

**NeSL Parties** refer to additional individuals or entities, **apart from the NeSL signers**, who are involved in the agreement and whose details must be submitted to NeSL. 

> **Info — Note**
>
> NeSL parties **may or may not be signer** in the agreement.

## How to Add NeSL Party

1. In the Invite Page, click **Signing Journey Options**.  
2. Enable **Number of NeSL Parties** toggle.  
3. Enter the number of parties whose details you need to send to NeSL.  
4. Click **Save**.  
5. Fill in the **Party Details** in the [**NeSL Form**](https://knowledge.leegality.com/document-execution/nesl/nesl-features/nesl-form) along with other documents and stamp details.

---

URL: https://knowledge.leegality.com/document-execution/nesl/nesl-features/stamp-duty-calculator

# Stamp Duty Calculator

The Stamp Duty Calculator allows users to fetch stamp duty amounts directly through NeSL within the dashboard. This simplifies the process by automatically calculating stamp duty based on the state, article code, and consideration amount reducing manual efforts.

## Available for eGRAS states

Supported only for eGRAS states only (Not applicable for SHCIL states)

- Maharashtra (MH)
- Madhya Pradesh (MP)
- Kerala (KL)
- West Bengal (WB)
- Karnataka (KA)
- Telangana (TS)
- Bihar (BH)

> **Warning — Not for fixed stamp duty**
>
> For article codes with fixed stamp duty:
>     - NeSL APIs will not return a value
>     - Users must manually enter the stamp duty. Refer to the [**NeSL Article Codes**](https://www.nesl.co.in/states-union-territories-for-digital-e-stamping/) for details

## How to Use NeSL Stamp Duty Calculator

In the NeSL form,

1. Fill the required **document details**.
2. In the Stamp Details section;
    1. Select appropriate **Article Code**
    2. Enter the **Consideration Price**
    3. Click on the **Calculator** icon next to Stamp duty amount field.

Stamp duty will be auto-filled based on the NeSL response. You can edit the value if needed.

All required fields must be filled in order to calculate the stamp duty amount.

---

URL: https://knowledge.leegality.com/document-execution/nesl/nesl-sending-journey

# NeSL Sending Journey

This article explains how to send documents for NeSL eSign across different use cases supported in Leegality:

- **NeSL Hybrid Flow**
- **NeSL Only Stamping**
- **NeSL eBG (Electronic Bank Guarantee)**

## Step 1: Prepare your document

The process of preparing the document is exactly the same as the Non-NeSL sending journey. Below are the key steps involved in document preparation.

1. Click **+ Create** and select **New Document Journey**.
2. Choose either:
   - Upload PDF(s).
> **Tip — Document Requirements**
>
> - **Format:** Only standard A4-sized PDFs are supported.
>             - **Digital Signatures Removed:** Any digital signature on the uploaded document will be cleared once NeSL stamp is applied.
   - Select a prebuilt [**template**](https://knowledge.leegality.com/document-execution/template).
     > **Note:** The **Allow first invitee to fill** option can only be used if a reviewer is the first invitee.
3. Click **Next**.

> **Info**
>
> For full details, refer to the [**complete document preparation process**](https://knowledge.leegality.com/document-execution/getting-started/sending-journey#step-1-prepare-your-document).

## Step 2: Add Invitees

Click **Add Invitee** and enter their **name**, **email**, and/or **phone number**.

- From the **Signature Type** dropdown, choose **NeSL eSign** if the invitee is a NeSL signer.
- Repeat for all NeSL signers.

> **Warning — Mandatory Fixed Signing Order**
>
> Enable **Request invitees to sign in fixed order** on the invite page.

> **Info**
>
> #### Supported Invitee Options for NeSL Signers
>     - Email, SMS, and WhatsApp notifications
>     - Add custom URLs/webhooks
>     - Mask contact details

## Step 3: Flow-Specific Instructions

#### NeSL Hybrid Flow

### What is NeSL Hybrid Flow?

In NeSL hybrid flow, there are invitees with both NeSL eSign and other eSign types. NeSL signers perform their signing journey on the NeSL portal.

Once all NeSL signers sign the document, then invitees with other eSign types start signing the document.

#### NeSL Hybrid Flow - Sending Journey

> **Warning — Mandatory**
>
> - *All NeSL invitees must be added first and grouped together in sequence.* You cannot place a reviewer or a non-NeSL signer between them.
>         > **Exception:** Only a [**reviewer**](https://knowledge.leegality.com/document-execution/leegality-features/invitee-level/types-of-invitee/reviewer) can be added as the first invitee.
>     - *Non-NeSL eSign invitees must be placed after all NeSL invitees*, as NeSL clears any pre-existing signatures.

1. Click **+ Add Invitee** and enter their **name**, **email address**, and/or **phone number**.
2. From the **Signature Type** dropdown, select **NeSL eSign**. 
    > 📌 **Note:** An invitee configured with *NeSL eSign cannot use any other eSign type simultaneously*.
3. After all NeSL signers have been added, you can add other invitees using any other [**signature types**](https://knowledge.leegality.com/category/esign-types) such as **Aadhaar**, **Virtual**, **Quick**, or **DSC**.
    > ℹ️ **Info:** Non-NeSL invitees can use the full range of Leegality features available under both [**Invitee-level Options**](https://knowledge.leegality.com/category/invitee-level) and [**Signing Journey Options**](https://knowledge.leegality.com/category/document-level).

#### NeSL Only Stamping

### What is NeSL Only Stamping?

_(Stamping via NeSL and Signing via Leegality)_

The NeSL Only Stamping enables organisations to procure real-time e-stamps through NeSL while executing the signing process entirely within Leegality using your preferred eSign methods (e.g., Aadhaar, DSC, Virtual, and Quick Sign.).

This offers a streamlined experience with the compliance benefits of NeSL stamping, without involving the more complex NeSL signing process.

It is ideal for institutions that want to leverage **NeSL's instant, state-compliant stamp generation** but avoid the **multi-step NeSL signer experience**, which often leads to user drop-offs.

#### Why Use NeSL Only Stamping Flow?

- **Real-time stamp generation** - No need for maintaining stamp inventory.  
- **Dynamic party name stamping** - actual names like “XYZ Ltd.” instead of placeholders like “Borrower.”  
- **Automatic data upload to NeSL IU** via DDE, saving operational effort (if applicable).

> **Warning — Prerequisite**
>
> **Approval required:** This flow is available **only to NeSL-approved clients**. Without NeSL's approval clients will be unable to use it.

#### NeSL Only Stamping - Sending Journey

1. On the create page, toggle on the **NeSL Stamping** option.  
2. Add and configure the invitees.
> **Info — Note**
>
> Since no NeSL signers are involved, **you do not need to configure any invitee under the NeSL eSign type**.
3. Click on the **Signing Journey Options**.  
   - **Number of NeSL parties:** Specify the involved [Parties](https://knowledge.leegality.com/document-execution/nesl/nesl-features/nesl-parties) in the agreement whose data will go to NeSL IU. (NeSL Parties can be signing/non-signing parties in the agreement.)
     > At least **1 NeSL party** is required in NeSL only stamping flow.
   - **Number of Stamp Papers:** By default, it is 1. You can use multiple stamp papers if required.  
4. Click **Next**.
5. Fill the [**NeSL Form**](https://knowledge.leegality.com/document-execution/nesl/nesl-features/nesl-form) details via the Dashboard or upload the filled XLS file.  
6. Configure the signing coordinates and **Send** the document.

After document setup:

![](https://mermaid.ink/img/pako:eNo9j0FvwjAMhf-K5XNBSdc2tAekjWkntMN2G-UQNW6JRhKWpAyG-O9LmYZPftZ7_uwLdk4RNtjv3Xe3kz7C-q21kOpxsyYa5F7HMwSyKoCEEKU5aDuAp6-RQoTo4JXe11uYzZbwtJl6kH2vTxQg7ghodotMvkkq142GbPzzrzYv2qcl2h51JAKdEF3URxlJQe88BD3YiaYt3G_ZYoaD1wqb6EfK0JA3cpJ4me5uMXEMtdikVkn_2WJrrylzkPbDOfMf824cdtj0ch-SGg8qQZ-1HLw096lPX5NfudFGbDivb0uwueApyaKclyXjecELXgmxqDI8Y1OzOcsrXj4UtRB5Xl8z_LlR2bxciJxVNStzVi8EF9dfWbJ5WQ?type=png)

> **Info — Note**
>
> **Stamping is triggered only after reviewer approval** (if reviewer is present).

#### Credit Consumption

- **NeSL Stamp Credits** are consumed upon successful stamp generation.  
- **Leegality eSign Credits** are consumed based on the eSign method used for signing.  
- **Credits are non-refundable** once deducted after stamp generation.

#### NeSL eBG Flow

### What is NeSL eBG?

NeSL eBG (Electronic Bank Guarantee) is a digital bank guarantee solution offered through the NeSL (National E-Governance Services Ltd.) platform. In the context of Leegality, NeSL eBG enables banks and corporates to issue, sign, and manage eBank Guarantees entirely online, streamlining the traditionally paper-heavy process.

Leegality integrates with NeSL eBG to support the eSigning of eBG documents through the NeSL platform. The integration ensures compliance with NeSL's security and workflow requirements while offering a seamless user experience within Leegality's document journey.

### Standard Practice for NeSL eBG

In most eBG use cases, only the bank officers (on behalf of the issuer) are required to sign the document. However, NeSL mandates the inclusion of Debtor and Beneficiary information during eBG issuance—even if they are not signing the document.

To support this requirement, Leegality introduces **NeSL Parties** in the eBG flow. These are non-signing entities (typically the Debtor and the Beneficiary) whose details are still uploaded to NeSL IU.

> 🔗 [Learn more about NeSL Parties](https://knowledge.leegality.com/document-execution/nesl/nesl-features/nesl-parties)

### NeSL eBG Flow - Sending Journey

1. Add invitee and enter their **name, email address**, and/or **phone number**.  
2. Click **Signature Type** and enable **NeSL eSign**.  
3. Click on the **Signing Journey Options** and enable the **Number of NeSL Parties** toggle.
> **Warning — Mandatory**
>
> At least 2 NeSL Parties (Debtor and Beneficiary) must be added for eBG flows.

4. Click **Next**. Here, you need to configure the details of Debtor and Beneficiary as NeSL Parties in the Form.

## Step 4: Fill NeSL Form

Next, fill out the [**NeSL Form**](https://knowledge.leegality.com/document-execution/nesl/nesl-features/nesl-form). You can choose one of two methods:

#### **Option 1: Excel Template**

- Click **Download Template Excel File**.  
- The first row contains field names; fill in details in the second row accordingly.

#### **Option 2: Dashboard Form**

- Click **Proceed to filling dashboard form**.  
- A multi-section form opens, with section names on the left and corresponding fields on the right.

> **Note:** Mandatory and optional fields vary depending on the selected registration type.

## Step 5: Configure Signing Coordinates

1. Place the [**signature coordinates**](https://knowledge.leegality.com/document-execution/leegality-features/signature-coordinate/signature-coordinate) on the document.  
2. Preview the document and click **Send** to complete the process.

## Post Sending Document

After sending the document, you will be redirected to its [**details page**](https://knowledge.leegality.com/document-execution/nesl/details-page), where you can track the signing status of all invitees and perform additional actions.

NeSL invitees will receive notifications from both NeSL and Leegality via their email address and/or phone number to [**sign the document**](https://knowledge.leegality.com/document-execution/nesl/nesl-signing-journey). Leegality notifications to NeSL signers are triggered only after receiving a success response from NeSL for transaction creation, and the first NeSL signer becomes active only after this confirmation. This ensures signers receive a notification with an active signing link only when the NeSL transaction has been successfully created. Non-NeSL invitees will receive notifications from Leegality based on your configured settings.

---

URL: https://knowledge.leegality.com/document-execution/nesl/nesl-signing-journey

# NeSL Signing Journey

This section explains how signers (invitees) can complete their NeSL eSigning process after receiving an invitation. 

#### OTP-based Signing Journey

1. Look for an invitation from NeSL. The message will contain a secure link to begin the eSigning process.
2. You will be redirected to NeSL’s eSigning platform.
3. Enter the OTP sent to the mobile number provided in the NeSL Form by the sender.
4. Once authenticated, the document will be displayed. Scroll to the bottom and click **I Agree** to proceed.
5. If the document includes an e-stamp, stamp details will be shown. Click **Next** to confirm.
   > ⚠️ **Important:** Once you click **Next**, the e-stamp paper will be generated. This action is **irreversible**.
6. The stamped version of the document will now be shown. Scroll down and click **Close** to continue.
7. A consent message will appear. Tick the checkbox to agree and click **Submit**.
8. A message will appear: *“You are being redirected to the ESP website.”* Click **Close** to proceed.
9. On the eSign Service Provider (ESP) site, enter your **Aadhaar number** and **OTP** to finish the eSign process.

#### Face Auth Signing Journey

You can now complete NeSL eSigning using Aadhaar face authentication, in addition to the existing Aadhaar OTP, biometric, and token-based eSign options.

#### Prerequisites

Before you begin, ensure you meet the following requirements:

1. You are using an Android device (face authentication is currently available only on Android).
2. Face authentication is enabled for your NeSL account. If you don't see this option, contact NeSL to request access.
3. Install the following apps on your device:
   - **Aadhaar Face RD** (by UIDAI): [Download from Play Store](https://play.google.com/store/apps/details?id=in.gov.uidai.facerd)
   - **eMudhra App** (by eMudhra, NeSL's eSign Service Provider): [Download from Play Store](https://play.google.com/store/apps/details?id=com.emudhra.esignpdf)

#### Face authentication signing journey

The NeSL process remains the same until you reach the eSigning step. After completing the link access, captcha, OTP authentication, and eStamping, follow these steps:

1. On the eSigning screen in NeSL, select **Face Auth Based eSign**.
2. You will be redirected to the eMudhra ESP page.
3. Select **Sign using Mobile App**.
4. The eMudhra App opens automatically.
5. Enter your Aadhaar number and complete the face capture process.
6. After successful verification, you will be redirected to the NeSL completion screen and then back to Leegality.

> **Info — NeSL Only Stamping - Automatic Retry**
>
> If a NeSL only stamping fails due to temporary stamping issues at NeSL's end, Leegality will automatically retry it. Upon success, the system seamlessly attaches the stamp, deducts the fee, updates the status, and triggers your invitations.
> 
> **Note:** NeSL form validation errors cannot be auto-retried and require you to send a new document.

---

URL: https://knowledge.leegality.com/document-execution/settings/account-level/eSignature-and-seal/overview

# eSignature and Seal settings

This section allows you to save the eSignature seal and signature appearance for specific eSign types, including:

* Virtual Sign  
* Quick Sign  
* Visual Sign  
* Document Signer Certificate (DSC)

You can also configure the automated signing process for all these eSign types here.

These saved configurations can be used whenever you sign a document using one of these eSign type.

> **Info — Example**
>
> If you have configured a hand-drawn signature for Virtual Sign, it will be automatically selected when you need to use Virtual Sign, eliminating the need to upload or draw the signature again.

This feature is particularly beneficial for regular signers, as it streamlines the signing process by saving their eSign and seal configurations, making document signing quicker and easier.

---

URL: https://knowledge.leegality.com/document-execution/settings/account-level/eSignature-and-seal/set-automated-sign

# Setting Up Automated Sign

Before proceeding, ensure that your eSign for which you want to automated sign is already set up in your account.

To Set Up Automated Sign in your account:

1. Click on the **Settings ⚙️** icon in the top right corner.
2. From the left panel, go to **Settings > eSignature & Seal.**
3. For the desired eSign type, click on the **edit** icon on the right side.
4. Toggle the **Automated Sign** option to enable it.
5. Check the consent box to agree to the terms of using Automated Sign.
6. Set a password for the Automated Sign feature to secure its use.

---

URL: https://knowledge.leegality.com/document-execution/settings/account-level/eSignature-and-seal/set-document-signer-certificate-dsc-for-your-account

# Setting up Document Signer Certificate (DSC)

The DSC configured here will also be used for bulk-signing the document.

To set up a Document Signer Certificate for your account:

1. Click on the **Settings ⚙️** icon in the top right corner.
2. From the left panel, go to **Settings > eSignature & Seal.**
3. In Document Signer Certificate, click on **Setup**.
4. Enter the **eSign Name**. It can be anything.
5. Choose where you want to store the Document Signer Certificate:
    - **My Server:** Select this if you want to store on your server. Provide the **Profile Access URL**, it should be publicly accessible. (**Important:** Leegality will provide a list of IP addresses for whitelisting to ensure secure access.)
    - **Leegality Server (_Recommended_):** If storing on Leegality's server, upload the `.pfx` file and enter the password of the .pfx file.
6. Provide the **Email Address(es)** for receiving certificate expiry notifications.
7. Click **Save** to complete the setup.

---

URL: https://knowledge.leegality.com/document-execution/settings/account-level/eSignature-and-seal/set-esignature-seal-for-your-account

# Setting up eSignature Seal

An eSignature seal is a digital version of the traditional rubber stamp. It is used to authenticate signatures.

If the sender requires your signature with an eSignature seal, the seal configured here will be pre-selected.

To set up the eSignature seal for your account:

1. Click on the **Settings ⚙️** icon in the top right corner.
2. From the left panel, go to **Settings > eSignature & Seal.**
3. In the Default eSignature Seal section, you can choose between three types of eSignature seals:
      - **Authorised Signatory:** Requires organization's name.
      - **Director:** Requires organization's name.
      - **Upload Physical Seal:** Upload an image of the physical seal. (Supported image formats are .jpg, .jpeg, and .png)

> **Info**
>
> The company seal feature is available in every signing method, including **Aadhaar eSign**. When using Aadhaar eSign with a company seal, the signature will display your company seal instead of the Aadhaar logo.

4. You can see the preview of the eSignature seal on the right.
5. Click **Update** to save your settings.

---

URL: https://knowledge.leegality.com/document-execution/settings/account-level/eSignature-and-seal/set-quick-sign-for-your-account

# Setting up Quick Sign

Quick Sign is a fast eSigning method that simplifies the signing process by eliminating OTP verification. It's ideal for situations where speed is prioritized over enforceability.

Quick Sign is a fast eSigning method that simplifies the signing process by eliminating OTP verification. It's ideal for use cases where speed is prioritised over enforceability.

To Set up Quick Sign for your account:

1. Click on the **Settings ⚙️** icon in the top right corner.
2. From the left panel, go to **Settings > eSignature & Seal.**
3. In the Quick Sign section, click on the **Setup**. A side menu will appear on your screen with three options:
      - **Draw:** Draw your signature on the screen.
      - **Choose a pre-built virtual sign:** Select a pre-built signature from the available options.
      - **Upload a photo of your signature:** Upload an image of your hand-drawn signature. (Supported image formats are .jpeg, .jpg, and .png)
4. Select your preferred option and click **Save**.

---

URL: https://knowledge.leegality.com/document-execution/settings/account-level/eSignature-and-seal/set-virtual-sign-for-your-account

# Setting up Virtual Sign

Virtual Sign is an electronic authentication that requires OTP verification of the Email or Phone Number.

By setting up a Virtual Signature in your account, you can also use for automated signing of documents.

To set up a Virtual Signature for your account:

1. Click on the **Settings ⚙️** icon in the top right corner.
2. From the left panel, go to **Settings > eSignature & Seal.**
3. In the Virtual Sign section, click on the **Setup**. A side menu will appear on your screen with three options:
      - **Draw:** Draw your signature on the screen and save it.
      - **Choose a pre-built virtual sign:** Select a pre-built virtual signature from the available options.
      - **Upload a photo of your signature:** Upload an image of your hand-drawn signature. (Supported image formats are .jpeg, .jpg, and .png)
4. Select your preferred option and click **Save**.

---

URL: https://knowledge.leegality.com/document-execution/stamps/stamp-procurement-panel

# Stamp Procurement Panel

The **Stamp Procurement Panel** is a lightweight, self-serve dashboard that enables you to manage stamp series and generate proforma invoices independently, without requiring access to the full Leegality dashboard. This upgrade makes stamp series creation  more accurate and fully self-serve with the following enhancements:

## What the Procurement Panel Offers

The **Stamp Procurement Panel** provides you with essential stamp management capabilities:

- **View All Stamp Series**: Access the complete list of all existing stamp series for your organization. See details including state, denomination, available stamps, and status at a glance.
- **Create and Edit Stamp Series**: 

    Based on your access level, you can:
        - Create new stamp series with state-specific configurations
        - Edit existing series details
- **Generate Proforma Invoices**: Download proforma invoices for your stamp purchases directly from the panel, streamlining your procurement and accounting processes.

## Access the Stamp Procurement Panel

### How to Get Access

The **Stamp Procurement Panel** is not publicly accessible. Access to the **Stamp Procurement Panel** is restricted and provided on a per-organization basis by the Leegality support team. Only users with authorized email addresses can log in to the panel.

If you need access to the **Stamp Procurement Panel**:

1. Contact the Leegality support team at **support@leegality.com** or the Leegality Account Manager of your organisation.
2. The support team will authorise the specified email addresses for your organization.
3. Once authorised, you will receive the access link to log in to the panel.

Two types of access are provided for the panel:

- **Edit and Create Access**: For those who need to create and edit stamp series from the panel.
- **View Access**: For those who require to purchase stamp paper but do not need to create or edit stamp series.

> **Info — NOTE**
>
> User with any level of access can generate proforma invoice.

### Login to Stamp Procurement Panel

Follow these steps to log in to the **Stamp Procurement Panel**:

1. Navigate to the Stamp Procurement Panel login page. (The access link will be provided by Leegality support or the AM.)
2. Enter your email address that has been authorized for access.
3. Click the **Send Verification Code** button.
4. An OTP (One-Time Password) will be sent to your email address.
5. Enter the OTP in the verification field.
6. Once authenticated, you will be logged into the **Stamp Procurement Panel** and can access your organization's stamp series and procurement options. 

> **Info — OTP Validity and Limits**
>
> - The OTP is valid for **10 minutes** from the time it is sent
>         - You can resend the OTP after **60 seconds** if you didn't receive it
>         - You can request a new OTP up to **5 times**. After 5 attempts, you will need to wait before requesting additional OTPs

## Dashboard Overview

Once you successfully log in to the **Stamp Procurement Panel**, you will see the main dashboard that displays your organization's stamp inventory and provides tools for managing stamp series and procurement.

The dashboard is organized into functional areas including:

| Section | Description | Key Features |
| :---- | :---- | :---- |
| **Top Navigation Bar** | Header section with search and action buttons | • Search by Series Number
• **Purchase** button (activates when series selected)
• **+ Create** button (admin only) |
| **Stamp Series Inventory Table** | Main table displaying all stamp series and their status | • Series Information (ID, State, Article Type)
• Denomination
• Inventory counts by status
• Last Purchase date
• **View** button for each series |

For detailed information about stamp series fields, inventory statuses, and column descriptions, see the [Stamp Series](https://knowledge.leegality.com/document-execution/stamps/stamp-series) page.

### Viewing Series Details

Click the **View** button to open a right-side panel showing complete series details.

> **Info — Edit Access**
>
> If you have edit access, you will see an **Edit** button in the details panel. Learn more about [editing stamp series](https://knowledge.leegality.com/document-execution/stamps/stamp-procurement-panel/edit-stamp-series).

## Getting Started

Once you have access to the **Stamp Procurement Panel**, you can:

- View all existing stamp series and their inventory status
- [Purchase Stamps and Download Proforma Invoice](https://knowledge.leegality.com/document-execution/stamps/stamp-procurement-panel/purchase-and-download-proforma) to order stamp papers and obtain invoices
- [Create a Stamp Series](https://knowledge.leegality.com/document-execution/stamps/stamp-procurement-panel/create-a-stamp-series) to set up new stamp configurations (admin access required)
- [Edit Stamp Series](https://knowledge.leegality.com/document-execution/stamps/stamp-procurement-panel/edit-stamp-series) to update shipping information and other editable fields (admin access required)

> **Tip — Need Help?**
>
> If you have questions about the **Stamp Procurement Panel** or need assistance with stamp procurement, contact **support@leegality.com**.

---

URL: https://knowledge.leegality.com/document-execution/stamps/stamp-series

# Stamp Series

Stamp Series is a system that helps you order and track stamp papers easily. Here's how it works:

1. **Store Your Information:** It saves details about the stamp papers you want to purchase and their delivery address.
2. **Easy Ordering:** You can order stamp papers without re-entering the same information each time.
3. **Inventory Management:** Monitor your stamp usage and manage your inventory effectively
4. **Track Your Stamps:** All your stamp papers are tracked in the system, so you can see where they are in the delivery process.

In short, Stamp Series makes ordering and tracking stamp papers simple and convenient by remembering your preferences and shipment details.

To access your Stamp Series, select **Stamps** on the top bar and **Series** on the left.

The Stamp Series section is divided into three categories:

- **All:** Displays all stamp series.
- **Starred:**  Displays stamp series you have marked as ⭐starred for quick access.
- **Draft:** Displays stamp series that are in the draft stage.

## Table overview

The table provides an overview of each stamp series with the following actions and information:

- Stamp Series Details
- [Purchase Stamp Papers](https://knowledge.leegality.com/document-execution/stamps/stamp-series/purchase-stamp-series)
- [Edit Stamp Series](https://knowledge.leegality.com/document-execution/stamps/stamp-series/edit-stamp-series)
- [Consumption History of stamps](https://knowledge.leegality.com/document-execution/stamps/stamp-series/consumption-history-of-stamps)
- [Extend Expiry of stamps](https://knowledge.leegality.com/document-execution/stamps/stamp-series/extend-expiry-of-stamps)

### Stamp Series Details

- **Series Number:** A unique number assigned to each stamp series. This helps identify the stamp series during purchase, group stamp creation, and document initiation. (**Note:** This is auto-generated by Leegality.)
- **State:**  Displays the state name corresponding to the stamp paper.
- **Series Name:** Name of the stamp series assigned by the creator of the series for identification
- **Denomination:** Indicates the value of the stamp paper(s) contained in the series.

### Stamp Statuses

- **Unused:** Stamps available for use when sending documents for execution.
- **Reserved:** Number of stamps affixed to documents currently waiting to get eSigned. 

> **Info**
>
> If the document remains unsigned these stamps are credited back to the Unused state.

- **Used:** Number of stamps affixed to documents that have been signed.
- **Blocked:** Number of blocked stamp papers that are not eligible for digital document creation.
- **In Process:** Number of stamps purchased and currently under procurement.
- **Expired:** Displays the count of stamps for which the expiry date has passed. You can [extend the expiry date](https://knowledge.leegality.com/document-execution/stamps/stamp-series/extend-expiry-of-stamps) to continue using these stamps for digital document execution.
- **Total:** The total number of stamps purchased to date.

> **Tip**
>
> You can add or remove columns by clicking on the (**III**) icon in the table header.

### Needs attention ![Needs Action](https://knowledge.leegality.com/img/needs-action.png)

- **Expiring Soon:** Indicates the number of stamp papers expiring in the next 30 days. You can directly extend the expiry date from here.
- **Low Balance:** Indicates that you have consumed 100% of your last purchase quantity. You can directly purchase from here.

---

URL: https://knowledge.leegality.com/document-execution/stamps

# Stamps Overview

The Stamps section gives you complete access to Stamp Series and Stamp Groups. Here, you can efficiently manage all stamp-related activities, including:

- [**Creating new Stamp series**](https://knowledge.leegality.com/document-execution/stamps/stamp-series/create-a-stamp-series) and [**Stamp groups**](https://knowledge.leegality.com/document-execution/stamps/stamp-group/stamp-groups)
- [**Purchasing stamps**](https://knowledge.leegality.com/document-execution/stamps/stamp-series/purchase-stamp-series)
- [**Viewing consumption history**](https://knowledge.leegality.com/document-execution/stamps/stamp-series/consumption-history-of-stamps)
- Inventory management

The stamp section has been divided into two parts:

- **Stamp Series:** Stamp Series is required to purchase the stamp papers of a specific state and denomination. It also helps you keep track of how and when the stamp papers are used.
- **Stamp Groups:** A Stamp Group is a collection of various stamp series of different denominations combined. This grouping allows you to pay [**variable stamp duty**](https://knowledge.leegality.com/document-execution/stamps/stamp-group/stamp-groups).

> **Info — Note**
>
> The stamps  section will only be visible if the stamp module is included in your subscription plan.

## Types of Stamps

---

URL: https://knowledge.leegality.com/document-execution/template/html-template

# HTML Template

HTML Templates allow you to create documents from scratch using an HTML-based editor. This provides flexibility and customization, letting you design documents that fit your specific needs without being restricted by a predefined layout.

## Key Features

- **Create from Scratch:** Build documents without requiring an existing PDF file.
- **Rich Text Formatting:** Use advanced formatting options to create professional-looking documents.
- **Dynamic Fields:** Add interactive elements like text boxes, dropdowns, and checkboxes.
- **Full Customization:** Control every aspect of your document's appearance and structure.

## When to Use HTML Templates

HTML Templates are ideal when you:
- Need to create a document from the ground up
- Require extensive formatting and styling options
- Want to incorporate dynamic elements and interactive fields
- Need to maintain brand consistency with custom styling

## Getting Started with HTML Templates

This section covers everything you need to know about working with HTML Templates:

- **[Create a New PDF](https://knowledge.leegality.com/document-execution/template/html-template/create-a-new-pdf):** Learn how to create a new HTML template from scratch.
- **[Formatting and Editing](https://knowledge.leegality.com/document-execution/template/html-template/formatting-and-editing):** Discover all the formatting and editing options available in the HTML template editor.
- **[Preview and Download](https://knowledge.leegality.com/document-execution/template/html-template/preview-and-download):** Learn how to preview your template and download the final PDF document.

---

URL: https://knowledge.leegality.com/document-execution/template

# Template Engine

Welcome to Leegality's Template Engine! Save time and streamline your document sending processes by creating reusable templates. Whether you're dealing with contracts, agreements, or any other document that follows a similar format, templates are the perfect solution.

Templates are perfect for almost any document sending journey that you do over and over again. You can use templates in new document journeys as well as workflows.

To access Template, on the dashboard, click **Templates** on the left.

## Types of Template

There are two types of templates:

- **PDF Editor:** Start with an existing PDF file and add dynamic fields on top of it.
- **Text Editor:** Start with a blank document in Leegality’s HTML-based template engine.

## Use Cases of Template

### PDF Template

Use PDF Editor to create standardized documents such as forms and legal agreements. This is especially helpful for businesses that already have pre-designed forms and just need to add fillable fields using the PDF editor.

### Text Editor

Use Text Editor Templates when you need flexibility and customisation. This HTML-based editor lets you create documents from scratch and create the structure to fit your specific needs, without being restricted by a predefined layout.

> **Tip**
>
> Contact us at support@leegality.com for template creation, tailored to your needs.

---

URL: https://knowledge.leegality.com/document-execution/troubleshooting/login-troubleshooting

# Login Troubleshooting

A quick reference for the most common errors you may see while logging into or signing up on the Leegality dashboard, along with the steps to resolve them.

| Error Message | Reason | Recommended Action |
| :---- | :---- | :---- |
| **Your account is locked due to 5 successive incorrect login attempts.** | Auto-lock triggered after five consecutive incorrect password attempts on the dashboard or a signing journey. | Open the unblock link sent to your registered email/phone number to unlock the account immediately. 

 If the link is unavailable, contact [support@leegality.com](mailto:support@leegality.com) with the locked email, user name, and organisation name. |
| **Email/phone number not registered with Leegality** | The email or phone number entered is not associated with any Leegality account. | On entering the OTP sent to the given email/phone number, the user is redirected to the sign-up page to create a new Leegality account. |
| **Login OTP not received** (no error shown; OTP simply does not arrive) | Email landed in spam, address is on Leegality's suppression list (from a prior bounce or spam report), corporate firewall is blocking Leegality's domain, or OTP was sent to a different email. | Check spam/junk for mails from `noreply@leegality.com`. 

 Resend the OTP and wait up to 2 minutes. 

 Ask IT to whitelist Leegality's sending domain. 

 Contact [support@leegality.com](mailto:support@leegality.com) for suppression list removal — include the affected email and organisation name. |
| **Forgotten password** | User cannot recall their dashboard password and needs to set a new one. | Go to the [Leegality dashboard login page](https://dashboard.leegality.com/), enter your registered email, and click **Forgot Password**. 

 Open the reset link from your inbox (check spam) and set a new password. 

 If the reset email does not arrive, your address may be on Leegality's suppression list — contact [support@leegality.com](mailto:support@leegality.com) for removal. |
| **Password reset email not received** | Same root cause as missing OTPs — spam filter, suppression list, or firewall block. | Check spam, then contact [support@leegality.com](mailto:support@leegality.com) for suppression list removal. |

## Still need help?

If none of the steps above resolve your issue, contact [support@leegality.com](mailto:support@leegality.com) with your registered email, organisation name, the exact error message, and a screenshot if possible.

---

URL: https://knowledge.leegality.com/document-execution/troubleshooting/sending-journey/upload-errors

# PDF Upload Errors

This page lists the common errors you may encounter when uploading a PDF on the **Create Document** page, along with their resolutions.

If you encounter an upload issue, first verify your file meets the upload requirements documented in the [Sending Journey](https://knowledge.leegality.com/document-execution/getting-started/sending-journey) — PDF format, up to 10 files, combined size within 30 MB, not password-protected, not corrupt. If the file meets all requirements and the error persists, find your error message below.





ErrorCauseResolution





"Selected file is not allowed"
The uploaded file does not meet the system's upload requirements. Common reasons:
  • The file is not a PDF
  • The PDF is corrupt
  • The PDF is password-protected
  • The PDF has editing or security restrictions


  1. Confirm the file is a valid PDF (.pdf) and not corrupt.
  2. Remove any password or security restrictions from the PDF.
  3. Re-save the PDF to clear any restrictive properties:
    • Open the PDF in Chrome or Adobe Reader
    • Click Print
    • Select Save as PDF as the destination
    • Save and re-upload the new copy
  4. Refresh the page, clear browser cache, or try a different browser.
  5. If you are on a corporate network or device, test on a personal device or network.





"The PDF file you are trying to upload is password protected. Please remove the password and try again."
The PDF you are uploading is password-protected.
Remove the password from the PDF and upload again. You can remove the password by opening the PDF in Adobe Acrobat (File > Properties > Security) or by re-saving via Print > Save as PDF in Chrome without a password.




"This particular PDF file is not suitable for eSigning. Please create a new file and try again."
The file was recognised as a PDF, but its validation failed. This can happen with corrupted PDFs.
Open the PDF in a standard PDF tool (Adobe Acrobat, Chrome, or Preview), re-save it, and re-upload the new copy.




"Unexpected error while uploading file. Please try again."
An unexpected error occurred during upload. This is usually transient.

  1. Retry the upload once.
  2. Verify the file format and that the file is not corrupt.
  3. If the error persists, contact support@leegality.com with the error code and a screenshot.





Upload completes but the page does not advance

Document upload stuck at 100%		

  • Browser cache or session issue
  • PDF is corrupt
  • A corporate network or firewall blocking part of the upload flow


  1. Refresh the page and retry the upload.
  2. Recheck file requirements (PDF only, up to 10 files, combined size within 30 MB, A4 preferred).
  3. Try a different browser.
  4. If you are on a corporate network or device, test on a personal device or network.







## Still need help?

If none of the steps above resolve your issue, contact [support@leegality.com](mailto:support@leegality.com) with the affected file (if shareable), the exact error message or error code, and a screenshot.

---

URL: https://knowledge.leegality.com/document-execution/workflows/v4/completion-emails

# Completion Emails

When a v4 document pack is signed, two different emails mark the progress:

1. **eSign confirmation** — sent to you immediately after you complete your signature.
2. **Completion email** — sent to all invitees once every invitee has signed the pack.

## eSign confirmation (when you sign)

As soon as you complete your signature, you receive a confirmation via email or SMS acknowledging your eSign. The pack is not complete yet — the other invitees' journeys continue until everyone has signed.

> **Info — Example eSign confirmation email**
>
> ![Example v4 eSign confirmation email sent to an invitee right after they sign](https://knowledge.leegality.com/img/eSign-success-mail-v4.png)

## Completion email (when every invitee has signed)

Once all invitees in the signing order have signed, the document pack is **completed**, and all invitees — including reviewers — receive the completion email with:

- **Each completely signed document attached separately**
- **A separate audit trail PDF for each document**

> **Info — Example completion email**
>
> ![Example v4 completion email with each signed document and its audit trail attached separately](https://knowledge.leegality.com/img/Signing-completion-mail.png)

> **Info — CC invitees**
>
> What [CC invitees](https://knowledge.leegality.com/document-execution/leegality-features/invitee-level/types-of-invitee/cc?type=v4-workflow&journey=new-document-journey) receive depends on the **CC Options** the sender has configured. For example, a CC invitee receives the signed documents and audit trails only if **Share document and Audit trail with CC** is enabled.

---

URL: https://knowledge.leegality.com/document-execution/workflows/v4/create-a-workflow

# Create a v4 workflow

A v4 workflow lets you save a reusable document-sending configuration — multi-document packs, stamping, invitee setup, and signature coordinates — so the workflow runner can send documents repeatedly without configuring everything each time.

> **Info — Note**
>
> Only admins have permission to create workflows.

Creating a v4 workflow happens across the **Create**, **Invite**, and **Finalise** stages. If any uploaded document contains a template, an additional **Template** stage appears before Finalise. These stages are covered in the steps below. You can also add an optional [Custom Page](https://knowledge.leegality.com/document-execution/workflows/v4/setup-configuration/custom-page) before Create, to collect the pack's key details on one screen.

## Step 1: Create a New Workflow

To start a new workflow:

1. Go to the **Workflows** section using the left panel.
2. Open the **V4 Workflows** tab and click **+ New Workflow**.
3. Enter the **Workflow Name** and click **Confirm**.

    This opens the workflow editor at the **Create** stage, where you assemble and configure the **document pack** — the set of documents this workflow will send each time it runs.

### Understand the document structure

- **Sub-document:** An individual PDF you upload. One or more sub-documents combine to form a primary document.
- **Primary document:** A set of one or more sub-documents. Each primary document is signed individually, has its own audit trail, and appears as a separate tab.
- **Document pack:** The collection of all primary documents, sent together to invitees in a single, unified journey.

For a detailed explanation, see [Packs and documents](https://knowledge.leegality.com/document-execution/workflows/v4/understanding-v4/packs-and-documents).

## Step 2: Prepare Your Documents

### Add primary documents

1. A primary document is already present when you land on the Create stage. Click **+ Add Document** to add more.
2. The primary document tabs appear at the top of the screen.

You can add up to **15 primary documents** in a single pack.

> **Info — NOTE**
>
> To delete a primary document, click the **Delete** icon in the Configure Documents section.

### Configure each primary document

 Each primary document must contain at least one sub-document, or at least one **enabled** template — an empty upload placeholder, or a template that is added but not enabled, does not satisfy this requirement.

A primary document can contain up to **10 sub-documents**. You can add **PDFs**, **templates**, or both.

#### Option 1: Upload PDF File(s)

1. Use the **upload PDF** box to add PDF sub-documents from your computer.
2. Drag and drop files into the designated area, or browse and select files manually.
3. Click the delete icon (🗑️) to remove unwanted files.

> **Warning — File size limit**
>
> The combined size of all sub-documents and the template in a primary document must be **15 MB or smaller**.

#### Option 2: Use Template(s)

> **Tip — Prerequisite**
>
> Templates must be created in advance. Learn how to create a [template](https://knowledge.leegality.com/document-execution/template/).

1. Click **Select** from the *Select Template* option. A drawer opens on the right, listing every template configured for the account.
2. Templates are grouped by **Template ID** — each template has a single row covering all its versions. Each row shows:
    - **Template name**
    - **Version** — a dropdown to pick a specific version, or leave it on **Latest** to always use whichever version is newest when the document is created or run.
    - **Template type** — PDF or HTML
    - **Created date**
    - **Preview** — opens the template in a preview modal
3. Use the **search** box to find a template by name, or the **type filter** to narrow the list to PDF or HTML templates.
4. Select one or more templates by ticking the checkbox next to each row, then close the drawer.

Selected templates are listed under the primary document's sub-documents, carrying the version (or the **Latest** tag) you picked in the drawer.

##### Enable and delete selected templates

Each selected template carries two more controls:

- **Enable toggle:** Controls whether the template is actually used in the signed document — a template that is selected but not enabled is kept as an available option for the workflow runner, but plays no part in signing unless it's enabled. All selected templates are enabled by default. This is an attribute like any other — by default it is **visible and editable** for the workflow runner, and you can restrict it using [Field Properties](https://knowledge.leegality.com/document-execution/workflows/v4/setup-configuration/field-properties).
- **Delete button:** Removes the template from the document. By default, it is **not visible and not editable** for the workflow runner.

Click and drag sub-documents to rearrange their order — this is the order in which they appear in the merged document.

#### 2. Set document details

1. Enter the **Document Name** (the primary document name). This field is required. Uploading a file also autopopulates the Document Name field — you can rename it if you want.
2. Enter the **Internal Reference Number**. Only letters (A-z), numbers (0-9), and special characters (.,-:(),_[]&/ ) are allowed.
3. **[Document Folder](https://knowledge.leegality.com/document-execution/manage-documents/folders?type=v4-workflow#assigning-a-folder-in-v4) (optional):** Use the **Document Folder** option to select the folder where the document will be saved.
4. **[Reference Attachment](https://knowledge.leegality.com/document-execution/leegality-features/document-level/reference-attachments) (optional):** Enable the **Reference Attachment** toggle to upload a reference file. Invitees can access and refer to these documents while signing. Supported file types are **PDF, JPEG, PNG, or JPG**.

> **Info — Note**
>
> The reference attachments' total file size must be **5 MB or smaller**.

Repeat this process for all primary documents in your pack.

### Add custom fields

Custom fields let you add new fields to your workflow — such as an employee ID, loan amount, or reference number. Custom fields must be created in advance (see [Create a custom field](https://knowledge.leegality.com/document-execution/workflows/v4/custom-fields/create-a-custom-field)), and they cannot be added in the **Template** or **Finalise** stages.

To add a custom field to your workflow:

1. Go to the **left panel**. If you don't see it, switch to the **Advanced** tab in the top-right corner.
2. Open **Custom Fields**. The fields you have already configured are listed here.
3. Click the **+** icon next to a field. A pop-up appears with two options:

    - **Add to Pack:** Adds the custom field to the whole pack. The field appears in the **right panel**, where workflow-level (pack) details are configured.
    - **Add to Document:** Adds the field to every document in the pack — including any documents you add later. To show the field in only some documents, mark it as **not visible** on the others using [Field Properties](https://knowledge.leegality.com/document-execution/workflows/v4/setup-configuration/field-properties).

> **Info — Reorder or remove fields**
>
> Every field has a **six-dot** handle — click and drag it up or down to reorder fields. This works throughout the workflow. To remove a custom field, right-click it and click the **delete** icon; this removes it from all documents in the pack.

> **Info — Set field properties and validations**
>
> At this stage, you can also control each field individually:
> 
>     - **[Field Properties](https://knowledge.leegality.com/document-execution/workflows/v4/setup-configuration/field-properties):** Set a field's **Visibility**, **Editability**, and **Mandatory** state to tailor how the runner sees and interacts with it.
>     - **[Validations](https://knowledge.leegality.com/document-execution/workflows/v4/setup-configuration/field-configuration):** Add character limits and a regex pattern to control what can be entered — for example, enforce a PAN pattern on the Internal Reference Number so only values like `ABCDE1234F` are accepted.

### Configure pack settings

This panel shows the values common to the whole pack. Configure pack-level settings in the right panel. These settings apply to the entire document pack:

- **Pack Details:**
    - **Pack Name:** Name for the entire pack.
    - **Pack Internal Reference Number:** Reference for tracking.
    - **Folder:** Select the folder for the pack.
- **Document Deletion:** Set an auto-delete time interval. This uses the settings configured in [**Settings ➔ Department ➔ Document Security**](https://knowledge.leegality.com/document-execution/settings/Department/document-security-settings#auto-delete-after-document-completion).
- **SFTP:** Choose an SFTP profile to automatically transfer signed documents after completion.

> **Info — Note**
>
> - The **Pack Name** is auto-populated once you add documents to the pack.
>     - Any custom fields added to the pack are displayed here.

---

## Step 3: Add Stamp Papers

Enable the **Attach Stamping** toggle on a primary document to add stamp paper. Two placement options appear:

#### Stamps for merged document

Attaches a single stamp paper at the beginning of all combined sub-documents (Stamp → Sub-document A + Sub-document B).

Choose one of the following stamping options to apply to the merged document:

1. **Stamp Series:** Select a **Stamp Series** and enter the **Quantity**. Click **Add new series** to add another series.
2. **Stamp Group:** Select a **Stamp Group** and enter the **Amount**.
3. **Revenue Stamp:** Add a **Revenue stamp** and enter the **Quantity**.
4. **Stamp Upload:** Provide the **State**, **Denomination**, **First party name**, **Second party name**, and **Stamp serial number**.

> **Warning**
>
> You cannot use **Stamp Upload** together with a **Stamp Series** or **Stamp Group**. When you choose to upload your own stamp, you cannot also add a series or group.

#### Separate stamps for sub-documents

Attaches a dedicated stamp paper to each sub-document (Stamp 1 → Sub-document A, Stamp 2 → Sub-document B).

This option appears only when a primary document has more than one sub-document. When selected, the sub-documents are listed — click a sub-document to configure its stamping, then choose one of the following stamping options. Repeat for each sub-document you want to stamp.

1. **Stamp Series:** Select a **Stamp Series** and enter the **Quantity**. Click **Add new series** to add another series.
2. **Stamp Group:** Select a **Stamp Group** and enter the **Amount**.
3. **Revenue Stamp:** Add a **Revenue stamp** and enter the **Quantity**.
4. **Stamp Upload:** Provide the **State**, **Denomination**, **First party name**, **Second party name**, and **Stamp serial number**.

> **Warning**
>
> You cannot use **Stamp Upload** together with a **Stamp Series** or **Stamp Group**. When you choose to upload your own stamp, you cannot also add a series or group.

To understand how stamps are distributed across a pack, see [Distributed stamping](https://knowledge.leegality.com/document-execution/workflows/v4/understanding-v4/distributed-stamping).

Once all document details are configured, click **Proceed** to move to the Invite stage.

---

## Step 4: Invitee Configuration

In the Invite stage, you configure who signs and reviews the documents. As the creator, you can fully configure each invitee, or leave their details empty for the workflow runner to fill when running the workflow.

### Add invitees

A blank invitee is already present when you land on the Invite stage.

1. On the invitee card, enter the invitee's details — **Name**, **Label**, **Email**, and **Phone**.
2. Choose the invitee's role from the dropdown at the top left of the card:
    - Signer
    - [Reviewer](https://knowledge.leegality.com/document-execution/leegality-features/invitee-level/types-of-invitee/reviewer?type=v4-workflow&journey=workflow-creation) — a non-signing invitee who reviews the document and then approves or rejects it
    - [Group Signer](https://knowledge.leegality.com/document-execution/leegality-features/invitee-level/types-of-invitee/group-invitee?type=v4-workflow)
    - Group Reviewer

    Each invitee's default role is **Signer**, with the default eSign type configured in [Settings ➔ Department ➔ eSignature](https://knowledge.leegality.com/document-execution/settings/Department/esignature-settings#set-the-default-esign-type).

3. Click **Assign Documents** to assign the documents configured in the Create stage to this invitee. Invitees see and sign only their assigned documents. If you assign multiple documents, the invitee views them in the order you select them — the first document selected appears first.

> **Info — Note**
>
> Every invitee must be assigned at least one primary document, and every primary document must be assigned to at least one invitee.

> **Tip — Example**
>
> - **Borrower:** assigned the Loan Agreement and Property Documents.
>         - **Guarantor:** assigned the Loan Agreement only.
>         - **Bank Officer:** added as CC on the Property Documents only.

4. Click **+ Add invitee** to add more invitees, and repeat the steps above.
5. To add a [CC invitee](https://knowledge.leegality.com/document-execution/leegality-features/invitee-level/types-of-invitee/cc?type=v4-workflow&journey=workflow-creation), click **+ Add CC** at the bottom and provide their **Name** and **Email**. A CC invitee does not sign, but receives notifications about the document's progress.

> **Info — Note**
>
> All of these details can also be left blank for the workflow runner to fill while running the workflow.

### Configure invitee details

For each invitee, the workflow creator has two options:

- Leave the **Name**, **Email Address**, and/or **Phone Number** placeholders empty, allowing the workflow runner to enter these while running the workflow.
- Or, provide the invitee's **Name** and **Email Address**/**Phone Number**. Whether the workflow runner can modify these details depends on the visibility and editability set on those fields using [Field Properties](https://knowledge.leegality.com/document-execution/workflows/v4/setup-configuration/field-properties).

### Set signing order

Two toggles control the signing sequence:

- **Set signing order:** Click and drag the invitee cards to rearrange the sequence. Enabling this toggle lets the workflow runner change the order of the invitees while running the workflow.
- **Lock signing order:** Enabling this toggle enforces the signing sequence. Invitees receive their signing links sequentially — the document moves to the next invitee only after the current signer has signed.

> **Tip — Example**
>
> If there are two signers, the document is sent to the second signer only after the first signer has signed.

#### Advance Signing Order

Advance Signing Order lets you group invitees into levels so that invitees within the same level can sign in parallel, while levels are processed sequentially.

Once **Set Signing Order** is enabled, you can enable the **Advance Signing Order** toggle.

When you enable the toggle, the invitee cards collapse into a level-wise view. Each invitee starts in its own level.

- **Move invitees between levels:** drag an invitee card from one level to another. Invitees in the same level become active simultaneously and can sign in parallel.
- **Reorder levels:** drag a level above or below another to change the sequence.
- **Add a level:** click **+ Add Level** to insert a new empty level.
- **Delete a level:** click 🗑️ to remove a level when it is empty.
- **Edit an invitee:** click a collapsed invitee card to expand it and access its settings. Each invitee can have its own invitee-level configurations (eSign type, certificate verification, security features, etc.) regardless of which level it belongs to.

Whether the workflow runner can modify the Advance Signing Order configuration depends on the visibility and editability set on this field using [Field Properties](https://knowledge.leegality.com/document-execution/workflows/v4/setup-configuration/field-properties).

> **Tip — Example**
>
> Suppose you add two invitees (Borrower 1 and Borrower 2) in Level 1, and one invitee (Lender) in Level 2. When the document is sent, both Borrower 1 and Borrower 2 become active at the same time and can sign in parallel. Once both have signed, the Lender in Level 2 becomes active and can sign.

### Configure multiple eSign combinations

By default, an invitee signs all their assigned documents with the same eSign type and settings. With multi-combination, you can create separate sign combinations for the same invitee. Each combination has its own group of documents, eSign type, and settings. This lets an invitee sign different documents with different eSign types in a single journey.

1. Click **+ Add New eSign Combination** on the invitee card to add a combination.
2. Each combination appears as a row inside the invitee card. Click **+ Assign Documents** on a combination to open a panel on the right with a checkbox list of all available documents. Select one or more documents for that combination.
3. To remove a combination, click its delete button. You cannot delete the last remaining combination.

#### Combination-level vs invitee-level settings

With multiple combinations, the right panel splits into two tabs:

- **Combination tab** settings apply only to the selected combination. Use the combination switcher (Combination 1 / Combination 2 / …) to move between them.

    For a **signer**:
    - eSign Types
    - eSign Prioritisation
    - Signature Appearance
    - Webhooks
    - Consent & Validity Controls

    For a **reviewer**:
    - Webhooks
    - Consent & Validity Controls

- **Invitee Level tab** settings apply once across all combinations for the invitee. All remaining settings (Security Options, Certificate Verification, Notifications, Manage Invitee Interactions, Contact Book) are configured here.

Whether the workflow runner can modify the combination configuration depends on the visibility and editability set using [Field Properties](https://knowledge.leegality.com/document-execution/workflows/v4/setup-configuration/field-properties).

In the signing journey, combinations are executed in order. Combination 1 is signed first, then Combination 2, and so on.

> **Tip — Example**
>
> An invitee has two combinations: Combination 1 contains a Key Fact Statement with Quick Sign, and Combination 2 contains a Loan Agreement with Aadhaar eSign. The invitee first previews and signs the Key Fact Statement using Quick Sign, then previews and signs the Loan Agreement using Aadhaar eSign.

#### Combination behaviour during the signing journey

- **Shared documents across combinations:** The same primary document can be assigned to more than one combination for the same invitee. For example, a Loan Agreement can appear in both Combination 1 and Combination 2 if it needs to be signed with different eSign types or settings in each.
- **Re-entry after drop-off:** If the invitee signs or approves all documents in a combination and proceeds to the next one, then drops off mid-journey, reopening the signing journey shows only the documents of the current combination - the one with at least one un-actioned document. Documents from previous completed combinations are no longer available for preview.
- **Rejection cascade:** If the invitee rejects documents of a particular combination, all remaining documents in that combination and all subsequent combinations are rejected.

### Configure invitee settings

Select an invitee card to view their settings in the right panel. With a single combination, all settings appear under one **Settings** tab. With multiple combinations, the settings split into a **Combination** tab and an **Invitee Level** tab as described in [Configure multiple eSign combinations](#configure-multiple-esign-combinations).

The following sections list all available settings:

- [**eSign Types**](https://knowledge.leegality.com/category/esign-types)**:** Choose the eSignature type(s) available to this invitee. Available options depend on your account configuration.
- [**eSign Prioritisation**](https://knowledge.leegality.com/document-execution/esign-type/aadhaar/prioritise-aadhaar-for-invitee?type=v4-workflow)**:** Set the preferred eSign type for the invitee. This works for **Aadhaar eSign** only.
- **Signature Appearance:** Control how the signature appears on the signed document.
    - [**Invitee Name on Signature**](https://knowledge.leegality.com/document-execution/leegality-features/invitee-level/esignature-appearance/invitee-name-in-signature?type=v4-workflow)**:** Choose whether to display the invitee's name in the signature.
    - [**Company Seal**](https://knowledge.leegality.com/document-execution/leegality-features/invitee-level/esignature-appearance/company-seal?type=v4-workflow)**:** Ask the invitee to upload a company seal image.
    - [**Invitee Name Editing**](https://knowledge.leegality.com/document-execution/leegality-features/invitee-level/esignature-appearance/invitee-name-editing?type=v4-workflow)**:** Allow or restrict name editing during signing.
- [**Webhooks**](https://knowledge.leegality.com/document-execution/leegality-features/invitee-level/custom-url-and-webhook/webhook-and-url?type=v4-workflow)**:** Configure a custom webhook and URL for real-time status updates.
- [**Consent and Validity Controls**](https://knowledge.leegality.com/document-execution/leegality-features/invitee-level/other-features/additional-consent?type=v4-workflow&journey=workflow-creation)**:** Add custom consent terms alongside the default consent.
- **Manage Invitee Interactions:** Control how the invitee interacts with the document during the signing journey.
    - [**Base URL**](https://knowledge.leegality.com/document-execution/leegality-features/invitee-level/custom-url-and-webhook/webhook-and-url?type=v4-workflow)**:** Set a custom base URL for the invitee's signing journey.
    - [**Redirect URL**](https://knowledge.leegality.com/document-execution/leegality-features/invitee-level/custom-url-and-webhook/webhook-and-url?type=v4-workflow)**:** Redirect the invitee to a specific page after events in the signing journey.
    - [**Add Supporting Documents**](https://knowledge.leegality.com/document-execution/leegality-features/invitee-level/other-features/supporting-documents?journey=workflow-creation&version=v4)**:** Request additional documents the invitee must upload while signing.
    - [**Allow rejection of doc(s)**](https://knowledge.leegality.com/document-execution/leegality-features/invitee-level/other-features/reject-to-sign?type=v4-workflow)**:** Allow the invitee to reject signing the document(s).
    - [**Custom message**](https://knowledge.leegality.com/document-execution/leegality-features/document-level/custom-message?type=v4-workflow)**:** Add a custom message that the invitee sees with the signing invitation.
    - [**Local Language Settings**](https://knowledge.leegality.com/document-execution/leegality-features/invitee-level/local-language?journey=workflow-creation&version=v4)**:** Let the invitee complete the signing journey in a local language. 
- **Security Options:** Apply authentication and verification controls for the invitee. The following toggles are available:
    - [**1 Factor Authentication before document preview**](https://knowledge.leegality.com/document-execution/leegality-features/invitee-level/security/one-factor-authentication?type=v4-workflow)**:** OTP verification via email or phone number before the invitee can preview the document.
    - [**2 Factor Authentication before document preview**](https://knowledge.leegality.com/document-execution/leegality-features/invitee-level/security/two-factor-authentication?type=v4-workflow)**:** OTP verification via both email and phone number before the invitee can preview the document.
    - [**Capture GPS locations**](https://knowledge.leegality.com/document-execution/leegality-features/invitee-level/security/capture-gps-location?type=v4-workflow)**:** Record the invitee's location at the time of signing, with optional accuracy- and location-based restrictions.
    - [**Capture Photo**](https://knowledge.leegality.com/document-execution/leegality-features/invitee-level/security/capture-photo?type=v4-workflow)**:** Capture the signer's photo before they sign.
    - [**Send Document download link with OTP notifs**](https://knowledge.leegality.com/document-execution/leegality-features/invitee-level/security/send-raw-document-link)**:** Send a link to download the raw PDF document in all OTP verification emails/messages.
    - [**Mask contact details**](https://knowledge.leegality.com/document-execution/leegality-features/invitee-level/other-features/mask-contact-details?type=v4-workflow)**:** If enabled, contact details of other invitees will be masked from this invitee.
- [**Notifications**](https://knowledge.leegality.com/document-execution/leegality-features/invitee-level/notifications/)**:** Select how invitations, reminders, and updates are sent to the invitee — **Email**, **SMS**, or **WhatsApp**.
- [**Certificate Verification**](https://knowledge.leegality.com/document-execution/esign-type/aadhaar/signature-certificate-verifier)**:** Verify the intended signer's details against the digital signature certificate after signing.
- [**Contact Book**](https://knowledge.leegality.com/document-execution/contact-book)**:** Reuse saved contacts when adding invitees.

> **Info — Note**
>
> For CC invitees, only email notifications are available.

### Add custom fields to invitees

You can also add [custom fields](https://knowledge.leegality.com/document-execution/workflows/v4/custom-fields/overview) to invitees in the Invite stage from the **left panel**. Here, the options are:

- **Add to Invitee:** Adds the custom field to the selected invitee.
- **Add to Invitee Group:** Adds the custom field to an invitee group.

🔄 Repeat the configuration for all invitees, then click **Proceed** to move to the next stage.

---

## Step 5: Template Stage (Optional)

The **Template** stage appears only if you selected a template in Step 2. If none of your documents contain a template, this stage is skipped and you move directly to the **Finalise** stage.

Every template-type sub-document added in Step 2 appears here — including any you left disabled, since a disabled template can still be enabled by the workflow runner later and needs to be ready either way. If a primary document has more than one template, they are grouped under that document but configured separately.

The left panel shows a preview of the selected template, and the right panel lists all the template fields within it.

> **Note**
>
> The workflow creator cannot fill template fields for signing purposes — this is done by the workflow runner (and optionally the first invitee). Template fields also carry no editable Visibility, Editability, or Mandatory properties; they behave exactly as configured in the template itself.

### Preview with dummy data

Click **Fill Dummy Data** to temporarily fill every empty field with placeholder values, so the document renders realistically for coordinate placement in the Finalise stage. This data — and anything else typed into a template field at this stage — is never saved; it only affects how the document renders here and in Finalise. Re-opening the Create journey or editing the workflow later shows these fields empty again.

### Allow first invitee to fill

Use the **Allow first invitee to fill** toggle to control how template fields are handled at runtime:

- **Disabled:** The workflow runner must fill the template fields before sending the document. If there are mandatory fields, the workflow runner must fill them before proceeding in the sending journey. The workflow runner cannot enable this toggle while running the workflow.
- **Enabled:** The workflow runner can fill some, all, or none of the fields before sending:
    - If the workflow runner fills all fields, the first invitee will have no role in template field filling.
    - If the workflow runner leaves some or all fields empty — including mandatory ones — the document can still be sent. The first invitee will then be required to fill all mandatory fields before proceeding in the signing journey.

    The workflow runner cannot disable this toggle while running the workflow.

> **Info — Template versioning**
>
> Template fields shown here are fetched from the template service. If you picked a specific version in Step 2, its fields are used. If you picked **Latest**, the fields shown here reflect whatever is newest right now — if a newer version is published by the time the workflow runner runs the workflow, they will see that newer version's fields instead.

Click **Proceed** to move to the Finalise stage.

---

## Step 6: Publish the Workflow

In the Finalise stage, you preview the pack, place the default signature coordinates, and publish the workflow.

### Preview documents

1. Use the tabs at the top to switch between primary documents.
2. Review each document before setting coordinates.

You can also **Download Documents** and **Download Coordinates** to review the configuration offline.

> **Info — Templates in the merged preview**
>
> Templates are not shown separately here — each merges into its primary document's preview, in the position its sub-document occupies. Every template selected in Step 2 is included, **even if you left it disabled** — so you can place coordinates for it now, ready for if the workflow runner enables it later. Deleting a template in Step 2 removes it from this preview entirely.

### Place signature coordinates

> **Info — Note**
>
> You can place **signature** coordinates only in this step. Other field types (such as date, name, or text) are not placed here.

A signature coordinate is where the invitee's signature appears on the document. By default, coordinates appear at the bottom of each page. To customise:

1. In the **Coordinate Placement** panel on the right, find the invitee.
2. Click the invitee's **signature button** — the coordinate attaches to your cursor.
3. Click on the document where you want the signature to appear.

Repeat for each invitee who needs to sign the primary document.

Configure coordinates for all primary documents in your pack.

> **Info — Copy coordinates across pages**
>
> After placing a coordinate, you can copy it to multiple pages:
> 
>     - **All pages within this sub-document:** Copies the coordinate to every page of the current sub-document only.
>     - **All pages across all sub-documents:** Copies the coordinate to every page of all sub-documents in the primary document.

### Publish

Once coordinates are placed, click **Publish**. The published workflow appears in the **V4 Workflows** list and is now ready for the workflow runner to use. To see how a published workflow is run, see [Run a pack](https://knowledge.leegality.com/document-execution/workflows/v4/run-a-pack).

> **Info — Customise stages with Visualisation**
>
> **Visualisation**, available in the **left panel** throughout the workflow editor, lets you hide or rename the stages the workflow runner sees. For details, see [Visualisation](https://knowledge.leegality.com/document-execution/workflows/v4/setup-configuration/visualisation). You can also add a [Custom Page](https://knowledge.leegality.com/document-execution/workflows/v4/setup-configuration/custom-page) from here, so the runner can send the pack from a single screen.

---

URL: https://knowledge.leegality.com/document-execution/workflows/v4/custom-fields/add-fields-to-workflow

# Add fields to a workflow

Once created, every custom field appears in the **left panel** of the workflow editor, ready to be added. The one decision that matters is the **level** you add it at — it determines how many copies of the value exist, who fills them, and what a rule reading the field will see.

## The four levels

| Level | How to add | The value exists… | Right for |
| --- | --- | --- | --- |
| **Pack** | Click **Add to Pack**, or place it on a [Custom Page](https://knowledge.leegality.com/document-execution/workflows/v4/setup-configuration/custom-page) | Once, shared across the entire pack — available on every document | Values true for the whole send: **Loan Amount**, Customer Type, Branch Code |
| **Document** | Right-click the field → **Add to Document** | Once **per document**, configured separately on each | Values that differ by document: a per-document reference, a document-specific rate |
| **Invitee** | Select an invitee, add the field from the left panel | Once **per invitee** | Values that differ by person: **Employee ID** for each signer |
| **Group** | Add to a group invitee at the group level | Once for the **group as a whole** | Values shared by everyone in a group card |

**Pack and Document level fields are added in the Create stage:**

**Invitee and Group level fields are added in the Invite stage:**

## Choosing the level: think in copies

The practical test: **how many values of this thing exist in one run?**

- One value for the whole send → **Pack**. A loan has one Loan Amount, no matter how many documents describe it.
- One per document → **Document**. Adding at document level adds the field to *each* document **separately** — three documents means three independent values.
- One per person → **Invitee** (or **Group** for the group's shared value). Getting this wrong shows up later in confusing ways: a "Loan Amount" added at document level means the runner types the amount three times — and a rule reads only the copy on the document it points at.

> **Note — Level determines what a rule reads**
>
> When a rule watches a custom field, it reads the field *at a specific level* — the pack's value, one document's value, or one invitee's value. If the field will drive a [rule](https://knowledge.leegality.com/document-execution/workflows/v4/rule-engine/overview), decide the level with the rule in mind; the rule's logic must point at the same placement. Ready-made rule logic in the [how-to guides](https://knowledge.leegality.com/document-execution/workflows/v4/rule-engine/build-your-first-rule) states which level it expects.

## Where you can't add fields

> **Warning**
>
> Custom fields cannot be added in the **Template** or **Finalise** stages. Add them in the stages where their data belongs — pack and document fields alongside the documents, invitee fields on the invitee cards.

## Reorder fields

Every field has a **six-dot** handle. Click and drag it up or down to rearrange — this works throughout the workflow, for every field and element.

## Remove a field

Hover over the field and click the **delete** icon.

## Next steps

With the field in place, configure how it behaves per document — visible, editable, mandatory — via [Field Properties](https://knowledge.leegality.com/document-execution/workflows/v4/setup-configuration/field-properties), and control its input format with [Validations](https://knowledge.leegality.com/document-execution/workflows/v4/setup-configuration/field-configuration). If the field exists to drive logic, continue to [Build your first rule](https://knowledge.leegality.com/document-execution/workflows/v4/rule-engine/build-your-first-rule).

---

URL: https://knowledge.leegality.com/document-execution/workflows/v4/custom-fields/create-a-custom-field

# Create a custom field

Custom fields are created once, centrally, and then become available to add in any v4 workflow.

> **Info — Admin only**
>
> Only admin users can create custom fields. If you don't see the option, ask your Leegality admin.

## Steps

1. Go to **Custom Fields** from the dashboard.
2. Provide the field's core details:
   - **API Name** — mandatory and **unique** (non-repetitive). This is the field's permanent technical identifier; rules and integrations refer to it by this name.
   - **Display Name** — the label shown in the workflow.
   - **Field Description** — what the field is for.
   - **Field Type** — **Text**, **Dropdown**, or **Toggle**.
3. Complete the type-specific configuration below.
4. Click **Save**.

## Configuration by field type

#### Text

A **Text** field captures free-form input.

1. Choose **Text** as the Field Type.
2. To add placeholder text, check the **placeholder text** checkbox and enter the text in the field below.
3. Set a **Minimum character limit** and **Maximum character limit**, and add a **custom regex** if the value must follow a pattern.
4. The **Display Text** preview shows how the field will look.
5. Click **Save**.

> **Tip — Regex at creation vs regex in the workflow**
>
> A regex set here applies everywhere the field is used. You can also add validations per document later, from the field's right-click **Validations** tab — see [Field Configuration](https://knowledge.leegality.com/document-execution/workflows/v4/setup-configuration/field-configuration). Put universal formats (a PAN pattern, a fixed reference format) here; put workflow-specific checks there.

#### Dropdown

A **Dropdown** field lets the user pick from a predefined list.

1. Choose **Dropdown** as the Field Type.
2. To add placeholder text, check the **placeholder text** checkbox and enter the text in the field below.
3. Add the dropdown values as a list: enter a value, then click the **+** icon to add the next. Add as many options as you need — these form the selection list.
4. In **Selection Type**, choose **Single Select** or **Multiple Select** (Multiple Select lets the user choose more than one option at the same time).
5. The **Display Text** preview shows how the field will look.
6. Click **Save**.

> **Tip — Dropdowns make the best rule inputs**
>
> A rule condition like *Customer Type = NRI* is only reliable if the value can't be misspelled. When a field will drive a rule, prefer a Dropdown over free Text — the condition then matches an exact, guaranteed option.

#### Toggle

A **Toggle** field captures an on/off (yes/no) value.

1. Choose **Toggle** as the Field Type.
2. Set the **default value** to toggle on or toggle off.
3. Click **Save**.

> **Info — Good fit for rule inputs**
>
> Toggles suit binary facts a rule might check — **KYC Verified**, **Insurance Opted** — where the only honest answers are yes and no.

## Naming the field well

The **API Name** can't be reused and shouldn't be renamed casually — rules and integrations depend on it. The **Display Name** is free to be human. A convention that works:

|  | API Name | Display Name |
| --- | --- | --- |
| Style | compact, stable, no spaces | natural language |
| Example | `loanAmount` | Loan Amount |
| Example | `customerType` | Customer Type |

Name the API side for what the value *is*, not where it's currently used — `loanAmount`, not `personalLoanWorkflowAmount`. Fields outlive the workflow they were created for.

## Next steps

The field now appears in the **left panel** of every v4 workflow editor. Next: [add it to a workflow at the right level](https://knowledge.leegality.com/document-execution/workflows/v4/custom-fields/add-fields-to-workflow) — pack, document, invitee, or group — and, if it's going to drive logic, [build the rule that watches it](https://knowledge.leegality.com/document-execution/workflows/v4/rule-engine/build-your-first-rule).

---

URL: https://knowledge.leegality.com/document-execution/workflows/v4/custom-fields/overview

# Custom Fields

Custom fields let you capture additional information in a v4 workflow — an employee ID, a loan amount, a reference number — beyond the standard document and invitee details.

They do two jobs. The obvious one: **collect data** the standard fields don't cover. The powerful one: **drive logic** — custom fields are the values that [Rule Engine rules](https://knowledge.leegality.com/document-execution/workflows/v4/rule-engine/overview) watch. When a rule says *"IF Loan Amount > ₹10,00,000"*, Loan Amount is a custom field someone created.

## Anatomy of a custom field

Every custom field is defined once, centrally, with four things:

| Part | What it is |
| --- | --- |
| **API Name** | The field's unique technical identifier. Mandatory, must not repeat. Rules and integrations refer to the field by this name — choose it carefully, it's the stable handle. |
| **Display Name** | The label people see in the workflow. |
| **Field Description** | What the field is for — context for whoever fills it. |
| **Field Type** | **Text** (free input, with optional character limits and regex), **Dropdown** (pick from a list, single or multiple select), or **Toggle** (on/off). |

> **Info — Admin only**
>
> Only admin users can create custom fields. Anyone building workflows can then *use* the fields the admin has created.

## Where custom fields live in a workflow

Once created, every custom field appears in the **left panel** of the workflow editor, ready to be added. You choose the **level** at which it applies:

- **Pack level** — one value shared across the entire pack. Right for values like **Loan Amount**. Pack-level fields can also be placed on a [Custom Page](https://knowledge.leegality.com/document-execution/workflows/v4/setup-configuration/custom-page), so the runner fills them in on one screen at the start of the journey.
- **Document level** — added to each document separately, configured per document.
- **Invitee level** — a value per invitee, like **Employee ID** for each signer.
- **Group level** — attached to a group invitee as a whole. Picking the right level matters more than it looks: it decides who fills the value, where it shows, and what a rule reading it will see. [Add fields to a workflow](https://knowledge.leegality.com/document-execution/workflows/v4/custom-fields/add-fields-to-workflow) covers the four levels with examples.

## Fields are configurable per document

Any field in a document — custom or built-in — can be right-clicked to control three properties: **Visible**, **Editable**, and **Mandatory**, plus validations like character limits and regex. So the same field can be visible and editable on one document, locked on another. Details in [Field Properties](https://knowledge.leegality.com/document-execution/workflows/v4/setup-configuration/field-properties) and [Field Configuration](https://knowledge.leegality.com/document-execution/workflows/v4/setup-configuration/field-configuration).

These right-click settings are **static** — fixed when the workflow is designed. When you need them to change *dynamically* based on data ("mandatory only for big loans"), that's a [rule](https://knowledge.leegality.com/document-execution/workflows/v4/rule-engine/overview).

## Custom fields as rule inputs

This is the pairing that makes v4 workflows adaptive:

1. A custom field **captures** a value — Loan Amount, Customer Type, Source.
2. A rule **watches** that field as its Subject Field.
3. When the condition is met, the rule **changes** another field's visibility, editability, mandatory state, or value. Designing a workflow with rules in mind usually starts here: *what data do rules need to see?* — then create those custom fields first. The [Build your first rule](https://knowledge.leegality.com/document-execution/workflows/v4/rule-engine/build-your-first-rule) tutorial walks the full loop: create the field, add it, build the rule that watches it.

## Explore the section

---

URL: https://knowledge.leegality.com/document-execution/workflows/v4/excel-upload/custom-mapping

# Custom Mapping

Custom Mapping lets you upload your own spreadsheet instead of the Leegality Excel template. You match each Leegality column header to a column in your spreadsheet once, and every later upload to that workflow uses the same mapping.

Custom Mapping is set per workflow, from the workflow details page. To open it, see Open the workflow details page.

## Create a custom mapping

1. On the workflow details page, click the **Custom Mapping** icon.
2. Upload your spreadsheet. (Supported formats: **.xls** and **.xlsx**.)
3. Click **Proceed**.

    The mapping screen opens. The left column lists the **Leegality Excel Column Headers**, written in the same format as the v4 API parameters (for example, `pack.packName`). The right column has a dropdown for each, listing the headers found in your spreadsheet.

4. For each Leegality column header you want to use, select the matching header from your spreadsheet in the dropdown.
5. Save the mapping:
    - **Save as Draft** — save your progress and come back later. You do not have to finish the mapping in one go.
    - **Save & Activate** — save the mapping and start using it for uploads.

> **Info — Start your data from row 2**
>
> Once a custom mapping is active, your spreadsheet only needs a single header row. Start entering pack data from **row 2**.

### Find fields on the mapping screen

The mapping screen groups headers into **Pack Details**, **Document Details**, and **Invitee Details**, and shows how many fields are mapped so far (for example, *7 of 31 fields mapped*). To find a field quickly:

- Search for a header in **Search column headers**.
- Use the **Field Type** filter to show only **unmapped fields**, only **conflicting** fields, or a single group such as **Pack Details**, **Document Details**, **Invitee Details**, or **CC Details**.

## Manage an existing mapping

Click the **Custom Mapping** icon on the workflow details page again. You get three options:

- **Edit Existing Mapping** — change the mapping that is currently active.
- **Start Afresh** — delete the existing mapping and create a new one from scratch.
- **Delete Mapping** — permanently remove the custom mapping.

## Add new columns to a mapping

If your spreadsheet gains a new column, you can map it without redoing the mappings you already have.

1. Click the **Custom Mapping** icon, and select **Edit Existing Mapping**.
2. Click **Upload Excel** at the top of the mapping screen.
3. Upload a spreadsheet that contains your **new columns plus all the columns you already mapped**, and click **Proceed**.
4. Map the new columns, and save the mapping.

### If previously mapped columns are missing

If the new spreadsheet is missing a column that was already mapped, Leegality warns you before continuing and lists the missing headers.

- **Go Back** — upload a spreadsheet that still has those headers. Your existing mappings are kept.
- **Proceed Anyway** — continue with the new spreadsheet. The mappings that used the missing columns become **conflicting** mappings.

A banner on the mapping screen shows how many mappings are conflicting. To resolve them:

1. In the **Field Type** filter, select **Show only conflicting**. Each conflicting mapping is marked **Not in the new Excel**.
2. Click **Dismiss** on each conflicting mapping.
3. Map those fields to columns in the new spreadsheet, if needed.

> **Warning**
>
> You must dismiss every conflicting mapping before you can save.

## Drafts of an active mapping

If you edit an active mapping and click **Save as Draft**, the workflow keeps two versions:

- **The active mapping** — still used for uploads.
- **The draft mapping** — your unsaved changes.

To put the draft into use, open it and click **Save & Activate**. To discard it, click **Revert to Activated**. This returns the mapping to the active version.



---

URL: https://knowledge.leegality.com/document-execution/workflows/v4/excel-upload/fill-excel-template

# Fill the v4 Excel template

The Excel template is generated from the workflow, so its columns match exactly what the workflow runner is allowed to fill in. Each row you add creates **one document pack**.

> **Tip — Example**
>
> - **Row 3:** A pack for Borrower A, with their loan details and documents.
> - **Row 4:** A separate pack for Borrower B, with their own details and documents.

To download the template, see [Run via Excel Upload](https://knowledge.leegality.com/document-execution/workflows/v4/excel-upload/run-via-excel-upload#download-the-excel-template).

## Start entering data from row 3

**Rows 1 and 2** of the template are reserved for column headers. Do not edit, delete, or move them. Enter your first pack in **row 3**, and add one pack per row after that.

> **Info — Note**
>
> If you upload your own spreadsheet using [Custom Mapping](https://knowledge.leegality.com/document-execution/workflows/v4/excel-upload/custom-mapping), start your data from **row 2** of that spreadsheet instead.



## Column headers follow the API format

Column headers are written in the same format as the v4 API parameters, so each header shows exactly where its value goes in the pack:

| Column header | What it holds |
|---|---|
| `pack.packName` | Name of the pack |
| `pack.packIrn`, `pack.packUrn` | Reference numbers for the pack |
| `documents[0].documentName` | Name of the first document |
| `documents[0].subDocuments[0].templateId` | Template used by the first sub-document of the first document |
| `documents[0].subDocuments[0].templateVersion` | Version of that template |
| `invitees[0].inviteeDetails[0].inviteeName` | Name of the first invitee |
| `invitees[0].inviteeDetails[0].inviteeEmail` | Email address of the first invitee |
| `invitees[0].inviteeDetails[0].inviteePhone` | Phone number of the first invitee |

The number in square brackets is a position that starts from zero: `documents[0]` is the first document, `documents[1]` is the second, and so on. The same applies to sub-documents and invitees.

## Which columns are included

The template only contains fields that the workflow runner is allowed to change — fields with **Editability** on in [Field Properties](https://knowledge.leegality.com/document-execution/workflows/v4/setup-configuration/field-properties#editability). Fields the workflow creator has locked are applied automatically to every pack and do not appear in the template.

A few columns are always included, whatever their Field Properties:

- `templateId` and `templateVersion`
- Invitee **name**, **email**, and **phone**



### Default values

If the workflow creator has set a default value for an editable field, the template shows that value. It is **not** copied to every row for you — to use the default for a pack, paste it into that pack's row.

## Add files

To add a file to a pack — such as a PDF sub-document, a Face Match reference image, or an image for a template field — enter a **public URL** of the file in the matching `file` column. Leegality fetches the file from that URL when it creates the pack.



## Limits

- **Documents are fixed.** You cannot add or remove documents from a pack in the Excel file. Every pack gets the documents set up in the workflow.
- **Invitees are capped.** You cannot add more invitees than the workflow creator added while creating the workflow.



## Common mistakes to avoid

✅ **Do not edit the header rows.** Rows 1 and 2 must stay exactly as downloaded.  
✅ **Start from row 3.** Data entered in rows 1 or 2 is not read as a pack.  
✅ **Do not add, remove, or reorder columns.** The upload fails if the headers do not match the workflow.  
✅ **Fill in defaults row by row.** A default value shown once in the template does not apply to the other rows.  
✅ **Use public URLs for files.** Leegality must be able to open the URL without signing in.

> **Info — Upload still failing?**
>
> If the template was changed accidentally, download a fresh template from the workflow details page, re-enter your data, and upload it again. To see why individual rows failed, download the [output file](https://knowledge.leegality.com/document-execution/workflows/v4/excel-upload/run-via-excel-upload#download-the-input-and-output-files).

---

URL: https://knowledge.leegality.com/document-execution/workflows/v4/excel-upload/run-via-excel-upload

# Run a v4 workflow via Excel Upload

Excel Upload lets you send many document packs for eSignature at once. Instead of running the workflow one pack at a time, you fill in the workflow's Excel template — **one row per pack** — and upload it. Leegality creates a pack for every row and sends it out, using all the settings defined during [workflow creation](https://knowledge.leegality.com/document-execution/workflows/v4/create-a-workflow).

> **Info — Which workflows can be used**
>
> - Only **Published** workflows can be run via Excel Upload.
> - Any v4 workflow qualifies, including workflows with **PDF-type sub-documents**.

## Open the workflow details page

Everything related to Excel Upload — downloading the template, uploading files, tracking results, and custom mapping — happens on the workflow details page.

1. Navigate to **Workflows** from the left panel.
2. Open the **V4 Workflows** tab.
3. Find the workflow you want to run. (**Note:** You can search by workflow name or ID.)
4. Click the **Three Dots (⋮)** on the right side of the workflow, and select **View Details**.

The details page shows the workflow's ID, creation and update dates, its [Upload Email and Authorized Email IDs](#run-via-email), and an **Excel Uploads** table listing every file uploaded so far. The icons at the top right of the page include **Download Template**, **Upload Excel**, and **Custom Mapping**.

## Download the Excel template

1. On the workflow details page, click the **Download Template (xlsx)** icon.
2. Fill in the template, one row per pack. See [Fill the Excel template](https://knowledge.leegality.com/document-execution/workflows/v4/excel-upload/fill-excel-template) for how the template is structured and what each column expects.

> **Tip**
>
> If your team already keeps this data in its own spreadsheet format, set up [Custom Mapping](https://knowledge.leegality.com/document-execution/workflows/v4/excel-upload/custom-mapping) once and upload that spreadsheet directly instead of copying data into the Leegality template.

## Upload the Excel file

1. On the workflow details page, click the **Upload Excel** icon.
2. Select your filled Excel file. (**Note:** You can also download the template from this pop-up using **Download Excel**.)
3. Click **Upload**.

The file appears at the top of the **Excel Uploads** table, and its packs are created in the background.

## Track the upload

The **Excel Uploads** table shows the progress of every uploaded file. Click **Refresh** to see the latest status, or search for a file by its name or ID.

### Processing Status

**Processing Status** tells you whether the Excel file itself could be read:

- **Processing** — the file has been uploaded and is being checked.
- **Completed** — the file has no file-level issues (such as mismatched headers), and Leegality has started creating a pack for each row.

> **Warning — Completed does not mean every pack was sent**
>
> **Completed** only confirms that the file was valid. Individual packs can still fail. Check the **Details** column for the result of each row.

### Details

The **Details** column shows how many packs from the file have been **created**, have **failed**, or are still **processing**. You can see at a glance whether every row went through, without downloading any file.



## Download the input and output files

1. In the **Excel Uploads** table, click the **Three Dots (⋮)** on the right side of the upload.
2. Select one of the following:
   - **Download Input File** — the Excel file exactly as you uploaded it.
   - **Download Output File** — your file with the result of each row, including an **Error** column for any pack that could not be created.

> **Info — One error per row**
>
> If a pack could not be created, the **Error** column of the output file shows a **single error** for that row. After you fix it, re-upload the row — if it has another problem, that error appears in the next output file. (In v3, all errors for a row were shown together.)

## Generate the invitation report

1. In the **Excel Uploads** table, click **Generate Report** in the **Invitation Report** column.
2. Once the report is ready, a **Download** link replaces **Generate Report**. Click it to download the report.

You can generate the report even while some packs from the file are still processing.



## Run via email

You can also run the workflow by emailing the filled Excel file to the workflow's **Upload Email** address. Only emails sent from an **Authorized Email ID** are processed.

1. On the workflow details page, click **Add users** next to **Authorized Email ID(s)**.
2. Click the text field. A list of users in your account appears. (**Note:** You can type to search.)
3. Select one or more users.
4. Click **Save**.

Once at least one Authorized Email ID is added, the **Upload Email** address appears on the details page. Click the copy icon next to it, and send the filled Excel file as an attachment to that address from any of the authorized email IDs.

> **Info — Note**
>
> Authorized Email IDs for v4 workflows can only be users of your own account (tenant). You cannot add external email addresses.

## What's different from v3 Excel Upload

| | v3 | v4 |
|---|---|---|
| **Eligible workflows** | Template-type workflows only | Any published workflow, including PDF-type sub-documents |
| **Where to start** | **Upload** button on the workflows list | Workflow details page |
| **Result of each row** | Download the output file to check | Shown in the **Details** column |
| **Errors in the output file** | All errors for a row | One error per row |
| **Custom mapping** | Completed in one go | Can be saved as a draft, edited, and extended with new columns |
| **Authorized Email IDs** | Set while editing the workflow | Users of your own account only, set from the details page |

---

URL: https://knowledge.leegality.com/document-execution/workflows/v4/getting-started

# Getting started with v4

This guide walks you through using v4 workflows for the first time—from setting up a workflow to sending documents for eSignature.

## Prerequisites

Before you start:

- Identify a use case requiring v4 capabilities
- Have access to your Leegality account
- Gather PDF documents to send
- Collect invitee information (names, emails, phone numbers)

## Step 1: Set up your v4 workflow

How the workflow is created depends on its complexity:

- **Basic workflows** (multiple documents, custom fields, invitee configuration, stamping) can be created by your own admin users. See [Create a V4 Workflow](https://knowledge.leegality.com/document-execution/workflows/v4/create-a-workflow).
- **Rule-based or complex workflows** are built by Leegality's team for higher-plan clients. Contact your Leegality representative with your requirements, sample documents, and use case details, then review and test the workflow once it's ready.

## Step 2: Access and run your workflow

Once your workflow is ready:

1. Log in to your Leegality account
2. Navigate to **Workflows**
3. Go to the **V4 Workflows** tab
4. Find your workflow and click **Run**

The workflow opens with three configuration steps.

## Step 3: Configure your pack (Create step)

In the Create step, you assemble the document pack — add primary documents, upload sub-documents, configure stamping where needed, and set pack-level details such as the pack name, folder, auto-deletion, and SFTP transfer. Click **Proceed** when done.

For the detailed how-to, see [Step 1: Prepare Your Document](https://knowledge.leegality.com/document-execution/workflows/v4/run-a-pack#step-1-prepare-your-document).

## Step 4: Configure invitees (Invite step)

In the Invite step, you add invitees (signers, reviewers, group invitees, and CC), set their signing order, configure invitee-level settings such as eSign type and security, and assign documents to each invitee. Click **Proceed** when done.

For the detailed how-to, see [Step 3: Invite Configuration](https://knowledge.leegality.com/document-execution/workflows/v4/run-a-pack#step-3-invite-configuration).

## Step 5: Set coordinates and send (Finalise step)

In the Finalise step, you place signature coordinates for each invitee, optionally copy them across pages, and send the pack. Invitees receive their notifications once processing completes.

For the detailed how-to, see [Step 4: Preview and Send documents](https://knowledge.leegality.com/document-execution/workflows/v4/run-a-pack#step-4-preview-and-send-documents).

## Understanding the result

### What you configured

You created a pack with:
- Multiple primary documents (each with one or more sub-documents)
- Selective document assignment per invitee
- Configured stamping where needed
- Set signature coordinates

### What invitees experience

Invitees receive:
- One notification for all assigned documents
- Single signing link
- Unified journey to sign all documents
- Clear progress tracking

Each invitee sees only the primary documents you assigned to them.

## Example: Home loan processing

**Your workflow:** Home Loan v4

### Step 1: Create

Add 2 primary documents:
1. **Loan Agreement** - Upload 2 sub-docs (loan terms + repayment schedule)
2. **Property Documents** - Upload 1 sub-doc (title deed)

Configure stamping:
- Loan Agreement: Stamp for merged document
- Property Documents: No stamps

Set pack name: "Home Loan - Rajesh Kumar - Jan 2025"

### Step 2: Invite

Add invitees:
- **Rajesh Kumar (Borrower)** - Signer
- **Priya Kumar (Co-borrower)** - Signer
- **Bank Officer** - Reviewer

Set signing order:
1. Rajesh Kumar (primary borrower signs first)
2. Priya Kumar (co-borrower signs second)
3. Bank Officer (reviews after both borrowers)

Configure settings:
- Rajesh: Aadhaar eSign, 2-factor authentication, GPS capture
- Priya: Aadhaar eSign, 2-factor authentication
- Bank Officer: Quick Sign

Assign documents:
- Rajesh Kumar: Both primary documents
- Priya Kumar: Loan Agreement only
- Bank Officer: Both documents

### Step 3: Finalise

Place coordinates:
- Loan Agreement: Rajesh's signature page 8, Priya's signature page 9, Bank Officer page 10
- Property Documents: Rajesh's signature page 3

Copy coordinates to all pages of each sub-document as needed.

Send pack.

### Result

- Rajesh receives notification for 2 documents, signs all in one session
- Priya receives notification for 1 document (Loan Agreement)
- Bank Officer receives notification for 2 documents to review
- All signing happens in one coordinated flow

## Troubleshooting first run

**Can't find v4 workflow:**
- Ensure you're in the **V4 Workflows** tab
- Contact support if workflow is missing

**Sub-document won't upload:**
- Check PDF format and file size
- Remove password protection
- Verify PDF is not corrupted

**Invitee assignment unclear:**
- Review the **Assign Documents** button on each invitee card
- Verify at least one document is assigned to each invitee
- Check privacy requirements are met

**Signature coordinates won't place:**
- Click the signature button first in Coordinate Placement panel
- Ensure document has fully loaded
- Try refreshing if coordinates don't stick to cursor

**Pack stuck in processing:**
- Check **Processing Queue** for status
- Large packs take longer to process
- Contact support if processing exceeds 10 minutes

---

URL: https://knowledge.leegality.com/document-execution/workflows/v4/multi-document-signing

# v4 Signing Journey

When you send a v4 document pack, invitees sign multiple primary documents in a single unified session. This guide walks through what invitees experience — from receiving the notification to completing their signature.

> **Info — Note**
>
> The invitee may not need to perform all the steps mentioned in this guide. The required actions depend on how the sender has configured the document pack.

## Step 1: Access and Preview the Documents

Invitees receive the invitation via **email, SMS, and/or WhatsApp**, or a direct link shared by the sender.

**Example email:**

#### Signer

![Example v4 eSign invitation email sent to a signer, listing the documents assigned to them](https://knowledge.leegality.com/img/invitation-to-signer-v4.png)

#### Reviewer

![Example v4 review invitation email sent to a reviewer, listing the documents assigned to them](https://knowledge.leegality.com/img/invitation-to-reviewer-v4.png)

### What the email shows

The email notification includes:

- **Sender information:** Who (person or entity) sent the document and requested signing
- **Expiry details:** Exact date and time when the invitation expires
- **Document count:** How many documents need to be signed (one or more)
- **Document names:** Names of all documents assigned to this invitee
- **Sequence information:** If multiple documents, they're shown in sequential order
- **[Custom message](https://knowledge.leegality.com/document-execution/leegality-features/document-level/custom-message):** Any additional message from the sender, if added

### Authenticate before preview (If Enabled)

If the sender has enabled **1-Factor** or **2-Factor Authentication before document preview**, the OTP verification is the **first screen** you see after clicking the signing link — before language selection and before any document is shown. These checks protect the documents' content itself: only the intended recipient can view the documents, even if the invitation is forwarded by mistake.

- [**One-Factor Authentication**](https://knowledge.leegality.com/document-execution/leegality-features/invitee-level/security/one-factor-authentication#signing-journey)**:** OTP sent to your email **or** phone number.
- [**Two-Factor Authentication**](https://knowledge.leegality.com/document-execution/leegality-features/invitee-level/security/two-factor-authentication)**:** OTPs to **both** email and phone number. Accessing the signing link via one channel counts as the first factor — you then verify the OTP on the other.

If the sender has not enabled these, you go straight to the steps below.

> **Info — OTP Expiry**
>
> All OTPs during the signing journey expire after **10 minutes**. If an OTP expires, you will need to start the signing process again.

### Choose a language

1. Click the **Sign Document(s)** button in the email, or the **signing link** if you received an SMS or WhatsApp message.
2. If the sender has enabled [**Local Language**](https://knowledge.leegality.com/document-execution/leegality-features/invitee-level/local-language?version=v4#signing-journey), you are taken to the language selection page — select the language in which you would like to proceed. Otherwise, you go directly to the document preview.

### Preview the documents

After selecting a language (or directly, if Local Language isn't enabled), you land on the preview page. In a multi-document pack, the documents appear in preview **one at a time, in the order the workflow creator set them up**. Each assigned document follows the same steps below — 1 and 2 — before you move to the next one.

#### 1. View the document

The document's merged PDF is shown — all its sub-documents and templates combined, already reflecting any template data the workflow runner filled in earlier.

While previewing, you can also:

- **View the invitee list** — all invitees the documents have been sent to.
- **[View reference attachments (📎)](https://knowledge.leegality.com/document-execution/leegality-features/document-level/reference-attachments?version=v4#accessing-reference-attachments-during-the-signing-journey)** — click the attachment icon to view and download any reference documents uploaded by the sender.
- **Download the documents** — click the download icon to download a document in its current state.
- **[Change the language](https://knowledge.leegality.com/document-execution/leegality-features/invitee-level/local-language?version=v4#signing-journey)** at any time from the list of languages.

Click **Proceed** to continue.

#### 2. Fill template fields (If Applicable)

This step appears only if the document has at least one template with **Allow first invitee to fill** enabled, and you are the first invitee — otherwise you skip straight to the next document. If a document has more than one such template, they are shown **one at a time**.

1. Click **Fill Document** for the template.
2. Fill out the fields, using the **Preview** option to verify your entries. All of the template's field validations — mandatory fields, character limits, and so on — are enforced before you can proceed.

> **Info — Group fields**
>
> If a template has group fields, filling one of them automatically updates the other fields in that group.

3. Click **Save as Draft** at any point to save your entries to the backend — if you resume later, your saved data is pre-filled.
4. Once all required fields are filled, click **Proceed** — to the next template if there's another, otherwise to a final view of this document's merged PDF showing all the data you just filled in, where **Save as Draft** is available again.

Click **Proceed** to move to the next document in the pack, or, once **all your assigned documents are reviewed**, to continue with the rest of the signing journey.

> **Info — When your data is saved**
>
> Besides **Save as Draft**, your template entries are also saved automatically:
> 
>     - Each time you click **Proceed** to move to the next document — provided you've already completed any required authentication at that point.
>     - Right before you sign — on the **Sign Document** click, or when redirected to the ESP page for Aadhaar eSign.

---

## Step 2: Sign the Documents

### Complete invitee actions (If Configured)

After previewing the documents, you may need to complete a few sender-configured actions before you reach the signing page:

- **[Upload Supporting Documents](https://knowledge.leegality.com/document-execution/leegality-features/invitee-level/other-features/supporting-documents#signing-journey)** — click **Upload**, add the file(s) the sender has requested, and click **Proceed**. Supported formats: .pdf, .png, .jpg (maximum file size: 2 MB).

- **[GPS Location](https://knowledge.leegality.com/document-execution/leegality-features/invitee-level/security/capture-gps-location#signing-journey-of-capture-gps-location)** — your current location is captured on the next screen (optionally with an accuracy threshold, or restricted to a geofenced area); click **Proceed** after the capture. GPS is captured **only once** — the single capture applies to all the documents you sign in the pack. A smartphone is recommended for better location accuracy.

- **Face Capture**

    - [**Capture your photo**](https://knowledge.leegality.com/document-execution/leegality-features/invitee-level/security/capture-photo#signing-journey)**:** Take a real-time photo using your device.
    - [**Face Match**](https://knowledge.leegality.com/document-execution/leegality-features/invitee-level/security/face-match#signing-journey)**:** Your photo will be compared with the identity information provided by the sender. If not matched, you cannot proceed to sign.
    - **User (Invitee) Liveliness Detection:** Confirms that the person signing is physically present. Failure to detect liveliness prevents signing.
        - [**Manual Liveliness**](https://knowledge.leegality.com/document-execution/leegality-features/invitee-level/security/manual-liveliness)**:** OTP-based verification
        - [**Smart User Liveliness**](https://knowledge.leegality.com/document-execution/leegality-features/invitee-level/security/smart-user-liveliness)**:** AI-based verification

- [**Company Stamp/Seal**](https://knowledge.leegality.com/document-execution/leegality-features/invitee-level/esignature-appearance/company-seal#example-of-company-seal-with-signature)

    - Authorised Signatory Seal
    - Director Seal
    - Upload Company Seal

- [**Name Editing**](https://knowledge.leegality.com/document-execution/leegality-features/invitee-level/esignature-appearance/invitee-name-editing)**:** If allowed by the sender, you can edit the name that will appear on the signature.

- [**Reject to Sign**](https://knowledge.leegality.com/document-execution/leegality-features/invitee-level/other-features/reject-to-sign?version=v4#invitee-rejection-journey)**:** If permitted, you can choose to reject the document at any time during the signing journey.

- [**Payment Collection**](https://knowledge.leegality.com/document-execution/leegality-features/invitee-level/payment-collect#signing-journey)**:** In some cases, the sender may require you to make a payment before completing the signing process. You will be prompted to make the payment securely within the signing journey, and once the payment is completed, you can proceed to sign the documents.

> **Info — Note**
>
> Not all actions are required for every signing journey. The document sender configures which actions are mandatory based on the document requirements.

### Sign or review the documents

On the signing page, proceed based on your role:

#### Signer

1. **Select an eSign Type:** Sign using the eSign type(s) the sender has enabled for you. If more than one is enabled, select your preferred type.
   - Available options can be:
        - [**Aadhaar**](https://knowledge.leegality.com/document-execution/esign-type/aadhaar/?type=otp#signing-a-document-using-aadhaar-esign)
        - [**DSC Token**](https://knowledge.leegality.com/document-execution/esign-type/dsc-token#signing-journey)
        - [**Virtual Sign**](https://knowledge.leegality.com/document-execution/esign-type/virtual-sign/virtual-signature#signing-journey)
        - [**Visual Sign**](https://knowledge.leegality.com/document-execution/esign-type/visual-sign#signing-journey)
        - [**Quick Sign**](https://knowledge.leegality.com/document-execution/esign-type/quick-sign#signing-journey)
2. Agree to the default and any additional consent terms.
3. Click **Sign Document**.

> **Info — One signature for the whole pack**
>
> You sign **only once** — the single signature applies to all the documents assigned to you in the pack.

On successful signing, you will receive a confirmation via email or SMS, and you are redirected to the **Public Details Page**, where you can monitor the progress and view invitee actions.

Once all invitees have signed, you receive the completion email with each signed document and its audit trail attached — see [Document completion](#document-completion).

#### Reviewer

1. After reviewing all your assigned documents, click **Proceed**.
2. If the sender has enabled **Require OTP for Approval/Rejection**, complete the OTP verification before submitting your decision.
3. Choose to either **Approve** or **Reject**. Your decision applies to **all the documents assigned to you** — a reviewer approves all their assigned documents together, or rejects them all together. You cannot approve some and reject others in the same review.
4. Click **Submit**, check the consent box, and confirm your action.

> **Info**
>
> Refer to [**Reviewer Journey**](https://knowledge.leegality.com/document-execution/leegality-features/invitee-level/types-of-invitee/reviewer#reviewer-journey) for more details.

## Document completion

Once all invitees in the signing order have signed, the document pack is **completed**. Completion triggers emails at two points — a confirmation when you sign, and a completion email to all invitees once everyone has signed. What each invitee receives (including CC invitees) depends on the sender's configuration.

For what each email contains, with examples, see [Completion Emails](https://knowledge.leegality.com/document-execution/workflows/v4/completion-emails).

## Step 3: Track Document Status on the Public Details Page

After signing, you are redirected to the **Public Details Page** — a central hub where you can preview and download the signed documents and their audit trails, save them to your Leegality account, and track each invitee's signing status.

The page is openly accessible for the first **48 hours** after you sign; after that, the link becomes secure and requires an OTP login. For the full breakdown of available actions and access rules, see [Public Details Page](https://knowledge.leegality.com/document-execution/workflows/v4/pack-details#public-details-page-for-invitees).

---

URL: https://knowledge.leegality.com/document-execution/workflows/v4/new-document

# New Document

This guide explains how to create and send a new document for eSignature in v4. Unlike [running a workflow](https://knowledge.leegality.com/document-execution/workflows/v4/run-a-pack), everything here is configured from scratch for a single send.

To start:

1. Navigate to **Workflows** from the left panel.
2. Open the **V4 Workflows** tab to reach the Workflows page.
3. Click the **+ New Document** button in the top-right corner.

The document editor opens at the **Create** stage. The journey runs across the **Create**, **Invite**, and **Finalise** stages, with an additional **Template** stage if any document uses a template.

## Step 1: Prepare Your Documents

The Create stage is where you assemble the **document pack** — the set of documents sent together in a single signing journey. A pack can contain multiple **primary documents** (each signed individually, shown as a separate tab), and each primary document can contain multiple **sub-documents**. For a detailed explanation, see [Packs and documents](https://knowledge.leegality.com/document-execution/workflows/v4/understanding-v4/packs-and-documents).

### Add documents to the pack

1. A primary document is already present when you land on the Create stage. Click **+ Add Document** to add more. You can add up to **15 primary documents** in a single pack.
2. Upload the sub-documents for each primary document. A primary document can contain up to **10 sub-documents** — you can add **PDFs**, **templates**, or both.

> **Info — NOTE**
>
> To delete a primary document, click the **Delete** icon in the Configure Documents section.

#### Option 1: Upload a PDF

1. Use the **upload PDF** box to add PDF sub-documents from your computer.
2. Drag and drop files into the designated area, or browse and select files manually.
3. Click and drag sub-documents to rearrange their order — this is the order in which they appear in the merged document.
4. Click the delete icon (🗑️) to remove unwanted files.

> **Warning — File size limit**
>
> The combined size of all sub-documents and the template in a primary document must be **15 MB or smaller**.

#### Option 2: Use a Template

> **Tip — Prerequisite**
>
> Templates must be created in advance. Learn how to create a [template](https://knowledge.leegality.com/document-execution/template/).

1. Click **Select** from the *Select Template* option.
2. A panel opens on the right listing all configured templates.
3. Select one or more templates to add them to the document by ticking the checkbox next to each.

You will fill the template's fields later in the journey — see [Fill Template Fields](#fill-template-fields-conditional).

### Set document details

For each primary document in the pack, configure:

1. **Document Name** — the name of the document. It appears in the email subject and body.

> **Tip — Example**
>
> **Email Subject:** "Invitation to eSign: Service Level Agreement"
2. **Internal Reference Number** *(optional)* — a reference for tracking. Only letters (A-z), numbers (0-9), and special characters (.,-:(),_[]&/ ) are allowed.
3. **[Document Folder](https://knowledge.leegality.com/document-execution/manage-documents/folders?type=v4-workflow#assigning-a-folder-in-v4)** *(optional)* — select the folder where the document will be saved.
4. **[Reference Attachment](https://knowledge.leegality.com/document-execution/leegality-features/document-level/reference-attachments?journey=new-document-journey&version=v4)** *(optional)* — enable the toggle to upload a reference file that invitees can refer to while signing.

> **Info — Note**
>
> The **Document Name** and **Pack Name** fields are autopopulated once you upload documents, even if you didn't name them. You can rename them as you wish.

### Attach stamping (optional)

Enable the **Attach Stamping** toggle on a primary document to add stamp paper. Two placement options appear:

- **Stamps for merged document:** A single stamp paper is attached at the beginning of all combined sub-documents (Stamp → Sub-document A + Sub-document B).
- **Separate stamps for sub-documents:** A dedicated stamp paper is attached to each sub-document (Stamp 1 → Sub-document A, Stamp 2 → Sub-document B). This option appears only when a primary document has more than one sub-document.

Then configure the stamp using one of the following options:

1. **Stamp Series:** Select a **Stamp Series** and enter the **Quantity**. Click **Add new series** to add another series.
2. **Stamp Group:** Select a **Stamp Group** and enter the **Amount**.
3. **Revenue Stamp:** Add a **Revenue stamp** and enter the **Quantity**.
4. **Stamp Upload:** Provide the **State**, **Denomination**, **First party name**, **Second party name**, and **Stamp serial number**, and upload the stamp paper.

> **Warning**
>
> You cannot use **Stamp Upload** together with a **Stamp Series** or **Stamp Group**. When you choose to upload your own stamp, you cannot also add a series or group.

To understand how stamps are distributed across a pack, see [Distributed stamping](https://knowledge.leegality.com/document-execution/workflows/v4/understanding-v4/distributed-stamping).

### Configure pack details

The right panel shows the settings that apply to the entire pack:

- **Pack Name** *(required)* — the name for the entire pack. Auto-populated once you add documents.
- **Pack Internal Reference Number** *(optional)* — a reference number for tracking the pack.
- **Pack Folder** *(optional)* — the folder where the pack is saved.
- **Document Deletion** — automatically delete the document after a set time interval. This uses the settings configured in [**Settings ➔ Department ➔ Document Security**](https://knowledge.leegality.com/document-execution/settings/Department/document-security-settings#auto-delete-after-document-completion).
- **SFTP** — automatically transfer signed documents via SFTP after completion.

Click **Proceed** to move to the Invite stage.

---

## Step 2: Add Invitees

In the Invite stage, you add your signers and reviewers, configure their settings, and assign documents to them.

### Add invitees

A blank invitee is already present when you land on the Invite stage. If you want to sign the document yourself, add yourself as an invitee with your own details.

1. Click **+ Add invitee** to add more.
2. Use the dropdown at the top left of the invitee card to select a role:
    - Signer
    - [Reviewer](https://knowledge.leegality.com/document-execution/leegality-features/invitee-level/types-of-invitee/reviewer?type=v4-workflow&journey=new-document-journey) — a non-signing invitee who reviews the document and then approves or rejects it
    - [Group Signer](https://knowledge.leegality.com/document-execution/leegality-features/invitee-level/types-of-invitee/group-invitee?type=v4-workflow)
    - Group Reviewer
3. Enter the invitee's **Name** and **Contact Details** (Email and/or Phone).

Each invitee's default role is **Signer**, with the default eSign type configured in [Settings ➔ Department ➔ eSignature](https://knowledge.leegality.com/document-execution/settings/Department/esignature-settings#set-the-default-esign-type).

**Add CC invitees:**

1. Click **+ Add CC** at the bottom.
2. Provide the CC invitee's details. A [CC invitee](https://knowledge.leegality.com/document-execution/leegality-features/invitee-level/types-of-invitee/cc?type=v4-workflow&journey=new-document-journey) does not sign, but receives notifications about the document's progress.

### Configure signing order

Click the **Signing Order** button at the top to control the signing sequence.

- **Set Signing Order:** Click and drag the invitee cards to rearrange the sequence.
- **Lock Signing Journey:** Enforces the signing sequence. Invitees receive their signing links sequentially — the document moves to the next invitee only after the current signer has signed.

> **Tip — Example**
>
> If there are two signers, the document is sent to the second signer only after the first signer has signed.

#### Advance Signing Order

Advance Signing Order lets you group invitees into levels so that invitees within the same level can sign in parallel, while levels are processed sequentially.

Once **Set Signing Order** is enabled, you can enable the **Advance Signing Order** toggle.

When you enable the toggle, the invitee cards collapse into a level-wise view. Each invitee starts in its own level.

- **Move invitees between levels:** drag an invitee card from one level to another. Invitees in the same level become active simultaneously and can sign in parallel.
- **Reorder levels:** drag a level above or below another to change the sequence.
- **Add a level:** click **+ Add Level** to insert a new empty level.
- **Delete a level:** click 🗑️ to remove a level when it is empty.
- **Edit an invitee:** click a collapsed invitee card to expand it and access its settings. Each invitee can have its own invitee-level configurations (eSign type, certificate verification, security features, etc.) regardless of which level it belongs to.

> **Tip — Example**
>
> Suppose you add two invitees (Borrower 1 and Borrower 2) in Level 1, and one invitee (Lender) in Level 2. When the document is sent, both Borrower 1 and Borrower 2 become active at the same time and can sign in parallel. Once both have signed, the Lender in Level 2 becomes active and can sign.

### Configure multiple eSign combinations

By default, an invitee signs all their assigned documents with the same eSign type and settings. With multi-combination, you can create separate sign combinations for the same invitee. Each combination has its own group of documents, eSign type, and settings. This lets an invitee sign different documents with different eSign types in a single journey.

1. Click **+ Add New eSign Combination** on the invitee card to add a combination.
2. Each combination appears as a row inside the invitee card. Click **+ Assign Documents** on a combination to open a panel on the right with a checkbox list of all available documents. Select one or more documents for that combination.
3. To remove a combination, click its delete button. You cannot delete the last remaining combination.

#### Combination-level vs invitee-level settings

With multiple combinations, the right panel splits into two tabs:

- **Combination tab** settings apply only to the selected combination. Use the combination switcher (Combination 1 / Combination 2 / …) to move between them.

    For a **signer**:
    - eSign Types
    - eSign Prioritisation
    - Signature Appearance
    - Webhooks
    - Consent & Validity Controls

    For a **reviewer**:
    - Webhooks
    - Consent & Validity Controls

- **Invitee Level tab** settings apply once across all combinations for the invitee. All remaining settings (Security Options, Certificate Verification, Notifications, Manage Invitee Interactions, Contact Book) are configured here.

In the signing journey, combinations are executed in order. Combination 1 is signed first, then Combination 2, and so on.

> **Tip — Example**
>
> An invitee has two combinations: Combination 1 contains a Key Fact Statement with Quick Sign, and Combination 2 contains a Loan Agreement with Aadhaar eSign. The invitee first previews and signs the Key Fact Statement using Quick Sign, then previews and signs the Loan Agreement using Aadhaar eSign.

### Configure invitee settings

Select an invitee card to view their settings in the right panel. With a single combination, all settings appear under one **Settings** tab. With multiple combinations, the settings split into a **Combination** tab and an **Invitee Level** tab as described in [Configure multiple eSign combinations](#configure-multiple-esign-combinations).

The following sections list all available settings:

- [**eSign Types**](https://knowledge.leegality.com/category/esign-types)**:** Choose the eSignature type(s) available to this invitee. Available options depend on your account configuration.
- [**eSign Prioritisation**](https://knowledge.leegality.com/document-execution/esign-type/aadhaar/prioritise-aadhaar-for-invitee?type=v4-workflow)**:** Set the preferred eSign type for the invitee. This works for **Aadhaar eSign** only.
- **Signature Appearance:** Control how the signature appears on the signed document.
    - [**Invitee Name on Signature**](https://knowledge.leegality.com/document-execution/leegality-features/invitee-level/esignature-appearance/invitee-name-in-signature?type=v4-workflow)**:** Choose whether to display the invitee's name in the signature.
    - [**Company Seal**](https://knowledge.leegality.com/document-execution/leegality-features/invitee-level/esignature-appearance/company-seal?type=v4-workflow)**:** Ask the invitee to upload a company seal image.
    - [**Invitee Name Editing**](https://knowledge.leegality.com/document-execution/leegality-features/invitee-level/esignature-appearance/invitee-name-editing?type=v4-workflow)**:** Allow or restrict name editing during signing.
- [**Webhooks**](https://knowledge.leegality.com/document-execution/leegality-features/invitee-level/custom-url-and-webhook/webhook-and-url?type=v4-workflow)**:** Configure a custom webhook and URL for real-time status updates.
- [**Consent and Validity Controls**](https://knowledge.leegality.com/document-execution/leegality-features/invitee-level/other-features/additional-consent?type=v4-workflow&journey=new-document-journey)**:** Add custom consent terms alongside the default consent.
- **Manage Invitee Interactions:** Control how the invitee interacts with the document during the signing journey.
    - [**Base URL**](https://knowledge.leegality.com/document-execution/leegality-features/invitee-level/custom-url-and-webhook/webhook-and-url?type=v4-workflow)**:** Set a custom base URL for the invitee's signing journey.
    - [**Redirect URL**](https://knowledge.leegality.com/document-execution/leegality-features/invitee-level/custom-url-and-webhook/webhook-and-url?type=v4-workflow)**:** Redirect the invitee to a specific page after events in the signing journey.
    - [**Add Supporting Documents**](https://knowledge.leegality.com/document-execution/leegality-features/invitee-level/other-features/supporting-documents?journey=new-document-journey&version=v4)**:** Request additional documents the invitee must upload while signing.
    - [**Allow rejection of doc(s)**](https://knowledge.leegality.com/document-execution/leegality-features/invitee-level/other-features/reject-to-sign?type=v4-workflow)**:** Allow the invitee to reject signing the document(s).
    - [**Custom message**](https://knowledge.leegality.com/document-execution/leegality-features/document-level/custom-message?type=v4-workflow)**:** Add a custom message that the invitee sees with the signing invitation.
    - [**Local Language Settings**](https://knowledge.leegality.com/document-execution/leegality-features/invitee-level/local-language?journey=new-document-journey&version=v4)**:** Let the invitee complete the signing journey in a local language. Two options are available:
        - **Allow Signers to Select Language:** Enable this option to set a language select screen as the first step for the signer.
        - **Set a Default Language:** Enable this option to set a default language for the signer.
- **Security Options:** Apply authentication and verification controls for the invitee. The following toggles are available:
    - [**1 Factor Authentication before document preview**](https://knowledge.leegality.com/document-execution/leegality-features/invitee-level/security/one-factor-authentication?type=v4-workflow)**:** OTP verification via email or phone number before the invitee can preview the document.
    - [**2 Factor Authentication before document preview**](https://knowledge.leegality.com/document-execution/leegality-features/invitee-level/security/two-factor-authentication?type=v4-workflow)**:** OTP verification via both email and phone number before the invitee can preview the document.
    - [**Capture GPS locations**](https://knowledge.leegality.com/document-execution/leegality-features/invitee-level/security/capture-gps-location?type=v4-workflow)**:** Record the invitee's location at the time of signing, with optional accuracy- and location-based restrictions.
    - [**Capture Photo**](https://knowledge.leegality.com/document-execution/leegality-features/invitee-level/security/capture-photo?type=v4-workflow)**:** Capture the signer's photo before they sign.
    - [**Send Document download link with OTP notifs**](https://knowledge.leegality.com/document-execution/leegality-features/invitee-level/security/send-raw-document-link)**:** Send a link to download the raw PDF document in all OTP verification emails/messages.
    - [**Mask contact details**](https://knowledge.leegality.com/document-execution/leegality-features/invitee-level/other-features/mask-contact-details?type=v4-workflow)**:** If enabled, contact details of other invitees will be masked from this invitee.
- [**Notifications**](https://knowledge.leegality.com/document-execution/leegality-features/invitee-level/notifications/)**:** Select how invitations, reminders, and updates are sent to the invitee — **Email**, **SMS**, or **WhatsApp**.

> **Info — Note**
>
> For CC invitees, only email notifications are available.
- [**Certificate Verification**](https://knowledge.leegality.com/document-execution/esign-type/aadhaar/signature-certificate-verifier)**:** Verify the intended signer's details against the digital signature certificate after signing.
- [**Contact Book**](https://knowledge.leegality.com/document-execution/contact-book)**:** Reuse saved contacts when adding invitees.

### Assign documents to invitees

Each invitee must be assigned at least one primary document:

1. Click **Assign Documents** on the invitee card.
2. Select which primary document(s) this invitee should sign. If you select multiple documents, the invitee views them in the order you select them — the first document selected appears first.
3. Invitees see and sign only their assigned documents.

> **Info — Note**
>
> - Every document in the pack must have at least one assigned invitee.
>     - Every invitee must have at least one document assigned to them.

For a detailed explanation, see [Document assignment](https://knowledge.leegality.com/document-execution/workflows/v4/understanding-v4/document-assignment).

🔄 Repeat the configuration for all invitees, then click **Proceed**.

---

## Fill Template Fields (Conditional)

> **Info — Conditional Step**
>
> This stage appears only when a document in the pack uses a template with fillable fields.

The Fill Template screen is divided into two sections:

- **Left Panel – Live Preview:** Displays a real-time preview of the document as you fill in the fields.
- **Right Panel – Form Fields:** Lists all available fields in the template. Enter or select values for each field as required.

As you complete each field on the right, the corresponding field in the preview updates instantly, so you can verify your entries before continuing.

Use the **Allow first invitee to fill** toggle to control who completes the template fields:

- **Disabled:** You must fill the mandatory template fields before proceeding.
- **Enabled:** You can fill some, all, or none of the fields before sending — the document can be sent even with mandatory fields left empty. The first invitee is then required to fill all mandatory fields before proceeding in the signing journey.

If more than one document in the pack uses a template, each template appears as a separate **tab** on this screen. Navigate to each tab and fill its fields — or enable **Allow first invitee to fill** — for each template as needed.

> **Tip — Best Practice**
>
> Fill template fields at this stage rather than leaving them for the signing journey. Filled fields can expand and shift the document content downward — since signature coordinates are placed at fixed positions, filling fields beforehand ensures signatures align with the final document layout.

Click **Proceed** to move to the Finalise stage.

---

## Step 3: Place Signature Coordinates and Send

In the Finalise stage, you preview the pack and place the signature coordinates that mark where each invitee signs.

### Preview documents

1. Use the tabs at the top to switch between primary documents.
2. Review each document before setting coordinates.

You can also **Download Documents** and **Download Coordinates** to review the configuration offline.

### Place signature coordinates

A signature coordinate is where the invitee's signature appears on the document. By default, coordinates appear at the bottom of each page. To customise:

1. In the **Coordinate Placement** panel on the right, find the invitee.
2. Click the invitee's **signature button** — the coordinate attaches to your cursor.
3. Click on the document where you want the signature to appear.

After placing a coordinate, you can drag it to reposition it, resize it by dragging its edges, or delete it.

Repeat for each invitee, on every primary document they are assigned.

> **Info — Copy coordinates across pages**
>
> After placing a coordinate, you can copy it to multiple pages:
> 
>     - **All pages within this sub-document:** Copies the coordinate to every page of the current sub-document only.
>     - **All pages across all sub-documents:** Copies the coordinate to every page of all sub-documents in the primary document.

> **Warning**
>
> If signature coordinates are not placed for some invitees, default coordinates will be placed automatically. A warning lists the affected invitees.

### Send the pack

1. Review the preview to ensure all elements (including signature coordinates) appear as expected.
2. Click **Send**, and invitations are sent to all invitees for signing or reviewing.

If the pack is processed within 10 seconds, you are redirected to the [Details page](https://knowledge.leegality.com/document-execution/workflows/v4/pack-details). If it takes longer, you'll see the message *"Document pack is being processed. This may take a few seconds,"* and the pack is queued for processing. Documents are sent to invitees automatically once processed, and you can track progress from the [Details page](https://knowledge.leegality.com/document-execution/workflows/v4/pack-details).

---

URL: https://knowledge.leegality.com/document-execution/workflows/v4/pack-details

# Document details page

After sending a v4 document, the details page helps you track progress, manage invitees, and access documents. To open it, click the document name in your **Sent documents** list.

## The two tab levels

The page has one **Document Pack** tab for the big picture, and one **Primary Document** tab for each document in the pack. Both show the same kinds of information — the difference is scope:

| What you see | Document Pack tab | Primary Document tab |
|---|---|---|
| **Information header** | Pack name, Pack ID, and pack status — **In Progress** (one or more documents not completed) or **Completed** (all documents completed) | Document name, Document ID, and status — **In Progress**, **Completed**, or **Expired** |
| **Invitee List** | All invitees across all documents, with **document tags** showing what's assigned to each | Only the invitees assigned to this document |
| **Documents** | All primary documents as cards, with name, ID, status, and **Preview Document** | A combined PDF of this document's **sub-documents**, with **Preview** and **Download** |
| **Activity Logs** (right side) | Complete timeline of the entire pack | Timeline for this document only |

## Track invitees

The Invitee List shows a card per invitee with their name, contact details (email and/or phone), and status — **Invited, Opened, Signed, Approved, Rejected, Expired,** or **Failed**.

On the Document Pack tab, each card also carries **document tags**, so you can see at a glance which documents each invitee is assigned — an invitee with multiple documents shows all of them as tags.

When [Advance Signing Order](https://knowledge.leegality.com/document-execution/workflows/v4/new-document#advance-signing-order) is enabled, invitee cards are grouped under their assigned levels — Level 1, Level 2, and so on.

## Manage the pack

Click the **three dots (⋮)** next to the pack name on the Document Pack tab:

- **Complete the pack** — manually completes the entire pack in its current state. All primary documents are marked complete, invitees who signed receive the signed documents and audit trail, and invitees who haven't signed can no longer sign. Use it when remaining invitees are unresponsive or the outstanding signatures are no longer needed — for example, in a pack of three documents where one is still waiting on a signature, completing the pack finalises all three as they stand.
- **Delete pack** — permanently deletes the entire pack and all documents within it. Use it when the pack was sent in error or is no longer needed.

> **Warning**
>
> Deleting a pack cannot be undone. All primary documents and pack data are permanently deleted.

## Manage a single document

Open the **three dots (⋮)** on a document card (Document Pack tab) or next to the document name (its Primary Document tab):

- **Complete** — marks only this primary document as complete; the other documents in the pack are unaffected.
- **Delete** — permanently removes this document from the pack. This cannot be undone.
- **Reference Attachment** — view and upload reference attachments for the invitees signing this document.

You can also **Preview** any document, and **Download** it from its Primary Document tab.

## Download the pack audit trail

Once the pack is completed (all documents signed by their assigned signers), open the **Document Pack tab** and click **Download Audit Trail** on the right side. The pack audit trail contains the information of all documents in the pack.

## Public Details Page (for invitees)

While the details page above is for the **sender**, every signer gets their own **Public Details Page** — they are redirected to it right after signing, and its link is included in their notifications. It serves as a central hub where signers can view document information, track signing progress, and manage their signed copy.

On this page, a signer can:

- **View and manage the documents** — preview the signed documents, **download** them and their **audit trails**, **save** them to a Leegality account for permanent storage, or **delete the copy**. Deleting permanently removes that signer's copy, and the Public Details Page link they received via email, SMS, or WhatsApp stops working.
- **Track signer progress** — see all invitees with their contact details, each invitee's status (e.g., "Signed," "Pending"), and the exact time the invitation was sent and each signature was completed.
- **Review document details** — find the Document ID, Document Name, and the overall status (e.g., "Completed," "Signed").

### Access rules

- **First 48 hours:** after a signer completes their signature, their link provides open access — no Leegality login needed. The window is **invitation-specific**: it starts for each signer individually at the moment they sign, not when the pack was sent or when the first person signed. For example, if Signer 1 signs Monday 2:00 PM, their link is open until Wednesday 2:00 PM; if Signer 2 signs Tuesday 10:00 AM, theirs is open until Thursday 10:00 AM.
- **After 48 hours:** the link automatically becomes a **secure link**. Clicking it leads to a login page where the default option is **Login with OTP** — the signer enters the email address or phone number associated with their invitation, receives the OTP, and regains full access after logging in.

---

URL: https://knowledge.leegality.com/document-execution/workflows/v4/request-workflow

# Request a v4 workflow

Most v4 workflows with basic functionality can be created by your own admin users—see [Create a V4 Workflow](https://knowledge.leegality.com/document-execution/workflows/v4/create-a-workflow). Workflows that need advanced logic, such as the [Rule Engine](https://knowledge.leegality.com/document-execution/workflows/v4/rule-engine/overview), are built by Leegality's team for higher-plan clients. This guide explains how to get a Leegality-built workflow.

## Before you request

Identify your use case and requirements clearly. Consider the following:

**Document requirements:**
- How many documents do you need in the workflow?
- Do different invitees need different document combinations?
- Where should stamps be placed (if required)?

**Invitee requirements:**
- How many invitee roles do you need (signers, reviewers, CC)?
- What signing order should be followed?
- What eSign type should each invitee use?
- What security settings are required (authentication, GPS, photo capture)?

**Field and configuration requirements:**
- What information needs to be collected at runtime?
- Which fields should be mandatory, optional, or locked?
- What settings should workflow runners be able to modify?
- Do you need configurable stamp options per run?

**Compliance and business rules:**
- What fields must remain locked to ensure compliance?
- What validations or constraints are needed?
- Are there any approval workflows or business logic requirements?

## How to request a v4 workflow

To request a v4 workflow:

1. **Prepare your requirements** using the considerations listed above
2. **Contact your Leegality representative:**

   
   - Account Manager: [Contact details to be added]
   - Support Team: [Contact details to be added]
   - Email: [Email address to be added]

3. **Provide detailed information** about your use case, including:
   - Business scenario and goals
   - Document types and structure
   - Invitee roles and responsibilities
   - Field requirements and governance rules
   - Any specific compliance or security needs

4. **Review the workflow** once created by Leegality's team
5. **Test the workflow** with sample data before production use
6. **Provide feedback** for any adjustments needed

> **Tip — Best practice**
>
> Provide real examples and sample documents when requesting a workflow. This helps the workflow creator understand your exact requirements and build a more accurate configuration.

## What happens after you request?

After you submit your request:

1. **Requirements review:** Leegality's team reviews your requirements and may ask clarifying questions
2. **Workflow creation:** The workflow creator builds and configures your v4 workflow
3. **Notification:** You receive notification when the workflow is ready
4. **Testing phase:** You test the workflow and provide feedback
5. **Refinement:** The workflow creator makes adjustments based on your feedback
6. **Production ready:** The workflow is ready for regular use

## Timeline expectations


The time to create a v4 workflow depends on complexity. Typical timelines:

- **Simple workflows:** [Timeline to be added]
- **Moderate complexity:** [Timeline to be added]
- **Complex workflows:** [Timeline to be added]

Your Leegality representative will provide specific timeline estimates based on your requirements.

## Requesting changes to existing workflows

If you need modifications to an existing v4 workflow, contact your Leegality representative with:

- The workflow name or identifier
- What needs to be changed
- Why the change is needed
- Any impact on existing documents or processes

> **Info — Note**
>
> For workflows your admin users created, an admin can edit them directly in your account. For Leegality-built (rule-based) workflows, contact your Leegality representative to request changes.

---

URL: https://knowledge.leegality.com/document-execution/workflows/v4/rule-engine/build-your-first-rule

# Build your first rule

In this tutorial you'll configure one complete, working rule from start to finish:

> **IF** Loan Amount is greater than ₹10,00,000, **THEN** the Reviewer's Name becomes **Mandatory**.

It's the classic Mandatory rule: big-ticket loans get a human check, small ones flow straight through.

A rule's logic is written in Leegality's **rule language**. You won't write any of it today — the logic for this rule is provided below, ready to paste — so you can focus on the configuration flow: title, logic, trigger method, test. What every line of the language means is a topic for Advanced: LEEQL, once the concepts have settled.

## Before you start

You'll need:

- **A v4 workflow open in the editor**, with a **reviewer as the first invitee**. The provided rule logic checks the first invitee card, so the order matters here. If you're practising, duplicate an existing workflow rather than editing a live one.
- **A Loan Amount custom field added at the pack level.** The rule watches this field, so it must exist first. If it doesn't, [create the custom field](https://knowledge.leegality.com/document-execution/workflows/v4/custom-fields/create-a-custom-field) with the API name `loanAmount`, then [add it at the pack level](https://knowledge.leegality.com/document-execution/workflows/v4/custom-fields/add-fields-to-workflow) — pack level suits a value shared across the whole pack. Come back when it appears in the editor.
- **The spec.** Even for a tutorial, start the way you always should — with the six lines written down:

```
TARGET field:   Reviewer (1st invitee) · Name field
ACTION:         Set Mandatory = true
SUBJECT field:  Loan Amount
CONDITION:      Loan Amount > ₹10,00,000
OUTCOME:        Reviewer's Name is Mandatory above ₹10L; Optional at or below ₹10L
Workflow:       (your practice workflow)
```

## Step 1 — Open the Rule Engine panel

In the workflow editor, open the **Rule Engine** from the **left panel** — it sits alongside Custom Fields and Visualisation, and is available at every stage of the workflow. Choose the option to create a new rule.

## Step 2 — Name the rule

Give the rule a **Rule Title** that states what it does, not just what it touches. A title you'll thank yourself for later:

```
Reviewer mandatory above ₹10L loan
```

> **Tip — Naming habit**
>
> Workflows accumulate rules. ` ` as a title pattern keeps the rule list scannable — compare the title above with something like "Loan rule 2".

## Step 3 — Add the rule logic

**Create Rule** is where the rule's logic lives, written in the rule language. Paste this in:

```
#version 2.0
var loanAmountRaw = pack.lecf_loanAmount; if(loanAmountRaw != null && (isEmpty(loanAmountRaw) == false)) { var loanAmountNumber = toNumber(loanAmountRaw); if(loanAmountNumber > 1000000) { var card = invitees.inviteeCards[0]; if(card != null) { var reviewerName = card.inviteeCard.inviteeDetails[0].inviteeName; if(reviewerName == null || isEmpty(reviewerName)) { throw "Reviewer Name is mandatory for loans above Rs. 10,00,000"; } } } }
```

One adjustment before pasting: `lecf_loanAmount` refers to your Loan Amount custom field by its **API name** with the `lecf_` prefix. If you named the field something other than `loanAmount` when creating it, change that part to match.

You don't need to read the language yet — but notice that every line of your spec is in there:

| Spec line | Where it lives in the logic |
| --- | --- |
| SUBJECT field | `pack.lecf_loanAmount` — the pack-level Loan Amount |
| CONDITION | `loanAmountNumber > 1000000` — greater than ₹10,00,000 |
| TARGET + ACTION | the check on the first invitee's Name, enforced with an error |
| OUTCOME, both sides | the error fires only above the threshold; at or below it, nothing blocks |

That mapping is the whole relationship between the [six-line spec](https://knowledge.leegality.com/document-execution/workflows/v4/rule-engine/turn-a-requirement-into-a-rule) and the language: the spec is the intake form, the language is the rule.

> **Note — Why an error message instead of a mandatory flag?**
>
> This is how "make X mandatory" rules typically ship: the rule **validates when the user clicks Proceed** and blocks the stage with a message naming exactly what's missing. The effect is the same — you can't continue without the reviewer — and the runner is told precisely why.

## Step 4 — Choose the Trigger Method

The **Trigger Method** decides *when* the workflow evaluates your rule. The dropdown offers seven options:

| Trigger Method | When the rule runs |
| --- | --- |
| On Click | When the user clicks the field. |
| On Change | When the field's value changes. |
| On Blur | When the user moves focus away from the field (clicks or tabs out of it). |
| On Proceed Invitee | When the user clicks Proceed to leave the Invite stage. |
| On Proceed Create | When the user clicks Proceed to leave the Create stage. |
| On Proceed Finalise | When the user clicks Proceed in the Finalise stage. |
| On Proceed Template | When the user clicks Proceed to leave the Template stage. |

For this rule, choose **On Proceed Invitee**: it runs at the moment the user clicks **Proceed** to leave the Invite stage — exactly when all invitee details should be complete.

Why not On Change? A validation like this one belongs at Proceed: it checks the finished state, once, at the moment it matters. On Change fires while data is still being typed — right for rules that should react live (a value recalculating, a field appearing), wrong for a completeness check.

## Step 5 — Set where the rule applies

**Field Execution On** sets where the rule's outcome is applied.

Save the rule.

## Step 6 — Test it

A rule isn't done until you've watched it fire — in both directions:

1. Run the workflow. Enter a Loan Amount of **15,00,000**, leave the reviewer's Name empty, and click **Proceed** on the Invite stage. The workflow should block you with the message: *Reviewer Name is mandatory for loans above Rs. 10,00,000*.
2. Fill in the reviewer's Name and click Proceed again — it should go through.
3. Now change the Loan Amount to **5,00,000**, clear the reviewer's Name, and Proceed — it should go through without any error. Testing both sides matters: step 3 catches the classic mistake where a rule enforces its condition but was written to fire in all cases.

> **Note — Rule didn't fire?**
>
> The three most common causes: the **Trigger Method** doesn't match how you're testing (a Proceed-triggered rule only runs when you click Proceed); the **field name** in the logic doesn't match your custom field's API name (`lecf_` + exact API name); or the **reviewer isn't the first invitee**, so the rule is checking a different card.

## What you built — and what transfers

Every rule follows today's motions: open the panel → title → rule logic → trigger method → test both directions. Only the logic changes — and you don't have to write it from scratch:

- **Adapt a pattern.** The how-to guides for each category — [mandatory](https://knowledge.leegality.com/document-execution/workflows/v4/rule-engine/how-to/make-a-field-mandatory), editable, [value](https://knowledge.leegality.com/document-execution/workflows/v4/rule-engine/how-to/calculate-a-field-value) — provide rule logic to copy and adjust, the way you adjusted `lecf_loanAmount` today.
- **Learn the language.** Advanced: LEEQL explains what you pasted, line by line, and how to write your own.
- **Or don't.** Write the [six-line spec](https://knowledge.leegality.com/document-execution/workflows/v4/rule-engine/turn-a-requirement-into-a-rule) and send it to [support@leegality.com](mailto:support@leegality.com) — Leegality writes the rule for you.

---

URL: https://knowledge.leegality.com/document-execution/workflows/v4/rule-engine/how-to/auto-assign-documents

# Auto-assign documents with a rule

**Goal:** when the runner adds a document, it should be assigned to the right invitees automatically — no manual wiring, no forgotten assignments. Working example: *every newly added document is auto-assigned to all invitees.*

This is an [assignment rule](https://knowledge.leegality.com/document-execution/workflows/v4/rule-engine/rule-categories#assignment-rules): it fires when something is **added** to the workflow and applies structural defaults to it. The same shape covers the mirror case — applying a default settings bundle to every newly added invitee.

## The spec

```
TARGET field:   Each invitee's assigned documents
ACTION:         Append the newly added document to every invitee's assignments,
                in the invitee's own role (signer signs, reviewer reviews)
SUBJECT field:  The documents list (a new document was just added)
CONDITION:      Fires on the Add Document action
OUTCOME:        The moment a document is added, every invitee has it assigned;
                documents added earlier are unaffected
Workflow:       (yours)
```

## The rule logic

```
#version 2.0
var docCount = len(documents); var lastAddedDoc = documents[docCount - 1]; if(lastAddedDoc != null) { for(invitee in invitees.inviteeCards) { var combination = invitee.inviteeCard.combinations[0]; var assignedDocs = combination.assignedDocuments; assignedDocs[len(assignedDocs)] = { "documentReference": "/documents/" + lastAddedDoc.id, "role": invitee.inviteeCard.inviteeType, "id": uuid() }; } }
```

The idiom that makes this work: the rule grabs the **last element** of the documents list (`documents[docCount - 1]`) — which, at the moment the Add Document click fires, is precisely the document that was just added. It then loops every invitee and appends an assignment that references the document and mirrors the invitee's own role, so signers get it to sign and reviewers to review.

## Adapt these parts

| Part | In the logic | Change it to |
| --- | --- | --- |
| Who gets the document | `for(invitee in invitees.inviteeCards)` — everyone | Assigning to only *some* invitees (by role or label) adds a condition inside the loop — spec it and ask [Support](mailto:support@leegality.com), or see Advanced: LEEQL |
| The role | `invitee.inviteeCard.inviteeType` — mirrors each invitee | Usually keep as is |
| What triggers it | the newly added (last) document | To assign a *newly added invitee* all existing documents instead, the same last-element idiom applies to the invitee list — that mirror rule is in Advanced: LEEQL |

## Configure it

1. Rule Engine panel → new rule → **Rule Title**: `New documents auto-assign to all invitees`.
2. Paste the logic into **Create Rule**.
3. **Trigger Method**: **On Click**, attached to the **+ Add Document** control — the rule must fire at the moment of adding, because "the last document in the list" is only guaranteed to be the new one right then. This trigger attaches to a specific control, unlike the Proceed triggers.
4. Save. Full configuration flow: [Build your first rule](https://knowledge.leegality.com/document-execution/workflows/v4/rule-engine/build-your-first-rule).

## Test it

1. Run the workflow with two invitees. Add a document → open each invitee's assignments: the new document appears on both, in each invitee's own role.
2. Add a second document → it too appears on both invitees; the first document's assignments are untouched.
3. Add an invitee *after* the documents (if your flow allows it) → note the new invitee does **not** get the earlier documents — that's the mirror rule, fired from Add Invitee, not this one.

## Related

The category explained: [Assignment rules](https://knowledge.leegality.com/document-execution/workflows/v4/rule-engine/rule-categories#assignment-rules). Assignment rules commonly ship alongside invitee-default rules (org seal, notifications, eSign types applied to every newly added invitee) — those bundles are built in the rule language; spec what you want and send it to [support@leegality.com](mailto:support@leegality.com).

---

URL: https://knowledge.leegality.com/document-execution/workflows/v4/rule-engine/how-to/calculate-a-field-value

# Calculate a field's value with a rule

**Goal:** a field's value should compute itself from other fields, so nobody does the math by hand. Working example: *Stamp Group Amount of Document 1 = Loan Amount × Stamp Duty %.*

This is a [Value rule](https://knowledge.leegality.com/document-execution/workflows/v4/rule-engine/rule-categories#c--value-rules) of the computed kind — multiple Subject Fields, arithmetic on the right-hand side, and a condition of "all inputs filled" rather than a threshold.

## The spec

```
TARGET field:   Stamp Group Amount of Document 1
ACTION:         Set Value = Loan Amount × Stamp Duty Percentage
SUBJECT field:  Loan Amount, Stamp Duty Percentage (pack-level custom fields)
CONDITION:      Both fields filled
OUTCOME:        Stamp Group Amount fills itself when both inputs exist;
                until then it is left untouched
Workflow:       (yours)
```

## The rule logic

This assumes both inputs are **pack-level** custom fields with API names `loanAmount` and `stampDutyPercentage` (the rate entered as a percentage, e.g. `0.5` for 0.5%), and the target is the **first document's** stamp group amount:

```
#version 2.0
var loanAmountRaw = pack.lecf_loanAmount; var rateRaw = pack.lecf_stampDutyPercentage; if(loanAmountRaw != null && (isEmpty(loanAmountRaw) == false) && rateRaw != null && (isEmpty(rateRaw) == false)) { var loanAmount = toNumber(loanAmountRaw); var rate = toNumber(rateRaw); var doc = documents[0]; if(doc != null) { doc.stamps.stampGroup.stampGroupAmount = loanAmount * rate / 100; } }
```

Two things worth noticing. The values a runner types arrive as **text**, so the logic converts them with `toNumber(...)` before doing arithmetic — every calculation rule needs this. And the whole computation sits inside the "both inputs filled" guard, so the rule stays silent until the data exists.

## Adapt these parts

| Part | In the logic | Change it to |
| --- | --- | --- |
| Input fields | `pack.lecf_loanAmount`, `pack.lecf_stampDutyPercentage` | `lecf_` + your fields' exact API names |
| The formula | `loanAmount * rate / 100` | Your arithmetic — drop `/ 100` if the rate is stored as a fraction (0.005) rather than a percentage (0.5) |
| Target document | `documents[0]` | `documents[0]` is document 1, `documents[1]` is document 2, and so on |
| Target field | `.stamps.stampGroup.stampGroupAmount` | Keep as is for stamp duty; other targets have other paths — see below |

Writing the result somewhere else — a custom field, a template field printed on the document, a setting on an invitee — uses the same shape with a different target path. For those, send the spec to [support@leegality.com](mailto:support@leegality.com) or see Advanced: LEEQL; a state-wise duty **lookup** instead of a flat rate is also covered there.

## Configure it

1. Rule Engine panel → new rule → **Rule Title**: `Stamp duty = loan amount × rate`.
2. Paste the adapted logic into **Create Rule**.
3. **Trigger Method**: **On Change**, attached to the input fields — so the amount recalculates the moment an input changes. (Set the rule to fire on each input field; a calculation that fires on only one input goes stale when the other is edited.)
4. Save. Full configuration flow: [Build your first rule](https://knowledge.leegality.com/document-execution/workflows/v4/rule-engine/build-your-first-rule).

## Test it — and re-test on edit

1. Enter Loan Amount 10,00,000 and rate 0.5 → Stamp Group Amount becomes 5,000.
2. Edit the Loan Amount to 20,00,000 → the amount should update to 10,000. Calculations must survive *edits*, not just first entry — this is where a wrong trigger shows itself.
3. Clear one input → the previously computed value remains (the rule doesn't erase; it only writes when both inputs exist).

---

URL: https://knowledge.leegality.com/document-execution/workflows/v4/rule-engine/how-to/make-a-field-mandatory

# Make a field mandatory with a rule

**Goal:** a field must be filled — but only when another field's value says so. Working example: *FATCA Declaration is mandatory when Customer Type = NRI; residents can leave it blank.*

This is a [Mandatory rule](https://knowledge.leegality.com/document-execution/workflows/v4/rule-engine/rule-categories#a--mandatory-rules), and it ships the way mandatory rules typically do: as a **validation at Proceed** — the rule checks the field when the user clicks Proceed and blocks the stage with an error naming exactly what's missing.

## The spec

```
TARGET field:   FATCA Declaration (pack-level custom field)
ACTION:         Set Mandatory = true
SUBJECT field:  Customer Type (pack-level custom field, Dropdown: NRI / Resident)
CONDITION:      Customer Type = NRI
OUTCOME:        NRI runs cannot Proceed with FATCA empty (error shown);
                Resident runs proceed freely with FATCA blank
Workflow:       (yours)
```

## The rule logic

This assumes both custom fields are added at **pack level**, with API names `customerType` and `fatcaDeclaration`:

```
#version 2.0
var customerType = pack.lecf_customerType; if(customerType != null && (isEmpty(customerType) == false)) { if(customerType == "NRI") { var fatca = pack.lecf_fatcaDeclaration; if(fatca == null || isEmpty(fatca)) { throw "FATCA Declaration is mandatory for NRI customers"; } } }
```

Reading it against the spec: the rule reads the Subject Field, checks the Condition (`== "NRI"`), and enforces the Target by throwing the error only when the field is empty **and** the condition holds. Below/outside the condition, the rule does nothing — that's the OUTCOME's other side.

## Adapt these parts

| Part | In the logic | Change it to |
| --- | --- | --- |
| Subject Field | `pack.lecf_customerType` | `lecf_` + your field's exact API name |
| Condition value | `"NRI"` | The exact dropdown option, spelled as configured |
| Target Field | `pack.lecf_fatcaDeclaration` | `lecf_` + the field being made mandatory |
| Error message | `"FATCA Declaration is mandatory for NRI customers"` | Your message, word for word — it's part of the spec |

For a **numeric** condition instead of a dropdown match (mandatory above a threshold), the comparison needs a number conversion — that variant is the [Build your first rule](https://knowledge.leegality.com/document-execution/workflows/v4/rule-engine/build-your-first-rule) tutorial, end to end. If your fields live at **document or invitee level** rather than pack level, the paths differ — send the spec to [support@leegality.com](mailto:support@leegality.com) or see Advanced: LEEQL for the data model.

## Configure it

1. Rule Engine panel → new rule → **Rule Title**: `FATCA mandatory for NRI customers`.
2. Paste the adapted logic into **Create Rule**.
3. **Trigger Method**: **On Proceed Create** — pack-level fields are completed in the Create stage, so the check belongs on that stage's Proceed. (If your target field is filled on the Invite stage, use **On Proceed Invitee** instead — pick the Proceed of the stage where the field gets filled.)
4. Save. Full configuration flow, step by step: [Build your first rule](https://knowledge.leegality.com/document-execution/workflows/v4/rule-engine/build-your-first-rule).

## Test it — both directions

1. Customer Type = NRI, FATCA empty, Proceed → blocked with your error.
2. Fill FATCA, Proceed → goes through.
3. Customer Type = Resident, FATCA empty, Proceed → goes through, no error.

## Related

Mandatory also works in reverse — relaxing a requirement when a condition holds — see [Rule categories](https://knowledge.leegality.com/document-execution/workflows/v4/rule-engine/rule-categories#a--mandatory-rules).

---

URL: https://knowledge.leegality.com/document-execution/workflows/v4/rule-engine/how-to/validate-before-proceed

# Validate fields before Proceed

**Goal:** the workflow must not move past a stage while the data is wrong — and the person running it should be told exactly what to fix. Working example: *every document's IRN must be filled and follow the format `LOAN-123456`; if not, Proceed is blocked and the error names the offending document.*

This is a [validation rule](https://knowledge.leegality.com/document-execution/workflows/v4/rule-engine/rule-categories#validation-rules): it runs on a stage's **Proceed**, checks a condition, and raises an error that blocks the stage. Validation is also how "make X mandatory" asks usually ship — this page covers the general pattern, including format checks and checks across *every* item.

## The spec

```
TARGET field:   IRN, on every document (including documents added at run time)
ACTION:         Validate at Proceed (block with error)
SUBJECT field:  IRN of each document
CONDITION:      IRN missing, or IRN not matching ^LOAN-[0-9]{6}$
OUTCOME:        Proceed on the Create stage is blocked with
                "IRN is mandatory for document N" or
                "IRN in document N must follow the format: LOAN-123456";
                with all IRNs valid, Proceed goes through
Workflow:       (yours)
```

Note the spec includes the **error messages word for word** — for validation rules, the message is part of the requirement.

## The rule logic

```
#version 2.0
var curDoc = 1; for(doc in documents) { var irn = doc.irn; if(irn != null) { irn = trim(irn); } if(irn == null || isEmpty(irn)) { throw "IRN is mandatory for document " + curDoc; } else { if(regex(irn, "^LOAN-[0-9]{6}$") == false) { throw "IRN in document " + curDoc + " must follow the format: LOAN-123456"; } } curDoc = curDoc + 1; }
```

Three habits of a good validation rule, all visible here:

- **It loops over everything.** `for(doc in documents)` checks every document — including ones the runner adds on the fly — instead of hardcoding "document 1".
- **It counts like a human.** `curDoc` starts at 1, so the error says "document 2", never "index 1".
- **It layers the checks.** Missing first, then format — the runner gets the most fundamental problem first. One behaviour to know: the rule stops at the **first** offending document per attempt. Fix it, Proceed again, and the next problem (if any) surfaces. That's standard for validations; a single error listing *all* offenders at once is possible in the rule language — ask Support or see Advanced: LEEQL.

## Adapt these parts

| Part | In the logic | Change it to |
| --- | --- | --- |
| What's checked | `doc.irn` | The field to validate (for a pack-level custom field, drop the loop and read `pack.lecf_yourField`) |
| The format | `"^LOAN-[0-9]{6}$"` | Your regex — anchored with `^` and `$` so the whole value must match |
| Error messages | both `throw` strings | Your exact messages, with the 1-based document number kept in |

## Configure it

1. Rule Engine panel → new rule → **Rule Title**: `IRN mandatory + format on all documents`.
2. Paste the adapted logic into **Create Rule**.
3. **Trigger Method**: **On Proceed Create** — documents and their IRNs live in the Create stage, so that's the Proceed to guard. Validating invitee data instead? Same pattern, **On Proceed Invitee**.
4. Save. Full configuration flow: [Build your first rule](https://knowledge.leegality.com/document-execution/workflows/v4/rule-engine/build-your-first-rule).

## Test it — all three states

1. Leave document 2's IRN empty, Proceed → blocked: *IRN is mandatory for document 2*.
2. Fill it with `LOAN-12` (too short), Proceed → blocked: *IRN in document 2 must follow the format: LOAN-123456*.
3. Fill it with `LOAN-123456`, Proceed → goes through.
4. Add a new document at run time with no IRN, Proceed → blocked again — the loop catches runtime additions too.

## Related

The conditional variant — mandatory only when another field says so — is [Make a field mandatory with a rule](https://knowledge.leegality.com/document-execution/workflows/v4/rule-engine/how-to/make-a-field-mandatory). Simple format checks on a single field can also be done without a rule at all, via the field's [Validations](https://knowledge.leegality.com/document-execution/workflows/v4/setup-configuration/field-configuration) tab; use a rule when the check is conditional, spans many items, or needs a custom message.

---

URL: https://knowledge.leegality.com/document-execution/workflows/v4/rule-engine/overview

# Rule Engine

You have been using rules all along without seeing them. Every v4 workflow runs on a set of built-in integrity rules — over a hundred of them — that keep configurations consistent behind the scenes. When selecting one eSign type automatically switches the incompatible ones off, that's a rule firing. The IRN format check that blocks a Proceed when a reference number is malformed — also a rule.

The Rule Engine opens this same machinery to you, so you can add logic specific to *your* process.

## The IF → THEN model

Every rule follows the same shape: **IF** a field's value meets a condition, **THEN** apply an action to another field.

```mermaid
graph LR
    A["Subject Field: Loan Amount"] --> B{"Condition: greater than ₹10,00,000?"}
    B -->|Yes| C["Action: set Mandatory = true"]
    C --> D["Target Field: Reviewer's Name"]
    B -->|No| E[No change]
```

The **IF** side checks the **Subject Field** against the **Condition**. The **THEN** side applies the **Action** to the **Target Field**. If the condition is not met, the field is left unchanged.

Read as a sentence: *IF Loan Amount is greater than ₹10,00,000, THEN the Reviewer's Name becomes Mandatory.*

Once you see this structure, every requirement becomes a fill-in-the-blanks exercise. These are the pieces you fill in:

| Component | What it defines |
| --- | --- |
| **Subject Field** | The field whose value the rule watches |
| **Condition** | The check applied to the subject field — *greater than ₹10,00,000*, *is filled*, *equals NRI* |
| **Target Field** | The field the rule acts on |
| **Action** | The change applied to the target field — set Mandatory, set Editable, or set a Value |
| **Outcome** | The resulting behaviour when the condition is met |
| **Trigger Method** | *When* the rule is evaluated — a field being clicked, changed, or blurred, or the user clicking Proceed on a specific stage. See the [full list of trigger methods](https://knowledge.leegality.com/document-execution/workflows/v4/rule-engine/build-your-first-rule#step-4--choose-the-trigger-method) |

A rule can have more than one Subject Field and more than one Target Field.

## How a rule is expressed

In the editor, a rule's logic is written in Leegality's **rule language** inside the rule's **Create Rule** step — the same IF → THEN, expressed precisely enough for the engine to run. You don't need to learn the language to work with rules. The six components above are what you *capture*, as a [six-line spec](https://knowledge.leegality.com/document-execution/workflows/v4/rule-engine/turn-a-requirement-into-a-rule); the language encodes them. From a good spec there are three ways to a working rule: configure one with ready-made logic ([Build your first rule](https://knowledge.leegality.com/document-execution/workflows/v4/rule-engine/build-your-first-rule) provides it), learn to write the language (Advanced: LEEQL), or send the spec to Support and get the rule built for you.

## The three properties a rule can change

Every rule changes exactly one of three field properties. This gives you three rule categories:

| Category | Property | Example |
| --- | --- | --- |
| **Mandatory** | Turn a field's required flag on or off | Make Reviewer mandatory IF Loan Amount > ₹10,00,000 |
| **Editable** | Lock or unlock a field | Lock Branch Code IF Source = LOS API |
| **Value** | Compute or assign a value | Stamp Duty Amount = Loan Amount × Stamp Duty % |

The **Value** category is the most powerful: the assigned value can be a constant, arithmetic across fields, a lookup, or a value copied from another part of the workflow. See [Rule categories](https://knowledge.leegality.com/document-execution/workflows/v4/rule-engine/rule-categories) for the full taxonomy with examples of each.

## What a rule is not

The Rule Engine acts only on what happens **inside a single workflow**, triggered by **field values**, changing **field properties**. Time-based actions ("send a reminder after 3 days"), signer-triggered behaviour, template swaps, and anything spanning two workflows cannot be built as rules — they have their own solutions.

## Custom fields: your rule inputs

Most rules watch a **custom field** — a Loan Amount, a Customer Type, a Source flag — that you add to the workflow yourself. If the field your rule needs doesn't exist yet, create it first: see [Custom Fields](https://knowledge.leegality.com/document-execution/workflows/v4/custom-fields/overview).

Fields on a [Custom Page](https://knowledge.leegality.com/document-execution/workflows/v4/setup-configuration/custom-page) make especially good subject fields. The runner enters a value once at the start of the journey, and rules carry it to template fields, stamp values, payment amounts, and document- or invitee-level fields.

> **Tip — Leegality can build rules for you**
>
> The Rule Engine is an advanced feature. If you know *what* you need but not how to set it up, write it down as a [rule spec](https://knowledge.leegality.com/document-execution/workflows/v4/rule-engine/turn-a-requirement-into-a-rule) and send it to our Support team at [support@leegality.com](mailto:support@leegality.com) — we'll configure it for you.

---

URL: https://knowledge.leegality.com/document-execution/workflows/v4/rule-engine/rule-categories

# Rule categories

Every rule changes exactly **one of three field properties**. That gives you three rule categories — and for any requirement, your first question is: *which property does this change?*

Answering that tells you which category you're building, which examples to copy from, and how to fill in the [rule spec](https://knowledge.leegality.com/document-execution/workflows/v4/rule-engine/turn-a-requirement-into-a-rule).

> **Note — Category shorthand**
>
> You'll sometimes see these referred to by letter — **A** Mandatory, **B** Editable, **C** Value. The letters and the property names mean the same thing.

## A · Mandatory rules

Turn a field's **required flag** on or off based on another field's value. The workflow won't let the stage complete until a mandatory field is filled.

*Example:* Say the requirement is **"Make Reviewer mandatory IF Loan Amount > ₹10,00,000."** Big-ticket loans need a human check before they go out, while smaller ones don't need to wait on one — so instead of always requiring a Reviewer, the rule watches the Loan Amount and switches the Reviewer field's mandatory flag on only once it crosses the threshold. Below ₹10,00,000, the stage completes without one.

Mandatory rules aren't limited to switching a requirement on, either — they can relax one too:
- **Make FATCA Declaration mandatory IF Customer Type = NRI** — a regulatory field that only applies to one customer segment.
- **Make Insurance Consent *non*-mandatory IF Insurance = No** — the same mechanism, run in reverse.

→ How-to: [Make a field mandatory with a rule](https://knowledge.leegality.com/document-execution/workflows/v4/rule-engine/how-to/make-a-field-mandatory)

## B · Editable rules

**Lock or unlock** a field. The field stays visible — the reader can see the value — but whether it can be changed depends on your condition.

*Example:* Take **"Lock Branch Code IF Source = LOS API."** When a branch code arrives pre-filled from the LOS API, it's a system-supplied value — there's no reason a runner or invitee should be able to hand-edit it, and every reason they shouldn't. The rule watches the Source field, and the moment it reads "LOS API," Branch Code switches to non-editable. It's still visible so everyone can see what value is being used; it just can't be changed.

The same pattern applies wherever a value needs to be frozen once it's trustworthy:
- **Lock Customer Name IF KYC Verified = true** — once identity is verified, the name shouldn't move.

## C · Value rules

**Compute or assign a value.** This is the most powerful category, because the right-hand side of the rule isn't limited to a constant — it can be:

- **A constant** — eSign Type = Aadhaar
- **Arithmetic across fields** — Stamp Group Amount = Loan Amount × Stamp Duty %
- **A lookup** — Stamp Duty = lookup(State, Loan Amount)
- **A value from another part of the workflow** — Payment Collect Amount of Invitee 1 = Stamp Group Amount of Document 1

*Example:* The classic case is **"Stamp Group Amount = Loan Amount × Stamp Duty %."** Nobody should have to do that arithmetic by hand, and nobody should have to remember to redo it if either input changes — so the rule fires the moment both Loan Amount and Stamp Duty % are filled, computes Stamp Group Amount itself, and recomputes it automatically if either input is edited afterward.

The right-hand side isn't limited to arithmetic, though — the same category covers lookups, conditional constants, and values copied from elsewhere in the workflow:
- **Stamp Duty = lookup(State, Loan Amount)** — duty tables differ by state, so the rule resolves the right rate.
- **eSign Type = Aadhaar IF Loan > ₹1,00,000, else Virtual Sign** — a value rule can route the signing experience by tier.

→ How-to: [Calculate a field's value with a rule](https://knowledge.leegality.com/document-execution/workflows/v4/rule-engine/how-to/calculate-a-field-value)

## Beyond the three: two special kinds

Two kinds of rules dominate real deployments and sit slightly outside the A–C property model. They're still rules — but they're worth recognising as their own shapes.

### Validation rules

A validation rule checks a condition when the user clicks **Proceed** and, if the check fails, **blocks the stage with an error message**. This is how "make X mandatory" requirements often ship in practice: rather than flipping the mandatory flag, the rule verifies the field at Proceed time and explains exactly what's missing.

> *Example:* IRN must follow the format `123-456789_ABC` with a valid sequence code. If any document's IRN is missing or malformed, Proceed is blocked and the error names the offending document.

→ How-to: [Validate fields before Proceed](https://knowledge.leegality.com/document-execution/workflows/v4/rule-engine/how-to/validate-before-proceed)

### Assignment rules

An assignment rule applies **structural defaults** when something is added to the workflow — most commonly, auto-assigning documents to invitees, or applying a standard settings bundle to every newly added invitee.

> *Example:* every newly added document is automatically assigned to all invitees, so the sender never has to wire assignments by hand.

→ How-to: [Auto-assign documents with a rule](https://knowledge.leegality.com/document-execution/workflows/v4/rule-engine/how-to/auto-assign-documents)

## Choosing the category: a 10-second habit

When a requirement lands, ask in order:

1. Is the ask about a field being **required**? → Mandatory (A)
2. About a field being **changeable or frozen**? → Editable (B)
3. About a field **getting a value** — computed, looked up, or copied? → Value (C)
4. About **stopping Proceed** with a message? → Validation
5. About **defaults applied when things are added**? → Assignment

Then write it down — [Turn a requirement into a rule](https://knowledge.leegality.com/document-execution/workflows/v4/rule-engine/turn-a-requirement-into-a-rule) gives you the six-line format.

---

URL: https://knowledge.leegality.com/document-execution/workflows/v4/rule-engine/turn-a-requirement-into-a-rule

# Turn a requirement into a rule

Requirements arrive as goals: *"auto-calculate the premium"*, *"big loans need a reviewer"*, *"NRI customers must fill FATCA"*. The Rule Engine needs those goals expressed as precise logic. The bridge between the two is a **six-line rule spec** — plain English, no syntax, but exact.

A working rule is written in Leegality's **rule language** — but the spec comes first, and it isn't paperwork. Think of it as the rule's **intake form**: each of its six lines answers a question the rule-writer must answer anyway, whether that writer is you (once you know the language) or Leegality Support. Write the spec well and writing the rule is mechanical. Write it vaguely and the wrong rule gets built. The whole game is precision.

## Before you write: two quick checks

1. **Is it a rule at all?** If it's time-based, signer-triggered, template-swapping, or cross-workflow, stop — it needs a different solution instead of a rule.
2. **Which category is it?** Identify which property changes — Mandatory, Editable, or Value — or whether it's a validation or assignment rule. [Rule categories](https://knowledge.leegality.com/document-execution/workflows/v4/rule-engine/rule-categories) makes this a 10-second habit.

## The six-line spec

Every rule spec has the same six lines:

```
TARGET field:   
ACTION:         
SUBJECT field:  
CONDITION:      
OUTCOME:        
Workflow:       
```

A filled-in spec looks like this:

```
TARGET field:   Reviewer (1st invitee) step
ACTION:         Set Mandatory = true
SUBJECT field:  Loan Amount
CONDITION:      Loan Amount > ₹10,00,000
OUTCOME:        Reviewer step is Mandatory; below ₹10L, Reviewer step is Optional
Workflow:       Personal Loan Workflow (workflow_id: pl_v4_01)
```

Six lines. Unambiguous. Anyone reading it — you next month, a colleague, Leegality Support — builds exactly the same rule.

## Worked translations

Three real customer asks, three specs. Notice the pattern: the customer speaks in goals; the spec pins down fields, thresholds, and both sides of the behaviour.

### "Big home loans need a credit officer"

> *"For home loans above ₹1 crore, we want an internal credit officer to review and approve the agreement before the borrower can sign. Below ₹1 Cr, no credit officer needed."*

```
TARGET field:   Credit Officer reviewer invitee · Name field
ACTION:         Set Mandatory = true
SUBJECT field:  Loan Amount
CONDITION:      Loan Amount > ₹1,00,00,000
OUTCOME:        Credit Officer review required above ₹1 Cr; optional otherwise
Workflow:       HDFC Home Loan (workflow_id: hdfc_hl_v4_01)
```

A **Mandatory** rule. The customer's phrase "before the borrower can sign" is captured by making the reviewer invitee mandatory — the signing order does the rest.

### "The premium should auto-calculate"

> *"The annual premium should auto-calculate from the customer's age, sum assured, and policy term — and show up on the policy document the customer is signing."*

```
TARGET field:   Premium Amount template field on Policy Document
ACTION:         Set Value = lookup(Age, Sum Assured, Policy Term)
SUBJECT field:  Age, Sum Assured, Policy Term
CONDITION:      All three fields filled
OUTCOME:        Premium appears printed on the policy document before signing
Workflow:       Term Life Policy (workflow_id: tl_v4_01)
```

A **Value** rule with multiple subject fields. "Show up on the document" tells you the target is a *template field* — the computed value prints into the document itself.

### "Lock the branch code once it's system-supplied"

> *"Branch Code is auto-populated from our LOS system for most sends. Once it's set that way, senders shouldn't be able to overwrite it — but for manual walk-in cases with no LOS data, they should still be able to type it in themselves."*

```
TARGET field:   Branch Code field
ACTION:         Set Editable = false (for LOS); true (for Manual)
SUBJECT field:  Source
CONDITION:      Source = LOS API
OUTCOME:        Branch Code is locked when sourced from LOS; editable for manual entries
Workflow:       Branch Onboarding (workflow_id: branch_v4_01)
```

An **Editable** rule. "Shouldn't be able to overwrite" is the giveaway — this is about who controls the value, not about whether it exists or is required.

## What makes a spec precise

The difference between a spec that builds right the first time and one that bounces back with questions:

- **Exact field names, not descriptions.** "Loan Amount" (the field as named in the workflow), not "the loan value". If the field is a [custom field](https://knowledge.leegality.com/document-execution/workflows/v4/custom-fields/overview), name it exactly as created.
- **Exact thresholds and values.** ₹10,00,000, not "around ten lakh". `NRI`, spelled as the dropdown option spells it.
- **Both sides of the behaviour.** The OUTCOME line states what happens when the condition is met *and* when it is not. "Below ₹10L, Reviewer is Optional" prevents the classic ambiguity: should the rule also *undo* its effect, or only ever apply it?
- **One workflow, named.** Include the workflow name and ID. A rule lives inside exactly one workflow — the spec should leave no doubt which.
- **Error message text, if it's a validation rule.** The message shown to the user is part of the spec, word for word.

## From spec to working rule: two paths

The spec is the form; the rule itself is written in the rule language and configured in the Rule Engine panel — title, logic, trigger method. With a finished spec, pick whichever path fits:

1. **Write the rule yourself.** [Build your first rule](https://knowledge.leegality.com/document-execution/workflows/v4/rule-engine/build-your-first-rule) walks the full configuration with ready-made rule logic to paste and adapt. When you're ready to write your own, Advanced: the LEEQL rule language teaches the language, and the use-case gallery is full of adaptable patterns.
2. **Send it to Support.** Mail the spec to [support@leegality.com](mailto:support@leegality.com) and Leegality writes and configures the rule for you. A clear six-line spec is everything Support needs.

> **Tip — Not sure it's buildable?**
>
> Borderline requirement? Spec it anyway and send it in. The spec format makes it easy to confirm whether something is a rule, and if it isn't, we'll point you to the right alternative.

---

URL: https://knowledge.leegality.com/document-execution/workflows/v4/rule-engine/visibility-rules

# Visibility rules (not currently supported)

> **Caution — Why this page exists**
>
> Visibility rules were removed from the live V4 Rule Engine docs on POC review (2026-08-20) because Leegality does not currently support them — only **Mandatory**, **Editable**, and **Value** rules are live. This page preserves every snippet that was removed, labeled by its original file and location, so the category can be restored quickly if/when Visibility rules ship. This page is `draft: true` and carries no sidebar entry, so it never appears on the live site.

## 1. `rule-engine/rule-categories.md`

**Frontmatter `description`** (replace "three" back with "four", and re-add Visibility):
```
description: The four rule categories — Mandatory, Visibility, Editable, and Value — plus the two special kinds that go beyond them - validation rules and assignment rules.
```

**Intro paragraph** (change "three" → "four" in both places):
```
Every rule changes exactly **one of four field properties**. That gives you four rule categories — and for any requirement, your first question is: *which property does this change?*
```

**Category shorthand note** — re-insert Visibility as B, and shift Editable/Value back to C/D:
```
> **Note — Category shorthand**
>
> You'll sometimes see these referred to by letter — **A** Mandatory, **B** Visibility, **C** Editable, **D** Value. The letters and the property names mean the same thing.
```

**The full section** — re-insert immediately after the "A · Mandatory rules" section (before what is currently "B · Editable rules", which reverts to "C · Editable rules"):
```
## B · Visibility rules

**Show or hide** a field — or an entire page — at runtime. Hidden fields don't just look optional; they're not part of the journey at all.

| Requirement | Reading it as a rule |
| --- | --- |
| Hide the Co-applicant Name field IF Loan Type = Personal | Personal loans have no co-applicant — remove the noise |
| Show the GST Number field IF Borrower Type = Business | Only businesses have one |
| Show the Coordinate Placement page IF new invitees are added at runtime | Visibility rules can target a whole **page**, not just a field |
```

**Section renumbering** — current "B · Editable rules" reverts to "C · Editable rules"; current "C · Value rules" reverts to "D · Value rules".

**"Beyond the three" section** — heading and range revert:
```
## Beyond the four: two special kinds

Two kinds of rules dominate real deployments and sit slightly outside the A–D property model. They still pass the three-question test — they're rules — but they're worth recognising as their own shapes.
```
(Note: the "three-question test" link fragment here depends on `what-is-a-rule.md` also being restored — see the separate draft-removal note on that page.)

**"Choosing the category" checklist** — re-insert the Visibility line as item 2, renumbering the rest:
```
1. Is the ask about a field being **required**? → Mandatory (A)
2. About a field **appearing or disappearing**? → Visibility (B)
3. About a field being **changeable or frozen**? → Editable (C)
4. About a field **getting a value** — computed, looked up, or copied? → Value (D)
5. About **stopping Proceed** with a message? → Validation
6. About **defaults applied when things are added**? → Assignment
```

## 2. `rule-engine/overview.md`

**Frontmatter `description`** — re-add "visibility,":
```
description: Build your own IF → THEN logic inside a v4 workflow. Rules watch a field's value and change another field's visibility, editability, mandatory state, or value — automatically.
```

**Action row in the IF→THEN component table**:
```
| **Action** | The change applied to the target field — set Mandatory, set Visibility, set a Value |
```

**Section heading + intro** — "three" reverts to "four":
```
## The four properties a rule can change

Every rule changes exactly one of four field properties. This gives you four rule categories:
```

**Categories table** — re-insert the Visibility row (between Mandatory and Editable):
```
| **Visibility** | Show or hide a field (or an entire page) | Hide Co-applicant Name IF Loan Type = Personal |
```

## 3. `rule-engine/turn-a-requirement-into-a-rule.md`

**"Which category is it?" checklist item**:
```
2. **Which category is it?** Identify which property changes — Mandatory, Visibility, Editable, or Value — or whether it's a validation or assignment rule. [Rule categories](https://knowledge.leegality.com/document-execution/workflows/v4/rule-engine/rule-categories) makes this a 10-second habit.
```

**Six-line spec template ACTION line**:
```
ACTION:         
```

**Worked example** — this replaced the "Lock the branch code once it's system-supplied" (Editable) example that now occupies this slot. Restoring Visibility means deciding whether to keep both examples (four worked translations instead of three) or swap back:
```
### "Only NRIs should see FATCA"

> *"For NRI customers, we need them to fill the FATCA Declaration field. For resident Indians, the FATCA field shouldn't even appear in the workflow."*

\`\`\`
TARGET field:   FATCA Declaration field
ACTION:         Set Visibility = true (for NRI); false (for Resident)
SUBJECT field:  Customer Type
CONDITION:      Customer Type = NRI
OUTCOME:        NRI customers see and fill FATCA; residents do not see the field at all
Workflow:       PMS Customer Onboarding (workflow_id: pms_v4_01)
\`\`\`

A **Visibility** rule. "Shouldn't even appear" is the giveaway — this is about the field existing in the journey, not about it being optional.
```

## 4. `rule-engine/build-your-first-rule.md`

**How-to guide list** — re-insert "visibility," between "mandatory" and "editable":
```
- **Adapt a pattern.** The how-to guides for each category — [mandatory](https://knowledge.leegality.com/document-execution/workflows/v4/rule-engine/how-to/make-a-field-mandatory), visibility, editable, [value](https://knowledge.leegality.com/document-execution/workflows/v4/rule-engine/how-to/calculate-a-field-value) — provide rule logic to copy and adjust, the way you adjusted `lecf_loanAmount` today.
```

## Restoration checklist

- [ ] Re-add all snippets above to their four source files, in the marked locations.
- [ ] Revert the A/B/C relettering in `rule-categories.md` back to A/B/C/D.
- [ ] Decide whether the Editable worked example added to `turn-a-requirement-into-a-rule.md` (branch code / LOS) stays alongside the restored FATCA/Visibility example, or is removed again.
- [ ] Delete this draft page once restoration is complete, or keep it as a historical record — either is fine since it carries no sidebar entry and is excluded from the build either way.

---

URL: https://knowledge.leegality.com/document-execution/workflows/v4/rule-engine/what-is-a-rule

# What counts as a rule?

Not every requirement is a rule. Some things that *sound* like rules — "remind the signer after 3 days", "use the Hindi agreement if they pick Hindi" — belong to other parts of Leegality, or to your own systems.

Before you build a rule (or promise one), run the requirement through three questions. Three YES answers mean it's a rule. Any NO means it's something else — and this page tells you what to do instead.

## The three-question test

### 1. Is everything happening inside one workflow?

A rule lives inside a single workflow. It cannot reach across workflows or act on anything outside the one it belongs to.

**If NO** → it's cross-workflow orchestration or external automation, not a rule.

### 2. Is the trigger a field value inside that workflow?

A rule is evaluated against the value of a field within the same workflow — a loan amount, a customer type, a dropdown selection. The clock, an incoming API call from another system, or an action taken by the signer cannot trigger a rule.

**If NO** → it's time-based, signer-triggered, or externally triggered — not a rule.

### 3. Does the outcome change one of the four field properties?

A rule's outcome changes a field's **Mandatory** state, **Visibility**, **Editability**, or **Value** (including calculated values). If the desired outcome is something else — sending a message, swapping a template, starting another workflow — it isn't a rule.

**If NO** → it's workflow composition or an external action, not a rule.

> **Note — The test at a glance**
>
> ✓ One workflow · ✓ field-value trigger · ✓ outcome changes Mandatory / Visibility / Editability / Value = **it's a rule**. Any ✗ = not a rule — identify which pattern below it matches, and use the alternative.

## Three requirements that are *almost* rules

Most "is this a rule?" confusion comes down to three recurring patterns. Learn to recognise them — each comes with a better solution.

### Anti-pattern 1: The clock triggers it, or the action reaches outside

> "Send a reminder SMS 3 days after the borrower gets the link."

Nothing inside the workflow caused this to fire — **time did**. And the action sends an SMS: it reaches *out* to the customer rather than changing a field in the workflow. This fails questions 2 and 3.

**What to do instead:** use Leegality's reminder settings, or the notification tooling in your own system. This is automation, not a rule.

### Anti-pattern 2: The signer triggers it, or the ask swaps templates

> "Use the Hindi loan agreement if the signer picks Hindi."

Two problems. The **signer** is the trigger — rules can't react to signer actions. And the action swaps which template the workflow uses — rules change field properties, not which documents or templates a workflow contains.

**What to do instead:** build a separate workflow per language, and have your system send each customer the right one.

### Anti-pattern 3: The ask spans more than one workflow

> "Start the Sanction Letter workflow after the Loan Agreement workflow finishes."

Two different workflows. Rules live inside one workflow only — they can't reach across. This fails question 1.

**What to do instead:** Leegality signals when a workflow completes; your system listens for that completion notice and starts workflow #2.

## Rule vs not-a-rule at a glance

| Requirement | Rule? | Why |
| --- | --- | --- |
| Make Reviewer mandatory IF Loan Amount > ₹10,00,000 | ✓ | Field-value trigger, changes the Mandatory property |
| Hide the Co-applicant Name field IF Loan Type = Personal | ✓ | Field-value trigger, changes Visibility |
| Stamp Duty Amount = Loan Amount × Stamp Duty % | ✓ | Field-value trigger, assigns a computed Value |
| Block Proceed with an error IF IRN format is invalid | ✓ | Field-value trigger, validates before the stage completes |
| Send a reminder SMS 3 days after the invitation | ✗ | Time-triggered, external action — use reminder settings |
| Use the Hindi agreement if the signer picks Hindi | ✗ | Signer-triggered, swaps templates — use one workflow per language |
| Start workflow B when workflow A finishes | ✗ | Spans two workflows — your system chains them on completion |

## Next steps

It passed the test? Two moves from here:

- Identify **which property** it changes — [Rule categories](https://knowledge.leegality.com/document-execution/workflows/v4/rule-engine/rule-categories) walks through the four types with examples.
- Write it as a six-line spec anyone can build from — [Turn a requirement into a rule](https://knowledge.leegality.com/document-execution/workflows/v4/rule-engine/turn-a-requirement-into-a-rule).

> **Tip — Borderline case?**
>
> If a requirement doesn't clearly pass or fail, write it up as a [rule spec](https://knowledge.leegality.com/document-execution/workflows/v4/rule-engine/turn-a-requirement-into-a-rule) anyway and send it to [support@leegality.com](mailto:support@leegality.com) — the spec makes it easy for us to confirm whether it's buildable and configure it if it is.

---

URL: https://knowledge.leegality.com/document-execution/workflows/v4/run-a-pack

# Run a v4 workflow

Running a v4 workflow sends a preconfigured document pack out for eSignature. All settings defined during [workflow creation](https://knowledge.leegality.com/document-execution/workflows/v4/create-a-workflow) are applied automatically — as the workflow runner, you fill in only what the creator left open, and you cannot change what they locked.

> **Info — Note**
>
> The options available to you depend on how the workflow was created. Not every workflow lets you modify documents, stamps, invitees, or other settings.

> **Tip — Sending many packs at once?**
>
> To create many packs in one go from a spreadsheet, see [Run a v4 workflow via Excel Upload](https://knowledge.leegality.com/document-execution/workflows/v4/excel-upload/run-via-excel-upload).

## Access your workflow

1. Navigate to **Workflows** from the left panel.
2. Open the **V4 Workflows** tab.
3. Find the workflow you want to run. (**Note:** You can search by workflow name or ID.)
4. Click the **Run** button on the right side of the workflow.

The workflow opens at its first stage. A v4 workflow runs across the **Create**, **Invite**, and **Finalise** stages, with an additional **Template** step after Invite if the pack uses fillable templates. If the workflow creator has added a [Custom Page](https://knowledge.leegality.com/document-execution/workflows/v4/setup-configuration/custom-page), it appears before Create and the workflow opens there instead. 

> **Info — Note**
>
> The options available to you are a matter of [workflow creation](https://knowledge.leegality.com/document-execution/workflows/v4/create-a-workflow).

> **Info — Stage names and visibility**
>
> The workflow creator can rename or hide stages using [Visualisation](https://knowledge.leegality.com/document-execution/workflows/v4/setup-configuration/visualisation). The stage names you see may differ from those shown here, and any stage the creator has hidden will not appear while you run the workflow. This includes the Custom Page, which the creator can rename.

---

### Fill in the Custom Page (Optional)

This step appears only if the workflow creator has added a [Custom Page](https://knowledge.leegality.com/document-execution/workflows/v4/setup-configuration/custom-page) to the workflow. The workflow opens on this page. It may appear in the stepper under a different name, such as *Loan Details*.

The Custom Page collects the key details for the whole pack on one screen, such as the loan amount or the borrower's name. The creator designs the page, so its fields, headings, and instructions vary from workflow to workflow.

1. Read the instructions on the page, and fill in each field. Mandatory fields must be filled before you can continue.
2. Click **Proceed** to continue to the next stage.

Values you enter here can fill in other fields in the pack automatically, such as template fields, stamp values, or payment amounts. If those stages are visible to you, check the filled-in values when you reach them.

> **Info — Sending from the Custom Page**
>
> Some workflows are set up so that the Custom Page is the only stage you see. In that case, click **Send** on the Custom Page to send the pack. You are then taken to the [Details page](https://knowledge.leegality.com/document-execution/workflows/v4/pack-details), just as in [Step 4](#step-4-preview-and-send-documents).



---

### Step 1: Prepare Your Document

The document pack is already assembled as configured in the workflow. Depending on the configuration, you may need to upload a PDF, or the templates and PDFs set during creation are attached automatically.

A pack can contain multiple **primary documents** (each shown as a separate tab), and each primary document can contain multiple **sub-documents**. For a detailed explanation, see [Packs and documents](https://knowledge.leegality.com/document-execution/workflows/v4/understanding-v4/packs-and-documents).

> **Info — NOTE**
>
> You can add new primary documents with the **+ Add Document** tab if the workflow creator left it visible and editable. If the creator has locked or hidden the option, it is not available while running the workflow. See [Field Properties](https://knowledge.leegality.com/document-execution/workflows/v4/setup-configuration/field-properties).

For each primary document:

1. **Upload sub-documents (if required):** If the creator left an upload placeholder, add the relevant PDF(s). If documents are pre-attached and locked, you cannot change them.
2. **Document Name:** Enter the primary document name. It appears in the email subject and body.

> **Tip — Example**
>
> **Email Subject:** "Invitation to eSign: Service Level Agreement"
3. **Internal Reference Number:** Enter the Internal Reference Number for the document.

The **Name**, **Internal Reference Number**, and any other input fields follow the [validations](https://knowledge.leegality.com/document-execution/workflows/v4/setup-configuration/field-configuration) (character limits and format) set during workflow creation.

> **Info — Note**
>
> Field behaviour depends on the workflow configuration. Fields the creator marked as non-editable are pre-filled and locked, hidden fields do not appear, and mandatory fields must be filled before you can proceed.
>     See [Control Field Behaviour](https://knowledge.leegality.com/document-execution/workflows/v4/setup-configuration/field-properties) for more details.

#### Manage templates

If the workflow creator left the **Select Template** option editable, you can select additional templates the same way as in [workflow creation](https://knowledge.leegality.com/document-execution/workflows/v4/create-a-workflow#option-2-use-templates) — search, filter by type, pick a version or **Latest**, and select one or more.

For templates the creator already selected, whether you can enable/disable or delete them depends on the same [Enable and delete controls](https://knowledge.leegality.com/document-execution/workflows/v4/create-a-workflow#enable-and-delete-selected-templates) the creator configured — available only where left visible and editable. Only **enabled** templates are used in the document sent for signing.

---

### Step 2: Add Stamp Papers

Depending on the workflow configuration, you may be able to select stamp settings, enter only a quantity, or simply confirm settings that are already fixed.

> **Info — Note**
>
> The options below are based on the workflow configuration. Not all workflows allow selection or modification of stamp settings.

Stamps can be attached in one of two ways:

- **Stamps for merged document:** A single stamp is attached at the beginning of all combined sub-documents (Stamp → Sub-document A + Sub-document B).
- **Separate stamps for sub-documents:** A dedicated stamp is attached to each sub-document (Stamp 1 → Sub-document A, Stamp 2 → Sub-document B). This applies only when a primary document has more than one sub-document.

If the workflow creator has already fixed which method to use, you must follow it. If they left it open, you can choose the stamping method while running the workflow. For more details, see [Add Stamp Papers](https://knowledge.leegality.com/document-execution/workflows/v4/create-a-workflow#step-3-add-stamp-papers) in the Create a Workflow guide.

Once you've chosen a method, configure the stamp using one of the following options:

#### Stamp Series

#### Stamp Series

**Option 1:**

- You may select a stamp series and enter the quantity. This is configurable while running the workflow.

**Option 2:**

- The stamp series is fixed by the workflow creator, but you must enter the number of stamps to attach from that series.

**Option 3:**

- Both the stamp series and the quantity are fixed by the workflow creator and cannot be changed.

#### Stamp Group

#### Stamp Group

**Option 1:**

- You may select a stamp group and enter the stamp value to attach.

**Option 2:**

- The stamp group is fixed by the workflow creator, but you must enter the stamp value. You cannot select a different stamp group.

**Option 3:**

- Both the stamp group and the stamp value are preset by the workflow creator and cannot be modified.

#### Revenue Stamp

#### Revenue Stamp

**Option 1:**

- You may add a revenue stamp and enter the quantity.

**Option 2:**

- The revenue stamp is fixed by the workflow creator, but you must enter the quantity.

**Option 3:**

- Both the revenue stamp and the quantity are fixed by the workflow creator and cannot be changed.

#### Stamp Upload

#### Stamp Upload

**Option 1:**

- You must provide the **State**, **Denomination**, **First party name**, **Second party name**, and **Stamp serial number**, and upload the stamp paper.

**Option 2:**

- The workflow creator has pre-filled some stamp details (such as State and Denomination). You enter the remaining details and upload the stamp paper.

---

### Step 3: Invite Configuration

> **Info — Note**
>
> All settings configured during workflow creation are automatically applied here. The availability of certain features depends on the workflow creator's configuration.

You can enter the invitee-specific parameters — such as **Name** and **Contact Details** (Email or Phone) — for any invitee the creator left open. How each field on the invitee card behaves depends on its [Field Properties](https://knowledge.leegality.com/document-execution/workflows/v4/setup-configuration/field-properties) — locked fields show fixed values, hidden fields do not appear, and mandatory fields must be filled.

The invitee's role — Signer, [Reviewer](https://knowledge.leegality.com/document-execution/leegality-features/invitee-level/types-of-invitee/reviewer?type=v4-workflow&journey=workflow-creation), [Group Signer](https://knowledge.leegality.com/document-execution/leegality-features/invitee-level/types-of-invitee/group-invitee?type=v4-workflow), or Group Reviewer — is set during workflow creation; unless the creator left it editable, you cannot change it. [CC invitees](https://knowledge.leegality.com/document-execution/leegality-features/invitee-level/types-of-invitee/cc?type=v4-workflow&journey=workflow-creation) do not sign, but receive notifications about the document's progress.

#### Set signing order

If the workflow creator enabled the signing-order controls, you can configure them while running the workflow. Whether they are available depends on whether the creator left them visible and editable.

- **Set signing order:** Drag the invitee cards to rearrange the signing sequence.
- **Lock signing order:** Enforces the sequence — the document moves to the next invitee only after the current signer has signed.

#### Invitee settings

Select an invitee card to view their settings in the right panel. The **Settings** tab groups the invitee-level options into the sections below. All of these are set during workflow creation — whether you can see or change any of them depends on the [Field Properties](https://knowledge.leegality.com/document-execution/workflows/v4/setup-configuration/field-properties) the creator has configured.

- [**eSign Types**](https://knowledge.leegality.com/category/esign-types)**:** The eSignature type(s) applied to this invitee. By default, the eSign type is visible but **non-editable** — you see the eSign type defined during workflow creation and cannot modify it, unless the creator left it editable.
- [**eSign Prioritisation**](https://knowledge.leegality.com/document-execution/esign-type/aadhaar/prioritise-aadhaar-for-invitee?type=v4-workflow)**:** The preferred eSign type set for the invitee. This works for **Aadhaar eSign** only.
- **Signature Appearance:** How the signature appears on the signed document.
    - [**Invitee Name on Signature**](https://knowledge.leegality.com/document-execution/leegality-features/invitee-level/esignature-appearance/invitee-name-in-signature?type=v4-workflow)**:** Whether the invitee's name is displayed in the signature.
    - [**Company Seal**](https://knowledge.leegality.com/document-execution/leegality-features/invitee-level/esignature-appearance/company-seal?type=v4-workflow)**:** The invitee is asked to upload a company seal image.
    - [**Invitee Name Editing**](https://knowledge.leegality.com/document-execution/leegality-features/invitee-level/esignature-appearance/invitee-name-editing?type=v4-workflow)**:** Whether the invitee can edit their name during signing.
- [**Webhooks**](https://knowledge.leegality.com/document-execution/leegality-features/invitee-level/custom-url-and-webhook/webhook-and-url?type=v4-workflow)**:** A custom webhook and URL for real-time status updates.
- [**Consent and Validity Controls**](https://knowledge.leegality.com/document-execution/leegality-features/invitee-level/other-features/additional-consent?type=v4-workflow&journey=workflow-creation)**:** Custom consent terms shown alongside the default consent.
- **Manage Invitee Interactions:** How the invitee interacts with the document during the signing journey.
    - [**Base URL**](https://knowledge.leegality.com/document-execution/leegality-features/invitee-level/custom-url-and-webhook/webhook-and-url?type=v4-workflow)**:** A custom base URL for the invitee's signing journey.
    - [**Redirect URL**](https://knowledge.leegality.com/document-execution/leegality-features/invitee-level/custom-url-and-webhook/webhook-and-url?type=v4-workflow)**:** The invitee is redirected to a specific page after events in the signing journey.
    - [**Add Supporting Documents**](https://knowledge.leegality.com/document-execution/leegality-features/invitee-level/other-features/supporting-documents?journey=workflow-creation&version=v4)**:** Additional documents the invitee must upload while signing.
    - [**Allow rejection of doc(s)**](https://knowledge.leegality.com/document-execution/leegality-features/invitee-level/other-features/reject-to-sign?type=v4-workflow)**:** The invitee is allowed to reject signing the document(s).
    - [**Custom message**](https://knowledge.leegality.com/document-execution/leegality-features/document-level/custom-message?type=v4-workflow)**:** A custom message the invitee sees with the signing invitation.
    - [**Local Language Settings**](https://knowledge.leegality.com/document-execution/leegality-features/invitee-level/local-language?journey=workflow-creation&version=v4)**:** The invitee completes the signing journey in a local language — either they select a language as the first step, or a default language is set for them.
- **Security Options:** Authentication and verification controls applied to the invitee.
    - [**1 Factor Authentication before document preview**](https://knowledge.leegality.com/document-execution/leegality-features/invitee-level/security/one-factor-authentication?type=v4-workflow)**:** OTP verification via email or phone number before the invitee can preview the document.
    - [**2 Factor Authentication before document preview**](https://knowledge.leegality.com/document-execution/leegality-features/invitee-level/security/two-factor-authentication?type=v4-workflow)**:** OTP verification via both email and phone number before the invitee can preview the document.
    - [**Capture GPS locations**](https://knowledge.leegality.com/document-execution/leegality-features/invitee-level/security/capture-gps-location?type=v4-workflow)**:** The invitee's location is recorded at the time of signing, with optional accuracy- and location-based restrictions.
    - [**Capture Photo**](https://knowledge.leegality.com/document-execution/leegality-features/invitee-level/security/capture-photo?type=v4-workflow)**:** The signer's photo is captured before they sign.
    - [**Send Document download link with OTP notifs**](https://knowledge.leegality.com/document-execution/leegality-features/invitee-level/security/send-raw-document-link)**:** A link to download the raw PDF document is sent in all OTP verification emails/messages.
    - [**Mask contact details**](https://knowledge.leegality.com/document-execution/leegality-features/invitee-level/other-features/mask-contact-details?type=v4-workflow)**:** Contact details of other invitees are masked from this invitee.
- [**Notifications**](https://knowledge.leegality.com/document-execution/leegality-features/invitee-level/notifications/)**:** How invitations, reminders, and updates are sent to the invitee — **Email**, **SMS**, or **WhatsApp**. For CC invitees, only email notifications are available.
- [**Certificate Verification**](https://knowledge.leegality.com/document-execution/esign-type/aadhaar/signature-certificate-verifier)**:** The intended signer's details are verified against the digital signature certificate after signing.
- [**Contact Book**](https://knowledge.leegality.com/document-execution/contact-book)**:** Reuse saved contacts when filling in invitee details.

#### Assign documents to invitees

1. Click **Assign Documents** on the invitee card.
2. Select which primary document(s) this invitee should sign. If you select multiple documents, the invitee views them in the order you select them — the first document selected appears first.
3. Invitees see and sign only their assigned documents.

> **Info — Note**
>
> Every invitee must be assigned at least one primary document, and every primary document must be assigned to at least one invitee.

> **Tip — Example**
>
> - **Borrower:** assigned the Loan Agreement and Property Documents.
>     - **Guarantor:** assigned the Loan Agreement only.
>     - **Bank Officer:** added as CC on the Property Documents only.

Once all invitees are configured, click **Proceed** to continue — to the Template step if your pack uses fillable templates, otherwise to Finalise.

---

### Fill Template Fields (Optional)

This step appears only when at least one document in the pack has at least one template that is both selected and **enabled**. 

> **Info — Note**
>
> If the workflow creator has hidden the Template stage using [Visualisation](https://knowledge.leegality.com/document-execution/workflows/v4/setup-configuration/visualisation), you won't see this step. A creator can hide or rename any stage this way.

If a primary document has more than one enabled template, they are grouped under that document but filled separately. The Fill Template screen is divided into two sections:

- **Left Panel – Live Preview:** Displays a real-time preview of the document as you fill in the fields. Changes made on the right are immediately reflected here.
- **Right Panel – Form Fields:** Lists all available fields in the template. Enter or select values for each field as required.

As you complete each field on the right, the corresponding field in the document preview on the left updates instantly, so you can verify your entries before continuing.

> **Info — Group fields**
>
> If a template has group fields, filling one of them automatically updates the other fields in that group.

> **Info — Template versioning**
>
> If the workflow creator picked **Latest** for a template, the version resolved here — the newest version available at this point — is the one used for the rest of the journey, including Finalise and signing.

#### Allow first invitee to fill

The **Allow first invitee to fill** toggle appears here only if the workflow creator left it visible; you can change it only if the creator left it editable.

- **Off:** All of the template's field validations (mandatory fields, character limits, etc.) run now — you must satisfy them before you can proceed to Finalise.
- **On:** Field validations are skipped here. You can leave fields empty — including mandatory ones — for the first invitee to complete during the signing journey.

> **Tip — Best Practice**
>
> We recommend filling template fields at this stage rather than during the signing journey. When fields like addresses or descriptions are filled, they may expand and shift the document content downward. Since signature coordinates are placed at fixed positions, filling fields beforehand ensures signatures align with the final document layout.

Click **Save as Draft** at any point to save your entries to the backend and resume later with the same data pre-filled. Whatever you've filled is also saved automatically once you send the pack.

Once you've filled all required fields, click **Proceed** to continue.

---

### Step 4: Preview and Send documents

This page previews the final documents that will be sent for signing.

1. **Preview the documents:** Use the tabs at the top to switch between primary documents, and review each one before sending.
2. **Verify signature coordinates:** The signature placement is fixed according to the workflow configuration. If invitee details for any signature coordinate are left blank, that signature box will remain empty.

> **Tip — Example**
>
> In a pack with three invitees, if the second invitee's details are not provided, the corresponding signature coordinate box will remain empty.

> **Info — Templates in the merged preview**
>
> Templates merge into their primary document here too, using the data you actually filled in the previous step. Unlike the Finalise preview in workflow creation, **disabled templates are not included** — a template must stay enabled all the way through to this point to be part of the pack that gets sent.

3. Click **Proceed** to send the pack. For any template where **Allow first invitee to fill** is off, its field validations are re-checked on the backend at this point before the pack is sent.

If the pack is processed within 10 seconds, you are redirected to the [Details page](https://knowledge.leegality.com/document-execution/workflows/v4/pack-details). If it takes longer, you'll see the message *"Document pack is being processed. This may take a few seconds,"* and the pack is queued for processing.

**During processing:**

- Continue using the dashboard normally.
- View status in the **Processing Queue** if needed.
- Documents are sent to invitees automatically once processed.

Once processing completes, invitees can begin signing, and you can track progress from the [Details page](https://knowledge.leegality.com/document-execution/workflows/v4/pack-details).

---

# Custom Page

URL: https://knowledge.leegality.com/document-execution/workflows/v4/setup-configuration/custom-page
> Design a single page that collects the key details for a pack, link those details to fields across the workflow, and let the workflow runner send documents from one screen.



# Custom Page

Most packs depend on a handful of details, such as the loan amount, the borrower's name, the state, or the branch code. Without a Custom Page, the workflow runner finds and fills these details across the **Create**, **Invite**, and **Finalise** stages.

A **Custom Page** brings them onto one screen. You design the page yourself, and it appears as the **first stage** of the workflow. Link its fields to the rest of the workflow with rules, and a value the runner enters once fills in everywhere it is needed. You can also hide the other stages, so the runner fills in the Custom Page and clicks **Send**.

> **Tip — Prerequisites**
>
> - **Custom page** must be enabled in [Workflow Builder Config](https://knowledge.leegality.com/document-execution/settings/Department/workflow-builder-config).
> - The fields you want on the page must already exist as custom fields. See [Create a custom field](https://knowledge.leegality.com/document-execution/workflows/v4/custom-fields/create-a-custom-field).

> **Info — Note**
>
> Only admins have permission to create and edit workflows.

## Step 1: Add a Custom Page

To add a Custom Page to a workflow:

1. Go to the **Workflows** section using the left panel, and open the **V4 Workflows** tab.
2. Open the workflow you want to add the page to, or click **+ New Workflow** to create one. The workflow editor opens at the **Create** stage.
3. In the **left panel** of the workflow editor, click the **Visualisation** icon. If you don't see the left panel, switch to the **Advanced** tab in the top-right corner.

    The Visualisation panel lists the stages of the workflow: **Create**, **Invite**, **Template** (if the workflow has one), and **Finalise**.
4. Click **+ Custom Page**.

    A **Custom Page** stage is added before **Create** in the stepper at the top of the screen, and a blank page opens with the message *Start building your page*.

> **Info — Note**
>
> The **+ Custom Page** button appears only when **Custom page** is enabled in Workflow Builder Config. A workflow can have only **one** Custom Page, so the button disappears once you add it.

## Step 2: Add Static Elements

Static elements don't collect any information. They give the page structure and tell the runner what to do. The toolbar at the top of the page offers six:

| Element | Use it for |
| --- | --- |
| **Heading** | Page and section titles, in four sizes (H1 to H4). For example, *Loan Form* or *Borrower Details*. |
| **Paragraph** | Longer instructions or background for the runner. |
| **Helper Text** | A short hint next to a field, such as *Enter borrower name and email*. |
| **Divider** | A horizontal line that separates one section from the next. |
| **Link** | A clickable link, for example to a policy or reference document. |
| **Accordion** | A collapsible section. |



To add a static element, click it in the toolbar. For a heading, choose the size you want. The element is added to the page with placeholder text, which you can replace with your own (see [Step 4: Arrange the Page](#step-4-arrange-the-page)).

## Step 3: Add Custom Fields

Custom fields are the parts of the page the runner fills in. Only **pack-level** custom fields can be placed on a Custom Page: each holds one value for the whole pack.

To add a custom field to the page:

1. Open the **Custom Field** tab in the left panel. It lists the fields you have already created. If the page is still empty, you can also click **Open Custom Fields** in the centre of the page.
2. Find the field you want. To narrow the list, type its name in the **Search** box.
3. Click the **+** icon next to the field. A pop-up titled **Choose Placement** appears.
4. Click **Custom Page**.

    The field is added to the page.

Repeat these steps for each field you want on the page.

> **Info — Set field properties and validations**
>
> Right-click a field on the page to control it individually, the same way as in the other stages:
> 
>     - **[Field Properties](https://knowledge.leegality.com/document-execution/workflows/v4/setup-configuration/field-properties):** Set the field's **Visibility**, **Editability**, and **Mandatory** state.
>     - **[Validations](https://knowledge.leegality.com/document-execution/workflows/v4/setup-configuration/field-configuration):** Add character limits and a regex pattern to control what can be entered.

## Step 4: Arrange the Page

Fields and static elements appear in the order you add them. To change the layout:

- **Reorder:** Click the **six-dot** handle to the left of any field or element, then drag it up or down.
- **Edit text:** Double-click the text of a heading, paragraph, helper text, or link, and type the new text.
- **Delete a static element:** Hover over the element and click the **delete** icon in its top-right corner.
- **Remove a custom field:** Right-click the field and click the **delete** icon in the pop-up.

## Step 5: Link Fields with Rules

A Custom Page is most useful when its fields feed the rest of the workflow. Using the [Rule Engine](https://knowledge.leegality.com/document-execution/workflows/v4/rule-engine/overview), you can link a field on the Custom Page to fields on the **Create**, **Invite**, or **Template** stages. When the runner enters a value on the Custom Page, the rules carry it to every linked field.

For example, a runner enters a **Consideration Price** once on the Custom Page, and rules use it to fill:

- the consideration amount in the template,
- the stamp value, worked out from the price and the state's stamp duty percentage,
- the payment amount.

This works for template fields, payment amounts, stamp values, and document-level or invitee-level custom fields. To see how a rule like this is built, see [Calculate a field value](https://knowledge.leegality.com/document-execution/workflows/v4/rule-engine/how-to/calculate-a-field-value).



## Step 6: Preview the Page

1. Click **Preview** in the top-right corner of the page. The page appears exactly as the runner will see it.
2. Close the preview and make any changes you need.
3. Click **Proceed**.

> **Warning — An empty Custom Page blocks publishing**
>
> A workflow can't be published while its Custom Page is empty. Add at least one field or element, or delete the Custom Page (see [Rename or delete a Custom Page](#rename-or-delete-a-custom-page)).

## Send Documents in One Step

If the Custom Page collects everything the pack needs, you can hide the other stages. The runner then sees only the Custom Page: they fill it in and click **Send**.

To set up one-step sending:

1. In the **left panel** of the workflow editor, click the **Visualisation** icon.
2. On each of the **Create**, **Invite**, **Template**, and **Finalise** cards, click the **View/Hide** (eye) icon. The icon changes to show the stage is hidden.
3. Click **Save**.

> **Caution — Check hidden stages before you publish**
>
> The runner can't fill in anything on a hidden stage. Every **mandatory** field on a hidden stage must get its value another way: from a default value set in the workflow, or from a rule linked to the Custom Page.
> 
>     **Leegality does not check this for you.** Run the workflow end to end before you share it with runners.



For more on hiding and renaming stages, see [Visualisation](https://knowledge.leegality.com/document-execution/workflows/v4/setup-configuration/visualisation).

## Rename or Delete a Custom Page

Once added, the Custom Page appears as a card at the top of the **Visualisation** panel, with its own controls:

- **Rename:** Click the **Edit** (pencil) icon, enter the new name, and click **Save**. This is the name the runner sees in the stepper, so choose something that describes the page, such as *Loan Details*.
- **Delete:** Click the **Delete** (bin) icon. This removes the Custom Page and everything on it from the workflow.



## Frequently Asked Questions

**Does a Custom Page change what signers see?**

> No. The Custom Page is only part of the **sending** journey, which the workflow runner goes through. Invitees go through the signing journey as usual.

**Can the details entered on a Custom Page be changed after the pack is sent?**

> Yes. Values entered on the Custom Page are saved as pack-level custom fields on the pack. You can change them later through **Pack Edit**, and any rules linked to those fields run again with the new value.
> 
> 

**Why can't I add a document-level or invitee-level custom field to the Custom Page?**

> A Custom Page holds one value per field for the whole pack, so only **pack-level** custom fields can be placed on it. To fill a document-level or invitee-level field from the Custom Page, add a pack-level field to the page and [link it with a rule](#step-5-link-fields-with-rules).

**Can a workflow have more than one Custom Page?**

> No. Each workflow can have only one Custom Page.

## Next Steps

- [Visualisation](https://knowledge.leegality.com/document-execution/workflows/v4/setup-configuration/visualisation): hide or rename the other stages of the workflow.
- [Rule Engine](https://knowledge.leegality.com/document-execution/workflows/v4/rule-engine/overview): build the rules that carry Custom Page values across the workflow.
- [Run a pack](https://knowledge.leegality.com/document-execution/workflows/v4/run-a-pack): see the sending journey from the runner's side.

---

URL: https://knowledge.leegality.com/document-execution/workflows/v4/setup-configuration/field-configuration

# Control Input Format 

A **validation** controls the **format** of what is entered into a field in a v4 workflow — using character limits and a **Regex** (regular expression) pattern. For example, you can enforce a PAN pattern on the Internal Reference Number so that only correctly formatted values are accepted.

## What you can set

For each field, you can set a:

- **Minimum character limit**
- **Maximum character limit**
- **Regex** — a pattern the entered value must match.

## Add a validation

1. Right-click any field to open the pop-up.
2. Go to the **Validations** tab.
3. Enter the **Minimum character limit**, **Maximum character limit**, and **Regex** as needed.
4. Click **Apply**.

> **Info — Note**
>
> A validation applies to every field of that type across the workflow. For example, if you set a validation on the **Document Name** field, it applies to all Document Name fields in the workflow.

**What's the difference between a validation and making a field Mandatory?**

> **Mandatory** (a [Field Property](https://knowledge.leegality.com/document-execution/workflows/v4/setup-configuration/field-properties)) controls *whether* a field must be filled before proceeding. A **validation** controls the *format* of what is entered — and only runs if a value has been entered. For example, a **Minimum character limit** of more than 0 does **not** force the field to be filled; if the field is left blank, the validation is skipped and no error is raised.
> 
> A field can use both: **Mandatory** so it can't be skipped, and a **validation** so the value, once entered, matches the required format. Don't use a minimum character limit as a substitute for Mandatory — it won't have the intended effect on empty fields.

---

URL: https://knowledge.leegality.com/document-execution/workflows/v4/setup-configuration/field-properties-faq

# Field Properties FAQ
## Create stage: what you can open up or lock

**Can the workflow runner add more primary documents?**

> - By default, **+ Add Document** is **invisible** and **non-editable** — the runner sends exactly the documents you set up.
> - To let the runner add their own, make it **visible** and **editable**.

**How do I let the workflow runner add files other than the ones I've uploaded?**

> - By default, the runner only fills the PDF placeholders you set up — no extras.
> - To let them add their own files, make the **Upload PDF** box **visible** and **editable**.
> - To lock the pack to exactly your files, leave it **non-editable**.

**Can I pre-fill a document detail but still let the runner change it?**

> Yes. Each of the document detail fields (Document Name, Internal Reference Number, Document Folder, Reference Attachment) carries its own properties:
> 
> - Pre-fill + keep **editable** — the runner can adjust your value.
> - Pre-fill + turn **Editability** off — the runner sees your value but cannot change it.
> - Turn **Visibility** off — the runner does not see the field at all.

**Can I show a custom field on only some documents of a pack?**

> Yes. Properties are set per field, per document — turn the field's **Visibility** off on the documents where it isn't needed and leave it on where it is.

**Can the workflow runner change the pack details?**

> Only if you leave them open. Pack detail fields carry **Visibility** and **Editability** controls (no Mandatory):
> 
> - Pre-fill + turn **Editability** off — locks the value for every run.
> - Turn **Visibility** off — hides the field from the runner.

**How do I let the runner decide the stamp values at send time?**

> - Set the stamping type and turn **Attach Stamping** on.
> - Leave the value fields (**Quantity**, **Amount**) editable — the runner fills in the value that fits each send.
> - To apply the same stamping to every run instead, enter the values here; they carry over automatically.

## Invite stage: what you can open up or lock

**Which properties can I set on the invitee card?**

> - The **detail fields** (Name, Email Address, Phone Number) carry all three properties:
>     - **Mandatory** — the runner must fill the field before proceeding.
>     - **Non-editable** — the runner sees your value but cannot change it.
>     - **Invisible** — the runner does not see the field.
> - The **role dropdown** (Signer, Reviewer, Group Signer, Group Reviewer) carries **Visibility** and **Editability** only:
>     - **Non-editable** — the runner cannot change the role you set.
>     - **Invisible** — the runner does not see the role selector.

**Can the runner change the signing order?**

> The **Set signing order** and **Lock signing order** toggles carry **Visibility** and **Editability** controls only:
> 
> - Keep them **visible** and **editable** — the runner can configure the signing order while running.
> - Make them **non-editable** — your setting is enforced on every run.
> - Make them **invisible** — the runner does not see the toggles.

**Can the workflow runner change the invitee settings?**

> That depends on how you configure each setting. For example, an eSign type you have enabled (such as Aadhaar eSign) can be:
> 
> - **Visible + non-editable** *(default)* — the runner sees the eSign type but cannot change it.
> - **Visible + editable** — the runner sees the eSign type, can disable the toggle, and can change the authentication types, if any.
> - **Invisible** — the runner does not see the eSign type at all.
> 
> The settings checkpoints themselves (eSign Types, eSign Prioritisation, Signature Appearance, and so on) carry only **Visibility** and **Editability** controls — there is no Mandatory state.

## How fields behave while running a workflow

As the workflow runner, you fill in only what the creator left open:

- **Non-editable field:** You see the value the creator has set but cannot edit it.
- **Invisible field:** You won't see the field at all.
- **Mandatory field:** You must enter a value in it and cannot proceed otherwise.

**Why can't I edit a field?**

> The workflow creator marked that field as **non-editable**, so its value is pre-filled and locked — you can see it but cannot change it. This is intentional. If the value needs to change, contact the person who created the workflow.

**A field I expected isn't showing. Why?**

> If the creator turned a field's **Visibility** off, it does not appear while you run the workflow. Hidden fields are set up that way deliberately, so you don't need to fill them.

**Why won't the workflow let me proceed?**

> A **mandatory** field is most likely still empty — fields the creator marked mandatory must be filled before you can move to the next stage. Check for any required field that is still blank. Also make sure your entries meet any [validations](https://knowledge.leegality.com/document-execution/workflows/v4/setup-configuration/field-configuration) set on the field, such as character limits or a required format.

**Can I change a value the creator has locked?**

> No. Values on non-editable fields are fixed by the workflow creator and cannot be changed while running the workflow. You can only edit the fields the creator left **visible** and **editable**.

## FAQs

**What's the difference between turning off Visibility and turning off Editability?**

> They hide different things. Turning **Editability** off keeps the field **visible** — the runner sees the value you entered but cannot change it. Turning **Visibility** off removes the field from the runner's view entirely, so they don't see the field or its value at all. Use **non-editable** to show a locked value, and **invisible** to hide a field the runner doesn't need.

**Why don't toggles and checkboxes have a Mandatory option?**

> Because they can never be empty. A toggle or checkbox always holds one of two values — on or off — so there is nothing for **Mandatory** to enforce. Mandatory applies only to input fields, where the runner could otherwise proceed without entering a value. Toggles and checkboxes carry the other two properties: use **Visibility** to show or hide the option, and **Editability** to fix its state so the runner cannot change it.

**Can I set more than one property on the same field?**

> Yes. The properties are independent, so you can combine them on a single field. Common combinations are **Mandatory + Editable** (the runner must enter a value before proceeding) and **Visible + non-Editable** (the runner sees a pre-filled value but cannot change it). Set each property separately using its icon or the right-click pop-up.

**Do these properties apply while running the workflow, or only while creating it?**

> Both. The property icons appear on fields **throughout the workflow, during both creation and running**. As the creator, you set them to shape what the runner sees; the runner then works within those settings and can adjust only the fields you left **visible** and **editable**.

**What's the difference between making a field Mandatory and adding a Validation?**

> **Mandatory** controls *whether* a field must be filled before the runner can proceed. A **validation** controls the *format* of what is entered — the minimum and maximum character limits and a regex pattern. A field can use both: mandatory so it can't be skipped, and validated so the value entered matches the required format (for example, a PAN pattern). See [Validations](https://knowledge.leegality.com/document-execution/workflows/v4/setup-configuration/field-configuration).

**If I make a field Mandatory, should I also keep it Editable?**

> Usually yes. If a mandatory field is **non-editable** and you haven't pre-filled a value, the runner can neither enter a value nor proceed. Keep **Editability** on so the runner can fill it. If the value is fixed, enter it yourself before locking the field.
> 
> 

**Can the Rule Engine change a property I've set here?**

> Yes. The properties you set on a field are its fixed, default state. The [Rule Engine](https://knowledge.leegality.com/document-execution/workflows/v4/rule-engine/overview) can change a field's **Visibility**, **Editability**, or **Mandatory** state dynamically, based on the data entered while the workflow runs — for example, making a field mandatory only when another field's value crosses a threshold.
> 
> 

---

URL: https://knowledge.leegality.com/document-execution/workflows/v4/setup-configuration/field-properties

# Control Field Behaviour

**Field Properties** are per-field controls that decide how every field and option in a v4 workflow behaves — whether it is shown, whether it can be changed, and whether it must be filled. **Every field and option is configurable individually**: the same workflow can hide an irrelevant field, lock a pre-filled value, and force a critical detail to be completed before the document moves on.

Field Properties are available during **both workflow creation and running**. The workflow creator sets properties to define how each field behaves on every run — this is what makes one workflow reusable across many different sends. The workflow runner then works within those properties, and can also set properties on the fields left open while preparing the send.



Each field carries up to three properties.

## Visibility

Visibility controls whether a field is shown at all. Use it to keep the journey clean — internal fields, unused settings, or details that only matter for certain documents can be hidden so they never distract from what actually needs attention. Because visibility is set per field and per document, the same field can be shown in one document of a pack and hidden in another.

- **Visibility on** — the field appears in the journey.
- **Visibility off** — the field is hidden and does not appear at all.

> **Info — Visibility is a UI-only property**
>
> Visibility only controls what the workflow runner **sees on screen** — it does not block the field at the API level. Even with Visibility off, a value can still be passed into that field via the API. If the requirement is to stop the workflow runner from supplying a value to the field at runtime (not just hide it from view), also turn **Editability** off.

## Editability

Editability controls whether a field's value can be changed. It is how you separate what is fixed from what is open: pre-fill a value and turn Editability off, and that value stays the same on every run; leave it editable, and the value can be adjusted each time. A non-editable field stays visible — its value is seen, but protected.

- **Editability on** — the value can be entered or changed freely.
- **Editability off** — the field shows its value, but the value cannot be changed.

## Mandatory

Mandatory controls whether a field must be filled before proceeding. Turn it on for information that must never be missed — an Employee ID, a loan reference, a contact detail — and the journey cannot move to the next stage while the field is empty. Mandatory ensures a value *exists*; to control the *format* of that value, pair it with a [validation](https://knowledge.leegality.com/document-execution/workflows/v4/setup-configuration/field-configuration).

- **Mandatory on** — the field must be filled before proceeding to the next stage.
- **Mandatory off** — the field is optional and can be left blank.

> **Info — Toggles and checkboxes don't carry Mandatory**
>
> A toggle or checkbox always holds a value — on or off — so there is never an empty state for Mandatory to enforce. These elements carry only Visibility and Editability. See [Which elements carry which properties](#which-elements-carry-which-properties) below.

A field left **visible** and **editable** is fully open — it can be filled or adjusted freely on every run.

## Set a field property

Every field shows an icon for each property it carries — up to three, for Visibility, Editability, and Mandatory — when you hover over it.

1. Hover over the field.
2. Click the icon for the property you want to change to enable or disable it.

The change applies to that field only, so every field can be configured differently.

You can also **right-click a field** to open a pop-up listing these properties — check or uncheck the respective boxes to enable or disable each one.

> **Tip**
>
> The same right-click pop-up includes a **Validations** tab for setting character limits and regex on a field. See [Validations](https://knowledge.leegality.com/document-execution/workflows/v4/setup-configuration/field-configuration).



## Which elements carry which properties

Only **text fields** and **custom fields** carry all three properties:

- **Text fields** — such as the document details (Document Name, Internal Reference Number) and the invitee details (Name, Email Address, Phone Number) — carry **Visibility**, **Editability**, and **Mandatory**.
- **Custom fields** you add to a workflow also carry all three.

Every other element carries only **Visibility** and **Editability** — there is no Mandatory state. This includes:

- Toggles and checkboxes.
- Upload boxes.
- Selection dropdowns, such as the invitee role (Signer, Reviewer, Group Signer, Group Reviewer).
- Checkpoints (Parent)-Eg; **Pack Details** in Create Stage, Settings checkpoints in Invite stage.

A toggle or checkbox always holds a value — on or off — so there is never an empty state for **Mandatory** to enforce.

Defaults also vary by element. For example, an enabled eSign type defaults to **visible + non-editable**, while the **+ Add Document** option defaults to **invisible + non-editable**.

> **Info — Pack Details**
>
> **Pack Name**, **Pack Internal Reference Number**, and **Pack Folder** are text fields, so — like any other text field — they carry all three properties, including Mandatory. It's the **Pack Details** checkpoint itself (the parent) that carries only Visibility and Editability, per the [parent and child rules](#parent-and-child-fields) below.

## Parent and child fields

Fields in a v4 workflow are **nested**. An element that contains other elements is a **parent**, and everything under it is its **child**. For example, the **Settings** tab as a whole is a parent — every setting inside it is its child.

Two rules govern how properties work across this hierarchy:

- **Properties are inherited.** A property set on a parent automatically applies to all of its children. Make the **Settings** tab **non-editable**, and every setting under it becomes non-editable too.
- **A child cannot contradict its parent.** If you manually change a child's property so it conflicts with the parent — for example, making one setting **editable** while the Settings tab is **non-editable** — an **error** appears when you try to proceed.

> **Tip — Example**
>
> You make the **Settings** tab non-editable. Everything under it is automatically non-editable — no need to lock each setting individually. If you then switch one child setting back to editable and try to proceed, the workflow shows an error, because the child now contradicts its parent.

To open up a single child, set the parent so it doesn't conflict — for example, keep the parent **editable** and lock the other children individually instead.



## Change properties dynamically

The properties set on a field are its fixed, default state. To change them based on the data entered while the workflow runs — for example, making a field mandatory only when a Loan Amount crosses a threshold — use the [Rule Engine](https://knowledge.leegality.com/document-execution/workflows/v4/rule-engine/overview).

## Common use cases

| Goal | Do this |
| --- | --- |
| Keep a fixed value on every run — a standard folder, clause reference, or internal reference number | Pre-fill the value, then turn **Editability** off |
| Pre-fill a suggested value that can still be adjusted | Pre-fill the value and leave the field **editable** |
| Hide internal fields that aren't needed in the journey | Turn **Visibility** off |
| Show a custom field on only some documents of a pack | Turn its **Visibility** off on the other documents — properties are set per field, per document |
| Guarantee a critical detail (such as an Employee ID) is always captured | Turn **Mandatory** on and keep the field **editable** |
| Let stamp values (such as **Quantity** or **Amount**) be decided per send | Configure the stamping, but leave the value fields **editable** |
| Allow extra documents or files to be added while running | Make **+ Add Document** or the **Upload PDF** box **visible** and **editable** |

---

URL: https://knowledge.leegality.com/document-execution/workflows/v4/setup-configuration/visualisation

# Visualisation

Visualisation, available in the **left panel** of the workflow editor, lets you control which stages of the workflow the runner sees and interacts with while creating a workflow.

The workflow stages appear as a list:

- **Create**
- **Invite**
- **Template** (appears only if the workflow document has a template file uploaded)
- **Finalise**

Each stage has two controls: **View / Hide** and **Edit**.

> **Tip — Add a Custom Page**
>
> Visualisation is also where you add a **Custom Page**, a sender-facing page you design yourself that appears before **Create**. Together with hidden stages, it lets the runner send a pack from a single screen. See [Custom Page](https://knowledge.leegality.com/document-execution/workflows/v4/setup-configuration/custom-page).

## View / Hide

Click **View/Hide** icon to hide a stage when the runner does not need to see it, so they can proceed directly to the next stage.

For example, suppose the **Finalise** stage only handles coordinate placement and you have already set that up. You can hide the stage so the runner proceeds without having to go through it.

## Edit

Click **Edit** to rename a stage. This customises the workflow so the runner sees only the name you set.

1. Click **Edit** on the stage.
2. Enter the new name in the field.
3. Click **Save**.

Once you have customised the stages, click **Save** to apply the changes.

---

URL: https://knowledge.leegality.com/document-execution/workflows/v4/understanding-v4/distributed-stamping

# Distributed stamping

v4 allows you to attach stamps to each sub-document within a primary document. This guide explains distributed stamping.

## What is distributed stamping?

Distributed stamping lets you attach a stamp before each sub-document within a primary document, instead of placing one stamp at the beginning for all sub-documents combined.

**Example:** Primary Document A has 3 sub-documents. With distributed stamping, you attach a stamp at the beginning of each sub-document, distributing stamps throughout the primary document such that the serial number and ID of the stamp will only be affixed on its corresponding sub-document, thus mapping the stamp with the sub-document.

If you have multiple primary documents in a pack, you can independently configure distributed stamping for each primary document.

## Stamping options

- **Stamps for merged document**: Places all stamps at the beginning, followed by all combined sub-documents in a primary document.

- **Separate stamps for sub-documents** (Distributed stamping): Places a dedicated stamp before each sub-document within a primary document. This is distributed stamping.

## Configuring stamping

When creating primary documents in the Create step:

1. Enable **Attach Stamping** for the primary document
2. Choose stamping option:
   - **Stamps for merged document:** One stamp for all sub-documents combined
   - **Separate stamps for sub-documents:** Distributed stamping - one stamp before each sub-document
3. Each primary document can have a different stamping configuration

> **Info — Flexibility per run**
>
> You can enable or disable stamping each time you run the workflow, if allowed by the workflow creator. This allows you to handle situations where stamps are sometimes required and sometimes not.

---

URL: https://knowledge.leegality.com/document-execution/workflows/v4/understanding-v4/document-assignment

# Document assignment

v4 allows you to assign specific primary documents to each invitee. This guide explains selective document assignment.

## What is document assignment?

Document assignment lets you control which documents each invitee receives from your document pack. Instead of sending all documents to everyone, you selectively assign specific primary documents to each invitee.

**How it works:**
- You create a document pack with multiple primary documents
- You add invitees
- For each invitee, you choose which primary documents they should receive and in what order
- Each invitee previews and signs/reviews only their assigned documents

**Example:**
A loan document pack contains Loan Agreement and Property Documents. You assign both documents to the Borrower, but only the Loan Agreement to the Guarantor. The Guarantor never sees the Property Documents.

> **Info — Key point**
>
> You assign **primary documents**, not sub-documents. All sub-documents within a primary document go together.

## How to assign documents

When configuring invitees in the Invite step:

1. Click **Assign Documents** on the invitee card
2. Select which primary documents this invitee should receive
3. Each invitee must be assigned at least one primary document

> **Info — Selection order is viewing order**
>
> When an invitee is assigned multiple documents, they view the documents in the order you selected them — the first document you select appears first in their signing journey.

## Assignment example

![Assignment example: a Document Pack containing a Loan Agreement and Property Documents, assigned so the Borrower signs both, the Guarantor signs the Loan Agreement, and the Bank Officer reviews the Property Documents](https://knowledge.leegality.com/img/document-assignment-diagram.svg)

**What each person sees:**
- Borrower: "You have 2 documents to sign"
- Guarantor: "You have 1 document to sign"
- Bank officer: "You have 1 document to review"

> **Info — What invitees see**
>
> Invitees see only their assigned documents in the signing interface and notifications. They don't see other documents in the pack.

---

URL: https://knowledge.leegality.com/document-execution/workflows/v4/understanding-v4/packs-and-documents

# Packs and documents

v4 workflows organize documents in a three-level hierarchy. This guide explains the structure.

## Document hierarchy

![Document hierarchy: a Document Pack contains three Primary Documents, each made up of one or more Sub-documents](https://knowledge.leegality.com/img/document-hierarchy-diagram.svg)

### Sub-documents

**Individual PDF files** you upload when running a workflow.

- The basic building blocks
- Can be any PDF document
- Combined to form primary documents

**Example:** loan_terms.pdf, repayment_schedule.pdf, property_details.pdf

### Primary documents

**One or more sub-documents** that function as a single document.

- Each primary document is signed independently
- Has its own audit trail
- Generates its own signed copy
- Can be assigned selectively to invitees

**Example:** Loan Agreement (primary document) = loan_terms.pdf + repayment_schedule.pdf

### Document pack

**Collection of all primary documents** sent together in one workflow run.

- Contains one or more primary documents
- Sent to invitees in a single action
- Enables unified signing journey
- Tracked as one pack with individual document status

## How it works

### Each primary document signed independently

Invitees sign each primary document separately:
- Loan Agreement → Signed once (covers all sub-documents)
- Property Documents → Signed once
- Insurance Policy → Signed once

Each primary document has:
- Own audit trail
- Own signature coordinates
- Own completion status
- Own signed PDF

### One signing session for all

While primary documents are signed separately, invitees complete everything **in one session**.

## Key points

> **Info — Important concepts**
>
> **Sub-documents:**
> - You upload these PDF files
> - Multiple sub-documents can form one primary document
> - Signers don't see sub-document boundaries—they see one combined primary document
> 
> **Primary documents:**
> - This is what gets signed
> - Each has independent audit trail
> - You can assign different primary documents to different invitees
> 
> **Document pack:**
> - All primary documents together
> - One sending action
> - Unified tracking

---

URL: https://knowledge.leegality.com/document-execution/workflows/v4/v4-templates

# v4 Templates

A template is a reusable document layout — with pre-placed fields and formatting — that saves you from setting up the same document every time. In v4, you create templates in the **Templates V4** area and then add them to a primary document while building a workflow or creating a new document.

> **Caution — v4 templates are separate from existing templates**
>
> Templates created for current (v3) workflows cannot be used in v4, and v4 templates cannot be used in current workflows. To use a template in v4, create it in the **Templates V4** tab.

## Create a v4 template

1. Go to the **Templates** section using the left panel.
2. Open the **Templates V4** tab.
3. Click **+ Create** to create a new template.
4. Enter a **Template name**.
5. Choose an editor:
    - [**PDF Editor**](https://knowledge.leegality.com/document-execution/template/pdf-editor/create-a-pdf-template) — start with an existing PDF file and add dynamic fields on top of it.
    - [**Text Editor**](https://knowledge.leegality.com/document-execution/template/html-template/) — start with a blank document in Leegality's HTML-based template engine.
6. Click **Proceed**.

The selected editor opens, where you can lay out the template and add fields.

## Use a v4 template

Once created, a template can be added to a primary document in two places:

- **In a workflow:** While configuring a primary document in the **Create** stage, click **Add Template** and select the template you want. For the full flow, see [Create a v4 workflow](https://knowledge.leegality.com/document-execution/workflows/v4/create-a-workflow#step-2-prepare-your-documents).
- **In a one-off document:** Add the template while preparing the document in the New Document journey. See [New Document](https://knowledge.leegality.com/document-execution/workflows/v4/new-document).

---

URL: https://knowledge.leegality.com/document-execution/workflows/v4/what-you-can-control

# What you can control as a runner

As a workflow runner, you configure the workflow each time you run it. This guide explains what you control when running v4 workflows.

## What you control when running a workflow

### Document pack creation

**Primary documents:**
- Add multiple primary documents using **+ Add Document**
- Upload sub-documents (PDF files) for each primary document
- Arrange sub-document order within each primary document
- Name each primary document
- Set internal reference numbers

**Pack configuration:**
- Pack name
- Pack internal reference number
- Folder selection
- Auto-delete time interval
- SFTP profile for signed documents

### Stamping configuration

**Per primary document:**
- Enable or disable stamping
- Choose stamping option:
  - Stamps for merged document
  - Separate stamps for sub-documents

Different primary documents can have different stamping configurations in the same pack.

### Invitee configuration

**Add and configure invitees:**
- Add signers, reviewers, group signers, group reviewers
- Add CC invitees
- Enter name, email, and phone number for each
- Set signing order (drag to reorder)
- Lock signing order to enforce sequence

**Invitee-level settings:**
- eSign type selection
- Security settings (authentication, GPS, photo capture)
- Notification preferences
- Custom consent messages
- Signing retry attempts
- Other invitee-specific options

### Document assignment

**Assign primary documents to invitees:**
- Choose which primary documents each invitee receives
- Each invitee must be assigned at least one primary document
- Maintain privacy through selective assignment

**Example:**
- Borrower: Receives Loan Agreement and Property Documents
- Guarantor: Receives only Loan Agreement
- Bank Officer: Receives only Property Documents (CC)

### Signature coordinate placement

**Set coordinates per invitee:**
- Place signature coordinates on documents
- Customize location for each invitee's signature
- Copy coordinates to other pages:
  - All pages within current sub-document
  - All pages across all sub-documents in primary document

### Reference attachments

**Add supporting documents:**
- Enable reference attachments per primary document
- Upload reference files for invitees
- Provide context and supporting information

## What the workflow creator configures

The workflow creator—your own admin or Leegality's team—may define:

**Workflow structure:**
- Basic workflow configuration
- Default settings and preferences
- Standard invitee role templates

**Note:** The level of pre-configuration varies by workflow. Many v4 workflows give you full flexibility to configure settings at runtime.

## Running the same workflow multiple times

Each time you run a v4 workflow:

**You configure fresh:**
- Upload new sub-documents
- Add specific invitees with their contact details
- Assign documents per run
- Set signature coordinates for this instance
- Configure stamping as needed

**Workflow saves time by:**
- Providing consistent structure
- Maintaining standard configurations
- Reducing setup steps
- Ensuring compliance with business rules

## Common questions

**Can I save a partially configured pack?**
- The system may support draft saving during configuration
- Check for "Save as Draft" option during the process

**Can I modify after sending?**
- No, once sent, the pack cannot be modified
- You would need to create a new workflow run

**Can I reuse invitee information?**
- You enter invitee details fresh each run
- Consider maintaining invitee lists externally for quick reference

**Can I change the workflow structure?**
- If your admin users created the workflow, an admin can edit it directly in your account
- For Leegality-built (rule-based) workflows, contact Leegality to request structural changes
- Runtime configuration happens within the workflow framework

**What if I need different stamping each time?**
- v4 allows you to configure stamping per run
- Enable or disable stamps as needed
- Choose merged or separate stamps per primary document

---

# Changelog

URL: https://knowledge.leegality.com/whats-new



---

URL: https://knowledge.leegality.com/document-execution/api/docsigner-esign

# POST /v4/packs/docsign — DocSigner eSign

:::info[Sandbox endpoint]

**Authentication:** `X-Auth-Token` header required on every request.

## Request URL

```
POST https://app1.leegality.com/api/v4/packs/docsign
```

**Environments:**
- Production: `https://app1.leegality.com/api/v4/packs/docsign`
- Sandbox: `https://sandbox.leegality.com/api/v4/packs/docsign`

---

## Request Body

**Content-Type:** `application/json`

| Field | Type | Required | Description | Example |
|-------|------|----------|-------------|---------|
| `signUrl` | string | Yes | Sign URL of the invitation to sign — the invitation URL from [Check Pack Details](https://knowledge.leegality.com/document-execution/api/check-pack-details) (`invitations[].inviteeDetails[].invitationUrl`). The invitation must be configured for DocSigner signing. | `https://app1.leegality.com/sign/a1b2c3d4-e5f6-7890-abcd-ef12` |
| `profileId` | string | Yes | DocSigner profile ID from the Leegality dashboard. The profile must belong to your account. | `01KT8RH0AUTOMATEDSIGNPROF99` |
| `consent` | string | No | Consent text recorded with the signature. | `I agree` |

### Sample Request

```json
{
  "signUrl": "https://app1.leegality.com/sign/a1b2c3d4-e5f6-7890-abcd-ef1234567890",
  "profileId": "01KT8RH0AUTOMATEDSIGNPROF99",
  "consent": "I agree"
}
```

---

## Responses

### 200 — Invitation signed.

**Error codes**

The request is rejected if any of the following applies:

| Scenario | Error code |
| --- | --- |
| No invitation found for this `signUrl` | `LE_ERR_AP_016` |
| Missing or blank `profileId` | `LE_ERR_AP_031` |
| Invitation is not configured for DocSigner | `LE_ERR_AP_032` |
| Invitation has already been signed | `LE_ERR_AP_033` |
| Invitation has been rejected | `LE_ERR_AP_034` |
| Invitation is not active yet (earlier signers in the signing order haven't finished) | `LE_ERR_AP_035` |
| DocSigner profile not found or not owned by your account | `LE_ERR_AP_036` |
| Another signing request for this invitation is in progress — retry shortly | `LE_ERR_AP_037` |
| Missing or malformed body / blank `signUrl` | `LE_ERR_AP_059` |
| Expired token (401) | `LE_ERR_AP_080` |
| Missing token (403) | `LE_ERR_AP_081` |

| Field | Type | Required | Description | Example |
|-------|------|----------|-------------|---------|
| `data` | object | No | Response payload. See **data** below. | — |

#### data

Response payload.

| Field | Type | Required | Description | Example |
|-------|------|----------|-------------|---------|
| `signUrl` | string | No | The invitation's sign URL that was signed. | `https://app1.leegality.com/sign/AbCdEf123456` |
| `submittedAt` | string | No | When the signature was submitted. | `2026-06-05T16:00:00Z` |
| `documentStatus` | string | No | The document's signing status after this call. | `SIGNED` |
| `combinationResults` | array\ | No | Per-combination signing outcome. Present only when the pack has multiple combinations — one entry per combination. See **combinationResults** below. | — |

##### combinationResults

| Field | Type | Required | Description | Example |
|-------|------|----------|-------------|---------|
| `combinationUuid` | string | No | Identifier of the combination. | `6f1c2a8e-9b3d-4f2a-8a1c-2b7e0d4f9a11` |
| `status` | string | No | Signing outcome for this combination. Possible values: - `SIGNED` — signed successfully. - `ALREADY_SIGNED` — the combination was already signed. - `FAILED` — signing failed; see `errorMessage`. Allowed: `SIGNED`, `ALREADY_SIGNED`, `FAILED`. | `SIGNED` |
| `errorMessage` | string | No | Reason for failure. Present only when `status` is `FAILED`. | `null` |

### Sample Response (200)

```json
{
  "data": {
    "signUrl": "https://app1.leegality.com/sign/AbCdEf123456",
    "submittedAt": "2026-06-05T16:00:00Z",
    "documentStatus": "SIGNED",
    "combinationResults": [
      {
        "combinationUuid": "6f1c2a8e-9b3d-4f2a-8a1c-2b7e0d4f9a11",
        "status": "SIGNED",
        "errorMessage": null
      }
    ]
  }
}
```