DEV Community: BoldSign

Programmatic Template Editing Using the BoldSign Edit Template API

Vijay Amalan — Wed, 01 Apr 2026 09:44:55 +0000

Templates often serve as living configuration in production eSignature workflows. As businesses scale, these templates change frequently, such as adding new approval steps, updated policies, branding refreshes, or additional required fields. When such updates are handled manually through dashboards, templates can drift across environments and introduce inconsistencies that break automated processes.

The BoldSign Edit Template API solves this by allowing developers to update existing or draft templates programmatically. You can modify metadata, signer roles, and form fields directly from your backend or CI/CD pipelines, keeping templates synchronized with application logic while reducing operational overhead and human error.

Why edit templates programmatically

Templates often act as “living configuration” in production workflows. Over time, teams update templates due to:

New approval steps (HR, finance)
Policy changes (legal, compliance)
Branding refreshes (marketing)
New mandatory fields (operations)

If these updates happen manually in the dashboard, templates can drift across environments (sandbox vs production) and become inconsistent. With the Edit Template API, you can apply controlled updates from your backend or CI/CD pipelines, keeping templates synchronized with your application logic while reducing operational overhead and human error.

What can you update using the Edit Template API

You can update common template configuration elements, including:

Template title: Rename the template to reflect its updated purpose.
Template description: Add or revise the summary of what the template is for.
Document title: Change the title that signers see on the document.
Document message: Update the message that accompanies the request to sign.
Signer roles: Add, remove, reorder, or rename roles (e.g., “Manager”, “Client”).
Form fields: Edit or add input elements (signature, text, date, checkbox) bound to pages and roles.
Signing order settings: Toggle and adjust signer order behavior when relevant.

What can’t you change using the Edit Template API

The following changes are not supported:

The document file itself (PDF or DOCX): If the underlying document needs to change, you must create a new template.
Template ID
Sent documents: Edits only apply to templates, not documents already sent for signing.

Partial updates vs nested updates

1) Top-level fields support partial updates

For simple changes like title, description, documentTitle, documentMessage, or enableSigningOrder, you can send only the fields you want to change.

Result: Unspecified top-level fields remain unchanged.

2) Nested objects must be complete (roles and form fields)

When you update nested objects (like roles or a role’s formFields), you should assume you are replacing the existing array.

Updating roles replaces the entire roles list Include every role you want to keep, not only the one you changed.
Updating formFields for a role replaces that role’s field list Include the full set you want to keep, preserving field IDs when updating existing fields.

Safe pattern

Fetch Template Properties
Edit the JSON in memory
PUT the updated structure back

Field naming note:

Template Properties responses may not match the exact request field names used by Edit Template in every SDK/version. Don’t copy/paste the Template Properties JSON directly into the Edit Template payload, map fields as needed (especially for form fields).

What you’ll need before calling the Edit Template API

Make sure you have the following in place:

A BoldSign account (sandbox or production).
An API key (or OAuth2 access token) to call BoldSign APIs over HTTPS.
A REST client such as cURL, Postman, or your preferred HTTP library.
The TemplateId of the template you want to update.

Authentication headers

Use one of the following:

API Key: X-API-KEY:
OAuth2: Authorization: Bearer

How do you safely edit a template step by step

Retrieve Template Properties Get the full structure of the template, especially important before nested edits. You can refer to the following link to access the template properties : Get Template Properties
Plan minimal changes Decide whether a top-level partial update is enough (e.g., title only) or whether you must update roles/fields.
Prepare the payload For nested edits, start from fetched JSON, modify only what’s needed, and keep unchanged roles/fields intact.
Send the update PUT /v1/template/edit?templateId= with your chosen auth header.
Verify Fetch Template Properties again or run a sandbox send to confirm behavior.

How do you update only the template title (top-level partial update)

When you only need to change the template title, send just the title field. Everything else remains unchanged.

Below is an example code snippet

cURL

    curl -X 'PUT' \ 
      'https://api.boldsign.com/v1/template/edit?templateId={YOUR_TEMPLATE_ID}' \ 
      -H 'accept: */*' \ 
      -H 'X-API-KEY: YOUR_API_KEY' \ 
      -H 'Content-Type: application/json' \ 
      -d '{ 
      "title": "Title of the template" 
    }'

            var apiClient = new ApiClient("https://api.boldsign.com", "YOUR_API_KEY"); 
            var templateClient = new TemplateClient(apiClient); 
            var editTemplateRequest = new EditTemplateRequest("YOUR_TEMPLATE_ID") 
            { 
                Title = "A new title for template" 
            }; 
            await templateClient.EditTemplateAsync(editTemplateRequest);

Python

    import boldsign 
    configuration = boldsign.Configuration(api_key = "YOUR_API_KEY") 
    with boldsign.ApiClient(configuration) as api_client: 
        template_api = boldsign.TemplateApi(api_client) 
        edit_template_request = boldsign.EditTemplateRequest(    
            title = "A new title for template") 
        template_api.edit_template(template_id  = "YOUR_TEMPLATE_ID", edit_template_request = edit_template_request)

PHP

    setApiKey('YOUR_API_KEY'); 
    $apiInstance = new TemplateApi($config); 
    $template_id = 'YOUR_TEMPLATE_ID'; 
    $edit_template_request = new EditTemplateRequest(); 
    $edit_template_request->setTitle('Updated Template Title'); 
    $apiInstance->editTemplate($template_id, $edit_template_request);

Java

    ApiClient apiClient = Configuration.getDefaultApiClient(); 
            apiClient.setApiKey("YOUR_API_KEY"); 
            TemplateApi templateApi = new TemplateApi(apiClient);
            EditTemplateRequest editTemplateRequest = new EditTemplateRequest(); 
            editTemplateRequest.setTitle("A new title for template"); 
            String templateId = "YOUR_TEMPLATE_ID"; 
            templateApi.editTemplate(templateId, editTemplateRequest);

Node js

    import { TemplateApi } from "boldsign"; 
    import { EditTemplateRequest } from "boldsign"; 
    const templateApi = new TemplateApi(); 
    templateApi.setApiKey("YOUR_API_KEY"); 
    var editTemplateRequest = new EditTemplateRequest(); 
    editTemplateRequest.title = "Updated Template Title"; 
    var templateId = "YOUR_TEMPLATE_ID"; 
    await templateApi.editTemplate(templateId, editTemplateRequest);

How do you update roles and form fields (nested update pattern)

Key rule: Include enableSigningOrder whenever roles are present.

When your request includes roles, always include enableSigningOrder explicitly (true or false). This ensures signer sequencing is unambiguous.

Recommended approach

Fetch Template Properties
Modify roles/fields in memory (keep unchanged roles/fields)
Send the updated roles along with enableSigningOrder

Below is an example code snippet

cURL C# Python PHP Java Node js

cURL

    curl -X 'PUT' \ 
      'https://api.boldsign.com/v1/template/edit?templateId={YOUR_TEMPLATE_ID}' \ 
      -H 'accept: */*' \ 
      -H 'X-API-KEY: YOUR_API_KEY' \ 
      -H 'Content-Type: application/json' \ 
      -d '{ 
      "enableSigningOrder": true, 
      "roles": [ 
        { 
          "name": "Customer", 
          "index": 1, 
          "signerOrder": 1, 
          "defaultSignerName": "Alex", 
          "defaultSignerEmail": "alexgayle@boldsign.dev", 
          "signerType": "Signer", 
          "locale": "EN", 
          "formFields": [ 
            { 
              "id": "Signature1", 
              "fieldType": "Signature", 
              "pageNumber": 1, 
              "bounds": { 
                "x": 100, 
                "y": 100, 
                "width": 200, 
                "height": 20 
              }, 
              "isRequired": true  
            } 
          ] 
        } 
      ] 
    }'

            var apiClient = new ApiClient("https://api.boldsign.com", "YOUR_API_KEY"); 
            var templateClient = new TemplateClient(apiClient); 
            var formFields = new List 
            { 
                new FormField( 
                    id: "Signature1", 
                    type: FieldType.Signature, 
                    pageNumber: 1, 
                    isRequired: true, 
                    bounds: new Rectangle(x: 150, y: 150, width: 200, height: 30)), 
            }; 
            var templateRoles = new List 
            { 
                new TemplateRole() 
                { 
                    Name = "Manager", 
                    Index = 1, 
                    DefaultSignerName = " Alex", 
                    DefaultSignerEmail = "alexgayle@boldsign.dev", 
                    SignerType = SignerType.Signer, 
                    FormFields = formFields, 
                    SignerOrder = 1, 
                    AllowRoleEdit = true, 
                    AllowRoleDelete = true, 
                }, 
            }; 
            var editTemplateRequest = new EditTemplateRequest("YOUR_TEMPLATE_ID") 
            { 
                EnableSigningOrder = true, 
                Roles = templateRoles, 
            }; 
            await templateClient.EditTemplateAsync(editTemplateRequest);

Python

    import boldsign 
    configuration = boldsign.Configuration(api_key = "YOUR_API_KEY") 
    with boldsign.ApiClient(configuration) as api_client: 
        template_api = boldsign.TemplateApi(api_client) 
        form_fields = [ 
            boldsign.FormField( 
                id = "Signature1", 
                name = "sign", 
                fieldType = "Signature", 
                pageNumber = 1, 
                font = "Helvetica", 
                bounds = boldsign.Rectangle(x = 50, y = 100, width = 100, height = 60), 
                isRequired = True 
            ) 
        ] 
        role = boldsign.TemplateRole( 
            index = 1, 
            name = "Manager", 
            defaultSignerName = "Alex Gayle", 
            defaultSignerEmail = "alexgayle@boldsign.dev", 
            signerType = "Signer", 
            formFields = form_fields, 
        ) 
        edit_template_request = boldsign.EditTemplateRequest(    
            enableSigningOrder = False, 
            roles = [role] 
        ) 
        template_api.edit_template(template_id  = "YOUR_TEMPLATE_ID", edit_template_request = edit_template_request)

