Update description for Update Contact by Email API in opensign.yaml

Patch 75

docs/docs/API-docs/intro.md

@@ -7,3 +7,4 @@ sidebar_label: Overview
 Welcome to the OpenSign API. Choose a version from the sidebar:
 - **v1** — stable baseline
 - **v1.1** — latest additions, backward-compatible with v1
+- **v1.2** — password protected pdf support, offline signing, signer roles, backward-compatible with v1.1

docs/docs/API-docs/v1.1/opensign.yaml

@@ -225,6 +225,55 @@ paths:
                 $ref: '#/components/schemas/invalidtoken'
       security:
       - x-api-token: []
+    put:
+      tags:
+      - Contacts
+      summary: Update Contact
+      description: The Update Contact API enables you to modify and update the details of a specific Contact.
+      operationId: updateContact
+      parameters:
+      - name: contact_id
+        in: path
+        description: objectId of contact
+        required: true
+        style: simple
+        explode: false
+        schema:
+          type: string
+          format: string
+      requestBody:
+        description: Provide the fields you wish to update. Any fields omitted from the request will remain unchanged.
+        content:
+          application/json:
+            schema:
+              $ref: '#/components/schemas/updatecontact_body'
+      responses:
+        "200":
+          description: Contact updated successfully!
+          content:
+            application/json:
+              schema:
+                $ref: '#/components/schemas/inline_response_200_14'
+        "400":
+          description: Please provide valid field names!
+          content:
+            application/json:
+              schema:
+                $ref: '#/components/schemas/inline_response_400'
+        "404":
+          description: Contact not found!
+          content:
+            application/json:
+              schema:
+                $ref: '#/components/schemas/inline_response_404_7'
+        "405":
+          description: Invalid API Token!
+          content:
+            application/json:
+              schema:
+                $ref: '#/components/schemas/invalidtoken'
+      security:
+      - x-api-token: []  
     delete:
       tags:
       - Contacts
@@ -269,6 +318,57 @@ paths:
                 $ref: '#/components/schemas/invalidtoken'
       security:
       - x-api-token: []
+  /contact-by-email/{email}:
+    put:
+      tags:
+      - Contacts
+      summary: Update Contact by Email
+      description: The Update Contact by Email API enables you to modify and update the details of a specific Contact using their email address as the identifier.
+      operationId: updateContactByEmail
+      parameters:
+      - name: email
+        in: path
+        description: Email address of the contact
+        required: true
+        style: simple
+        explode: false
+        schema:
+          type: string
+          format: string
+          example: joebee@example.com
+      requestBody:
+        description: Provide the fields you wish to update. Any fields omitted from the request will remain unchanged.
+        content:
+          application/json:
+            schema:
+              $ref: '#/components/schemas/updatecontactbyemail_body'
+      responses:
+        "200":
+          description: Contact updated successfully!
+          content:
+            application/json:
+              schema:
+                $ref: '#/components/schemas/inline_response_200_14'
+        "400":
+          description: Please provide valid field names!
+          content:
+            application/json:
+              schema:
+                $ref: '#/components/schemas/inline_response_400'
+        "404":
+          description: Contact not found!
+          content:
+            application/json:
+              schema:
+                $ref: '#/components/schemas/inline_response_404_7'
+        "405":
+          description: Invalid API Token!
+          content:
+            application/json:
+              schema:
+                $ref: '#/components/schemas/invalidtoken'
+      security:
+      - x-api-token: []
   /contactlist:
     get:
       tags:
@@ -2359,6 +2459,52 @@ paths:
                 $ref: '#/components/schemas/invalidtoken'
       security:
       - x-api-token: []
+  /signinglinks/{document_id}:
+    get:
+      tags:
+      - Documents
+      summary: Get Signing Links
+      description: |
+        The Get Signing Links API enables you to retrieve signing urls of signers for the document.
+      operationId: getsigninglinks
+      parameters:
+      - name: document_id
+        in: path
+        description: objectId of Document
+        required: true
+        style: simple
+        explode: false
+        schema:
+          type: string
+          format: string
+          example: aB2cc2hpbh
+      responses:
+        "200":
+          description: successful operation
+          content:
+            application/json:
+              schema:
+                $ref: '#/components/schemas/getsigninglinks'
+        "400":
+          description: "Something went wrong, please try again later!"
+          content:
+            application/json:
+              schema:
+                $ref: '#/components/schemas/inline_response_400_1'
+        "404":
+          description: Document not found!
+          content:
+            application/json:
+              schema:
+                $ref: '#/components/schemas/inline_response_404_3'
+        "405":
+          description: Invalid API Token!
+          content:
+            application/json:
+              schema:
+                $ref: '#/components/schemas/invalidtoken'
+      security:
+      - x-api-token: []
   /drafttemplate:
     post:
       tags:
@@ -5256,6 +5402,52 @@ components:
           $ref: '#/components/schemas/date'
       xml:
         name: contactdetails
+    updatecontact_body:
+      type: object
+      properties:
+        name:
+          type: string
+          format: string
+          example: joe bee
+        email:
+          type: string
+          format: string
+          example: joebee@example.com
+        phone:
+          type: string
+          format: string
+          example: "4131231231"
+        company:
+          type: string
+          format: string
+          example: opensign
+        job_title:
+          type: string
+          format: string
+          example: dev
+      xml:
+        name: contactdetails 
+    updatecontactbyemail_body:
+      type: object
+      properties:
+        name:
+          type: string
+          format: string
+          example: joe bee
+        phone:
+          type: string
+          format: string
+          example: "4131231231"
+        company:
+          type: string
+          format: string
+          example: opensign
+        job_title:
+          type: string
+          format: string
+          example: dev
+      xml:
+        name: contactdetails 
     folder:
       type: object
       properties:
@@ -5437,6 +5629,17 @@ components:
       xml:
         name: signerIpsResponse
 
+    getsigninglinks:
+      type: object
+      properties:
+        objectId:
+          type: string
+          format: string
+          example: hji2zxcv2P
+        signurl:
+          type: array
+          items:
+            $ref: '#/components/schemas/inline_response_doc_signurl'
     formdataResponse:
       type: object
       properties:
@@ -6054,6 +6257,8 @@ components:
           type: boolean
           description: |
             This parameter allows you to specify whether you want emails to be sent to signers. The default value is "true". If the value of this parameter is "true" and no 'email_subject'/'email_body' parameters are specified default email templates will be used.
+
+            If the field is omitted or provided as an empty/invalid value, the template value is used.
           example: true
         email_subject:
           type: string
@@ -6065,32 +6270,59 @@ components:
           example: "<p>Hi {{receiver_name}},</p><p>We hope this email finds you well. <strong>{{sender_name}}</strong> has requested you to review and sign <strong>{{document_title}}</strong>.</p><p>Your signature is crucial to proceed with the next steps as it signifies your agreement and authorization.</p><p><a href='{{signing_url}}'>Sign here</a></p><p>If you have any questions or need further clarification, please contact the sender.</p><p>Thanks,<br>Team OpenSign™</p>"
         sendInOrder:
           type: boolean
-          description: "If set to 'true', only the first signer will receive the signature request email initially. Emails to subsequent signers will be triggered sequentially, with each sent only after the previous signer has completed their signing. By default, sendInOrder is set to 'true'."
+          description: |
+            **true** - Only the first signer receives the signature request email initially. Each subsequent signer is notified in sequence, only after the previous signer has completed their signing. This is the default behavior.
+
+            **false** - All signers receive the signature request email simultaneously.
+
+            If the field is omitted or provided as an empty/invalid value, the template value is used.
           example: true
         timeToCompleteDays:
           type: number
-          description: time to complete days is used to calculate expiry date of your document
+          description: time to complete days is used to calculate expiry date of your document. If this field is present in the request body, it overrides the template value, even when set to 0. If omitted, the template value is used.
           format: number
           example: 15
         enableOTP:
           type: boolean
-          description: "true - this option will enable OTP verification. Users will receive a verification code via email, which they must enter to sign the document. false -  this option will disable OTP verification, allowing users to sign the document directly without additional steps."
+          description: |
+            **true** - this option will enable OTP verification. Users will receive a verification code via email, which they must enter to sign the document. 
+            
+            **false** -  this option will disable OTP verification, allowing users to sign the document directly without additional steps.
+
+            If the field is omitted or provided as an empty/invalid value, the template value is used.
           example: false
         enableTour:
           type: boolean
-          description: "true - this option will enable a guided tour for signers, providing instructions during the signing process. false - disable the guided tour, ensuring a faster, uninterrupted signing experience."
+          description: |
+            **true** - this option will enable a guided tour for signers, providing instructions during the signing process. 
+            
+            **false** - disable the guided tour, ensuring a faster, uninterrupted signing experience.
+
+            If the field is omitted or provided as an empty/invalid value, the template value is used.
           example: false
         sender_name:
           type: string