PHP

    setApiKey('YOUR_API_KEY'); 
    $apiInstance = new TemplateApi($config); 
    $template_id = 'YOUR_TEMPLATE_ID'; 
    // Create form field 
    $signatureField = new FormField(); 
    $signatureField->setFieldType('Signature'); 
    $signatureField->setPageNumber(1); 
    $bounds = new Rectangle([100, 100, 100, 50]); 
    $signatureField->setBounds($bounds);  
    // Create role and assign form field 
    $role = new TemplateRole(); 
    $role->setName('Signer'); 
    $role->setDefaultSignerEmail('alexgayle@boldsign.dev'); 
    $role->setDefaultSignerName('Alex Gayle'); 
    $role->setSignerOrder(1); 
    $role->setIndex(1); 
    $role->setFormFields([$signatureField]); 
    // Create edit template request 
    $edit_template_request = new EditTemplateRequest(); 
    $edit_template_request->setEnableSigningOrder(true); 
    $edit_template_request->setRoles([$role]); 
    $apiInstance->editTemplate($template_id, $edit_template_request);

Java

    ApiClient apiClient = Configuration.getDefaultApiClient(); 
            apiClient.setApiKey("YOUR_API_KEY"); 
            TemplateApi templateApi = new TemplateApi(apiClient); 
            Rectangle bounds = new Rectangle(); 
            bounds.setX(50f); 
            bounds.setY(100f); 
            bounds.setWidth(100f); 
            bounds.setHeight(60f); 
            FormField formField = new FormField(); 
            formField.setFieldType(FormField.FieldTypeEnum.SIGNATURE); 
            formField.setPageNumber(1); 
            formField.setBounds(bounds); 
            TemplateRole role = new TemplateRole(); 
            role.setIndex(1); 
            role.setName("Manager"); 
            role.setDefaultSignerName("Alex"); 
            role.setDefaultSignerEmail("alexgayle@boldsign.dev"); 
            role.setSignerOrder(1); 
            role.setSignerType(TemplateRole.SignerTypeEnum.SIGNER); 
            role.setFormFields(Arrays.asList(formField)); 
            EditTemplateRequest editTemplateRequest = new EditTemplateRequest(); 
            editTemplateRequest.setEnableSigningOrder(false); 
            editTemplateRequest.setRoles(Arrays.asList(role)); 
            String templateId = "YOUR_TEMPLATE_ID"; 
            templateApi.editTemplate(templateId, editTemplateRequest);

Node js

    import { TemplateApi, EditTemplateRequest, TemplateRole, Rectangle, FormField } from "boldsign"; 
    const templateApi = new TemplateApi(); 
    templateApi.setApiKey("YOUR_API_KEY"); 
    const bounds = new Rectangle(); 
    bounds.x = 100; 
    bounds.y = 50; 
    bounds.width = 100; 
    bounds.height = 100; 
    var formField = new FormField(); 
    formField.fieldType = FormField.FieldTypeEnum.TextBox; 
    formField.pageNumber = 1; 
    formField.bounds = bounds; 
    var editTemplateRequest = new EditTemplateRequest(); 
    editTemplateRequest.enableSigningOrder = true; 
    var role = new TemplateRole(); 
    role.index = 1; 
    role.defaultSignerEmail = "alexgayle@boldsign.dev"; 
    role.defaultSignerName = "Alex"; 
    role.name = "Signer"; 
    role.signerOrder = 1; 
    role.formFields = [formField]; 
    editTemplateRequest.roles = [role]; 
    var templateId = "YOUR_TEMPLATE_ID"; 
    await templateApi.editTemplate(templateId, editTemplateRequest);

Real-world use cases of the Edit Template API

1) HR offer letters

Scenario: A candidate’s role changes from “Developer” to “Engineer” right before sending the offer.

Solution: Update the template roles/messages instantly without recreating or editing in the dashboard.

2) Sales contracts

Scenario: High-value deals require an additional “Legal Reviewer” role.

Solution: Add/reorder roles and enforce signing order programmatically for compliance.

3) Operations & compliance

Scenario: A new checkbox/date field becomes mandatory across agreements.

Solution: Update form fields programmatically across templates to align with policy.

4) Marketing agreements

Scenario: Campaign names or project titles change frequently.

Solution: Update template metadata dynamically so documents remain current and professional.

Summary: Managing templates with BoldSign APIs

Templates are foundational when your eSignature workflows must evolve with business needs. With the Edit Template API, you can:

Update titles, descriptions, and messages via partial updates
Adjust signer roles and form fields via complete nested updates
Reduce drift caused by manual edits
Keep templates consistent across environments and teams

Conclusion

Editing templates programmatically is a smart way to keep eSignature workflows flexible and stable at scale. Use partial updates for top-level changes and the fetch–modify–update pattern for roles and fields to prevent accidental overwrites. With a few API calls, your team can keep templates current, reduce operational burden, and maintain consistency across environments.

If you’d like to learn more about BoldSign, leave a comment, book a demo, or connect with our support team through the support portal.

Related blogs

Note: This blog was originally published at boldsign.com

Select Visual Studio Enterprise Subscribers: Get 12 Months of BoldSign Growth Plan + 50 API Credits

Vijay Amalan — Tue, 31 Mar 2026 07:22:47 +0000

Visual Studio Enterprise subscribers now receive one year of the BoldSign Growth plan as part of their subscriber benefits. This gives developers a low-risk way to embed an eSignature solution, automate document workflows, and test production-ready signing software. SaaS teams can launch native signing experiences without upfront subscription costs for 12 months.

What’s included in the benefit

When you activate the BoldSign benefit, you unlock the full BoldSign Growth Plan along with API credits, which includes:

Unlimited reusable templates.
Embedded requesting (send documents from inside your app).
Embedded signing (users sign without leaving your UI).
Custom branding and custom email domain.
Team management and roles.
Full API and SDK access.
50 API document credits included.

How do API usage and pricing work?

The 12-month benefit period includes full access to BoldSign:

First 50 API documents are included.
Additional API sends cost $0.75 per document.
A credit card is required only for verification.
You will be charged only if you exceed the included credits.
After 12 months, the plan renews at $5 per month (cancel at any time).

This setup is ideal for evaluation, prototyping, and early-stage launches.

Why do developers choose BoldSign for embedded workflows?

Native, in-app signing.
Seamless experience with no redirects or external signing pages.
Fast developer onboarding.
Sandbox, templates, embedded signing, and webhooks setup can be completed in a single day.
Consistent product experience.
Unified branding across signer pages, emails, and workflows.
Scalable automation.
Flexible mix of manual, template-based, and API-driven flows.

Do all users need a BoldSign account?

Required: Anyone who sends, manages, or requests signatures.
Not required: People who only sign documents. (Signers do not need an account, which reduces friction.)

What should I know about BoldSign security and compliance?

BoldSign is built with enterprise-grade security:

End-to-end encryption.
Secure, regulatory-compliant document storage.
Detailed audit logs.
SOC 2-aligned processes.
Fine-grained organization access controls.

All document actions are fully traceable and tamper evident.

Why this is a valuable one-year opportunity

The included 12-month access period gives developers enough time to:

Build complete, embedded eSignature workflows.
Automate recurring document processes.
Test signing inside their apps.
Validate API integrations.
Scale usage without upfront subscription commitments.

This is a practical, low-risk way to integrate eSignatures into SaaS products or internal workflows.

Want to build embedded eSignature workflows in minutes? Start here:

If you want to get started on building an end-to-end embedded signing experience, our technical guides cover:

How to activate your BoldSign account through the Visual Studio subscriber benefits portal:

Open your Visual Studio Subscriber Benefits page.
Find the BoldSign benefit tile.
Select Activate.
Complete the signup.
Start sending documents immediately.

Related blogs

Note: This blog was originally published at boldsign.com

Introducing BoldSign’s Snapchat QR Code Generator

Vijay Amalan — Mon, 30 Mar 2026 09:32:36 +0000

A Snapchat QR code allows anyone to open your profile instantly with a single scan. With BoldSign’s free Snapchat QR code generator, you can convert any Snapchat link into a scannable QR code within seconds with no signup, no watermark, and no usage limits.

Whether you are boosting your brand, growing a creator audience, connecting with customers, or adding Snapchat to your digital identity, this guide covers how Snapchat QR codes work and how to use them effectively.

What is a Snapchat QR code

A Snapchat QR code is a scannable code that opens your Snapchat profile, public account, or Snap-specific link when someone points their smartphone camera at it. You can link to:

A Snapchat profile
A public creator page
A Snap code URL
A direct add me link

Why it matters: It removes the friction of searching usernames manually or dealing with typos.

Why use a Snapchat QR code

A Snapchat QR code makes sharing your profile faster, simpler, and more effective across social media, marketing materials, and offline channels.

Key Benefits

Instant audience growth- People can follow your Snapchat account in one scan.
Better engagement – Useful at events, booths, stores, or meetups where quick access matters.
Stronger digital identity – Add it to websites, posters, product packaging, portfolios, or social bios.
Smartphone friendly – Modern cameras scan QR codes natively without any extra apps.

How to create a Snapchat QR code for free

Creating your Snapchat QR code takes less than a minute. Just follow these steps.

What you will need

Your Snapchat link
Any desktop or mobile browser

Step by step

Copy your Snapchat URL Use your profile link, public page URL, or Snap code link.
Paste it into BoldSign’s Snapchat QR code generator Your QR code appears instantly.
Customize your QR code Adjust options such as:
- Pattern color
- Background color
- QR code size
Download and share Export your QR code as*:*
- PNG
- JPEG
- SVG

Why choose BoldSign’s Snapchat QR code generator

BoldSign’s tool is built for privacy, speed, and clean professional output.

100% free forever: No fees, no watermarks, no limits.
Privacy first: Your Snapchat link never leaves your browser. We do not store or track your data.
Instant results: Create high-quality QR codes in seconds.
Works on any device: Compatible with Windows, macOS, Linux, iOS, and Android.

Best ways to use a Snapchat QR code

Snapchat QR codes can elevate your digital presence across both online and physical spaces. Here are powerful ways to use them:

Business cards: Make your contact card instantly scannable.
Product packaging: Let customers access offers, tutorials, or behind-the-scenes content.
Websites and landing pages: Add it to your portfolio, link in bio, or homepage.
Events and pop ups: Display it at booths, banners, or digital screens for instant audience connection.
Print marketing: Add it to posters, flyers, menus, brochures, or store signage.
Creator branding: Great for merch, stickers, giveaways, and creator kits.

Conclusion

A Snapchat QR code makes it easier for people to find and follow you instantly. It boosts visibility, enhances your brand identity, and removes the friction of searching usernames manually.

Create your Snapchat QR Code with BoldSign today and start building stronger, smarter connections.

Ready to simplify your document workflows? Start your free BoldSign trial or connect with our support team for a personalized demo.

Related blogs

Note: This blog was originally published at boldsign.com

Electronic Signature in Healthcare: Where They Help Most

Vijay Amalan — Fri, 27 Mar 2026 06:21:46 +0000

A busy clinic receptionist needs a patient’s signed consent before a simple procedure, but the paper consent form is missing from the file. Filling, printing, chasing signatures, and scanning eat-up time and frustrate patients. What they really need is a quick, secure way to collect signatures digitally that fit into clinical workflows without extra hassle. Tools like BoldSign can step in as a simple helper to collect, track, and store those signatures securely.

Why e‑signatures matter in healthcare

Health providers handle lots of forms that must be signed correctly and stored securely. Paper slows care, increases errors, and makes audits harder. E-signatures reduce friction, improve traceability, and support faster patient flow, helpful for clinics, hospitals, telehealth providers, and billing teams.

Simple real-life scenario

A small dental practice sees six patients per hour. Each patient must sign an intake form, a consent for treatment, and a privacy notice. The clinic currently uses paper forms on a clipboard. Sometimes forms are illegible, sometimes a printed form is misplaced, and staff must reprint or call patients. The practice needs a simple, secure digital signing flow so patients can sign a tablet in the waiting room or finish at home before the appointment.

Common paper-based workflow

Some clinics try to solve this by scanning signed paper into a shared folder or emailing PDFs back and forth. Problems:

Extra manual steps: scan, rename, move files.
Hard to track whether a form is signed or which version is current.
Security and access control are inconsistent.
Audits become time-consuming because records are scattered.

A better digital workflow

Design a simple e-sign workflow:

Create a single template for each form type (intake, consent, release).
Collect patient data once and send a secure link or present a tablet for on-site signing.
Save the signed document directly into the patient’s record with access logs.

Benefits:

Faster check-in.
Fewer filing errors and lost forms.
Clear audit trail (who signed, when, where).
Patients can sign remotely before their appointment.

How tools like BoldSign support this workflow

E-signature platforms provide the building blocks for the workflow above, templating, field pre-fill, signer authentication, secure storage, and audit logs. Below is a simple, generic example of workflow:

Typical steps:

Upload or create a template for consent forms.
Send a secure signing link to the patient (or open on a clinic tablet).
Receive the signed document and store it in the patient’s record with an audit trail.

Key Takeaway: Use templates and pre-fill fields to cut patient time-to-sign and avoid manual data entry.

Security and privacy considerations

Use secure authentication for accessing e-sign tools.
Limit who can view or send sensitive forms.
Ensure transport (HTTPS) and storage are encrypted.

Best practices

Create reusable templates for each form type.
Pre-fill fields from the EHR to reduce typing and errors.
Provide multiple signing options. Ex: on-tablet, email link.
Use signer authentication appropriate to the risk level (Email OTP, SMS OTP, Access code).
Keep an audit trail, signer identity, timestamp, IP address, etc.
Train staff on the new workflow so they can assist patients quickly.
Test the signing process on common device types (phones, tablets) before rolling out.

Conclusion

E-signatures simplify many administrative tasks in healthcare by cutting down waiting times, reducing errors, and giving a clear audit trail. When combined with templates and proper authentication, they fit naturally into clinical workflows, improving patient experience and freeing staff to focus on care.

Get started today! Sign up for a free BoldSign account and begin managing tasks with just a few steps. For questions or assistance, visit our support portal or book a demo.

Related blogs

Note: This blog was originally published at boldsign.com

Join Our Webinar: Find Any Contract in Seconds with BoldSign’s AI Search

Vijay Amalan — Wed, 25 Mar 2026 09:27:31 +0000

As document volume grows, teams spend more time filtering and searching instead of moving work forward. AI Search solves this by understanding natural language queries, applying the correct filters automatically, and ranking results so the most relevant documents appear first.

Led by Gayathri Annamalai, a Software Developer at Syncfusion, this session will walk you through real-world examples of how AI Search helps teams follow up faster, reduce manual checks, and work more efficiently.

Webinar details

Date: March 27, 2026
Time: 10:00 AM ET
Duration: 40 minutes + live Q&A
Speaker: Gayathri Annamalai
Registration: Register now

Who this webinar is for

This session is ideal for:

Operations teams managing process efficiency and document throughput
Sales and customer success leaders who depend on fast follow ups and SLA driven workflows
Legal and contract teams handling agreements, reviews, and high volumes of documents
BoldSign administrators who oversee user management, workflow setup, and organization-wide search
High volume teams that need quick access to pending, expiring, or time sensitive documents

If your work depends on finding the right documents quickly and minimizing manual filtering, this webinar is for you.

Agenda: What we will cover

Why AI Search now

How traditional filtering breaks down as document volume increases, and why teams need a smarter way to locate contracts.

How AI Search works

A simple overview of how natural language intent becomes automatically applied filters and ranked results.

Natural language query examples

Here are some examples of real queries you can type directly into AI Search:

Documents waiting for my signature
Contracts sent last month that are still pending
Show completed contracts from last month
Find agreements updated in the last 7 days
NDA documents sent by John this month
Expired documents between January 1 and January 15

Live demo

Real examples showing how teams can use everyday language to find what they need in seconds.

Best practices

How to write effective queries for accuracy, speed, and better prioritization.

Q&A

Get your questions answered live.

Why attend?

You will get:

A clear understanding of how AI Search reduces manual filtering
Live, practical examples of everyday queries across teams
Simple techniques to make searching faster and more accurate
Insights from BoldSign experts who work directly on product and engineering

What you will be able to do after the webinar

After this session, you should be able to:

Search in plain English to find documents by status, date, signer, template, and more
Combine multiple conditions in a single query, including status, date range, owner, and document type
Prioritize work faster using AI ranked results that surface what matters most
Accelerate follow ups by instantly finding pending, expiring, or stalled documents

Reserve your spot

Don’t miss this opportunity to experience the new AI Search capabilities in BoldSign.

For questions, contact us at support@boldsign.com

Related blogs

Note: This blog was originally published at boldsign.com

What Are the Common Challenges When Using Signature APIs in Software Development

Vijay Amalan — Tue, 24 Mar 2026 06:47:21 +0000

Signature APIs usually work flawlessly in development, but start failing the moment they hit real production traffic, real documents, and real recipients. The reason is simple: eSignature workflows aren’t “one API call.” They’re distributed, stateful, multistep systems that break at predictable failure points like authentication, PDF rendering inconsistencies, webhook handling, template drift, deliverability issues, compliance gaps, and retry storms.

This guide breaks down the seven most common reasons Signature API integrations fail in production and the engineering patterns that prevent them. You’ll see exactly where real-world systems fail, what reliable teams do differently, and how BoldSign’s builtin capabilities eliminate these reliability gaps from day one.

Why do Signature API integrations fail after they reach production

Because a signing workflow is not “one API call.”

It’s an orchestration system with:

Authentication
Document rendering
Field placement
Notifications
Webhooks
Lifecycle state changes
Evidence collection
Compliance storage
Retries and rate limits

Most failures aren’t caused by the provider being “down.”

They happen because implementations don’t include defensive patterns for real-world conditions.

If your workflow depends on a single success response, it’s not production-ready.

What authentication mistakes cause random 401 errors in Signature APIs

Authentication failures usually don’t show up during testing because sandbox flows are short and clean.

In production, failures come from:

Access tokens expiring mid-process
Refresh token logic missing or unsafe
Multiple servers refreshing at the same time (“refresh storms”)
Sandbox and production credentials getting mixed
Clock skew causing “expired/not valid yet” surprises

What reliable teams do instead

Choose auth based on your workflow: API key for backend automation, OAuth2 for user-consented access
Refresh early (before expiry), not only when it breaks
Ensure only one refresh happens at a time
Log failures with context (without leaking secrets)
Keep sandbox and prod credentials strictly separated

How BoldSign helps

Scoped API keys that reduce blast radius
OAuth2 guidance and supported flows so you don’t “invent auth”
Clear documentation for setting up OAuth2 correctly

Concrete Action: Add the header X-API-KEY: {your-api-key} to every API request to authenticate securely.

Learn more: API Key Authentication

Checkpoint: If your access token refresh can trigger from multiple servers at once, you need a single-source refresh mechanism.

Why do signature fields shift or render incorrectly on PDFs

This is one of the most common “it worked yesterday” failures.

Fields shift because PDFs are not consistent across:

Generators (Word → PDF, Google Docs → PDF, print-to-PDF, scanners)
Page sizes, rotation, and scaling rules
Page boxes (CropBox/MediaBox differences)
Font substitution and layout changes
Tiny template edits that change coordinates

What reliable teams do instead

Treat placement like layout engineering, not guesswork
Avoid hard-coded coordinates whenever possible
Test with multiple PDF types (scanned, rotated, different sizes)
Add a repeatable QA step: “compare final rendered doc vs expected placement”

How BoldSign helps

Text tags so fields can anchor to content instead of brittle X/Y math
A single switch (UseTextTags=true) enables tag-based placement when sending a document, making field rendering consistent across all PDF types.

Concrete Action: Enable text-tag anchoring by setting UseTextTags=true in the /v1/document/send request.