-          description: The name of the person or organization on whose behalf the email is being sent.
+          description: |
+            The name of the person or organization on whose behalf the email is being sent. If this field is present in the request body, it overrides the template value, even when set to an empty string (""). If omitted, the template value is used.
+            
+            If nothing is set, it will use the owner’s preferences. If the owner’s preferences are also not set, it will default to "".
           example: opensign™
         sender_email:
           type: string
-          description: The email address of the person or organization that users can reply to.
+          description: |
+            The email address of the person or organization that users can reply to. If this field is present in the request body, it overrides the template value, even when set to an empty string (""). If omitted, the template value is used.
+
+            If nothing is set, it will use the owner’s preferences. If the owner’s preferences are also not set, it will default to "".
+
           example: mailer@opensignlabs.com
         allow_modifications:
           type: boolean
-          description: "true - Permits signers to add elements such as signatures, initials, stamps, or text on top of existing widgets in the document. false - Restricts signers from adding any additional elements to the document. This is the default value."
+          description: |
+            **true** - Permits signers to add elements such as signatures, initials, stamps, or text on top of existing widgets in the document. 
+
+            **false** - Restricts signers from adding any additional elements to the document. This is the default value.
+
+            If the field is omitted or provided as an empty/invalid value, the template value is used.
           example: false
         file:
           type: string
@@ -6099,11 +6331,11 @@ components:
           example: ""
         auto_reminder:
           type: boolean
-          description: "Set to true to enable automatic reminders. Set to false to disable them (default behavior)."
+          description: Set to true to enable automatic reminders. Set to false to disable them (default behavior). If the field is omitted or provided as an empty/invalid value, the template value is used.
           example: false
         remind_once_in_every:
           type: number
-          description: "Number of days between reminders. This is only applicable when auto_reminder is set to true."
+          description: Number of days between reminders. This is only applicable when auto_reminder is set to true.  If this field is present in the request body, it overrides the template value, even when set to 0. If omitted, the template value is used.
           example: 5
         merge_certificate: 
           type: boolean
@@ -6123,6 +6355,10 @@ components:
             **false** - The document creator will not receive an email notification whenever a signer signs the document.
 
             Note: Regardless of this setting, a completion email with the signed document and completion certificate attached is depend on 'send_email' parameter.
+        redirect_url:
+          type: string
+          description: Specifies the URL where the signer will be redirected upon completing the document signing process. If this field is present in the request body, it overrides the template value, even when set to an empty string (""). If omitted, the template value is used.
+          example: ""
         pen_colors:
           type: array
           items:
@@ -6134,7 +6370,9 @@ components:
             type: string
           example: ["user@example.com","user2@example.com"]
           description: |
-            bcc (blind carbon copy): Users added here will receive a notification email once the document is completed.  
+            bcc (blind carbon copy): Users added here will receive a notification email once the document is completed.
+            If this field is present in the request body, it overrides the template value, even when provided as an empty array ([]).
+            If omitted or provided empty string ("") the template value is used.
         prefill: 
           type: object
           properties:
@@ -6867,6 +7105,15 @@ components:
           type: array
           items:
             $ref: '#/components/schemas/folder_res'
+    inline_response_200_14:
+      type: object
+      properties:
+        objectId:
+          type: string
+          example: Bh2Hspnmch
+        message:
+          type: string
+          example: Contact updated successfully
     selfsigndocument_body_signer:
       type: object
       properties:

docs/docs/API-docs/v1.2/intro.md