Learn more: Text Tags Introduction

Checkpoint: If a tiny PDF edit breaks your field coordinates, you need text-tag-based anchoring instead of X/Y positioning.

What causes webhook failures and missing document updates

Webhooks are where production workflows live or die.

Failures come from:

Slow endpoints that timeout
Deploys that drop events
Duplicate deliveries that double-update states
Out-of-order events leading to the wrong final state
Skipping signature verification (a security risk)

What reliable teams do instead

Respond fast, process later (acknowledge quickly, handle asynchronously)
Make handlers idempotent (duplicates should do nothing)
Verify authenticity before trusting payloads
Model state transitions so late events can’t “rewind” the document

How BoldSign helps

Webhooks with signature verification using X-BoldSign-Signature (HMAC SHA256)
Guidance on webhook event types and scope
Clear operational requirement : webhooks should respond quickly (designed to push you toward reliable receivers)

Concrete Action: Validate incoming webhook payloads using the X-BoldSign-Signature HMAC-SHA256 header.

Learn more: Verify Webhook Events

Checkpoint: If a duplicate webhook can change your document state twice, you need idempotent handlers.

Why do templates break automated workflows over time

Templates feel stable until someone edits one field and automation breaks across your product.

Common failures:

Roles or fields changed in a live template
Automation assumes templates are ready instantly after creation
No record of which template version was used

What reliable teams do instead

Treat templates like code: version names, changelogs, controlled rollout
Never mutate a template silently, create a new version
Keep roles consistent and mapped to your app’s signer types
Account for asynchronous readiness after creation

How BoldSign helps

Role-based templates that fit automation patterns
Clear template endpoints and support for template lifecycle behaviors
Webhook-style readiness approach for async template processing

Concrete Action: Create templates via POST /v1/template/create and track readiness using the TemplateCreated webhook event.

Learn more: Create Template

Checkpoint: If editing a template can break your automation, you need versioned, immutable templates.

Why do email, SMS, and WhatsApp delivery failures break signing

The most painful production issue isn’t API errors.

It’s “the signer never received anything.”

Delivery issues happen because:

Email goes to spam or bounces
Phone numbers are invalid or missing country codes
Carrier filtering blocks SMS
WhatsApp numbers may be inactive/unregistered
Teams assume “sent = delivered”

What reliable teams do instead

Separate “document created” from “recipient notified”
Track notification attempts and signer progress separately
Provide repair paths: update contact info, resend, switch channels
Prefer embedded signing for product-led, in-app flows

How BoldSign helps

Multiple delivery modes : Email, SMS, Email+SMS, WhatsApp
Reminders endpoint for follow-ups
Ability to disable platform notifications when you want full in-app control
Embedded signing support to bypass deliverability entirely

Concrete Action: Recover stuck signers by calling the reminders endpoint POST /v1/document/remind?documentId={documentId}.

Learn more: Send Reminder

Checkpoint: If a signer who didn’t receive the message stops the entire workflow, you need repair paths like resend + update contact info.

What compliance gaps create “we can’t prove it” disputes

Compliance isn’t just storing the signed PDF.

Teams get stuck when they can’t answer:

Who signed
When they signed
What events occurred
What was presented at signing time
What evidence exists if a signature is challenged

What reliable teams do instead

Decide what to retain upfront (PDF + event evidence)
Automatically fetch evidence when documents complete
Implement retention rules aligned with your industry

How BoldSign helps

Audit trail download via API
Guidance for retrieving document history/evidence
Option to combine signed document + audit trail into a single package (when enabled)

Concrete Action: Automatically store event evidence by downloading the audit log using GET /v1/document/downloadAuditLog?documentId={id}.

Learn more: Download Audit Trail

Checkpoint: If you cannot prove who signed, when they signed, and what happened, you need automated audit trail storage.

Why do rate limits and retries create duplicate signature requests

Rate limits don’t hurt because they exist.

They hurt because apps respond badly to them.

What goes wrong:

Aggressive retries cause storms
Timeouts trigger “create again” logic (duplicates)
Teams retry 4xx validation errors without fixing requests
Sandbox limits differ from production, so load tests lie

What reliable teams do instead

Throttle bursts before they hit the API
Retry only transient failures (timeouts, network errors, 5xx, 429)
Don’t retry 4xx unless the request changes
Add “create safety”: track your own request IDs to prevent duplicates

How BoldSign helps

Published rate limits (sandbox vs production)
Practical guidance to design within limits
Sandbox environment for safer testing

Concrete Action: Implement client-side throttling using BoldSign published limit of 2000 requests/hour to avoid 429 errors.

Learn more: Rate Limit Documentation

Checkpoint: If a timeout can create two signature requests, you need idempotent “create” logic in your app.

What are the 7 Signature API challenges you should design for first

If you only remember one thing, remember this list:

Auth expiry + refresh safety
PDF placement stability
Webhook reliability + idempotency
Template version safety
Deliverability + repair paths
Audit trail evidence storage
Rate limits + retry discipline

These are the points where “it works in testing” becomes “it breaks in production.”

What production-readiness checks should every eSignature integration pass

A production-ready eSignature workflow must be resilient across authentication, documents, webhooks, templates, notifications, compliance, and rate limits. The checklist below lets engineering teams verify at a glance, whether their integration can withstand realworld traffic, real documents, and real signer behavior.

Category	What You Must Validate Before Going Live	Ready for Production When…
Authentication Safety	• Token refresh happens before expiration • Only one service instance handles refresh • Sandbox & production keys are isolated • Clock skew is accounted for • API key vs OAuth2 chosen intentionally	Your system never generates multiple refreshes and avoids intermittent 401s.
PDF Rendering & Field Placement Stability	• No brittle hard-coded coordinates • Text-tags anchor fields reliably • Tested across mixed PDF generators (Word, Google Docs, scanned, rotated) • Final signed PDF matches expected placement • Template edits don’t cause movement	A small document or template change cannot shift or break field positions.
Webhook Reliability & Duplicate Safety	• HMAC SHA256 verification is enforced • Handlers acknowledge fast and process async • Duplicate events do nothing (idempotent) • Out-of-order events can’t revert state • Deployments don’t drop events	A webhook delivered twice behaves exactly like one delivery.
Template Version Control	• Templates use explicit versioning • No silent edits to live templates • Template readiness checked before use • Roles align with your signer types • System records which template version was used	Template changes cannot break automation or field mapping.
Deliverability & Recovery Paths	• Email, SMS, WhatsApp delivery tracked • Contacts can be fixed mid-process • Resend and follow-up flows implemented • Embedded signing available as fallback • “Sent” and “Delivered” treated separately	A signer who didn’t receive the message cannot stall the workflow.
Compliance Evidence Storage	• Signed PDFs stored securely • Audit trails auto-downloaded • Retention rules match your industry • Evidence ties to exact document version • Full event history is retrievable any time	You can prove who signed, when, and what happened without gaps.
Rate Limits, Retries & Idempotency	• Retries only for transient failures (429/5xx/timeouts) • 4xx never retried without fixing request • Client-side throttling implemented • Request IDs prevent duplicate creations • Sandbox vs production limits tested	A timeout can never create duplicate documents or retry storms.

Final Takeaway: What should you take away before you ship a Signature API integration?

Signature APIs don’t usually fail because the provider is unreliable. They fail because production systems expose the weak spots: expired auth, fragile PDF placement, webhook duplicates, template drift, deliverability gaps, missing audit evidence, and retry storms. If you design for these seven failure points up front, you don’t just “integrate eSignatures”. You build a workflow that stays stable under real load, real documents, and real recipients.

For detailed implementation guidance, refer to the BoldSign API documentation.

Start your free 30‑day BoldSign trial today. If you need support aligning these best practices with your workflow, you can reach out through the support portal or schedule a demo with our team.

Related blogs

Note: This blog was originally published at boldsign.com

How Claude and OpenAI Are Redefining AI for Healthcare and eSignature Workflows

Vijay Amalan — Mon, 23 Mar 2026 06:17:15 +0000

Healthcare doesn’t have diagnosis problem as much as it has workflow problem.

Clinicians and staff lose hours to administrative tasks: prior authorizations, claims and appeals, care coordination, intake and consent, document retrieval, and reporting. That’s why two of the biggest AI announcements in early 2026, Claude for Healthcare and OpenAI for Healthcare, read less like “AI replaces doctors” and more like “AI helps healthcare teams move faster without compromising privacy.”

And it’s also why eSignature is becoming a core part of the healthcare AI stack.

At BoldSign, we see this shift clearly: when AI helps people find, draft, and route documents faster, the bottleneck quickly becomes the last mile, getting the right forms signed, stored, searchable, and audit-ready. That’s exactly where a HIPAA-compliant eSignature platform with AI-powered document capabilities earns its place.

How Claude optimizes healthcare: Access, context, time

Anthropic’s healthcare announcement emphasizes HIPAA-ready infrastructure and connectors that help clinicians and administrators retrieve and understand information across healthcare systems faster.

Two themes stand out:

Information retrieval across systems: The connector approach is aimed at reducing the friction of searching multiple platforms and compiling reports. (Anthropic)
Workflow acceleration, not medical decision-making: The language focuses on tasks that slow teams down, such as coordination, documentation, and admin workflows, rather than diagnosing patients. (Claude)

The “so what?” for healthcare ops leaders: AI is moving closer to the systems where work happens, including EHR-adjacent tools, registries, policy libraries, clinical-trial ecosystems, while trying to keep compliance front-and-center.

How OpenAI for healthcare improves high-quality operations

OpenAI’s announcement frames OpenAI for Healthcare as a suite designed to help organizations deliver more consistent, high-quality care while supporting HIPAA compliance requirements. (OpenAI)

That wording matters. In practice, it signals:

Healthcare-specific packaging (not “generic chat for everything”)
Enterprise compliance posture designed for regulated environments
Operational use cases where speed and consistency matter (documentation, communications, administrative workflows)

It’s the same pattern: AI as a workflow engine, helping teams standardize and accelerate the non-clinical work that impacts patient experience.

The missing link in AI for healthcare: Document execution

AI can draft the intake form. AI can summarize a coverage policy. AI can help staff find the right template.

But healthcare still runs on documents that must be signed:

Patient consent (treatment, procedures, telehealth, HIPAA acknowledgements)
Intake packets and insurance authorizations
Release of information (ROI) forms
Financial responsibility and payment agreements
Clinical trial and research consent
Vendor BAAs, HR onboarding, compliance attestations

If the signature workflow is slow, or worse, non-compliant, AI-generated efficiency gains get stuck at the finish line.

This is exactly where BoldSign fits into the new healthcare AI landscape.

BoldSign’s view: AI accelerates document creation and discovery, and BoldSign completes the workflow securely

BoldSign is built for organizations that need signing workflows that are fast, auditable, and scalable. For healthcare teams, the bar is higher: documents frequently contain PHI, access must be controlled, and auditability is non-negotiable.

1) HIPAA compliance isn’t a checkbox; it’s operational readiness

BoldSign provides a HIPAA compliance path designed for healthcare workflows, including support for being treated as a Business Associate and enabling HIPAA mode via a Business Associate Agreement (BAA).

BoldSign also publishes practical guidance on HIPAA-compliant eSignatures, helping teams understand what “compliant” means in real signing scenarios (not just marketing claims).

2) AI features that reduce document friction (before you even hit “Send”)

Healthcare is document-heavy, and most delays are caused by “small” things: finding the right form, preparing fields, tracking status, and locating the final signed PDF later.

BoldSign has been investing in AI features aimed directly at those pain points:

AI Search for documents and templates: Search using natural language to find the right agreement or template without perfect recall of titles and filters.
AI Form Field Detection: Upload a document and automatically detect and place fields to speed up preparation, especially useful for intake packets, consent forms, and standardized templates.

These capabilities complement the direction Claude and OpenAI are taking: reduce time lost to “finding, formatting, and forwarding.”

3) Turning AI assistants into action: BoldSign MCP for eSignature automation

One of the most interesting developments in workflow automation is bridging AI assistants to real systems safely.

BoldSign introduced an MCP (Model Context Protocol) approach that lets AI assistants trigger eSignature actions (e.g., send a document from a template, track status) through the BoldSign API returning structured results for clear confirmations and next steps.

For healthcare ops, that opens up new automation patterns like:

“Send the patient consent packet for tomorrow’s appointment”
“Find all unsigned telehealth consents from last week”
“Generate a standard ROI form and route it to the patient + compliance officer”

The point isn’t “AI does everything.” It’s AI reduces the clicks, while your signing and compliance system remains the source of truth.

Where this is going: healthcare “workflow stacks” will converge around documents

Claude for Healthcare and OpenAI for Healthcare reinforce a trend: healthcare AI is being productized around repeatable operational workflows with compliance guardrails. (Anthropic)

In the near future, healthcare organizations will assemble workflow stacks that look like this:

AI assistant layer (summarize, draft, retrieve, guide staff)
Core healthcare systems (EHR, scheduling, billing, registries)
Document execution layer (prepare fields, route for signature, store, audit, retrieve)

BoldSign lives in (3) and increasingly helps with (1) via AI Search, AI field detection, and MCP-enabled automation.

Practical examples: what “AI + BoldSign” can look like in healthcare workflows

Patient intake & consent

AI helps staff choose the right packet based on appointment type
BoldSign auto-detects fields and routes to patient + guardian + provider
Signed documents become searchable instantly via AI Search for fast follow-up

Prior authorizations & administrative documentation

AI summarizes payer requirements and drafts the supporting cover sheet
BoldSign routes the forms for signatures and keeps a clean audit trail
Staff can quickly find “the latest signed version” without digging (Claude)

Research and life sciences

AI accelerates regulatory paperwork preparation and review
BoldSign keeps signature workflows standardized for study documents and approvals
Teams retrieve the exact signed document version when audits or submissions arise (Anthropic)

A compliance note worth repeating

Even when products are designed to support HIPAA compliance, implementation decisions matter: what data flows where, who has access, what gets logged, and what’s retained. BoldSign’s HIPAA mode and BAA process are part of building that operational rigor into document workflows.

The BoldSign takeaway

Claude for Healthcare and OpenAI for Healthcare are strong signals that AI’s biggest near-term impact in healthcare is workflow acceleration, helping teams handle the administrative reality of modern care at scale.

BoldSign’s role in that future is straightforward:

Make signing and document execution fast
Keep workflows HIPAA-ready
Use AI to reduce document prep and retrieval friction
Enable automation that connects AI assistants to real eSignature actions

If your organization is exploring healthcare AI initiatives, it’s worth asking a simple question:

“Once AI drafts or finds the document, how quickly can we execute it, securely?”

That’s the gap BoldSign is built to fill.

Start your free 30‑day BoldSign trial today.

Connect with our support team for guidance and request a personalized demo to see how BoldSign completes your AI‑powered healthcare eSignature workflows.

Related blogs

Note: This blog was originally published at boldsign.com

Ship eSignatures Faster with BoldSign Skill for Code Studio and Claude

Vijay Amalan — Thu, 19 Mar 2026 04:05:58 +0000

What is a Skill (and why does eSignature need one)?

A Skill is a structured set of reference files you add to your Code Studio workspace and include in the AI context. When you prompt Claude in Code Studio, the model can use those files to generate code that follows the API’s patterns, naming conventions, and best practices. No hallucinated endpoints. No outdated SDKs.

eSignature APIs are particularly tricky to integrate from scratch. There’s the asynchronous nature of document sending, the webhook choreography for tracking status, HMAC verification, form-field coordinate math, and multi-signer ordering. Without a Skill, Claude might get the broad strokes right but miss the details that break things in production, such as assuming SendDocument is synchronous or forgetting to verify webhook signatures.

The BoldSign eSignature Skill encodes all of this knowledge into a package Claude can reference every time you ask for help. Think of it as giving Claude the entire senior developer onboarding guide before it writes a single line of code.

Anatomy of the BoldSign Skill

The Skill ships as a folder containing a root SKILL.md and a set of reference files organized by stack and workflow:

    BoldSign/
    ├── SKILL.md                          ← Main entry point Claude reads first
    ├── references/
    │   ├── stacks/
    │   │   ├── nodejs.md                   ← Node.js / TypeScript SDK
    │   │   ├── python.md                   ← Python SDK
    │   │   ├── dotnet.md                   ← .NET / C# SDK — our focus today
    │   │   └── php.md                      ← PHP SDK
    │   └── workflows/
    │       ├── embedded-saas.md            ← Embedded send + sign in iframes
    │       └── multi-signer.md             ← Sequential, parallel, bulk signing

The root SKILL.md covers the universal concepts: authentication models, rate limits, sandbox vs live environments, webhook events, form field types, text tags, and the critical “document sending is asynchronous” warning. It then directs Claude to load the right stack file, in our case, references/stacks/dotnet.md, based on your request.

This layered structure means Claude loads only what’s relevant. Asking for a C# webhook handler won’t pull in the Node.js or Python references, keeping the context window lean.

Installing the Skill

Using the BoldSign Skill in Code Studio is straightforward. Here’s the process:

1. Get the Skill folder

Download or clone the BoldSign folder containing SKILL.md and the references/ directory.

**2. **Upload to Code studio’s Skill directory****

Place the folder in /.codestudio/skills/. The Skill is automatically triggered when working on BoldSign or document‑signing related tasks.

Code Studio Dashboard View

3. Select your AI model

Open the model selector at the bottom of Code Studio and choose the model you want to use.

AI Model Selection for Code Studio

4. Start prompting

Just ask AI to integrate eSignature. Once the BoldSign/ folder is added to the AI context, you can prompt normally without any special commands.

Prompt Input for Executing Request

Popular AI coding agents that support Skill

Many modern AI coding agents allow developers to load external context folders such as the BoldSign Skill, so the agent can generate accurate, SDK aligned integration code.

Syncfusion Code Studio — AI code editor / IDE for enterprise app development.
Claude Code — Anthropic’s AI coding agent for terminal, IDE, desktop, and browser.
Cursor — AI-first code editor.
GitHub Copilot Coding Agent — GitHub’s coding agent for project tasks and fixes.
OpenAI Codex — OpenAI’s AI coding partner / agent platform.

Quickstart: Generate your first eSignature using the Skill

Once the Skill is installed, getting a working eSignature flow is remarkably fast. Here’s a real conversation flow targeting .NET / C#:

Prompt

    "Send a PDF for signature using BoldSign in .NET C# with API Key authentication.
    Then add a webhook handler for this flow in ASP.NET Core.
    Finally, generate an embedded signing link so signers can sign inside my app instead of through email, with each part implemented independently."

Send a document

Claude uses the BoldSign reference files added to context, systematically pulls in references/stacks/dotnet.md, and generates an implementation-ready example with the NuGet SDK, form field placement, signer configuration, and the critical reminder that sending is async:

    using BoldSign.Api;
    using BoldSign.Model;
    public async Task<string> SendDocumentAsync()
    {
        var apiClient = new ApiClient(
            "https://api.boldsign.com",
            Environment.GetEnvironmentVariable("BOLDSIGN_API_KEY")
        );
        var documentClient = new DocumentClient(apiClient);
        using var fileStream = File.OpenRead("contract.pdf");
        var documentFile = new DocumentFileStream
        {
            ContentType = "application/pdf",
            FileData    = fileStream,
            FileName    = "contract.pdf"
        };
        // Define where the signature field appears on the PDF
        var bounds = new Rectangle
            { X = 100, Y = 200, Width = 200, Height = 50 };
        var signatureField = new FormField
        {
            FieldType  = FieldType.Signature,
            PageNumber = 1,
            Bounds     = bounds,
            IsRequired = true
        };
        var signer = new DocumentSigner(
            name:         "John Doe",
            emailAddress: "john@example.com",
            signerType:   SignerType.Signer,
            formFields:   new List<FormField> { signatureField }
        );
        var sendRequest = new SendForSign
        {
            Title   = "Service Agreement",
            Message = "Please sign this agreement.",
            Signers = new List<DocumentSigner> { signer },
            Files   = new List<IDocumentFile> { documentFile }
        };
        var result = documentClient.SendDocument(sendRequest);
        Console.WriteLine($"Document ID: {result.DocumentId}");
        // ⚠️ Async — use webhooks to confirm Sent status
        return result.DocumentId;
    }