@@ -0,0 +1,87 @@
+# Overview
+
+> **OpenSign™ API v1.2 — the open-source DocuSign alternative, built for developers and trusted by enterprises.**
+
+The OpenSign™ API is a production-ready, RESTful interface for embedding legally binding electronic signatures and end-to-end document workflows into any application. Send documents for signature, build reusable templates, automate signing pipelines, and track every event in real time — all from a single, well-documented API, with no vendor lock-in.
+
+Whether you are digitising a single contract flow or powering signatures across an entire enterprise, v1.2 gives you the building blocks to move fast while staying compliant with global e-signature standards (ESIGN, UETA, eIDAS).
+
+---
+
+# Key Features
+
+- **Documents** — Create, send, update, revoke, and delete signature requests with fine-grained control over signers, ordering, and reminders.
+- **Templates** — Build reusable templates with pre-placed widgets and dispatch them to one or many signers in a single call.
+- **Self-Sign** — Generate self-signed documents instantly, without an invitation or signer flow.
+- **Public Templates** — Publish a shareable signing link for open intake forms — no pre-defined signer list required.
+- **Draft Workflow** — Persist documents and templates as drafts, iterate, and finalise them on your own schedule.
+- **Signer Roles** — Assign each recipient a role: `signer`, `viewer` (read-only), or `approver` (everything except a signature).
+- **Password-Protected PDFs** — Work seamlessly with encrypted source files via the `file_password` parameter.
+- **Offline Signing Control** — Toggle offline signing per template with `allow_offline_sign`.
+- **Contacts & Folders** — Manage your signer contact book and organise documents in OpenSign Drive programmatically.
+- **Webhooks** — Receive real-time event notifications at your own endpoint for every document lifecycle change.
+- **Users & Credits** — Retrieve account information and monitor available credits on demand.
+- **Security & Compliance** — TLS-encrypted transport, audit trails, IP logging, and tamper-evident signed PDFs aligned with international legal standards.
+
+---
+
+# What’s New in v1.2
+
+- **Cleaner Template Retrieval** — `GET /template/:id` and `GET /templatelist` now return prefill data separately from signer parameters, with redundant fields removed for easier consumption.
+- **Password-Protected PDF Support** — Pass `file_password` on document, template, draft, and self-sign creation routes.
+- **Offline Signing Control** — Explicitly enable or disable offline signing per template.
+- **Signer Roles** — A new `signer_role` field on the `signers` object unlocks viewer and approver flows alongside the default signer behaviour.
+- **Fully Backwards-Compatible** — All v1 and v1.1 endpoints remain available on the v1.2 base URL. New parameters are optional unless otherwise documented.
+
+---
+
+# Getting Started
+
+Every request must include your API token in the `x-api-token` header:
+
+```
+x-api-token: <your-api-token>
+```
+
+→ [How to generate your API token](https://docs.opensignlabs.com/docs/help/Settings/APIToken)
+
+Prototype risk-free in the **sandbox environment** before going live.
+
+## Available Environments
+
+| Environment    | Base URL                                        |
+| -------------- | ----------------------------------------------- |
+| **Sandbox**    | `https://sandbox.opensignlabs.com/api/v1.2`     |
+| **Production** | `https://app.opensignlabs.com/api/v1.2`         |
+| **EU Region**  | `https://eu-app.opensignlabs.com/api/v1.2`      |
+| **Staging**    | `https://staging-app.opensignlabs.com/api/v1.2` |
+
+---
+
+# Target Audience
+
+- **Developers & IT Teams** — Embedding signatures and document automation into web, mobile, or backend systems.
+- **Product & SaaS Companies** — Adding white-labelled e-signature flows to their own platforms.
+- **Enterprises & Operations** — Standardising secure, auditable document workflows across departments.
+- **Legal & Compliance Teams** — Meeting ESIGN, UETA, and eIDAS requirements with verifiable audit trails.
+
+---
+
+# Usage Scenarios
+
+- Automating contract creation, dispatch, and signing across sales and procurement pipelines.
+- Powering HR onboarding — offer letters, NDAs, and policy acknowledgements at scale.
+- Collecting structured input via public template links for intake forms, waivers, and applications.
+- Orchestrating multi-party approval flows using mixed `signer`, `approver`, and `viewer` roles.
+- Standardising legal, financial, and government document workflows with reusable templates.
+- Integrating signing events into downstream systems through real-time webhooks.
+
+---
+
+# Useful Links
+
+- [OpenSign Website](https://www.opensignlabs.com)
+- [Full Documentation](https://docs.opensignlabs.com)
+- [GitHub Repository](https://github.com/opensignlabs/opensign)
+- [Generate API Token](https://docs.opensignlabs.com/docs/help/Settings/APIToken)
+- [Terms of Service](https://www.opensignlabs.com/terms/)

docs/docs/help/New-Document/enforce-email-verification.md

@@ -21,14 +21,12 @@ The "Enable OTP Verification" feature in OpenSign is designed to add an extra la
 
 3. **Configure Security Settings**:
    - Click the "Advanced Options"
-   - <img width="499" alt="image" src="https://github.com/user-attachments/assets/2f099abb-9421-49fb-b53a-7d9a610a8cfe"/>
-
    - Under **Security Settings**, find the option labeled "Enable OTP Verification."
    - Select **Yes** to activate OTP verification for this document.
-   - <img width="1125" alt="image" src="https://github.com/user-attachments/assets/48d15c53-5eba-407c-8f81-1b17a47f32cb"/>
-
-  
+     
+<img width="499" alt="image" src="https://github.com/user-attachments/assets/2f099abb-9421-49fb-b53a-7d9a610a8cfe"/>
 
+<img width="1125" alt="image" src="https://github.com/user-attachments/assets/48d15c53-5eba-407c-8f81-1b17a47f32cb"/>
 
 4. **Send the Document**:
    - Once all settings are configured, proceed to send the document to the signers.
@@ -61,6 +59,44 @@ Once the document is fully signed by all parties, OpenSign generates a **Complet
 
 This feature makes it clear that the signing process involved OTP verification, adding credibility to the document’s legal standing.
 
+## Impact on the Signing Flow When Email OTP Verification and Allowed Modifications Are Enabled
+
+The widgets available to a signer depend on the **Enable OTP Verification** and **Allowed Modifications** settings configured for the document.
+
+### Enable OTP Verification = Enabled + Allowed Modifications = Enabled
+
+The signer can add the following widgets during the signing process:
+
+<img width="1731" alt="image" src="https://github.com/user-attachments/assets/b06e6575-0ab8-4de0-8755-4c29ee08e17d" />
+
+- Signature
+- Stamp
+- Initials
+- Name
+- Job Title
+- Company
+- Email
+- Text
+- Cells
+
+> **Note:** If the signer has an OpenSign account with previously saved **Signature**, **Initials**, or **Stamp** items, those saved items are automatically displayed and can be used immediately while signing.
+
+---
+
+### Enable OTP Verification = Disabled + Allowed Modifications = Enabled
+
+The signer can add the following widgets during the signing process:
+
+<img width="1731" alt="image" src="https://github.com/user-attachments/assets/c9dd68fd-67e7-47d1-a186-deda8e73f646" />
+
+- Signature
+- Stamp
+- Initials
+- Text
+- Cells
+
+> **Note:** Previously saved **Signature**, **Stamp**, and **Initials** from the signer's OpenSign account are **not** displayed. The signer must create a new signature, stamp, or initials by **drawing**, **typing**, or **uploading** them during the signing process.
+
 ## When to Use OTP Verification
 
 Consider enabling OTP verification in scenarios where:
@@ -69,6 +105,8 @@ Consider enabling OTP verification in scenarios where:
 - **Authentication** is a priority: OTP adds an extra layer of verification, enhancing the document’s validity and security.
 - **Compliance** is required: Certain regulations or standards may necessitate an additional verification step for document signing.
 
+
+
 ## Disabling OTP Verification
 
 If OTP verification is unnecessary for a particular document:

docs/docs/help/New-Document/guestsigning.md

@@ -0,0 +1,139 @@
+---
+sidebar_position: 7
+title: Guest signing flow
+---
+
+# Signer Signing Flow
+
+This guide explains how signers complete a document in OpenSign and how features such as **Duplicate Widget Name**, **Auto Sign**, and the **Image Widget** work during the signing process.
+
+---
+
+# Duplicate Widget Name
+
+The **Duplicate Widget Name** feature helps signers complete documents more efficiently by automatically populating widgets that share the same name.
+
+## How it works
+
+When multiple widgets of the **same type** have the **same widget name**, OpenSign treats them as linked fields.
+
+After the signer fills in one of these widgets, the entered value is automatically copied to all other widgets with the same widget name.
+
+### Example
+
+- Three **Text** widgets named `address`
+- Four **Email** widgets named `company_email`
+
+When the signer enters a value in the first widget, all remaining widgets with the same name are automatically updated.
+
+> **Note:** This feature does **not** apply to **Signature**, **Stamp**, or **Initials** widgets. These widgets use the **Auto Sign** feature instead. When clicked Auto Sign, completing the first Signature, Stamp, or Initials widget automatically fills all remaining matching widgets.
+
+## Supported Widgets
+
+Duplicate Widget Name is supported for the following widget types:
+
+- Name
+- Job Title
+- Company
+- Email
+- Text
+
+> **Important:** Widgets are linked only when both the **widget type** and the **widget name** are identical.
+
+## Unsupported Widgets
+
+Duplicate Widget Name is **not** supported for the following widget types:
+
+- Number
+- Date
+- Checkbox
+- Radio Button
+- Dropdown
+- Cells
+- Attachment
+
+Although you can assign the same widget name to these widgets while creating a document, they behave **independently** during the signing process.
+
+### Example
+
+Suppose a document contains two **Date** widgets with the same widget name, `agreement_date`.
+
+When the signer selects a date in the first Date widget, the selected value is **not** copied to the second Date widget. Each Date widget must be completed individually.
+
+The same behavior applies to all unsupported widget types listed above.
+
+---
+
+# Auto Sign
+
+The **Auto Sign** feature allows signers to complete **Signature**, **Stamp**, or **Initials** only once. After the first widget is completed, OpenSign automatically fills all other matching widgets where **Auto Sign** is enabled.
+
+This reduces repetitive actions and speeds up the signing process.
+
+## Signature Widget
+
+When **Auto Sign** is enabled:
+
+1. Click the first Signature widget.
+2. Create the signature by:
+   - Drawing
+   - Typing
+   - Uploading
+   - Selecting a previously saved signature (if available)
+3. Click **Auto Sign**.
+4. OpenSign automatically fills all remaining Signature widgets that have Auto Sign enabled.
+
+The signer only needs to sign once.
+
+---
+
+## Stamp Widget
+
+When **Auto Sign** is enabled:
+
+1. Click the first Stamp widget.
+2. Upload a stamp or select a previously saved stamp (if available).
+3. Click **Auto Sign**.
+4. All remaining Stamp widgets with Auto Sign enabled are automatically completed.
+
+---
+
+## Initials Widget
+
+When **Auto Sign** is enabled:
+
+1. Click the first Initials widget.
+2. Create the initials by:
+   - Drawing
+   - Typing
+   - Uploading
+   - Selecting previously saved initials (if available)
+3. Click **Auto Sign**.
+4. OpenSign automatically fills all remaining Initials widgets that have Auto Sign enabled.
+
+---
+
+# Image Widget
+
+The **Image** widget allows signers to upload an image during the signing process.
+
+Common use cases include:
+
+- Company logo
+- Passport photo
+- Profile picture
+- Supporting document image
+- Identity verification image
+
+## How it works
+
+1. Click the Image widget.
+2. Select an image from your device.
+3. Upload the image.
+4. Click **Auto Sign**.
+
+If multiple **Image** widgets have the **same widget name**, clicking **Auto Sign** automatically fills all Image widgets with that same name using the uploaded image.
+
+Image widgets with **different widget names** are **not** linked and will not be updated.
+
+> **Note:** Image widgets are linked only when both the **widget type** and **widget name** are identical.

docs/docs/help/New-Document/widgets.md

@@ -121,6 +121,45 @@ Assume you have four number widgets named:
 - Ensure all widget names used in formulas exist in the same document.
 
 ---
+# 📎 Understanding the Attachment Widget
+
+The **Attachment Widget** allows signers to upload supporting files directly while completing and signing a document. This is useful when additional documents or evidence are required as part of the signing workflow.
+
+<img width="918" alt="image" src="https://github.com/user-attachments/assets/ffbe6e7f-35c9-4f46-9b02-68709dbe46cd" />
+
+Examples of files that can be requested include:
+
+- Identity documents (Passport, Driver's License, ID Card)
+- Proof of address
+- Supporting agreements or contracts
+- Certificates and licenses
+- Other required supporting documents
+
+## Benefits of the Attachment Widget
+
+The Attachment Widget helps you:
+
+- Collect supporting documents from signers
+- Keep all required files associated with a document in one place
+- Eliminate the need for separate email attachments
+- Streamline document collection and verification workflows
+- Ensure signers provide the necessary supporting information before completing the document
+
+## How the Attachment Widget Works
+
+1. Signers can upload up to **5 files** using a single Attachment Widget.
+2. Each file can be a maximum of **10 MB** in size.
+3. A single Attachment Widget can therefore accept up to **50 MB** of attachments in total.
+4. Supported file formats include:
+   - PDF (`.pdf`)
+   - Microsoft Word (`.docx`)
+   - PNG (`.png`)
+   - JPG (`.jpg`)
+   - JPEG (`.jpeg`)
+5. Once the signer uploads the files and completes the signing process, the uploaded files are appended as additional pages to the end of the original PDF document.
+<img width="918" alt="document attchement" src="https://github.com/user-attachments/assets/6325793e-a4ed-4aed-ab12-5e29e625f28a" />
+
+> **Note:** All uploaded attachments become part of the completed document package, making it easier to store, review, and share the signed document along with its supporting files.
 
 ## 📩 Need Help?
 

docs/docs/help/Settings/APIToken.md

@@ -89,9 +89,28 @@ OpenSign provides a **sandbox testing cloud environment**, which is a replica of
 > ⚠️ **Important Note:**  
 > Manually entering your username and password will **not work** for sandbox login. Always use the "Login to Sandbox" button for access.
 ---
-### Buy the api credit 
-User can buy the api credit using this feature 
-On the click of the buy premium credits.
+### Buy API Credits
+
+Follow these steps to purchase premium API credits:
+
+1. **Navigate to the Purchase Page**  
+   Go to **Settings → API Token → Buy Premium Credits**.
+   
+<img width="436" alt="buy premium credits" src="https://github.com/user-attachments/assets/82d7c571-702f-4f7f-83eb-baa86a63b829" />
+
+3. **Select the Number of Credits**  
+   Choose the number of credits you wish to purchase and click **Proceed**.
+   
+   <img width="436" alt="buy premium credits" src="https://github.com/user-attachments/assets/da7f72e6-84be-481b-9f5d-36bffafb11ae" />
+
+5. **Credits Added to Your Account**  
+   The selected credits are instantly added to your account. You can view the updated balance in the **Premium Credits Available** section.
+
+6. **Payment and Invoice**  
+   A **payment link** and **invoice** will be sent to your registered email address.
+
+7. **Complete the Payment**  
+   Open the email and click the **Buy Now** button to access the payment link and complete the transaction.
 
 ## 🧠 Frequently Asked Questions
 

docs/docs/help/Settings/Preferences.md

@@ -100,8 +100,26 @@ Decide whether the document should be signed **sequentially** or **simultaneousl
 
 > Users can change this option while creating the document or a template.
 
----
+---  
 
+## Allow offline signing
+Choose whether signers can submit a copy of this document signed using an external tool for owner review.
+   - **Yes**: Signers will see a “Sign Offline” option, allowing them to upload an externally signed PDF and submit it to the document owner for approval.
+   - On Approval: Once the owner approves the submission, the signer’s signing process will be marked as completed. After the document is approved by the owner, a notification email will be sent to the signer confirming that the document has been approved and their signing process is complete. At the same time, a request signature email will be triggered and sent to the next signer in the signing order.
+   - On Declined: If the document is incorrectly filled out or improperly formatted, the owner can decline it and add comments. The signer can then use the same signing link that was initially shared to them to either re-upload a corrected offline file or continue the process using OpenSign’s online signing interface.
+   
+   - **No**: Signers can only sign within the app. The Sign Offline option will be hidden.
+
+This feature is only available on paid plans.
+
+---
+## ✉️ Use profile name as sender
+
+- **On** – When this option is enabled, your profile name will be used as the sender name in Request Signature and Document Completion emails.
+
+- **Off** – When it is disabled, your SMTP email ID will be used as the sender name.
+
+---
 ## 🚫 Enable Tour
 
 The tour feature provides guidance for first-time users. You can turn this off for a cleaner, uninterrupted experience:

docs/docs/help/User Menu/Console/custom_filestorage.md

@@ -26,7 +26,7 @@ Follow the steps below to navigate to the **Custom File Storage** setup page in
 2. Click on your **profile menu** (top-right corner) and select **Console**.  
 3. In the **left sidebar**, go to **Storage**.  
 
-<img width="1722" height="814" alt="Custom file storage" src="https://github.com/user-attachments/assets/813f6685-3f36-40e4-aaaf-0d8b86bdc3b7" />
+<img width="1722"  alt="Custom file storage" src="https://github.com/user-attachments/assets/813f6685-3f36-40e4-aaaf-0d8b86bdc3b7" />
 
 You will now be on the **Custom File Storage** setup page where you can configure your own storage provider.
 

docs/docs/help/User Menu/Console/signing_certificate.md

@@ -9,7 +9,7 @@ The **Custom Signing Certificate** page allows you to upload and manage your own
 
 By default, OpenSign uses its **built-in signing certificate** to digitally sign documents.  
 However, if your organization has its own **custom certificate (PFX or P12 format)**, you can upload and activate it here.
-<img width="1722" height="814" alt="pfx cerificate upload" src="https://github.com/user-attachments/assets/a5668f61-332d-49c5-ace2-5f0f92d3b68f" />
+<img width="1722" alt="pfx cerificate upload" src="https://github.com/user-attachments/assets/a5668f61-332d-49c5-ace2-5f0f92d3b68f" />
 
 ---
 

docs/docs/self-host/docker/run-locally.md

@@ -20,6 +20,16 @@ Make sure Docker is running in the background before proceeding.
 **Warning:** The commands below should only be used when installing OpenSign for the first time. You may loose your settings as this will overwrite .env & caddy files.
 
 ### Running on a custom domain
+
+Point a subdomain to the server where you will be executing these commands by adding the correct A record to your DNS settings.
+
+Copy the command below, paste it into the terminal, and press Enter to pull and start the containers automatically. 
+
+Make sure to replace the host URL with your subdomain where OpenSign will be accessible. 
+
+
+> ⚠️ **WARNING:** MAKE SURE THAT PORT **27017** IS NOT EXPOSED TO THE INTERNET, AS THE DEFAULT CONFIGURATION DOES NOT ENABLE MONGODB AUTHENTICATION.
+  
 Command for linux/MacOS 
 ```
 export HOST_URL=https://opensign.yourdomain.com && curl --remote-name-all https://raw.githubusercontent.com/OpenSignLabs/OpenSign/main/docker-compose.yml https://raw.githubusercontent.com/OpenSignLabs/OpenSign/main/Caddyfile https://raw.githubusercontent.com/OpenSignLabs/OpenSign/main/.env.local_dev && mv .env.local_dev .env.prod && docker compose up --force-recreate
@@ -33,14 +43,6 @@ Command for Windows (**CMD/Terminal**)
 set HOST_URL=https://opensign.yourdomain.com && curl -O https://raw.githubusercontent.com/OpenSignLabs/OpenSign/main/docker-compose.yml && curl -O https://raw.githubusercontent.com/OpenSignLabs/OpenSign/main/Caddyfile && curl -O https://raw.githubusercontent.com/OpenSignLabs/OpenSign/main/.env.local_dev && rename .env.local_dev .env.prod && docker compose up --force-recreate
 ```
  
-Copy the command above, paste it into the terminal, and press Enter to pull and start the containers automatically. 
-
-Make sure to replace the host URL with your subdomain where OpenSign will be accessible. 
-
-You will also need to point the subdomain to the server executing these commands by adding the correct A record to your DNS settings.
-
-> ⚠️ **WARNING:** MAKE SURE THAT PORT **27017** IS NOT EXPOSED TO THE INTERNET, AS THE DEFAULT CONFIGURATION DOES NOT ENABLE MONGODB AUTHENTICATION.
-  
 ### Running locally
 If instead want to run locally try out below commands.
   
@@ -72,6 +74,7 @@ Once the deployment is successful, the application will be accessible at [https:
 To set up OpenSign™ locally using Docker, the following prerequisites are required: 
 
 Add below Environment Variables to the ".env.prod" file that is automatically created in order to personalize your installation:
+> Beginner note: The .env.prod file is created in the current directory (the same directory where you ran the previous commands). On macOS, files that begin with a dot (.) are hidden by default. To view hidden files in Finder, press Cmd + Shift + . (period), or run ls -a in Terminal. Once you locate the file, you can edit it using any text editor or a command-line editor such as vi or nano.
 
 | Environment Variable  | Value | Description |
 | ------------- | ------------- | ------------- |

docs/docusaurus.config.js

@@ -80,6 +80,12 @@ const config = {
               specPath: "docs/API-docs/v1.1/opensign.yaml", // your v1.1 spec file
               outputDir: "docs/API-docs/v1.1",              // generated mdx + sidebar.js
               sidebarOptions: { groupPathsBy: "tag" },
+          },
+            opensign_v1_2: {
+              // OpenAPI v1.2
+              specPath: "docs/API-docs/v1.2/opensign.yaml", // your v1.1 spec file
+              outputDir: "docs/API-docs/v1.2",              // generated mdx + sidebar.js
+              sidebarOptions: { groupPathsBy: "tag" },
           }
         }
       }

docs/sidebars.js

@@ -13,6 +13,7 @@
 // import apiSidebar from './docs/API-docs/sidebar.ts';
 import apiV1Sidebar from './docs/API-docs/v1/sidebar.ts';
 import apiV11Sidebar from './docs/API-docs/v1.1/sidebar.ts';
+import apiV12Sidebar from './docs/API-docs/v1.2/sidebar.ts';
 
 /** @type {import('@docusaurus/plugin-content-docs').SidebarsConfig} */
 const sidebars = {
@@ -23,6 +24,13 @@ const sidebars = {
   // apiSidebar: apiSidebar,
   // Single API sidebar containing two top-level categories
   apiSidebar: [
+   {
+      type: 'category',
+      label: 'v1.2',
+      link: { type: 'generated-index', title: 'OpenSign API v1.2', slug: '/API-docs/v1.2' },
+      collapsed: false,
+      items: apiV12Sidebar,
+    },
     {
       type: 'category',
       label: 'v1.1',