Add a webhook handler

Claude generates an ASP.NET Core controller with raw body reading (required for HMAC), X-BoldSign-Signature verification, and handlers for Completed, Declined, and SendFailed — including the signed PDF download step that many developers forget:

    [ApiController]
    [Route("webhooks")]
    public class BoldSignWebhookController : ControllerBase
    {
        [HttpPost("boldsign")]
        public async Task<IActionResult> HandleWebhook()
        {
            // 1. Read raw body for HMAC verification
            using var reader = new StreamReader(Request.Body);
            var body = await reader.ReadToEndAsync();
            // 2. Verify HMAC SHA-256 signature
            var signature = Request.Headers["X-BoldSign-Signature"].ToString();
            var secret = Environment.GetEnvironmentVariable("BOLDSIGN_WEBHOOK_SECRET");
            var expectedSig = ComputeHmac(body, secret);
            if (signature != expectedSig)
                return Unauthorized();
            // 3. Parse and route event
            var payload = JsonSerializer.Deserialize<JsonElement>(body);
            var eventType = payload
                .GetProperty("event")
                .GetProperty("eventType").GetString();
            var documentId = payload
                .GetProperty("document")
                .GetProperty("documentId").GetString();
            switch (eventType)
            {
                case "Completed":
                    await HandleCompleted(documentId);
                    break;
                case "SendFailed":
                    // Alert ops — don't silently swallow failures
                    break;
                case "Declined":
                    // Notify relevant parties
                    break;
            }
            return Ok();
        }
        private async Task HandleCompleted(string documentId)
        {
            // Download signed PDF + audit trail
            var pdf = documentClient.DownloadDocument(documentId);
            await File.WriteAllBytesAsync(
                $"signed/{documentId}.pdf", pdf);
            var audit = documentClient.DownloadAuditLog(documentId);
            await File.WriteAllBytesAsync(
                $"signed/{documentId}-audit.pdf", audit);
        }
        private string ComputeHmac(string message, string secret)
        {
            var keyBytes = Encoding.UTF8.GetBytes(secret);
            var msgBytes = Encoding.UTF8.GetBytes(message);
            using var hmac = new HMACSHA256(keyBytes);
            var hash = hmac.ComputeHash(msgBytes);
            return Convert.ToHexString(hash).ToLower();
        }
    }

Embed signing in the frontend

Claude produces the C# backend method that generates a short-lived sign link, ready to be loaded in an <iframe> on your frontend:

    public string GetEmbeddedSignLink(
        string documentId,
        string signerEmail)
    {
        var signLinkExpiry = DateTime.UtcNow.AddHours(24);
        var result = documentClient.GetEmbeddedSignLink(
            documentId:        documentId,
            signerEmail:       signerEmail,
            signLinkValidTill: signLinkExpiry,
            redirectUrl:       "https://yourapp.com/signing-complete"
        );
        return result.SignLink; // load in <iframe>
    }

Supported workflows & prompts

Here’s a quick reference of what you can ask for and which parts of the Skill Claude will use:

What you want	Example prompt	Skill files used
Basic document send	“Send a PDF for signature using .NET C#”	`SKILL.md` + `dotnet.md`
Template-based send	“Send from a BoldSign template in C#”	`SKILL.md` + `dotnet.md`
Embedded signing	“Embed signing in my ASP.NET app via iframe”	`SKILL.md` + `dotnet.md`
Embedded sending	“Let users prepare and send docs without leaving my app”	`SKILL.md` + `embedded-saas.md`
Multi-signer / sequential	“Set up a 3-party NDA with sequential signing in C#”	`SKILL.md` + `multi-signer.md`
Webhook setup	“Add BoldSign webhooks to my ASP.NET Core API”	`SKILL.md` + `dotnet.md`
Download signed PDF	“Download the completed document and audit trail in C#”	`SKILL.md` + `dotnet.md`

Getting webhooks right

BoldSign’s document operations are asynchronous. The API returns a DocumentId immediately, but the document isn’t “sent” yet. The Skill makes sure Claude never generates code that treats SendDocument as synchronous. Instead, it always pairs document sending with a webhook handler.

The key webhook events you need to handle:

Event	When it fires	What to do
`Sent`	Document processing complete	Update status to “sent” in your DB
`SendFailed`	Processing failed	Alert your ops team; do not swallow this
`Signed`	One signer completes	Track progress; for sequential flows, next signer is auto-notified
`Completed`	All signers done	Download signed PDF + audit trail → store permanently
`Declined`	A signer declined	Notify relevant parties; the entire doc halts
`Expired`	Document passed its expiry date	Clean up and optionally resend

BoldSign retries webhook delivery for up to 8 hours if your server is down, so you have a generous buffer. But always respond with a 200 OK quickly, and do heavy processing (like PDF downloads) in a background task.

Common pitfalls the Skill prevents

One of the biggest advantages of a Skill over raw LLM code generation is that it encodes hard-won lessons. Here are mistakes the BoldSign Skill prevents Claude from making:

Polling instead of webhooks

Polling burns through your rate limit (50/hr in sandbox, 2,000/hr in prod). The Skill always generates webhook-based status tracking.

Using JSON for file uploads

File uploads must use multipart/form-data, not application/json. The .NET SDK handles this via DocumentFileStream, but the Skill ensures Claude uses it correctly.

Assuming SendDocument is synchronous

The API returns a DocumentId immediately, but the document is still processing. The Skill adds a comment warning and webhook handler every time.

Skipping HMAC verification

Without signature verification, anyone can POST fake events to your webhook endpoint. The Skill never generates a controller without HMACSHA256 validation.

Hardcoding API keys

By Design, every code sample the Skill produces reads credentials securely via Environment.GetEnvironmentVariable or appsettings.json, never inline strings.

Forgetting to set the region base URL

EU, AU, and CA accounts require a different base URL. The Skill reminds Claude to configure eu-api.boldsign.com (or the correct regional endpoint) when the user specifies a non-US region.

Advanced: Embedded send + sign architecture

For apps that want the full white-label experience, where neither the sender nor the signer ever leaves your application, the Skill helps generate an embedded send-and-sign architecture. Here’s the flow:

Your .NET Application

Step 1: Sender prepares document

POST /v1/document/createEmbeddedRequest → Returns sendUrl → Load in : sender drags fields, clicks Send

Step 2: Signer signs inside your app

GET /v1/document/getEmbeddedSignLink → Returns signLink → Load in : signer reviews and signs

Step 3: Webhook events

Sent → Signed → Completed → DownloadDocument + DownloadAuditLog → store

The Skill’s embedded-saas.md and dotnet.md references give Claude everything it needs to generate: the EmbeddedDocumentRequest with ShowToolbar, ShowSaveButton, and ShowSendButton configuration; the sign link generation with expiry and redirect URL; and the ASP.NET Core webhook controller that downloads the signed PDF on Completed.

Tip — Template-Based Sending: If your documents follow a repeatable structure (contracts, NDAs, offer letters), use BoldSign Templates. Create the template once in the BoldSign web app with pre-placed fields, then send via TemplateClient.SendUsingTemplate. No coordinate math required. The Skill generates the SendForSignFromTemplate code with role mapping automatically.

What’s next

With the BoldSign Skill added to Code Studio, you can seamlessly start generating implementation‑ready eSignature workflows directly from prompts. Begin by building and testing a basic document‑send flow in the Sandbox environment, then extend it with webhooks, embedded signing, templates, or multi‑signer workflows as your requirements evolve.

To get started, sign up for a free BoldSign Sandbox account and explore the available APIs and SDKs in the BoldSign Developer Documentation. Use the Skill alongside Code Studio to iterate quickly on your integration.

If you need help during setup or testing, visit the BoldSign support portal to connect with the team.

Related blogs

Note: This blog was originally published at boldsign.com

E-Signature Retention: How Long Should You Keep Records

Vijay Amalan — Wed, 18 Mar 2026 06:25:51 +0000

Picture this: it’s a normal Tuesday, and then “bam” you get an email saying you’ve been selected for an audit. You locate the contract quickly… but then the follow-up question lands: can you prove who signed it, when they signed it, and what exactly they agreed to? And when you think you’re clear, a privacy review asks the opposite: Did you keep that personal data longer than necessary?

This is the daily balancing act of modern recordkeeping, retaining electronic signatures long enough for legal enforceability but not so long that you violate privacy rules.

An electronic signature is any electronic method used to indicate a person’s intent to sign or approve a document. Instead of signing with pen and paper, the signer uses a digital process such as typing their name, clicking a button, drawing a signature on screen, or using a secure digital certificate to show agreement to the document’s content.

In legal terms, an electronic signature is not about the technology itself, but about intent, consent, and attribution. When properly captured and retained, e‑signatures can be legally binding and enforceable, carrying the same legal effect as handwritten signatures in many jurisdictions.

Common examples include:

Signing a contract through an e‑signature platform
Clicking to accept terms and conditions online
Electronically approving HR forms, invoices, or consent documents

The short answer is that there is no single universal retention period. Instead, electronic signatures must be retained for as long as the underlying record is legally required to be kept. This article explains how retention requirements work, what laws say and don’t say, and how organizations can build a compliant retention strategy.

Privacy law vs. State law: Why retention rules can pull in different directions

Electronic signature retention is shaped by two overlapping legal forces that do not always align neatly:

State laws generally address state record‑keeping laws and privacy or data‑protection laws. How long must records be retained to support enforcement, audits, or litigation? These rules often come from statutes of limitation, labor laws, tax regulations, or sector regulators, and they typically push organizations toward longer retention periods to preserve evidentiary value.

Privacy laws, by contrast, focus on how long personal data should be kept. Most modern privacy frameworks require organizations to retain personal data only for as long as it is necessary for a legitimate legal or business purpose. Once that purpose expires, continued storage can itself become a compliance risk.

For electronic signatures, this creates a balancing act: organizations must retain signature records long enough to satisfy legal and regulatory obligations, but not longer than justified once those obligations end. A defensible retention policy clearly links the retention period to a legal requirement and defines when and how signature data is securely disposed of afterward.

The role of the audit trail in electronic signatures

An electronic signature is rarely just a visual mark on a document. Its legal strength comes from the audit trail that accompanies it.

An audit trail typically records key evidence such as who signed, when they signed, how they were authenticated, and whether the document was altered afterward. This metadata is often critical in audits, disputes, or regulatory reviews, where the question is not merely whether a document exists, but whether the signature can be trusted.

From a retention perspective, the audit trail must be preserved for the same duration as the signed document itself. Retaining only the signed PDF without its supporting audit data can weaken enforceability, while retaining audit data longer than necessary may raise privacy concerns. Well-designed e‑signature retention practices treat the document and its audit trail as a single evidentiary record, governed by the same retention and disposal rules.

Electronic signatures and the law: What is actually required

In the United States and many other jurisdictions, electronic signatures are legally equivalent to handwritten signatures when certain conditions are met.

Under key laws such as the Electronic Signatures in Global and National Commerce (ESIGN) Act and the Uniform Electronic Transactions Act (UETA):

A contract or signature cannot be denied legal effect simply because it is electronic.
If a law requires a record to be retained, an electronic version satisfies that requirement, provided it is accurate, accessible, and reproducible for later reference.

However, neither ESIGN nor UETA specifies exact timeframes for retention. Instead, they defer to existing record-keeping requirements, industry regulations, and statutes of limitation.

The core principle: Retain the signature as long as the record

An electronic signature should be retained for the same duration as the document it signs. This principle is widely accepted by regulators, courts, and records management authorities.

For example:

If an employment contract must be kept for 7 years, the e-signature evidence must also be kept for 7 years.
If tax records must be retained for audit purposes, the electronic signatures associated with those records must remain accessible during that period.

Destroying the signature data before the document’s retention period ends can undermine enforceability and legal defensibility.

Typical retention periods by document type

Although requirements vary by jurisdiction, industry, and organization, the following general guidelines are commonly used:

1. Commercial contracts

Most jurisdictions tie contract retention to statutes of limitation for enforcement. In many U.S. states, the period is 3 to 6 years for written contracts, with some extending to 10 years for real estate or long-term obligations.

2. Employment and HR records

Employment agreements, offer letters, and policy acknowledgements are often retained 5 to 7 years after termination, depending on labor laws and dispute risk. Regulatory bodies emphasize that electronic signatures must remain readable and retrievable throughout this period.

3. Financial and tax records

Tax authorities typically require retention of supporting records for 3 to 7 years. Electronic signatures on invoices, loan documents, or consent forms must be preserved accordingly.

4. Regulated industries

Industries such as banking, healthcare, and life sciences may be subject to extended retention requirements, typically 7 to 15 years, with strict rules on integrity, audit trails, and access controls.

What must be retained along with the signature

Keeping a signed PDF alone may not be sufficient. To ensure legal defensibility, best practice is to retain:

The signed electronic document
Audit trails (date, time, IP address, authentication method)
Signer consent records
Tamper-evident certificates or logs, where applicable

Both ESIGN and UETA stress that electronic records must be capable of accurate reproduction for later reference, which includes the ability to prove how the signature was created.

Electronic signature retention periods by industry

Key rule: Electronic signatures must be retained for the same length of time as the underlying record, and in a form that is accurate, accessible, and reproducible throughout the retention period.

Industry	Common documents signed electronically	Typical retention period	Regulatory / Legal basis
General Commercial / Corporate	Sales contracts, NDAs, vendor agreements	3–6 years after contract termination	Statutes of limitation for written contracts; ESIGN/UETA require records to remain accessible
Human Resources & Employment	Employment contracts, offer letters, policy acknowledgements	5–7 years after termination	Labor and employment record‑keeping rules; records must remain readable and reproducible
Finance & Banking	Loan agreements, account openings, customer consents	5–7 years (often longer for active loans)	Financial regulations and audit requirements; electronic records must be capable of accurate reproduction
Insurance	Policies, claim forms, beneficiary designations	6–10 years after policy expiration or claim closure	Industry‑specific record retention laws and litigation risk periods
Healthcare & Life Sciences	Patient consents, clinical trial agreements	7–15 years (or longer for clinical trials)	Sector regulations require long‑term integrity, audit trails, and accessibility of electronic records
Government & Public Sector	Licenses, permits, citizen forms	As defined by official records schedules (often 7–10+ years)	Public records and archives rules; electronic records must remain trustworthy and inspectable
Tax & Accounting	Tax filings, invoices, audit confirmations	3–7 years	Tax authority audit and compliance requirements; ESIGN allows electronic retention if records are accurate
Real Estate	Leases, purchase agreements, disclosures	7–10 years or longer	Property and contract limitation periods; heightened evidentiary requirements

Storage and access requirements matter

Retention is not just about time; it’s also about usability.

Regulatory guidance consistently requires that electronic records:

Remain accessible to authorized parties
Are protected against alteration or loss
Can be retrieved and reproduced during audits, litigation, or inspections

Failure to maintain proper access, even if the document technically still exists, can be treated as non-compliance.

Data privacy and retention: Finding the balance

Retention laws must be balanced with data protection principles. Privacy regulations generally require organizations not to retain personal data longer than necessary.

As a result, many organizations adopt a policy of retaining electronic signatures:

For the full legal or regulatory requirement, and
No longer than necessary once that requirement expires

A defensible retention schedule should clearly define when records are destroyed and why.

Best practices for electronic signature retention

To manage electronic signature retention effectively:

Align retention periods with record type requirements, not the signature itself.
Use e-signature platforms that generate audit trails and tamper-evident records.
Integrate e-signature records with your records to manage the mentor document management system.
Review retention schedules regularly to reflect legal and regulatory changes.
Document your policies and ensure consistent enforcement across departments.

Authoritative records management guidance consistently emphasizes that retention planning should occur before electronic signature adoption, not after.

Conclusion

There is no single answer to how long electronic signatures should be retained, but the guiding rule is simple: retain them for as long as the signed record itself must be kept. Laws like ESIGN and UETA ensure electronic signatures are valid, but they place the responsibility for retention squarely on organizations.

By aligning electronic signature retention with legal requirements, industry regulations, and sound records management practices, organizations can protect themselves from legal risk while maintaining compliance and efficiency.

Related blogs

Note: This blog was originally published at boldsign.com

BoldSign Launches Salesforce eSignature Integration

Vijay Amalan — Tue, 17 Mar 2026 08:58:13 +0000

BoldSign now offers a direct eSignature integration for Salesforce. If your team already runs on Salesforce, you can now send documents for signature, track their status, and store signed copies, all without leaving your CRM.

This guide covers what the integration does, how to set it up, and what your team gains once it’s connected.

What the integration actually changes

Without an eSignature integration, document work sits outside Salesforce. Teams prepare files in one tool, send them through another, and then manually update CRM records once signing is done. Files land in the wrong place. Follow-ups get forgotten. Records fall out of sync.

With BoldSign connected, the full document workflow lives inside Salesforce. Sending a contract, checking its status, and storing the signed copy all happen from the same CRM screen your team already uses every day.

Key features of the BoldSign Salesforce integration

Send documents from any Salesforce record

Start a signing request from a Lead, Contact, Account, or Opportunity without leaving that record. Signer names and email addresses pull in from Salesforce automatically, so there is no need to copy data or switch between tabs.

Auto-fill documents using Salesforce data

Map BoldSign templates to Salesforce fields and documents fill themselves in before they are sent. Contact names, company details, deal values, and dates populate automatically, reducing preparation time and removing the risk of sending a document with missing or incorrect information.

Track signing status in real time

See whether a document has been sent, viewed, or signed directly from the Salesforce record. Your team always knows where each document stands without checking a separate tool, which makes timely follow-ups much easier to manage.

Store signed copies back to Salesforce automatically

Once signing is complete, BoldSign attaches the final PDF to the Salesforce record it was sent from. No manual upload is needed. The signed document and its audit trail are saved exactly where they belong.

Send one-off documents without a template

For documents that do not follow a fixed format, upload a file and send it for signature directly from Salesforce. This is useful for custom agreements, one-time approvals, or anything outside your standard document types.

How signing works step by step

1. Open a record in Salesforce

A team member opens any Opportunity, Lead, Contact, or Account and starts a signing request from within that record.

2. Select a template or upload a document

They choose a BoldSign template with mapped Salesforce fields, or upload a document for a one-time send. Mapped templates fill with Salesforce data automatically.

Salesforce Record

3. Confirm and send

They review the document and signer details, then send it. The signer receives a secure link by email.

4. Signer reviews and signs

The signer clicks the link and signs from any device. No account or software is needed on their end.

5. Status updates on the record

The signing status on the Salesforce record updates as the signer opens and completes the document.

BoldSign - Track Document Status

6. Signed PDF saves to Salesforce

Once all signatures are collected, the completed PDF is automatically attached to the Salesforce record.

Completed Documents

How to set up BoldSign in Salesforce

Setup requires no coding and is handled by a Salesforce admin. Most teams are ready to send documents on the same day they install the integration.

1. Enable Salesforce in your BoldSign account

Enable Salesforce integration in BoldSign by going to the Settings menu, opening Integrations, selecting Salesforce, and following the prompts to activate it.

Enable Salesforce

2. Install from Salesforce AppExchange

Find BoldSign on the Salesforce AppExchange and install it into your org following the standard AppExchange process.

BoldSign in Salesforce AppExchange

3. Connect your BoldSign account

Go to the BoldSign integration settings inside Salesforce and link your BoldSign account. New users can sign up for a free trial at this point.

Connect BoldSign into Salesforce

4. Assign user permissions

Set access for the team members who will send and manage documents. Permissions can be assigned by role to control who can send, view, and track documents.

Inviting Users

5. Map templates to Salesforce fields

Create your standard document templates in BoldSign and map them to the relevant Salesforce fields. Once mapped, those fields auto-fill every time a document is sent using that template.

Create Template

Prepare Template

Configure Template Field

Map the BoldSign field ID to Salesforce source field

6. Send your first document

Test the setup by sending a document from an Opportunity or Contact record, then roll out access to the rest of your team.

What this saves your team

Connecting BoldSign to Salesforce removes several manual steps from the document process. Sender spend less time on document preparation because Salesforce data fills templates automatically. Operations teams spend less time filing because signed copies are stored automatically. And everyone spends less time on follow-up because signing status is visible directly in Salesforce rather than buried in a separate inbox or tool.

The result is a cleaner CRM, fewer dropped documents, and a shorter gap between agreement and signature with the BoldSign Salesforce integration.

Get started with BoldSign for Salesforce

If your team lives in Salesforce, signing should happen there too. BoldSign keeps sending, tracking, and saving signed documents inside the record, so deals move faster and nothing gets missed.

Install BoldSign from the AppExchange and start a free trial to send your first document today. If assistance is needed Request a demo or visit our Support Portal for quick help.

Related blogs

Note: This blog was originally published at boldsign.com

Free WhatsApp QR Code Generator for Instant Chat Links

Vijay Amalan — Mon, 16 Mar 2026 05:55:29 +0000

We are excited to introduce the BoldSign WhatsApp QR Code Generator, a fast and user-friendly tool that lets anyone start a WhatsApp conversation in one quick scan. Whether you want customers to reach your business, clients to message you instantly, or attendees to contact support without typing a number, this tool makes communication simple and immediate.

Messaging people on WhatsApp should be easy, but manually typing numbers or searching contacts often slows people down. With our WhatsApp QR Code Generator, you can instantly create a scannable code that opens a WhatsApp chat with your chosen phone number. You can also prefill a message along with your number to guide users with a ready-to-send text. Perfect for customer support, sales teams, event staff, service professionals, or anyone who wants faster message based communication. Start chats instantly with a QR code that needs no typing, no searching, and no friction.

Why should you try this tool

Here’s why this WhatsApp QR Code Generator stands out as a fast, reliable, and user‑friendly option for anyone who wants instant messaging.

100% Free, No Hidden Cost: Create WhatsApp QR codes without paying anything. No watermarks, no limits.
No Sign Up Required: Just enter your number, generate your QR code, and start sharing instantly.
Instant Message Access: One scan opens a WhatsApp chat window with your number prefilled.
Privacy First: Everything happens within your browser. Your number is never stored or sent anywhere.
Works on All Devices: Compatible with phones, tablets, and computers, using any modern browser.
Fast and Simple: Generate shareable WhatsApp QR code in seconds with a clean, easy interface.

Key features

Optimized for professional use, these features provide everything you need to create a clean, customizable WhatsApp QR code with ease.

Secure Processing: Your QR code is created directly in your browser to ensure your number stays private.
Easy to Use: A clean, simple layout makes creating your WhatsApp QR code effortless.
Cross Platform Support: Works perfectly on Windows, macOS, Linux, iOS, and Android.
Customizable Output: Adjust QR code pattern color, background color, and size to match your brand or design.
Preview Before Downloading: See your QR code in real time before saving.
Reset with One Click: Start over instantly without reentering details.
High Quality Downloads: Save your QR code as PNG, JPEG, or SVG for print or digital use.

How to get started

Creating your WhatsApp QR code is quick and hassle free. Follow these easy steps:

Visit the Tool: Open the BoldSign WhatsApp QR Code Generator.
Enter your WhatsApp number: Add the number you want people to contact instantly.
Customize your QR code: Adjust the pattern color, background color, and size.
Download Your QR Code: Save your final QR code as PNG, JPEG, or SVG. Share it on print or digital platforms.

Best ways to use a WhatsApp QR code

WhatsApp QR codes help people message you instantly without saving your phone number manually.

Use them on:

Business cards – Let people message you without typing your number.
Storefronts – Visitors can instantly contact support or sales.
Flyers and posters – Ideal for promotions, bookings, and quick inquiries.
Event booths – Easy for attendees to reach your team instantly.
Websites and landing pages – Convert visitors instantly with one scan.
Social media posts – Drive direct WhatsApp conversations from your campaigns.

Conclusion

A WhatsApp QR code makes communication faster and easier. It removes manual steps, prevents typing errors, and allows customers or users to message you instantly with a simple scan. Whether you are running a business, managing support, or promoting a service, this tool ensures seamless and immediate WhatsApp engagement.

Create your WhatsApp QR Code with BoldSign today and make conversations effortless.

Want to streamline more workflows? Try a free BoldSign trial and explore our secure e-signature platform.

For more details about BoldSign’s features, schedule a personalized demo or contact our support team via our support portal.

Related blogs

Note: This blog was originally published at boldsign.com

Why SOC 2 Certification Matters for E-Signature Platforms

Vijay Amalan — Thu, 12 Mar 2026 05:39:35 +0000

E-signature platform providers operate in a high-risk area. This is due to the fact that they often handle legally binding documents, PII, financial data, and metadata on authentication. E-signature platforms are often considered critical vendors for companies that use them. This means it is essential to choose a software provider that maintains high standards for security and legal compliance.

A SOC 2 report is one method to validate the security and compliance of an e-signature platform provider. It is a rigorous auditing procedure developed by the American Institute of CPAs (AICPA) that ensures service providers manage data securely to protect the interests of their clients and the privacy of their clients’ customers.

In this blog, we will explore what customers should verify beyond just “does the provider have a SOC 2 report?” and outline some key items customers should pay attention to when evaluating an e-signature software provider.

What is an e-signature

An electronic signature, more often called an “e-signature,” is an increasingly common method of signing one’s name on a document. An e-signature includes typing one’s name into signature box or using a cursor to digitally draw one’s signature onto a document and then clicking “I Accept.” An e-signature can carry legal validity, and as such, it is important to use an e-signature service provider whose technical measures are in line with your compliance requirements to ensure e-signature validity.

What SOC 2 is and is not

SOC 2 is an independent assurance report, not merely a certification or badge, issued by a licensed CPA firm using AICPA Trust Services Criteria. SOC 2 evaluates controls, not products or features.

Trust Services Criteria Overview

Security
Availability
Processing
Integrity
Confidentiality
Privacy

For e-signature software providers, Trust Services Criteria are important to pay attention to. Security can mean access control and encryption for protecting contracts and attachments. The availability principle guides providers’ uptime commitments and disaster recovery. Meeting processing and integrity criteria demonstrates accurate execution of signing workflows. Privacy and Confidentiality (especially when PII is involved) address the management of personal information and ensures that it is collected, used, retained, and disclosed in accordance with privacy policies and regulations.

SOC 2 Type I vs. Type II: what customers should expect

Customers increasingly expect Type II over Type I reports. There is a clear reason why.

Type I: Point‑in‑time review of control design.

Type II: Controls tested over time (typically 3–12 months).

Type I may be acceptable for early‑stage vendors or for providers in the middle of a transition period. However, Type II has an obvious edge due to its ability to provide assurance of operating effectiveness over a longer period.

What customers should verify in an e‑signature software provider’s SOC 2 report

1. Scope: what systems are actually covered

The scope description should be reviewed by customers to verify that the specific e-signature platform provider is in scope, not just the overarching corporation. Overly narrow system descriptions can be a red flag as it may indicate the report is not fully encompassing the systems you will be utilizing. On the other hand, an overly broad or vague scope can be a red flag, as the specifics of the platform you are using may not have been reviewed.

2. Audit period and report currency: is the report still valid

Customers should review the date of the audit report provided to them. SOC 2 reports are valid for 1 year from issuance, so note if the audit was completed within the last 12 months. An outdated report should weaken the assurance you have in a provider. At minimum, customers should inquire as to when or if the provider expects to have a new report published soon. If one is planned, customers should wait and review the new report for the most up-to-date view of the provider’s information security controls.

Customers should also pay attention to the audit period length: was it short or a meaningful review window? There is a difference between an audit report demonstrating an organization was able to keep its security controls effectively operating for 12 months versus a three-month window.

3. Complementary controls: does the provider maintain relevant controls

Customers should look for the controls that align with their needs concerning e-signatures. Some relevant controls to review could be those related to incident responses and breach notifications to ensure proper alignment with your regulatory needs.

Depending on your location, you may want to review controls that support compliance with e-signature laws within your jurisdiction. These could include controls relating to data integrity, encryption, and audit trails.

How SOC 2 fits into vendor due diligence for e‑signatures

SOC 2 reports can be seen as a starting point, not the full security review. Customers can review a report in depth to validate if their requirements are met through the specific controls a company has in their report. This review can accompany security questionnaires, legal reviews, and technical reviews that you may want to conduct.

Conclusion: Importance of an e‑signature provider’s SOC 2 report

A SOC 2 report should provide a clear scope, include relevant Trust Services Criteria, and have a recent audit period. Customers should be sure to ask informed questions based on their industry, company needs, and compliance requirements. A SOC 2 report is part of building a relationship of trust between e-signature platform providers and their customers. It demonstrates commitment to security and transparency.

You can review information on BoldSign’s SOC 2 Type II report here. Additionally, new and existing customers can use this form to submit a request to review BoldSign’s most recent SOC 2 Type II report.

Want to get your documents signed legally? Try a free BoldSign trial and explore our complete e-signature platform.

Need help? Schedule a demo or contact our support team via our support portal. You can also visit the BoldSign help center for quick step-by-step guides.

Related blogs

Note: This blog was originally published at boldsign.com