DEV Community: BoldSign

How to Manage Document Access Across Teams with Custom Permissions

Vijay Amalan — Tue, 12 May 2026 03:43:22 +0000

When teams work across departments, document access can become messy fast.

If access is too limited, collaboration slows down. Sales cannot loop in Legal quickly, Finance cannot review deal paperwork, and teams start finding workarounds. If access is too broad, sensitive documents become visible to people who should not see them.

BoldSign Custom Permissions help solve both problems. They let Account Admins give specific users or teams access to selected resources and actions without opening up the entire account. That means you can support cross-team work while keeping control over sensitive files.

What are custom permissions in BoldSign?

A custom permission let Account Admins override default role-based access and grant or deny specific actions for users or teams.

By default:

Team Admins can manage resources within their own team
Members can manage their own documents and templates
Users cannot access documents from other teams unless permission is explicitly granted

With Custom Permissions, admins can allow or restrict actions such as:

View Metadata
View Document
Edit
Delete

This makes it possible to support collaboration across teams without removing existing security boundaries.

How roles work

BoldSign organization accounts support three main roles:

Primary Roles and Permissions

Account admin

Oversees the entire BoldSign account with full control over users, teams, and settings.
Create, edit, and delete users and teams.
Manage all documents, templates, bulk sends, and links.
Grant or revoke Custom Permissions.
Track permission history and audit logs.

Team admin

Manages a specific team or department. Limited by default to that team’s resources.

Add or remove team members.
Create, send, and track documents, templates, and bulk sends within their team.
View and edit team-specific reports.
Cannot access other teams’ documents without Custom Permissions.

Member

Standard user with the most restricted access, handling day-to-day eSignature tasks.

Create, send, and manage their own documents and templates.
View personal document history and reports.
No access to team-wide or cross-team resources unless explicitly granted.

For more details on account roles and their privileges, check our article on Account roles and privileges in BoldSign.

Why custom permissions matter

Custom Permissions are useful when teams need to collaborate without exposing unrelated or sensitive information.

Common examples include:

Letting Legal review contracts created by Sales
Allowing Finance to access selected deal documents without exposing HR files
Giving a team member view-only access to templates from another department
Blocking a Team Admin from deleting certain completed documents

This approach helps organizations balance collaboration, security, and auditability.

What resources can admins control?

Custom Permissions can be applied to:

Documents
Templates
Bulk Links
Bulk Sends

Admins can grant or deny access for specific actions depending on the resource and user involved.

How to create a custom permission

Setting up a Custom Permission in BoldSign takes only a few steps.

Go to Users & Teams from the dashboard.
Select Custom Permissions.
Click New Custom Permission.
Choose the user or users who need access.
Select the Entity Type, such as Documents, Templates, Bulk Link, or Bulk Send.
Choose the team whose resources should be shared or restricted.
Select the actions to allow or deny, such as View Metadata, View Document, Edit, or Delete.
Set Access Type to Allow or Deny.
Click Save.

How to deny access

Admins can also use Custom Permissions to block access.

For example, if a Team Admin should not be able to delete completed documents created by their team, an Account Admin can create a rule with Access Type = Deny for that action and resource.

This is useful when you want tighter control over sensitive or regulated workflows.

Enabling downloads for team documents

One important use case is download access. By default, Account Admins and Team Admins cannot download team documents, Bulk Link files, or Bulk Send documents unless the required permission is enabled. To allow downloads, admins must grant View Document access for the relevant team and resource type. This is useful for archiving, audits, and compliance reviews.

Managing and tracking permissions

Once Custom Permissions are in place, you can easily monitor and adjust them as your organization’s needs change.

View history: Back on the Custom Permissions page, use the Filter button to search by user, team, or date. Apply filters to see granted and denied permissions and their history.
Edit or delete: Select a permission record and click Edit to modify it, or Delete to revoke it. Deleting a Custom Permission cancels access immediately.

Conclusion: Elevate your workflow with precision

Custom Permissions in BoldSign turn rigid role-based defaults into a flexible, dynamic access management system. This enables secure collaboration without exposing unnecessary data. With these tools, Account Admins can block unauthorized access to other teams’ documents while still allowing trusted users to download and edit files where appropriate.

Ready to get started?

Sign up for BoldSign’s 30-day free trial and start using Custom Permissions today. Prefer a walkthrough? Schedule a demo with our team to see Custom Permissions in action.

Related blogs

Note: This blog was originally published at boldsign.com

How to Retrieve Uploaded Identity Verification Documents via API

Vijay Amalan — Mon, 11 May 2026 04:21:31 +0000

If a signer uploads an ID document during BoldSign identity verification flow, you can later download that same image through the Identity Verification APIs. This is for developers building KYC, onboarding, healthcare, or legal workflows who must access uploaded ID documents, even when automated verification fails. In this guide, you’ll see exactly how to get the fileId from the Identity Verification Report and then use it with the Identity Verification Image API to download the image stream, with code samples in multiple languages.

What is BoldSign identity verification and when is it useful?

BoldSign Identity Verification is a signer authentication feature that adds an identity check to your eSignature workflows. It:

Validates whether a signer is who they claim to be before they can access or sign a document.
Works with flows where verification requests are delivered via email, SMS, or WhatsApp delivery modes.
Lets signers upload government-issued IDs for proof-of-identity checks.
Supports both automated verification and manual review.
Stores verification data (including images) so senders can retrieve reports and documents later for audits and compliance.

Why would you need to download identity verification documents?

You typically want to download uploaded ID images when:

Automated verification fails and a human must review the document (glare, blur, cropping, etc.).
Your organization must meet KYC/AML or industry-specific regulations.
You need to retain ID documents for audits or regulatory reviews.
You want to avoid asking signers to re-upload the same document, reducing friction and drop-offs.
You must confirm identity before executing high-value or high-risk agreements.

Downloading verification images via API keeps identity data inside your controlled systems instead of spreading copies across email chains or screenshots.

What you’ll need before calling the identity verification API

Make sure you have:

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 documentId for the document that used identity verification
The signer’s identifier used during verification:
- Email address, if the verification request was delivered via email, or
- Country code + phone number, if the request was delivered via SMS or WhatsApp.

Authentication headers should be in one of the following formats:

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

Which endpoints do you use to retrieve identity documents?

Task	Method + Path	Key inputs	Output
Get verification report + fileId	POST /v1/identityVerification/report	documentId (query), emailId or countryCode + phoneNumber, order (optional)	JSON report including fileIds
Download uploaded image	POST /v1/identityVerification/image	documentId (query), same identifier (emailId or countryCode + phoneNumber), fileId, order (optional)	Binary image file (stream)

The report gives you the fileId; the image API returns the actual image for that fileId.

How do you get the fileId from the identity verification report?

When a signer finishes identity verification, whether it succeeds or fails, BoldSign generates an Identity Verification Report. This report contains:

The result of the verification attempt.
The timestamp of verification.
Extracted document data (name, document type, etc.).
One or more file IDs for the associated verification images.

One of these IDs is the fileId you’ll pass to the Image API.

What inputs are required for the report API?

You must provide:

documentId as a query parameter.
In the request body, either:
- EmailId , or
- CountryCode and PhoneNumber .

Delivery Method	Required Input(s) to the API	Description
Email	EmailId	Verification request was delivered to the signer by email.
SMS	CountryCode + PhoneNumber	Signer received the verification request by SMS.
WhatsApp	CountryCode + PhoneNumber	WhatsApp uses the signer’s mobile number; therefore treated the same as SMS.
Email + SMS (either)	Either one is OK: • EmailId or • CountryCode + PhoneNumber	Either email or SMS can be used; both are supported, but only one is required.

Optionally, you can include:

Order: required if signing order is enabled in the document (to specify which signer’s report you want)..
OnBehalfOf: if you’re acting on behalf of another sender identity.

Below is an example code snippet showing how to generate a verification report via the API.

cURL

    curl -X POST 'https://api.boldsign.com/v1/identityVerification/report?documentId=55a6f0cf-xxx-xxxx-xxxx-796d02cb0977' \
    -H 'accept: application/json' \
    -H 'X-API-KEY: {your-api-key}' \
    -H 'Content-Type: application/json' \
    -d '{
        "EmailId": "alex.gayle@cubeflakes.com",
        "Order": 1
    }'

            var apiClient = new ApiClient("https://api.boldsign.com", "{your-api-key}");
    var idVerificationClient = new IdVerificationClient(apiClient);
    var documentId = "55a6f0cf-xxx-xxxx-xxxx-796d02cb0977";
    var verificationReportRequest = new VerificationReportRequest()
    {
        EmailId = "alex.gayle@cubeflakes.com",
        Order = 1,
    };
    var idVerificationReport = idVerificationClient.GetReport(documentId, 
    verificationReportRequest);

Python

    import boldsign
    configuration = boldsign.Configuration(api_key="YOUR_API_KEY")
    with boldsign.ApiClient(configuration) as api_client:
        identity_verification_api = boldsign.IdentityVerificationApi(api_client)
        identity_verification_report = boldsign.VerificationDataRequest(
           emailId="alex.gayle@cubeflakes.com",
           countryCode="+91",
           phoneNumber="87654345678", 
           order=1
        )
        document_id = "YOUR_DOCUMENT_ID" 
        report_response = identity_verification_api.report(document_id, 
    identity_verification_report)

PHP

    use BoldSign\Configuration;
    $config = new Configuration();
    $config->setApiKey('YOUR_API_KEY');
    $apiInstance = new BoldSign\Api\IdentityVerificationApi($config);
    $document_id = "YOUR_DOCUMENT_ID";
    $verification_report_request  = new \BoldSign\Model\VerificationDataRequest();
    $verification_report_request ->setEmailId("alex.gayle@cubeflakes.com");
    $verification_report_request ->setCountryCode("+91");
    $verification_report_request ->setPhoneNumber("9876543210");
    $verification_report_request ->setOrder(1);
    $result = $apiInstance->report($document_id, $verification_report_request);

Java

    ApiClient apiClient = Configuration.getDefaultApiClient();
    apiClient.setApiKey("YOUR_API_KEY"); 
    IdentityVerificationApi identityVerificationApi = new IdentityVerificationApi(apiClient);
    String document_id = "YOUR_DOCUMENT_ID"; 
    VerificationDataRequest verificationDataRequest = new VerificationDataRequest();
    verificationDataRequest.setEmailId("alex.gayle@cubeflakes.com");
    verificationDataRequest.setCountryCode("+91");
    verificationDataRequest.setPhoneNumber("9944445555");
    IdReport verificationReport = identityVerificationApi.report(document_id,verificationDataRequest);

Node js

    import { VerificationDataRequest, IdentityVerificationApi } from "boldsign";
    const identityVerificationApi = new IdentityVerificationApi();
    identityVerificationApi.setApiKey("YOUR_API_KEY");
    var data_request = new VerificationDataRequest();
    data_request.emailId = "alex.gayle@cubeflakes.com";
    data_request.countryCode = "+91";
    data_request.phoneNumber = "23467898765";
    var document_id = "YOUR_DOCUMENT_ID";
    var verification_report = await identityVerificationApi.report(document_id,data_request);

How do you download the uploaded identity image with the image API?

Once you have a fileId, you can download the actual ID image through the Identity Verification Image API. The call structure is similar: you supply the same signer identifier (email, SMS or WhatsApp), the same documentId, plus the specific fileId.

The API then returns the image file as a binary stream, which you can:

Save to disk or cloud storage.
Pipe into an image-processing or document-handling pipeline.
Attach to an internal case or ticket for compliance review.

What inputs are required for the image API?

documentId as a query parameter.
In the request body:
- EmailId or CountryCode + PhoneNumber (matching how verification was delivered).
- Order – only required if the document has signing order enabled.
- FileId (from the Identity Verification Report).

Here’s a code snippet showing how to get the uploaded verification document using the API

cURL

    curl --location 'https://api.boldsign.com/v1/identityVerification/image?documentId={document Id}' \
    --header 'Content-Type: application/json' \
    --header 'X-API-KEY: {your-api-key}' \
    --data-raw '{
      "emailId": "alexgayle@cubeflakes.com",
      "order": 1,
      "fileId": "{file Id}"
    }'

           var apiClient = new ApiClient("https://api.boldsign.com", "{your-api-key}");
    var idVerificationClient = new IdVerificationClient(apiClient);
    var documentId = "{document Id}";
    var verificationImageRequest = new VerificationImageRequest()
    {
        EmailId = "alexgayle@cubeflakes.com",
        FileId = "{file Id}",
        Order = 1,
    };
    var idVerificationImage = idVerificationClient.GetImage(documentId, 
    verificationImageRequest);

Python

    import boldsign
    configuration = boldsign.Configuration(api_key="YOUR_API_KEY")
    with boldsign.ApiClient(configuration) as api_client:
        identity_verification_api = boldsign.IdentityVerificationApi(api_client)
        identity_verification_image = boldsign.DownloadImageRequest(
           emailId="alex.gayle@cubeflakes.com",
           countryCode="+91",
           phoneNumber="87654345678",
           fileId="YOUR_FILE_ID",
           order=1
        )
        document_id = "YOUR_DOCUMENT_ID" 
        image_response = identity_verification_api.image(document_id, 
    identity_verification_image)

PHP

    use BoldSign\Configuration;
    $config = new Configuration();
    $config->setApiKey('YOUR_API_KEY');
    $apiInstance = new BoldSign\Api\IdentityVerificationApi($config);
    $document_id = "YOUR_DOCUMENT_ID";
    $image_request  = new \BoldSign\Model\DownloadImageRequest();
    $image_request ->setEmailId("alex.gayle@cubeflakes.com");
    $image_request ->setCountryCode("+91");
    $image_request ->setPhoneNumber("9876543210");
    $image_request->setFileId("YOUR_FILE_ID");
    $image_request ->setOrder(1);
    $result = $apiInstance->image($document_id, $image_request );

Java

    ApiClient apiClient = Configuration.getDefaultApiClient();
    apiClient.setApiKey("YOUR_API_KEY");        
    IdentityVerificationApi identityVerificationApi = new IdentityVerificationApi(apiClient);
    String document_id = "YOUR_DOCUMENT_ID"; 
    DownloadImageRequest downloadImageRequest = new DownloadImageRequest();
    downloadImageRequest.setEmailId("alex.gayle@cubeflakes.com");
    downloadImageRequest.setCountryCode("+91");
    downloadImageRequest.setPhoneNumber("9944445555");
    downloadImageRequest.setFileId("YOUR_FILE_ID");
    File verificationimage = identityVerificationApi.image(document_id,downloadImageRequest);

Node js

    import { IdentityVerificationApi, DownloadImageRequest } from "boldsign";
    const identityVerificationApi = new IdentityVerificationApi();
    identityVerificationApi.setApiKey("YOUR_API_KEY");
    var image_request = new DownloadImageRequest();
    image_request.emailId = "alex.gayle@cubeflakes.com";
    image_request.countryCode = "+91";
    image_request.phoneNumber = "23467898765";
    image_request.fileId = "YOUR_FILE_ID";
    var document_id = "YOUR_DOCUMENT_ID";
    var verification_image = await identityVerificationApi.image(document_id,image_request);

How can this workflow help in real-world scenarios?

How can compliance teams manually review failed verifications?

Scenario: A bank requires ID verification to open accounts. A customer’s automated verification fails because the ID photo is blurry.
Problem: Most systems don’t expose failed verification images, so the customer has to start over.
Solution: The compliance team calls the Report API to get the fileId, then downloads the ID image through the Image API, manually confirms identity, and approves the account without asking for a new upload.

How can law firms confirm remote signer identity?

Scenario: A law firm needs to verify a remote client’s identity before they sign a high-value contract.
Problem: Automated verification flags the passport as low confidence.
Solution: The firm uses the Image API to retrieve the uploaded passport, manually validates it, and proceeds with the contract while keeping a verifiable audit trail.

How can healthcare portals grant access without re-uploads?

Scenario: A hospital uses identity verification before granting access to a patient portal. A patient’s driver’s license fails automated checks.
Problem: Re-upload requests slow down care and frustrate patients.

Solution: Staff download the previously uploaded license image via the API, review it, and grant portal access while following internal compliance policies

How does this improve compliance and manual verification workflows?

Using the Identity Verification Report + Image APIs together helps you:

Access uploaded ID images regardless of verification outcome (success or failure).
Reduce friction by enabling manual validation without forcing repeated document uploads.
Maintain a complete audit trail for regulators and internal reviews.
Align with requirements like KYC, AML, and healthcare privacy rules by centralizing identity evidence.
Integrate identity data into your CRM, onboarding flows, ticketing systems, or risk engines.

Compliance Reminder

Identity documents are highly sensitive. Ensure your storage, logging, and access control follow your organization’s security standards and any applicable regulations (such as GDPR, HIPAA, and local KYC/AML rules).

What should you do next with the BoldSign identity verification APIs?

Enable identity verification for high-risk or regulated workflows in BoldSign.
Integrate the Identity Verification Report API to capture verification results and fileId after each attempt.
Add the Identity Verification Image API to download and store ID images whenever manual review is needed.
Automate routing of failed verifications (and their images) to compliance or risk queues.

You can prototype everything in a sandbox account and then move the same code to production once your flows are validated.

Conclusion: When should you use the BoldSign identity verification API?

The BoldSign Identity Verification API makes it easy to securely retrieve uploaded identity documents, whether verification succeeds or not. Whether you’re building onboarding flows, automating compliance checks, or integrating identity data into internal systems, the API helps you maintain trust, meet regulatory standards, and streamline operations with minimal effort.

Get started today! Sign up for a free sandbox account to explore our API features. You can also connect with our support team anytime through the support portal.

Related blogs

Note: This blog was originally published at boldsign.com

Why Medical Records Requests Get Delayed and How to Fix It

Rachel Atieno — Fri, 08 May 2026 13:01:56 +0000

Medical records requests get delayed most often because forms are incomplete, signatures are missing, identity checks take time, and paper-based workflows are hard to track. A faster approach is to digitize requests with HIPAA compliant eSignatures, reusable templates, automated reminders, identity verification, real-time tracking, and audit trails. 

This guide explains the medical records request process, the biggest causes of delays and compliance risk, and how BoldSign helps healthcare teams reduce errors and deliver records faster. 

Where medical records requests usually break down

Traditional release workflows often look manageable on paper, but in practice they create friction at multiple points.

The most common issues include:

Slow processing caused by manual handoffs and backlogs
Incomplete or missing signatures that require repeated follow-up
Paperwork errors from handwritten or repeatedly entered information
Unclear request status once forms start moving between teams
Compliance risks when communications or document handling are inconsistent
Lost or misrouted requests caused by paper-based processes

None of these problems are unusual on their own. Together, they create a slow and error-prone system that makes records requests harder to manage than they should be.

What a reliable medical records request process should look like

A secure medical records request process usually follows a clear sequence.

First, the patient or authorized party submits a request form that includes the records needed, the purpose of release, recipient details, and the preferred delivery method. Then the provider verifies identity and authorization, reviews the request for completeness, retrieves the necessary records, prepares them for release, and delivers them through a compliant channel. The original draft lays out this process clearly, including identity checks, provider review, retrieval, release preparation, and final delivery.

That workflow is straightforward in theory. The problem is that many teams are still managing it with disconnected steps, manual reviews, and paper forms that leave too much room for delay.

Why digital workflows work better

The biggest advantage of digitizing medical records requests is not just speed. It is consistency.

Digital workflows make it easier to:

Standardize request and authorization forms
Reduce missing fields and incomplete submissions
Track request status in real time
Route documents to the right people in the right order
Keep a secure activity history for compliance review

The original draft also compares digital and paper forms across accessibility, speed, storage, error reduction, tracking, and security. That comparison supports the same conclusion: digital workflows reduce delays by improving visibility, accuracy, and control.

How BoldSign helps reduce delays and errors

BoldSign fits this workflow because it addresses the exact points where medical records requests tend to slow down.

Templates for release and authorization forms 

Healthcare teams can create reusable release, authorization, and consent forms so every request starts from a consistent format. That helps reduce missing information and lowers the chance of avoidable mistakes. The draft calls out templates as a way to improve consistency and reduce incorrect or incomplete information.

Create new template

Automated reminders 

When signatures or reviews are delayed, reminders help keep requests from stalling. This reduces the need for staff to chase patients or internal stakeholders manually. The original draft includes automated reminders specifically as a way to prevent stalled requests and reduce follow-ups.

Send automatic follow‑ups to patients and internal reviewers to prevent stalled requests and reduce manual follow‑ups.

Automate reminders

Role-based routing 

Medical records requests often involve more than one step or reviewer. BoldSign helps route each request to the right people in the right order, which reduces handoff errors and makes the process easier to manage. The draft explicitly maps this to patient/requester, reviewer, and approver roles.

Role-based routing

Real-time tracking 

When staff can see where a request stands, they can identify bottlenecks faster and avoid the “where is this request now?” problem that slows teams down. The original version positions tracking as a way to monitor request status from sent to completed.

Real-time tracking

Secure audit trail

In healthcare, it is not enough to complete a process, teams also need a clear record of what happened. BoldSign’s audit trail supports compliance reviews by showing when documents were viewed, signed, and completed.

Audit trail

Identity verification and secure access

The draft also highlights identity verification, encrypted workflows, access controls, and the ability for patients to sign without creating an account. These features matter in a healthcare context because they improve security without adding unnecessary friction for patients.

HIPAA compliant eSignature workflow 

Handle sensitive medical records and PHI using HIPAA‑compliant, encrypted eSignature workflows with access controls designed for healthcare use cases.

Branded patient experience 

Create a consistent and professional signing experience with custom branding across emails and signing pages, helping patients recognize your organization and complete forms with confidence.

Branding

Why this matters for healthcare teams

Medical records requests are not just administrative tasks. They are part of a regulated process that has to be both efficient and defensible.

When forms are incomplete, signatures are delayed, or requests are hard to track, the result is not just slower turnaround. It also creates more work for staff and increases the chance of compliance mistakes. The original draft repeatedly ties delays to incomplete submissions, paper handling, misrouting, and weak tracking, all of which are exactly the kinds of issues healthcare teams need to reduce.

That is why a better records request workflow should do more than digitize a form. It should reduce friction across the whole request lifecycle.

Digital vs paper forms in medical records requests 

Digitizing forms reduces delays, improves tracking, and lowers the risk of lost paperwork. 

Comparison point	Digital forms	Paper forms
Accessibility	Accessible anywhere on supported devices	Requires physical handling
Speed	Faster distribution and completion	Slower handoffs and processing
Storage	Easy centralized storage	Requires physical storage space
Error reduction	Can reduce incomplete submissions	Higher risk of missing fields
Tracking	Status visibility and activity history	Hard to track progress
Security	Secure handling with controls	Vulnerable to loss or damage

Digital workflows reduce delays by improving visibility, accuracy, and control. 

Conclusion 

The medical records request process does not have to be slow or stressful. By replacing paper-based steps with a digital workflow, healthcare teams can reduce missing signatures, avoid lost requests, and improve turnaround times. 

With BoldSign’s HIPAA compliant eSignature tools, templates, reminders, identity verification, tracking, and audit trails, providers can deliver records faster while maintaining a secure and traceable workflow. 

If you’re not yet a BoldSign user, start a free trial to explore these capabilities, or schedule a demo for a walkthrough. 

Related blogs

Note: This blog was originally published at boldsign.com

Migrate Your Docusign API to BoldSign Using AI Skills – Without Breaking Production

Vijay Amalan — Fri, 08 May 2026 03:46:20 +0000

The real problem is not switching platforms. It is switching safely.

If you are running Docusign in production today, you already know migration is not a weekend project. Your codebase does not just call Docusign. It relies on a connected set of behaviors such as signing flows, template and field mappings, webhook based status updates, and downstream logic triggered by document lifecycle events.

If any of those behaviors change during migration, problems can surface quietly. Signatures may be delayed. Webhook handlers may stop firing. Downstream systems may receive events they do not recognize.

The challenge was never “can we build a BoldSign integration?” It’s “can we replace Docusign without disrupting what already works?”

That is exactly what the Docusign to BoldSign Migration Skill is designed to help with. In this blog post, we will walk through how it supports a safer migration.

Why teams are migrating now

Docusign’s pricing has become a growing concern for teams, especially for API driven workflows. While it often comes down to per document or per envelope usage, the total cost is commonly shaped by plan tiers, feature gates, and usage thresholds. As document volume grows across multiple workflows and environments, those constraints can push costs up faster than many teams expect.

BoldSign also follows a per document style pricing model, but with a structure that is typically easier to forecast as automation scales. Limits and overages can still apply, but teams often evaluate BoldSign because the pricing tends to be more predictable and, in many cases, lower than Docusign for comparable API driven usage. BoldSign also provides SDKs for .NET, Node.js, Python, Java, and PHP.

For teams evaluating broader tradeoffs, BoldSign provides a detailed comparison of API models, pricing, and capabilities in its Docusign API alternative overview.

But cost alone doesn’t justify the risk of migrating a production integration. What justifies it is having a reliable, repeatable process, and that’s where AI Agent Skills come in.

Migration goal: Behavior parity, not reinvention

The goal of this migration is not to redesign workflows or introduce new architecture. The goal is to preserve existing behavior.

If a document triggered specific lifecycle events before migration, it should trigger the same events afterward. Downstream systems should continue to receive the same signals, in the same order, with no changes required.

A successful migration is one where users notice no difference and only the underlying platform has changed.

Why a specialized migration skill is needed

If you’re using AI coding agents like Claude Code, GitHub Copilot, OpenAI Codex, Cursor, or any of the 16+ tools that now support the SKILL.md standard, you’ve probably noticed a pattern: AI agents are great at generating code, but they struggle with platform-specific nuances.

Ask an AI agent to “migrate this Docusign code to BoldSign” without context, and you’ll get code that compiles but breaks in production. Common failures include:

Treating document sending as synchronous. BoldSign’s SendDocument returns a DocumentId immediately, but the document isn’t sent yet. You must use webhook events to track completion.
Missing webhook verification. The agent generates a webhook handler but skips signature validation entirely.
Wrong field mappings. Docusign calls them “tabs.” BoldSign calls them “form fields.” The mapping isn’t one-to-one, and the agent guesses wrong.
Polling instead of webhooks. The agent defaults to polling for status, which burns through rate limits.

A Migration Skill prevents all of these by encoding the correct mappings, lifecycle behaviors, and platform rules directly into the agent’s context. Think of it as giving the AI the complete senior developer onboarding guide before it writes a single line of code.

Common migration mistakes the skill prevents

Mistake	What Happens	How the Migration Skill Helps
Treating SendDocument as synchronous	Code waits for completion that never occurs, leading to timeouts in production	Ensures completion is always tracked via webhook events
Polling for document status	Rapidly consumes API rate limits in sandbox and production	Enforces an event‑driven lifecycle model
Skipping webhook signature verification	Webhook endpoint becomes vulnerable to spoofed events	Requires HMAC SHA256 verification for all webhook handlers
Using application/json for file uploads	API rejects uploads and document sending fails	Enforces multipart form‑data for all file operations
Assuming audit logs are included with documents	Compliance data is missing or not stored	Generates a separate audit log retrieval call
Hardcoding API endpoints	Deployment breaks for EU or regional environments	Selects the correct regional API endpoint automatically

Anatomy of the Docusign to BoldSign migration Skill

The skill is intentionally minimal and focused.

    docusign-to-boldsign-api-migration/ 
    ├── README.md 
    └── BoldSign/ 
        └── SKILL.md

Everything important is defined inside SKILL.md.

It contains:

Object mappings such as envelopes to documents, tabs to form fields, and recipients to signers
Behavior guarantees that must remain unchanged
Assumptions that no longer apply after migration such as synchronous sends or polling
Correct webhook usage and lifecycle handling patterns

Before generating any migration code, the AI agent reads this file and applies its constraints, ensuring production-safe output rather than guessed implementations.

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, .NET 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.

In this blog post, we demonstrate the migration using Syncfusion Code Studio with the Claude model.

Getting started with the migration skill

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

Step 1: Obtain the skill

Clone or download the Docusign to BoldSign API Migration GitHub repository

Step 2: Place it in your skills directory

Place the folder in /.codestudio/skills/. Once placed here, the Skill becomes available whenever Docusign to BoldSign migration context is detected. 

Code Studio Dashboard View

*Step 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

*Step 4: Prompt the agent*

Provide your existing Docusign .NET code and prompt:

“Using the skill, convert this Docusign .NET implementation to BoldSign while preserving functionality.”

Prompt Input for Executing Request

The agent will:

Analyze the existing Docusign logic
Apply the mappings defined in the skill
Generate equivalent BoldSign .NET SDK code
Preserve asynchronous lifecycle behavior

Key example: Sending a document

This example shows how a common Docusign envelope workflow translates cleanly to BoldSign while preserving behavior.

Docusign .NET Example

    using Docusign.eSign.Api;  
    using Docusign.eSign.Client;  
    using Docusign.eSign.Model;  
      
    // 1. Setup client  
    var apiClient = new ApiClient("https://demo.Docusign.net/restapi");  
    apiClient.Configuration.DefaultHeader.Add("Authorization", "Bearer " + accessToken);  
    var envelopesApi = new EnvelopesApi(apiClient);  
      
    // 2. Create document  
    var doc = new Document  
    {  
        DocumentBase64 = Convert.ToBase64String(File.ReadAllBytes("contract.pdf")),  
        Name = "Contract.pdf",  
        FileExtension = "pdf",  
        DocumentId = "1"  
    };  
      
    // 3. Create signer with tabs  
    var signer = new Signer  
    {  
        Email = "john@example.com",  
        Name = "John Doe",  
        RecipientId = "1",  
        RoutingOrder = "1",  
        Tabs = new Tabs  
        {  
            SignHereTabs = new List<SignHere>   
            {  
                new SignHere  
                {  
                    DocumentId = "1",  
                    PageNumber = "1",  
                    XPosition = "100",  
                    YPosition = "200"  
                }  
            },  
            DateSignedTabs = new List<DateSigned>  
            {  
                new DateSigned  
                {  
                    DocumentId = "1",  
                    PageNumber = "1",  
                    XPosition = "300",  
                    YPosition = "200"  
                }  
            },  
            TextTabs = new List<Text>  
            {  
                new Text  
                {  
                    DocumentId = "1",  
                    PageNumber = "1",  
                    XPosition = "100",  
                    YPosition = "300",  
                    TabLabel = "company_name",  
                    Required = "true"  
                }  
            }  
        }  
    };  
       
    // 4. Build and send envelope  
    var envelopeDefinition = new EnvelopeDefinition  
    {  
        EmailSubject = "Please sign this document",  
        EmailBlurb = "Please review and sign.",  
        Documents = new List<Document> { doc },  
        Recipients = new Recipients  
        {  
            Signers = new List<Signer> { signer },    
        },  
        Status = "sent"  // "sent" sends immediately; "created" saves as draft  
    };  
      
    var result = envelopesApi.CreateEnvelope(accountId, envelopeDefinition);  
    Console.WriteLine($"Envelope ID: {result.EnvelopeId}");

BoldSign .NET Equivalent

    using BoldSign.Api;  
    using BoldSign.Model;  
      
    // 1. Setup client — much simpler  
    var apiClient = new ApiClient("https://api.boldsign.com",  
        Environment.GetEnvironmentVariable("BOLDSIGN_API_KEY"));  
    var documentClient = new DocumentClient(apiClient);  
      
    // 2. Load file as stream (not Base64)  
    using var fileStream = File.OpenRead("contract.pdf");  
    var documentFile = new DocumentFileStream  
    {  
        ContentType = "application/pdf",  
        FileData = fileStream,  
        FileName = "contract.pdf"  
    };  
      
    // 3. Create form fields (equivalent to Docusign tabs)  
    var signatureField = new FormField  
    {  
        FieldType = FieldType.Signature,  
        PageNumber = 1,  
        Bounds = new Rectangle(x: 100, y: 200, width: 200, height: 50),  
        IsRequired = true  
    };  
      
    var dateSignedField = new FormField  
    {  
        FieldType = FieldType.DateSigned,  
        PageNumber = 1,  
        Bounds = new Rectangle(x: 300, y: 200, width: 150, height: 30)  
    };  
      
    var textField = new FormField  
    {  
        Id = "company_name",  
        FieldType = FieldType.Textbox,  
        PageNumber = 1,  
        Bounds = new Rectangle(x: 100, y: 300, width: 200, height: 30),  
        IsRequired = true  
    };  
      
    // 4. Create signer (with form fields attached to the signer)  
    var signer = new DocumentSigner(  
        name: "John Doe",  
        emailAddress: "john@example.com",  
        signerType: SignerType.Signer,  
        formFields: new List<FormField> { signatureField, dateSignedField, textField }  
    );  
       
    // 5. Build and send  
    var sendRequest = new SendForSign  
    {  
        Title = "Please sign this document",  
        Message = "Please review and sign.",  
        Signers = new List<DocumentSigner> { signer },  
        Files = new List<IDocumentFile> { documentFile },  
        // ExpiryDays = 30,  
        // EnableSigningOrder = true  // For sequential signing  
    };  
      
    var result = documentClient.SendDocument(sendRequest);  
    Console.WriteLine($"Document ID: {result.DocumentId}");  
    // NOTE: Document send is ASYNC — listen for Sent/SendFailed webhooks

Important: Document sending in BoldSign is asynchronous. Completion must be tracked using webhooks, not polling or blocking logic.

In the above example, the document send logic maps cleanly from Docusign to BoldSign using equivalent SDK calls. Core workflow intent remains unchanged, while platform-specific differences are handled automatically by the Migration Skill.

What the skill handles during migration

Authentication

Converts OAuth-based Docusign flows
Supports BoldSign API key or OAuth
Prevents hardcoded credentials

Signing behavior

Preserves signing order
Enforces required fields
Supports template-based and coordinate-based workflows

Embedded signing

Preserves iframe-based flows
Maintains redirect and expiry behavior
Ensures access controls remain unchanged

Document retrieval and audit trails

Reliable signed document retrieval
Explicit audit trail APIs
Compliance workflows preserved

Webhooks and lifecycle tracking

Event-driven lifecycle handling
HMAC SHA256 verification enforced
Correct handling of Sent, Viewed, Signed, Completed, Declined, Expired, and failure events

The five-step recommended migration approach 

Don’t migrate everything at once. Each step should be verified independently before moving forward. 

Step 1: Basic document send  

Migrate a single document send flow. Verify delivery, field placement, and signer access. Use BoldSign’s sandbox environment for all testing. 

Step 2: Webhook lifecycle tracking  

Configure HMAC verified webhooks. Confirm that lifecycle events are processed correctly.  

Step 3: Embedded signing 

Migrate iframe based signing. Validate link generation, redirects, and signing experience.  

Step 4: Templates and advanced fields  

Migrate template workflows. Validate field mappings, defaults, and validation rules.  

Step 5: Multisigner and advanced workflows 

Extend to sequential and parallel signing, reminders, revocation, and signer authentication. 

Supported migration workflows

The Migration Skill supports:

Single and multi-signer workflows
Sequential and parallel signing
Embedded signing for SaaS applications
Template-based document sending
Bulk send operations
Full lifecycle tracking via webhooks
Signed document and audit trail retrieval
Reminder, revoke, and delete operations
OTP, access code, and identity verification

All migrations target behavior parity. The goal is to achieve identical functionality on a different platform, not to redesign existing workflows.

Final takeaway

Migrating from Docusign does not require rebuilding your system.

With BoldSign’s Docusign to BoldSign Migration Skill, teams can:

Preserve existing workflows
Reduce migration risk
Maintain webhook and lifecycle behavior
Transition safely without disrupting production

Start with a single workflow. Validate it thoroughly from end to end. Then expand with confidence.

Get started

Explore the Docusign to BoldSign Migration Skill on GitHub
Create a free BoldSign Sandbox account
Review available APIs and SDKs in the BoldSign Developer Documentation

If you are building new workflows, the BoldSign eSignature Skill for new integrations provides a strong foundation. Existing Docusign templates can also be migrated easily using the Import Docusign Templates into BoldSign guide.

If additional help is needed during setup, testing, or migration planning, the BoldSign Support Portal provides direct access to documentation, guides, and the BoldSign support team.

Related blogs

Note: This blog was originally published at boldsign.com

Reduce eSignature Drop‑Off: Practical Ways to Improve Completion Rates

Vijay Amalan — Thu, 07 May 2026 04:06:19 +0000

If your eSignature completion rate isn’t where you want it, it is rarely because people “don’t want to sign.” More often, they intend to complete the document. Something in the experience creates friction. The email does not land, the flow feels unclear on mobile, authentication slows them down, or the signer has to jump between apps and tabs.

The good news: you don’t need to redesign everything to fix this. You can diagnose drop-off like a funnel, identify where people are getting stuck, and apply a handful of targeted improvements that typically lift completion rates quickly.

In this guide, we’ll walk through:

The eSignature funnel to pinpoint where drop-off happens
The most common causes (and what to change) at each stage
How BoldSign supports these fixes with embedded signing, templates, reminders, sender branding, custom email domain, and configurable security controls

How can you diagnose eSignature drop-off using a funnel?

Treat your signing experience like a conversion funnel so you can stop guessing and start fixing the right step.

Sent → Delivered → Opened → Started → Completed

Sent: Your system triggered the request successfully.
Delivered: The email reached the inbox (not spam/bounce).
Opened: The recipient opened the message.
Started: The recipient clicked and began signing.
Completed: The recipient finished and submitted.

Once you know where the biggest drop is, the fix usually becomes obvious.

How do you reduce eSignature drop-off step by step?

Reducing drop-off means removing small but compounding friction points. Each stage below targets a specific failure pattern.

1) How do you improve “Sent → Delivered” rates?

If your “Delivered” rate is low, your issue is not signing. It is email deliverability or sender trust.

Common causes

Sender domain looks unfamiliar or untrusted
Poor list hygiene (old/invalid emails)
Emails routed to spam or promotions tabs

Practical fixes

Use a recognizable sender name and consistent “From” identity
Tighten list hygiene and reduce bounces
Keep subject lines and copy clear and predictable (avoid spam signals)

How BoldSign helps

Branded email so recipients recognize the request and trust it
Custom email domain so signature requests come from a domain aligned with your brand (helping recognition and reducing “who is this?” hesitation)

2) How do you increase “Delivered → Opened” rates?

If delivered emails aren’t being opened, the request may not feel urgent, safe, or relevant.

Common causes

The sender name or domain is unfamiliar, triggering hesitation or distrust
The subject line is vague, generic, or looks automated
The email does not clearly explain why the recipient is receiving it
The action required is not obvious at a glance
The message blends into promotions or notification clutter

Practical fixes

Use a straightforward subject line (e.g., “Signature requested: [Document Name]”)
State the “why” in the first sentence (what it is + what they need to do)
Put the primary action clearly above the fold

How BoldSign helps

Brand-consistent including custom email content increases recognition and reduces hesitation

3) How do you reduce friction from “Opened → Started”?

This is where many flows quietly fail. People open the email, then postpone because starting feels like work.

Common causes

The user has to log in or switch apps
The signing link expires too quickly (or the rules are unclear)
The CTA is weak or the next step feels uncertain

Practical fixes

Reduce app switching wherever possible
Make the “Start signing” step immediate and predictable
Use reasonable expirations and make them clear

How BoldSign helps

Embedded signing keeps the signer inside your product or portal
Configurable expiration for embedded links so links don’t die before the signer returns

4) Started → Completed: How do you cut friction inside the document?

Once a signer starts, completion should be fast. If they start but don’t finish, the document UX is likely the problem.

Common causes

Too many fields, or too many required fields
Signatures placed late in the document (users don’t see quick progress)
Confusing labels, unclear instructions, or bad mobile layout

Practical fixes

Remove unnecessary fields; minimize required inputs
Pre-fill anything you already know (name, company, address, dates)
Place signature/initial fields earlier where appropriate
Add clear labels and hints (“Sign here,” “Initial here,” “Date auto-fills”)
Ensure a mobile-friendly layout (spacing, tap targets, field alignment)

How BoldSign helps

Templates to standardize layouts and reduce mistakes across recurring documents
Pre-fill fields in templates to minimize manual entry and speed up completion
Audit trails to support compliance and reduce disputes after signing

5) How much authentication is too much for eSignatures?

Extra authentication can protect sensitive workflows, but too much friction can dramatically reduce completion.

Common causes

Authentication applied to low risk documents where it isn’t expected
One time passwords (OTP) or access codes added without explaining the reason

Practical fixes

Apply stronger authentication only when the document warrants it
If you require OTP or access codes, make sure the signer knows why in one sentence.

How BoldSign helps

Authentication frequency settings so you can tune friction vs. assurance based on workflow needs

Why do eSignature reminders consistently increase completion rates?

Most non-completions are not rejections; they are caused by forgetfulness and busy schedules

Common causes

No follow up after the initial request
Manual reminders delayed or forgotten by senders
Signers intend to complete later but miss the deadline
Expiration dates arrive without warning
No visibility into which stage the signer is stuck in

Practical fixes

First reminder: 24–48 hours
Follow-ups: every 2–3 days (limit total reminders to avoid annoyance)
Add a final “expires soon” nudge if you use expirations

How BoldSign helps

Automatic reminders at create
Reminders via API so your product can trigger reminders based on recipient behavior and funnel stage.

What common mistakes quietly lower eSignature completion?

Many eSignature requests fail not because people refuse to sign, but because small usability issues make the process confusing or slower than expected, causing signers to stop before finishing.

Mistake	What signers experience	How to prevent it
Too many fields	Task feels longer than expected	Request only essential data
Unclear invitation	Hesitation or distrust	Explain sender and purpose clearly
No reminders	People forget	Schedule polite follow‑ups
Unclear field labels	Confusion and pauses	Use simple, descriptive labels
Unnecessary signing order	One delay blocks everyone	Enforce order only when needed

What should you verify before sending an eSignature request?

Before sending an eSignature request, confirm a small set of fundamentals that prevent avoidable delays and signer drop-off.

This checklist focuses only on configuration and setup decisions that influence whether a signer can start and finish without friction.

Use this pre send checklist:

Deliverability: Recognizable sender name, custom email domain, clean recipient list
Email clarity: Clear subject line and a visible call to action near the top of the email
Start friction: Embedded signing enabled, minimal redirects, clear and reasonable expiration timelines
Document usability: Only required fields included, known data prefilled, layout optimized for mobile
Follow up: Automatic reminders scheduled, with the first reminder sent within 24 to 48 hours

What actually improves eSignature completion in the real world

Checkout time signing: Embedded signing during a transaction completes faster than email based flows
Offer letters: Placing signature fields earlier reduces candidate hesitation and delays
Vendor onboarding: Removing duplicate or nonessential fields shortens time to completion
Low risk agreements: Using lighter authentication avoids unnecessary signer frustration
Automated reminders: Replacing manual follow ups reduces idle time between steps

These improvements focus on how people actually behave after receiving a signing request.

Final key takeaways: How reducing friction improves eSignature completion rates

Reducing eSignature drop-off is not about pushing signers harder. It is about removing avoidable friction at every stage of the signing journey. When emails are trusted, starting is effortless, documents are fast to complete, security feels appropriate, and reminders arrive at the right time, completion rates improve naturally. You do not need to redesign your workflow to see results. Treat eSignature like a funnel, identify where signers pause, and apply targeted fixes. This approach consistently increases completion without adding operational overhead.

BoldSign supports this end to end with embedded signing, reusable templates, pre filled fields, branded email delivery, flexible authentication, automated reminders, and audit ready compliance, so teams can focus on speed, trust, and completion rather than follow ups and guesswork.

If you’d like to explore more about BoldSign capabilities, sign up for a free BoldSign API account leave a comment, book a demo, or connect with our support team through the BoldSign support portal.

Webinar Show Notes: Salesforce Contract Management with BoldSign

Vijay Amalan — Wed, 06 May 2026 03:39:06 +0000

In this session, Gayathri Annamalai, Software Developer at BoldSign, walks through how organizations can eliminate manual document steps by managing the entire eSignature lifecycle inside Salesforce. Instead of exporting data, switching tools, or tracking status manually, teams can send agreements, monitor progress, and store signed documents directly from Salesforce records.

If you missed the live session or would like to watch it again, the recording is embedded on this page and is also available on our YouTube channel.

Webinar recap

The webinar opened with a common challenge many Salesforce teams face today. Contract workflows often involve copying data from Salesforce into documents, sending them through separate eSignature tools, and manually updating status afterward. This back and forth introduces delays, duplicate work, and a lack of visibility.

Gayathri then introduced the BoldSign Salesforce integration and explained how it brings eSignature workflows directly into Salesforce. She demonstrated how admins enable the integration once at the account level and how users work entirely within Salesforce afterward.

The live demo showed how templates and field mapping automatically prefill Salesforce data into documents, ensuring consistency and reducing errors. The session also highlighted how BoldSign Lightning Components can be added to Accounts, Contacts, Leads, and Opportunities, allowing users to send and track documents without navigating away from the record they are working on.

Finally, the webinar covered real-time document tracking and the automatic storage of completed agreements back into Salesforce, keeping Salesforce as the single source of truth.

Highlights

Enable and configure the BoldSign Salesforce integration with a one time admin setup
Use templates and field mapping to automatically prefill Salesforce data
Add BoldSign Lightning Components to Salesforce record pages
Send documents directly from Salesforce without exporting files
Track document status in real-time inside Salesforce
Automatically save signed documents back to Salesforce records

Key takeaways

Configure the BoldSign Salesforce integration once as an admin
Eliminate manual data entry with templates and field mapping
Send and manage eSignatures directly from Salesforce records
Maintain full visibility into document status without switching tools
Keep signed documents automatically stored in Salesforce

Helpful resources

Learn more about BoldSign for Salesforce
Explore BoldSign Integrations
View Salesforce Integration Documentation
Contact BoldSign Support
Start a free trial

Related blogs

Note: This blog was originally published at boldsign.com

Introducing BoldSign’s Free Phone Number QR Code Generator

Vijay Amalan — Tue, 05 May 2026 03:47:12 +0000

Phone Number QR codes make communication effortless. With a single scan, users can open their phone dialer with your number already filled in and ready to call. This simple upgrade eliminates typing errors, speeds up response time, and increases the chances of customers connecting with you instantly.

With BoldSign’s free Phone Number QR code generator, you can convert any phone number into a scannable QR code in seconds. No sign up, no watermark, no tracking, and no limits. This guide covers everything you need to know, including what a Phone Number QR code is, how it works, and all the best ways to use it effectively.

What is a Phone Number QR code?

A Phone Number QR code is a scannable code that opens the phone dialer with your number prefilled when someone scans it with their smartphone camera. One tap places the call.

You can link to:

A personal number
A business contact number
A support or helpdesk number• A service hotline
A campaign-specific call number

Why it matters: It removes the friction of typing digits manually and reduces errors dramatically.

Why use a Phone Number QR code?

A Phone Number QR code makes starting a call quick, simple, and frustration-free. It is effective across both online and offline channels where you want instant customer contact.

Key benefits

Instant calling – One scan opens your number in the dialer. Faster communication and fewer missed opportunities.
Higher conversions – Ideal for reservation counters, brochures, and event booths where customers decide quickly.
Better customer experience – No typing, no searching, no mistakes.
Modern presentation – Add QR codes to business cards, brochures, receipts, and printed materials to upgrade your brand presence.
Mobile first convenience – All modern smartphones support QR code scanning with the native camera.

How to create Phone Number QR code for free?

Creating your Phone Number QR code takes only a few seconds.

What you’ll need

Your phone number
A browser on any device

Step by step

Enter your phone number Type the number you want users to call instantly.
Customize your QR code

Adjust:
- Pattern color
- Background color
- QR code size
Download and share

Export your QR code as:
- PNG
- JPEG
- SVG

Phone Number QR code generator

Why choose BoldSign’s Phone Number QR code generator

BoldSign’s tool is built for speed, security, and ease of use.

100% free forever: No subscriptions, no hidden fees, and no watermarks.
Privacy first: Your number is processed directly in your browser. Nothing is stored or sent anywhere.
Instant results: Generate high quality QR codes in seconds.
Works on all devices: Windows, macOS, Linux, iOS, and Android. No apps are needed.

Best ways to use Phone Number QR code

Phone Number QR codes can improve customer communication everywhere you place them.

Business cards: Make contacting you easier with a quick scan.
Storefronts and counters: Let walk-in customers call for assistance or reservations.
Printed marketing: Add QR codes to flyers, banners, posters, and brochures.
Events and exhibitions: Great for booths, badges, and digital screens where quick contact matters.
Online communication: Add your QR code to email signatures, social media graphics, and presentations.

Conclusion

A Phone Number QR code makes calling you faster, simpler, and error-free. It removes extra steps, increases customer accessibility, and lets people reach you instantly from any medium, whether it is printed or digital.

Create your Phone Number QR code with BoldSign today and make it easier for people to connect with you in seconds.

Ready to simplify your document workflows? Sign up for a free 30-day trial or connect with our support team for a personalized demo.

Related blogs

Note: This blog was originally published at boldsign.com

Construction Contract Basics: What Every Project Agreement Should Include

Vijay Amalan — Mon, 04 May 2026 04:11:53 +0000

A construction contract is the document that defines the project scope, responsibilities, timeline, payment terms, and change rules so everyone knows exactly what to do and how disputes will be handled. The strongest construction agreements prevent misunderstandings early by clearly documenting who is involved, what work will be done, when it will happen, how payments work, and what to do when something changes. 

In this guide, you’ll learn the must-have components of a construction contract, the most common agreement challenges, and a simple approval workflow. You’ll also see how BoldSign helps teams execute contracts faster with templates, signing order, reminders, tracking, and audit trails. 

Why a solid construction contract matters 

A construction contract is more than a formality. It protects the project by creating a clear, enforceable framework for: 

Communication between owners, contractors, architects, subcontractors, and suppliers 
Legal protection against misunderstandings, claims, and disputes 
Scope clarity for deliverables, materials, and quality standards 
Timeline control with milestones and delay handling 
Payment clarity including retainage, progress billing, and approvals 
Change management when the scope or schedule shifts 
Safety and compliance alignment with local regulations and requirements

A strong contract reduces risk, improves coordination, and helps keep the project on schedule and on budget. 

Common challenges in construction agreements 

Construction projects involve many stakeholders and moving parts. The most frequent issues usually come from unclear terms, delays, and inconsistent approvals. 

Delays and scheduling conflicts 

Weather, labor shortages, or supply disruptions can trigger timeline disputes and added costs. 

How to reduce risk 

Define delay allowances and notice requirements 
Track approvals and hold signers accountable with reminders and visibility

Payment disputes 

Disagreements over amounts due, timing, or work quality can impact cash flow and lead to liens. 

How to reduce risk 

Specify payment milestones, retainage, and approval conditions 
Maintain clear records of approvals and signed terms

Contract interpretation issues 

Ambiguous wording around scope, responsibilities, or change control can cause conflicts. 

How to reduce risk 

Standardize contract language using templates 
Reference drawings, specifications, and addenda clearly

Changed conditions or scope creep 

Design changes and site surprises often cause cost and timeline disputes. 

How to reduce risk 

Define a formal change order process 
Require documented approvals before work proceeds

Subcontractor and quality disputes 

Workmanship issues and coordination gaps can escalate quickly. 

How to reduce risk 

Assign responsibility clearly 
Keep sign-offs and confirmations traceable with audit-ready records

Most disputes come from unclear scope, unclear payment terms, unmanaged changes, and missing approval evidence. 

Essential components of a construction contract 

Below are the core elements every construction contract should include. These are the sections that make agreements clear, enforceable, and easier to manage. 

Identification of parties 

Include full legal names, addresses, and roles for: 

Owner 
General contractor 
Subcontractors (as applicable) 
Architects, engineers, or designers (as applicable)

Scope of work 

Define what work will be performed and how it will be measured. 

Include: 

Project tasks and deliverables 
Materials and workmanship standards 
Drawings, specifications, and addenda references 
Exclusions and assumptions to prevent scope creep

Project timeline and schedule 

Outline the schedule and how delays are handled. 

Include: 

Start date and substantial completion date 
Milestones and deliverable deadlines 
Delay notice requirements 
Consequences for delays if applicable

Payment terms and schedule 

Clarify how and when payment happens. 

Include: 

Total contract value or pricing structure 
Progress payment schedule 
Retainage percentage and release conditions 
Invoicing requirements and approval process 
Late payment terms if applicable

Change order process 

Define how scope, cost, and timeline changes are approved. 

Include: 

What qualifies as a change order 
Required documentation 
Approval roles and signing order 
How costs and schedule changes are calculated

Responsibilities and warranties 

Assign responsibilities clearly and protect the project quality. 

Include: 

Responsibilities for owner, contractor, and subcontractors 
Workmanship and materials warranties 
Insurance requirements and coverage levels

Dispute resolution 

Set a clear path to handle conflicts. 

Include: 

Mediation, arbitration, or litigation process 
Governing law and jurisdiction 
Notice and escalation steps

Termination clauses 

Define when and how the agreement can end. 

Include: 

Termination for cause and termination for convenience 
Cure periods and notice requirements 
Final payment and materials handling

Force majeure and insurance 

Cover uncontrollable events and risk protection. 

Include: 

Force majeure definition and impacts on schedule 
Required insurance for all parties 
Safety and incident reporting expectations

Contract documents list 

List every document that forms the agreement. 

Include: 

General conditions and special conditions 
Drawings and specifications 
Change orders and addenda 
Schedules and exhibits

 These components reduce ambiguity and create a clear rulebook for handling delays, payments, and changes. 

Key steps in the contract approval workflow 

A typical construction contract approval workflow looks like this. 

Step 1: Draft the contract 

Build from a standardized template 
Include project-specific scope, schedule, and payment terms

Step 2: Review 

Share with legal, project stakeholders, and required approvers 
Confirm compliance requirements and risk terms

Step 3: Negotiate and revise 

Address feedback 
Finalize scope and change control language 
Confirm pricing, milestones, and retainage

Step 4: Approve and sign 

Route to signers in the correct order 
Ensure every party signs the final version

Step 5: Execute and store 

Distribute the signed copy 
Store securely with audit-ready records

The approval process fails most often when versions split and signing order is unclear. 

How BoldSign improves construction contract approvals 

BoldSign streamlines contract execution for construction teams with features designed for multi-party workflows. 

Templates 

Use reusable contract templates to standardize common construction agreements and speed up drafting.

With document template, teams can:

Draft contracts faster
Reduce missing fields and costly errors
Standardize contract language across projects

Templates ensure consistency across bids, change orders, and subcontractor agreements.

create new template

E-signatures 

Enable secure, legally compliant eSignatures for on‑site teams and remote stakeholders.

With eSignature, construction teams benefit from:

Faster contract turnaround
Reduced reliance on paper and printing
Mobile‑friendly signing from any device

Signing order and role routing 

Automatically route documents to the right stakeholders in sequence or parallel using signing order and role‑based workflows.

Common flows include: 

Owner approval followed by contractor and subcontractor
Legal review before final client sign‑off

This ensures approvals happen in the correct order without manual coordination.

Automated reminders 

Reduce delays by automatically following up with pending signers. 

Real-time tracking 

Monitor contract progress from send to completion using a centralized dashboard with real-time visibility through document tracking.

Identify approval bottlenecks early
Monitor deadlines more effectively
Reduce status check emails and calls

Audit trails 

Maintain tamper‑evident records for compliance and accountability with the availability of detailed audit trails.

Who signed the contract
When each signature was completed
All actions taken during the approval process

This is especially valuable for dispute resolution and regulatory audits.

Audit Trail

Conclusion 

A solid construction contract is a roadmap for project success. When your contract clearly defines scope, timelines, payments, responsibilities, and change control, you reduce disputes and keep work moving. 

With digital approvals and eSignatures, teams can execute contracts faster, reduce manual coordination, and maintain audit-ready records. If you manage complex construction workflows, BoldSign can help standardize and speed up contract approvals. 

Related blogs

Note: This blog was originally published at boldsign.com

BoldSign Formula Fields: Automate Calculations in eSignature Documents

Vijay Amalan — Thu, 30 Apr 2026 04:04:47 +0000

Manually calculating values in documents can be time-consuming and leave you prone to error, especially when dealing with contracts, invoices, or agreements that require dynamic values like totals, taxes, or discounts. You might struggle to ensure accuracy and consistency across multiple signers and documents. Repetitive manual entry of calculated fields like subtotals, taxes, and totals increases the risk of human error, which can lead to compliance issues or financial discrepancies. It can also cause delays in document turnaround because calculations need verification before sending.

What if you could automate these calculations directly within your e-signature workflow? That’s where BoldSign formula fields come in.

What problems do formula fields solve in eSignature documents?

With formula fields, you can define dynamic calculations directly in your e-signature documents using the BoldSign API.

Key benefits include:

Automated calculations: You can perform real-time calculations like totals, taxes, discounts, or custom formulas based on other field values.
Error reduction: Reduce manual entry errors by computing values automatically, ensuring consistency and accuracy.
Improved user experience: Signers don’t need to do math themselves. The document updates instantly as they fill in fields.
Dynamic content: You can create smart documents that adapt based on user input, making them more interactive and professional.
Time savings: Save time for both senders and signers by eliminating the need for manual calculations or post-signing edits.
Supports complex logic: Use functions like IF for advanced scenarios.

How do BoldSign formula fields work?

These formulas are built using supported operators, functions, and fields without storing static data. As signers enter values into the form, the formula fields in the document recalculate instantly. This ensures accurate results and reduces manual effort.

Which fields, operators, and functions are supported?

BoldSign formula fields support various form fields, operators, and functions to help you streamline arithmetic calculations in your e-signature documents.

How do you add formula fields to a document API request?

When creating or sending a document or template via the BoldSign API, you can add formula fields programmatically by including them in the formFields array of your request payload.

Here’s what to include:

fieldType: Set to “Formula” to indicate it’s a formula field.
formulaFieldSettings: This object contains:
- formulaExpression: The actual calculation logic (e.g., “[textbox1] – [textbox2]”). Use only the field ID in your formula expression.
- decimalPrecision: The number of decimal places to show in the result.

What does a vehicle sales agreement example look like with formula fields?

Let’s look at a practical example. Suppose you’re sending a vehicle sales agreement and want the signer to enter:

Total vehicle value → [Textbox1].
Deposit amount → [Textbox2].

From these inputs, you want to:

Calculate the remaining balance.

Formula: Balance = [Textbox1]- [Textbox2]

Set the Payment Date to be seven days from the signing date.

Formula: PaymentDate = AddDays([SigningDate], 7)

(Payment should be made 7 days from the signing date.)

When the document is sent via the BoldSign API, the balance and payment date are automatically calculated in real time as the signer fills in the values. This eliminates manual math, reduces errors, and improves the signing experience.

Here are example code snippets for sending a signature request with formula fields via API.

cURL

    curl -X 'POST' \
      'https://api.boldsign.com/v1/document/send' \
      -H 'accept: application/json' \
      -H 'X-API-KEY: {your API key}' \
      -H 'Content-Type: application/json' \
      -d '{
        "Signers": [
          {
            "Name": "Hanky",
            "EmailAddress": " david@cubeflakes.com",
            "SignerType": "Signer",
            "DeliveryMode": "Email",
            "FormFields": [
              {
                "Id": "signature1",   
                "FieldType": "Signature",
                "PageNumber": 1,
                "Bounds": { "X": 50, "Y": 50, "Width": 100, "Height": 50 },
                "IsRequired": true
              },
              {
                "Id": "textbox1",              // TextBox 1
                "FieldType": "TextBox",
                "PageNumber": 1,
                "Bounds": { "X": 50, "Y": 100, "Width": 100, "Height": 30 },
                "IsRequired": true,
                "ValidationType": "NumbersOnly"
              },
              {
                "Id": "textbox2",          // TextBox 2
                "FieldType": "TextBox",
                "PageNumber": 1,
                "Bounds": { "X": 200, "Y": 100, "Width": 100, "Height": 30 },
                "IsRequired": true,
                "ValidationType": "NumbersOnly"
              },
              {
                "Id": "SigningDate",        // Signing Date
                "FieldType": "DateSigned",
                "PageNumber": 1,
                "Bounds": { "X": 200, "Y": 200, "Width": 125, "Height": 25 },
                "IsRequired": true
              },
              {
                "Id": "PaymentDate",     # Payment Date (7 days after Signing Date)
                "FieldType": "Formula",
                "PageNumber": 1,
                "Bounds": { "X": 50, "Y": 200, "Width": 200, "Height": 30 },
                "FormulaFieldSettings": {
                  "FormulaExpression": "AddDays([SigningDate],7)",
                }
              },
              {
                "Id": "Balance",   // Balance (Formula)
                "FieldType": "Formula",
                "PageNumber": 1,
                "Bounds": { "X": 50, "Y": 250, "Width": 200, "Height": 30 },
                "FormulaFieldSettings": {
                  "FormulaExpression": "[textbox1] - [textbox2]",
                  "DecimalPrecision": 1
                }
              }
            ],
            "Locale": "EN"
          }
        ],
        "ExpiryDays": 30,
        "Files": [
          "data:application/pdf;base64,JVBERi0xLjcKJcfs..." 
        ],
        "Title": "Vehicle Sales Agreement",
        "ExpiryDateType": "Days",
        "ExpiryValue": 60,
        }
      }'

    var apiClient = new ApiClient("https://api.boldsign.com", "Your API Key");
                    var documentClient = new DocumentClient(apiClient);

                    // Define all form fields
                    List<FormField> formField = new List<FormField>
                    {
                        // Signature field
                        new FormField(
                            id: "Signature",
                            type: FieldType.Signature,
                            pageNumber: 1,
                            bounds: new Rectangle(x: 50, y: 50, width: 200, height: 30)),

                        // TextBox 1
                        new TextBoxField(
                            id: "textbox1",
                            validationType: BoldSign.Model.ValidationType.NumbersOnly,
                            pageNumber: 1,
                            bounds: new Rectangle(x: 50, y: 100, width: 100, height: 30),
                            isRequired: true),

                        // TextBox 2
                        new TextBoxField(
                            id: "textbox2",
                            validationType: BoldSign.Model.ValidationType.NumbersOnly,
                            pageNumber: 1,
                            bounds: new Rectangle(x: 200, y: 100, width: 100, height: 30),
                            isRequired: true),

                        // Signing date
                        new FormField(
                            id: "SigningDate",
                            type: FieldType.DateSigned,
                            pageNumber: 1,
                            bounds: new Rectangle(x: 200, y: 200, width: 125, height: 25),
                            isRequired: true),

                        // Payment date
                        new FormField(
                            id: "PaymentDate",
                            type: FieldType.Formula,
                            pageNumber: 1,
                            bounds: new Rectangle(x: 50, y: 200, width: 200, height: 30),
                            isRequired: true
                            ),

                        // Balance (formula)
                        new FormField(
                            id: "Balance",
                            type: FieldType.Formula,
                            pageNumber: 1,
                            bounds: new Rectangle(x: 50, y: 250, width: 200, height: 30),
                            isRequired: true
                            )
                    };

                    formField[4].FormulaFieldSettings= new FormulaFieldSettings
                    {
                        FormulaExpression = "AddDays([SigningDate],7)",
                    };
                    formField[5].FormulaFieldSettings = new FormulaFieldSettings
                    {
                        FormulaExpression = "[textbox1] - [textbox2]",
                        DecimalPrecision = 1
                    };

                    // Document details
                    var documentDetails = new SendForSign
                    {
                        Title = "Agreement",
                        Signers = new List<DocumentSigner>
                        {
                            new DocumentSigner(
                                signerName: "David",
                                signerType: SignerType.Signer,
                                signerEmail: "david@cubeflakes.com",
                                formFields: formField)
                        },
                        Files = new List<IDocumentFile>
                        {
                            new DocumentFilePath
                            {
                                ContentType = "application/pdf",
                                FilePath = "Your File Path.pdf",
                            }
                        },
                    };

                    // Send document
                    var documentCreated = documentClient.SendDocument(documentDetails);
                    Console.WriteLine($"Document sent successfully. Document ID: {documentCreated?.DocumentId}");

Python

    import boldsign
    configuration = boldsign.Configuration(api_key="Your API Key ")
    with boldsign.ApiClient(configuration) as api_client:
        document_api = boldsign.DocumentApi(api_client)
        # Signature field
        signature_field = boldsign.FormField(
            fieldType="Signature",
            pageNumber=1,
            bounds=boldsign.Rectangle(x=50, y=50, width=200, height=25)
        )
        # Total vehicle value
        textbox1 = boldsign.FormField(
            id="textbox1",
            fieldType="TextBox",
            pageNumber=1,
            bounds=boldsign.Rectangle(x=50, y=100, width=100, height=30),
            validationType="NumbersOnly",
            isRequired=True
        )
        # Deposit amount
        textbox2 = boldsign.FormField(
            id="textbox2",
            fieldType="TextBox",
            pageNumber=1,
            bounds=boldsign.Rectangle(x=200, y=100, width=150, height=30),
            validationType="NumbersOnly",
            isRequired=True
        )
    # Balance formula
    formula_balance = boldsign.FormField(
        id="FormulaBalance",
        fieldType="Formula",
        pageNumber=1,
        bounds=boldsign.Rectangle(x=50, y=150, width=200, height=30),
        formulaFieldSettings=boldsign.FormulaFieldSettings(
            formulaExpression="[textbox1] - [textbox2]", 
            decimalPrecision=1
        )
    )
    #  Signing date
    signing_date_field = boldsign.FormField(
        id="SigningDate",
        fieldType="DateSigned",
         isRequired=True,
        pageNumber=1,
        bounds=boldsign.Rectangle(x=50, y=200, width=100, height=30),

    )
    # Payment date (seven days after signing date)
    payment_date_field = boldsign.FormField(
        id="PaymentDate",
        fieldType="Formula",
        pageNumber=1,
        bounds=boldsign.Rectangle(x=50, y=250, width=200, height=30),
        formulaFieldSettings=boldsign.FormulaFieldSettings(
            formulaExpression="AddDays([SigningDate], 7)",
        )
    )
    # Signer with all fields
    document_signer = boldsign.DocumentSigner(
        name="David",
        emailAddress="david@cubeflakes.com",
        signerType="Signer",
        formFields=[
            signature_field,
            textbox1,
            textbox2,
            formula_balance,
            signing_date_field,
            payment_date_field
        ]
    )
    send_for_sign = boldsign.SendForSign(
        title="Vehicle Sales Agreement",
        files=["Your file path.pdf"],
        signers=[document_signer]
    )
    document_created = document_api.send_document(send_for_sign)

PHP

    <?php require_once "vendor/autoload.php";
    use BoldSign\Configuration;
    use BoldSign\Api\DocumentApi;
    use BoldSign\Model\{
        FormField,
        Rectangle,
        DocumentSigner,
        SendForSign,
        FileInfo,
        FormulaFieldSettings,
        EditableDateFieldSettings
    };
    $config = new Configuration();
    $config->setApiKey('Your API Key');
    $document_api = new DocumentApi($config);
    // Signature field
    $signatureField = new FormField();
    $signatureField->setFieldType('Signature');
    $signatureField->setPageNumber(1);
    $signatureField->setBounds(new Rectangle([50, 50, 200, 25]));
    // Total vehicle value
    $textbox1 = new FormField();
    $textbox1->setId('textbox1');
    $textbox1->setFieldType('TextBox');
    $textbox1->setPageNumber(1);
    $textbox1->setBounds(new Rectangle([50, 100, 100, 30]));
    $textbox1->setValidationType('NumbersOnly');
    $textbox1->setIsRequired(true);
    // Deposit amount
    $textbox2 = new FormField();
    $textbox2->setId('textbox2');
    $textbox2->setFieldType('TextBox');
    $textbox2->setPageNumber(1);
    $textbox2->setBounds(new Rectangle([200, 100, 100, 30]));
    $textbox2->setValidationType('NumbersOnly');
    $textbox2->setIsRequired(true);
    // Signing date
    $signingDateField = new FormField();
    $signingDateField->setId('SigningDate');
    $signingDateField->setFieldType('DateSigned');
    $signingDateField->setPageNumber(1);
    $signingDateField->setBounds(new Rectangle([50, 200, 100, 30]));
    $signingDateField->setIsRequired(true);
    // Payment date (seven days after signing date)
    $paymentDate = new FormField();
    $paymentDate->setId('PaymentDate');
    $paymentDate->setFieldType('Formula');
    $paymentDate->setPageNumber(1);
    $paymentDate->setBounds(new Rectangle([50, 200, 200, 30]));
    $paymentSettings = new FormulaFieldSettings();
    $paymentSettings->setFormulaExpression('AddDays([SigningDate],7)');
    $paymentDate->setFormulaFieldSettings($paymentSettings);
    // Balance formula
    $balanceField = new FormField();
    $balanceField->setId('Balance');
    $balanceField->setFieldType('Formula');
    $balanceField->setPageNumber(1);
    $balanceField->setBounds(new Rectangle([50, 250, 200, 30]));
    $balanceSettings = new FormulaFieldSettings();
    $balanceSettings->setFormulaExpression('[textbox1] - [textbox2]'); 
    $balanceSettings->setDecimalPrecision(1);
    $balanceField->setFormulaFieldSettings($balanceSettings);
    // Signer
    $document_signer = new DocumentSigner();
    $document_signer->setName("David");
    $document_signer->setEmailAddress("david@cubeflakes.com");
    $document_signer->setSignerType("Signer");
    $document_signer->setFormFields([
        $signatureField, $textbox1, $textbox2, $signingDateField, $paymentDate, $balanceField
    ]);
    $send_for_sign = new SendForSign();
    $send_for_sign->setFiles(['Non Disclosure Agreement.pdf']);
    $send_for_sign->setSigners([$document_signer]);
    $send_for_sign->setTitle('Vehicle Sales Agreement');
    // Send document
    $document_created = $document_api->sendDocument($send_for_sign);

Java

    ApiClient client = Configuration.getDefaultApiClient();
            client.setApiKey("Your API Key");
            DocumentApi documentApi = new DocumentApi(client);
            // Signature field
            FormField signatureField = new FormField();
            signatureField.setFieldType(FormField.FieldTypeEnum.SIGNATURE);
            signatureField.setPageNumber(1);
            signatureField.setBounds(new Rectangle().x(100f).y(100f).width(100f).height(50f));
            // Total vehicle value
            FormField vehicleValue = new FormField();
            vehicleValue.setId("textbox1");
            vehicleValue.setFieldType(FormField.FieldTypeEnum.TEXT_BOX);
            vehicleValue.setPageNumber(1);
            vehicleValue.setBounds(new Rectangle().x(50f).y(50f).width(120f).height(30f));
            vehicleValue.setValidationType(FormField.ValidationTypeEnum.NUMBERS_ONLY);
            // Deposit amount
            FormField depositAmount = new FormField();
            depositAmount.setId("textbox2");
            depositAmount.setFieldType(FormField.FieldTypeEnum.TEXT_BOX);
            depositAmount.setPageNumber(1);
            depositAmount.setBounds(new Rectangle().x(200f).y(50f).width(120f).height(30f));
            depositAmount.setValidationType(FormField.ValidationTypeEnum.NUMBERS_ONLY);
            // Signing date 
            FormField signingDate = new FormField();
            signingDate.setId("SigningDate");
            signingDate.setFieldType(FormField.FieldTypeEnum. DATE_SIGNED); 
            signingDate.setPageNumber(1);
            signingDate.setBounds(new Rectangle().x(50f).y(100f).width(180f).height(30f));
            signingDate.setDateFormat("MM/dd/yyyy"); 
            // Payment date
            FormField paymentDate = new FormField();
             paymentDate.setId("PaymentDate");
             paymentDate.setFieldType(FormField.FieldTypeEnum.FORMULA);
             paymentDate.setPageNumber(1);
             paymentDate.setBounds(new Rectangle().x(50f).y(140f).width(180f).height(30f));
            FormulaFieldSettings paymentSettings = new FormulaFieldSettings();
             paymentSettings.setFormulaExpression("AddDays([SigningDate],7)");
             paymentDate.setFormulaFieldSettings( paymentSettings);
            // Balance 
            FormField balanceField = new FormField();
            balanceField.setId("Balance");
            balanceField.setFieldType(FormField.FieldTypeEnum.FORMULA);
            balanceField.setPageNumber(1);
            balanceField.setBounds(new Rectangle().x(50f).y(200f).width(200f).height(30f));
            FormulaFieldSettings balanceSettings = new FormulaFieldSettings();
            balanceSettings.setFormulaExpression("[textbox1] - [textbox2]");  
            balanceSettings.setDecimalPrecision(2);
            balanceField.setFormulaFieldSettings(balanceSettings);
            // Signer
            DocumentSigner signer = new DocumentSigner();
            signer.setName("David");
            signer.setEmailAddress("david@cubeflakes.com");
            signer.setSignerType(DocumentSigner.SignerTypeEnum.SIGNER);
            signer.setFormFields(Arrays.asList(
                    signatureField,
                    vehicleValue,
                    depositAmount,
                    signingDate,
                    paymentDate,
                    balanceField
            ));
            // Send document
            SendForSign sendForSign = new SendForSign();
            File file = new File("Your file path.pdf"); 
            sendForSign.setFiles(Arrays.asList(file));
            sendForSign.setSigners(Arrays.asList(signer));
            sendForSign.setTitle("Vehicle Sales Agreement");
            DocumentCreated documentCreated = documentApi.sendDocument(sendForSign);
            System.out.println("Document created: " + documentCreated.getDocumentId());

Node js

    import { DocumentApi, DocumentSigner, FormField, Rectangle, SendForSign } from "boldsign";
    import * as fs from 'fs';

    const documentApi = new DocumentApi();
    documentApi.setApiKey("Your API KEY");

    // Signature field
    const signatureField = new FormField();
    signatureField.fieldType = FormField.FieldTypeEnum.Signature;
    signatureField.pageNumber = 1;
    signatureField.bounds = new Rectangle();
    signatureField.bounds.x = 50;
    signatureField.bounds.y = 50;
    signatureField.bounds.width = 200;
    signatureField.bounds.height = 25;

    // Total vehicle value
    const textbox1 = new FormField();
    textbox1.id = "textbox1";
    textbox1.fieldType = FormField.FieldTypeEnum.TextBox;
    textbox1.pageNumber = 1;
    textbox1.bounds = new Rectangle();
    textbox1.bounds.x = 50;
    textbox1.bounds.y = 100;
    textbox1.bounds.width = 100;
    textbox1.bounds.height = 30;
    textbox1.validationType = "NumbersOnly";
    textbox1.isRequired = true;

    // Deposit amount
    const textbox2 = new FormField();
    textbox2.id = "textbox2";
    textbox2.fieldType = FormField.FieldTypeEnum.TextBox;
    textbox2.pageNumber = 1;
    textbox2.bounds = new Rectangle();
    textbox2.bounds.x = 200;
    textbox2.bounds.y = 100;
    textbox2.bounds.width = 150;
    textbox2.bounds.height = 30;
    textbox2.validationType = "NumbersOnly";
    textbox2.isRequired = true;

    // Balance formula
    const formulaBalance = new FormField();
    formulaBalance.id = "FormulaBalance";
    formulaBalance.fieldType = FormField.FieldTypeEnum.Formula;
    formulaBalance.pageNumber = 1;
    formulaBalance.bounds = new Rectangle();
    formulaBalance.bounds.x = 50;
    formulaBalance.bounds.y = 150;
    formulaBalance.bounds.width = 200;
    formulaBalance.bounds.height = 30;
    formulaBalance.formulaFieldSettings = {
        formulaExpression: "[textbox1] - [textbox2]",
        decimalPrecision: 1
    };

    // Signing date
    const signingDateField = new FormField();
    signingDateField.id = "SigningDate";
    signingDateField.fieldType = FormField.FieldTypeEnum.DateSigned;
    signingDateField.isRequired = true;
    signingDateField.pageNumber = 1;
    signingDateField.bounds = new Rectangle();
    signingDateField.bounds.x = 50;
    signingDateField.bounds.y = 200;
    signingDateField.bounds.width = 100;
    signingDateField.bounds.height = 30;

    // Payment date (seven days after signing date)
    const paymentDateField = new FormField();
    paymentDateField.id = "PaymentDate";
    paymentDateField.fieldType = FormField.FieldTypeEnum.Formula;
    paymentDateField.pageNumber = 1;
    paymentDateField.bounds = new Rectangle();
    paymentDateField.bounds.x = 50;
    paymentDateField.bounds.y = 250;
    paymentDateField.bounds.width = 200;
    paymentDateField.bounds.height = 30;
    paymentDateField.formulaFieldSettings = {
        formulaExpression: "AddDays([SigningDate], 7)",
    };
    // Signer with all fields
    const documentSigner = new DocumentSigner();
    documentSigner.name = "David";
    documentSigner.emailAddress = "david@cubeflakes.com";
    documentSigner.signerType = DocumentSigner.SignerTypeEnum.Signer;
    documentSigner.formFields = [
        signatureField,
        textbox1,
        textbox2,
        formulaBalance,
        signingDateField,
        paymentDateField
    ];

    const files = fs.createReadStream("Your File Path.pdf");

    const sendForSign = new SendForSign();
    sendForSign.title = "Vehicle Sales Agreement";
    sendForSign.signers = [documentSigner];
    sendForSign.files = [files];

    const documentCreated = documentApi.sendDocument(sendForSign);

In the code examples above, replace the placeholders Your API Key and file path with your actual API key and the correct file path. In the formula expression section, use only the field ID. Once executed, the document will be sent to the specified signers, and any formula fields will automatically calculate values based on their input in real time, as shown below.

Formula Fields

What best practices help formula fields work reliably?

Keep formulas simple: Avoid overly complex expressions for clarity.
Validate inputs: Use NumbersOnly or other validation types.
Use decimal precision wisely: Match financial standards in your industry.
Test templates: Send sandbox documents to confirm formulas work as expected.
Think about the user experience: Place formula fields logically so signers see results immediately.

Conclusion

Using formula fields via API brings a new level of automation to your e-signature workflows. Whether you’re in sales, finance, HR, or legal, this feature can help you deliver smarter, faster, and more reliable documents.

Ready to automate your document calculations? Try out formula fields with BoldSign today!

Sign up for a free sandbox account and explore our developer documentation to learn more about our APIs. For any assistance, visit our support portal to connect with our team.

Related blogs

Note: This blog was originally published at boldsign.com

ASP.NET Core Minimal APIs: When to Use Them and When Not To Use Them

Vijay Amalan — Wed, 29 Apr 2026 03:44:33 +0000

Minimal APIs are an endpoint-first way to build HTTP APIs in ASP.NET Core by mapping routes directly to handlers (no controllers required). They’re best for teams building small-to-medium, bounded services (microservices, BFFs, webhooks, internal APIs) that want fast iteration with less ceremony, as long as you add structure early. They solve the “too much framework for a small API” problem, and they matter because choosing the wrong model (or letting Program.cs become a dumping ground) creates long-term maintenance pain.

What decision should you make: Minimal APIs or Controllers?

Use this checklist and pick the first match.

Choose Minimal APIs when your API is bounded and you can enforce conventions

You’re building a focused service boundary (webhooks, microservice, BFF, internal tool API).
You can enforce a module convention (route groups + one file per feature).
Your team likes explicit routing and fluent metadata (OpenAPI tags, response types).
You want cross-cutting behavior via middleware + endpoint filters rather than MVC filters.

Choose Controllers when the API surface is large or the team is large

You expect many endpoints across multiple domains/features.
You rely heavily on attribute-driven conventions (routing/filters/versioning patterns).
Many developers contribute and you need high discoverability via familiar conventions.
Your org already has controller-first templates, libraries, or standards.

Checkpoint: If you can’t commit to a module convention on day 1, controllers are usually the safer default.

What will you build in this guide?

You’ll build a production-shaped Minimal API starter with one clear outcome:

End result: A Minimal API that’s structured with route groups + feature modules, uses endpoint-filter validation, returns consistent Problem Details errors, exposes OpenAPI docs, and is verifiable with curl + an integration test.

What prerequisites do you need before starting?

.NET SDK installed
Basic C# knowledge
Terminal access (PowerShell/Bash)
Optional: Postman/Insomnia

Checkpoint: dotnet –version prints a version successfully.

How does a Minimal API request flow work in production?

A[HTTP Request] –> B[Middleware pipeline]

B –> C[Routing selects endpoint]

C –> D[Endpoint filters (optional)]

D –> E[Handler runs]

E –> F[Result writes response (JSON, status code)]

F –> G[HTTP Response]

Checkpoint: You can point to exactly where you’ll put (1) global behavior (middleware), (2) per-feature behavior (endpoint filters), and (3) business orchestration (handlers).

How do you avoid a giant Program.cs with Minimal APIs?

Use a feature-module convention:

Program.cs only wires dependencies, middleware, and “maps modules”
Endpoints/Endpoints.cs defines routes for a feature via a route group
Infrastructure/ holds cross-cutting filters (validation, correlation, etc.)
Services/ holds business logic (handlers stay thin)

Checkpoint: You can add a new feature by creating one new Endpoints/*Endpoints.cs file, without touching existing endpoint files.

How do you build the production starter step by step?

1) How do you create a Minimal API project?

.NET

    dotnet new web -n MinimalApiStarter 
    cd MinimalApiStarter

Checkpoint: dotnet run starts the server without errors.

2) How do you enable OpenAPI document generation?

.NET

    Add the official OpenAPI package: 
    dotnet add package Microsoft.AspNetCore.OpenApi

Checkpoint: Package install succeeds.

3) How do you create a service layer so handlers don’t become “mini controllers”?

.NET

    Create Services/ProductService.cs: 
    namespace MinimalApiStarter.Services;
    public record ProductDto(int Id, string Name, decimal Price);
    public record CreateProductRequest(string Name, decimal Price);
    public interface IProductService
    {
        Task GetAsync(int id, CancellationToken ct);
        Task CreateAsync(CreateProductRequest request, CancellationToken ct);
    }
    public sealed class ProductService : IProductService
    {
        public Task GetAsync(int id, CancellationToken ct)
            => Task.FromResult(id == 404 ? null : new ProductDto(id, "Demo", 10m));
        public Task CreateAsync(CreateProductRequest request, CancellationToken ct)
            => Task.FromResult(new ProductDto(123, request.Name, request.Price));
    }

Checkpoint: No ASP.NET-specific types appear in the service.

4) How do you centralize validation using an endpoint filter?

.NET

    Create Infrastructure/ValidateCreateProductFilter.cs:
    using Microsoft.AspNetCore.Http.HttpResults;
    using MinimalApiStarter.Services;

    namespace MinimalApiStarter.Infrastructure;

    public sealed class ValidateCreateProductFilter : IEndpointFilter
    {
       public async ValueTask InvokeAsync(
          EndpointFilterInvocationContext context,
          EndpointFilterDelegate next)
       {
           var request = context.Arguments.OfType().FirstOrDefault();

           if (request is null)
               return TypedResults.BadRequest(new { error = "Request body is required." });

           var errors = new Dictionary();

           if (string.IsNullOrWhiteSpace(request.Name))
              errors["name"] = new[] { "Name is required." };

           if (request.Price < 0)
              errors["price"] = new[] { "Price must be >= 0." };

           if (errors.Count > 0)
               return TypedResults.ValidationProblem(errors);

           return await next(context);
       }
    }

Checkpoint: Validation rules are written once and reused, handlers stay clean.

5) How do you define endpoints as a feature module with a route group?

.NET

    Create Endpoints/ProductsEndpoints.cs: 
    using Microsoft.AspNetCore.Http.HttpResults;
    using MinimalApiStarter.Infrastructure;
    using MinimalApiStarter.Services;
    namespace MinimalApiStarter.Endpoints;
    public static class ProductsEndpoints
    {
        public static RouteGroupBuilder MapProductsEndpoints(this IEndpointRouteBuilder app)
        {
            var group = app.MapGroup("/api/products")
                .WithTags("Products")
                .RequireAuthorization("api");
            group.MapGet("/{id:int}", async Task<Results<Ok<ProductDto>, NotFound>> (
                int id,
                IProductService service,
                CancellationToken ct) =>
            {
                var product = await service.GetAsync(id, ct);
                return product is null ? TypedResults.NotFound() : TypedResults.Ok(product);
            })
            .Produces<ProductDto>(StatusCodes.Status200OK)
            .Produces(StatusCodes.Status404NotFound)
            .WithOpenApi();
            group.MapPost("/", async Task<Created<ProductDto>> (
                CreateProductRequest request,
                IProductService service,
                CancellationToken ct) =>
            {
                var created = await service.CreateAsync(request, ct);
                return TypedResults.Created($"/api/products/{created.Id}", created);
            })
            .AddEndpointFilter<ValidateCreateProductFilter>()
            .Produces<ProductDto>(StatusCodes.Status201Created)
            .ProducesValidationProblem()
            .WithOpenApi();
            return group;
        }
    }

Checkpoint: No endpoints are mapped inside Program.cs.

6) How do you wire auth, ProblemDetails, OpenAPI, and modules in Program.cs?

.NET

    Replace Program.cs with: 
    using MinimalApiStarter.Endpoints;
    using MinimalApiStarter.Services;
    var builder = WebApplication.CreateBuilder(args);
    // OpenAPI document generation
    builder.Services.AddOpenApi();
    // Problem Details support (standardized error shape)
    builder.Services.AddProblemDetails();
    // Demo authorization policy (replace with real auth in production)
    builder.Services.AddAuthorization(options =>
    {
        options.AddPolicy("api", policy => policy.RequireAssertion(_ => true));
    });
    builder.Services.AddScoped();
    var app = builder.Build();
    // Centralized exception handler (works well with ProblemDetails)
    app.UseExceptionHandler();
    app.UseAuthorization();
    // Expose OpenAPI JSON endpoint
    app.MapOpenApi();
    // Map feature modules
    app.MapProductsEndpoints();
    app.Run();
    // For integration tests (WebApplicationFactory)
    public partial class Program { }

Checkpoint: dotnet run compiles and starts successfully.

How do you test and verify the API?

How do you run the API locally?

.NET

    dotnet run

How do you verify GET returns a product?

cURL

    curl -i http://localhost:5000/api/products/1

Expected:

200 OK
JSON like: {“id”:1,”name”:”Demo”,”price”:10}

Checkpoint: You get a 200 with JSON for /1.

How do you verify GET returns 404 for missing

cURL

    curl -i http://localhost:5000/api/products/404

Expected:

404 Not Found

Checkpoint: /404 returns 404.

How do you verify validation runs via the endpoint filter?

cURL

    curl -i -X POST http://localhost:5000/api/products \ 
      -H "Content-Type: application/json" \ 
      -d "{\"name\":\"\",\"price\":-1}"

Expected:

400 Bad Request
A validation payload (from ValidationProblem)

Checkpoint: Validation fails before the handler runs.

How do you verify OpenAPI is being generated?

Fetch the OpenAPI JSON exposed by MapOpenApi() (path depends on your ASP.NET Core version/config). Confirm you see a JSON document containing /api/products/{id} and /api/products.

Checkpoint: OpenAPI JSON includes your endpoints and response metadata.

How do you add an integration test to prove endpoint wiring works?

1) How do you add a test project?

.NET

    dotnet new xunit -n MinimalApiStarter.Tests 
    dotnet add MinimalApiStarter.Tests reference MinimalApiStarter 
    dotnet add MinimalApiStarter.Tests package Microsoft.AspNetCore.Mvc.Testing

2) How do you write a minimal integration test?

.NET

    Create MinimalApiStarter.Tests/ProductsApiTests.cs: 
    using System.Net; 
    using Microsoft.AspNetCore.Mvc.Testing; 
    using Xunit; 

    public class ProductsApiTests : IClassFixture> 
    { 
        private readonly HttpClient _client; 

        public ProductsApiTests(WebApplicationFactory factory) 
        { 
            _client = factory.CreateClient(); 
        } 

        [Fact] 
        public async Task Get_Product_ReturnsOk() 
        { 
            var resp = await _client.GetAsync("/api/products/1"); 
            Assert.Equal(HttpStatusCode.OK, resp.StatusCode); 
        } 

        [Fact] 
        public async Task Get_MissingProduct_ReturnsNotFound() 
        { 
            var resp = await _client.GetAsync("/api/products/404"); 
            Assert.Equal(HttpStatusCode.NotFound, resp.StatusCode); 
        } 
    }

Run:

.NET

    dotnet test

Checkpoint: Tests pass and confirm routing + module mapping works.

What are the most common production mistakes with Minimal APIs and how do you fix them?

1) Why did my Minimal API turn into a “giant Program.cs”?

Cause: You mapped endpoints directly in Program.cs as the project grew.

Fix: Move each feature into Endpoints/_Endpoints.cs with Map_Endpoints().

2) Why are my endpoints inconsistent (validation, errors, logging)?

Cause: Each handler does its own checks and error shapes.

Fix: Use endpoint filters for validation, and standardize error responses using Problem Details.

3) Why does RequireAuthorization(“api”) throw “policy not found”?

Cause: Policy wasn’t registered or name mismatch.

Fix: Ensure AddAuthorization(options => options.AddPolicy(“api”, …)) matches exactly.

4) Why does my POST look like the handler runs even with bad input?

Cause: Validation is in-handler, or the filter wasn’t applied.

Fix: Confirm .AddEndpointFilter() is on the endpoint or group.

5) Why is my OpenAPI endpoint returning 404?

Cause: OpenAPI services weren’t added or endpoint wasn’t mapped.

Fix: Confirm builder.Services.AddOpenApi() and app.MapOpenApi() are both present.

What did you achieve, and what should you do next?

You now have a Minimal API starter that’s intentionally “production-shaped”:

Route groups + feature modules keep code discoverable
Endpoint-filter validation keeps handlers thin
ProblemDetails gives predictable error responses
OpenAPI generation keeps API docs accurate
Integration tests prove wiring won’t regress

Next step: Replace the demo authorization policy with real authentication (JWT/OAuth), then align your API security checklist with OWASP’s API Security Top 10.

Start today and unlock all features of BoldSign.

Need assistance? Request a demo or visit our Support Portal for quick help.

Bring fast, secure eSignatures to your Minimal APIs with BoldSign’s developer-friendly API.

Try BoldSign API Free

Related blogs

Note: This blog was originally published at boldsign.com

Prevent “I Didn’t Sign This” Claims with ID Verification Methods & Audit Trails

Vijay Amalan — Tue, 28 Apr 2026 05:29:15 +0000

“I didn’t sign this” claims, also known as repudiation claims, pose a serious risk in electronic signature workflows. They can delay deals, trigger costly disputes, damage trust, and create compliance issues, especially for legal paperwork, high‑value contracts, financial documents, and HR agreements. BoldSign effectively minimizes these risks by combining advanced signer identity verification with comprehensive, tamper-evident audit trails.

This layered approach delivers undeniable proof of who signed, when they signed, their intent, and that the document remained unchanged, ensuring strong non-repudiation and legally defensible agreements.

What are repudiation claims

Repudiation claims happen when a signer denies signing a document or claims the signature was unauthorized, forged, or completed through a compromised account. In electronic signature workflows, these disputes can delay agreements, create legal challenges, and increase operational risk. They are especially common in low-security workflows that rely only on email access without stronger identity checks.

What is the risk of repudiation in electronic signatures

Repudiation occurs when a signer denies signing a document, claiming it was forged, unauthorized, or completed through a compromised account. This is more common in basic email-only workflows with minimal identity checks. High-value or regulated agreements are especially vulnerable, as disputes can invalidate contracts, lead to legal challenges, and cause financial or operational harm.

For an electronic signature to be enforceable and provide non-repudiation, it must prove three key elements:

Signer intent – Clear evidence they meant to sign.
Signer identity – Reasonable (or strong) confirmation of who they are.
Document integrity – Proof the document wasn’t altered after signing.

BoldSign exceeds these requirements through layered security features, making repudiation claims extremely difficult to sustain.

BoldSign’s advanced identity verification methods

BoldSign offers flexible, multi-layered authentication options to confirm the signer is the authorized person before they access or complete the document. You can apply these selectively per signer (including in multi-party workflows) or standardize them via templates.

Key methods include:

Email OTP – A one-time password sent to the signer’s email; they must enter it to proceed, confirming email ownership.
SMS OTP – A one‑time code sent to the signer’s phone by text message.
Access Code – A custom PIN you create and share securely through a separate channel; the signer enters it for access.
Government ID Verification with Biometric Selfie – For higher-risk documents, require:
- Upload of a government-issued ID (e.g., passport, driver’s license, national ID card).
- A live biometric selfie.
- Advanced matching (powered by technology like Stripe Identity) compares the selfie to the ID photo, with configurable strictness levels (strict, moderate, lenient) and options like live document capture to prevent photos or photocopies.

Identity Verification

These controls, especially government ID with a selfie, tie the signing process to real‑world identity and significantly reduce impersonation and unauthorized access risks.

What does an audit trail prove

Every BoldSign document includes a detailed, tamper-evident audit trail that logs the entire signing process. This creates a consistent, court-admissible record supporting non-repudiation.

The audit trail typically captures:

Precise timestamps for events (sent, viewed, authenticated, signed, completed).
IP addresses and device details.
Authentication activity, including methods used such as OTP, access code, and ID verification.
Signer actions and consent to electronic disclosures.
Document integrity verification, using cryptographic hashes to confirm that no alterations were made after signing.
Sender and recipient information, including names and email addresses.

After completion, download the audit trail as a branded PDF (separately or combined with the signed document). It is digitally signed to prevent tampering, ensuring reliability for reviews, audits, or disputes.

How do ID verification and audit trails work together

This combination forms a powerful, multi-layered defense:

Identity is verified upfront – Blocking unauthorized users before access.
Every key action is logged – With timestamps, IP/device data, and verification outcomes.
Integrity is preserved – Through hashes and tamper-evident records.

Together, they generate a complete evidence package: Proven identity + documented intent + unaltered document. This makes repudiation claims unsustainable and supports compliance with standards like ESIGN Act, UETA, and eIDAS.

Key business benefits

Here’s how these features translate into real business advantages:

Stronger legal defensibility – Meets or exceeds global e-signature laws with verifiable non-repudiation.
Fewer disputes and faster resolution – Clear and reliable evidence minimizes challenges and speeds up issue handling.
Enhanced trust – Signers, partners, legal teams, and stakeholders gain confidence from robust security.
Flexible security – Apply stricter verification only where needed (e.g., high-value documents), balancing protection with efficiency.
Operational efficiency – Avoids costly delays from repudiation claims and streamlines workflows.

Conclusion

“I didn’t sign this” claims don’t have to derail your agreements. BoldSign’s robust identity verification paired with detailed, tamper-evident audit trails provides strong proof of identity, intent, and document integrity, virtually eliminating repudiation risks.

Secure your high-value or regulated workflows with confidence. Try BoldSign free and explore powerful audit logging, automated workflows, and secure signing.

Have questions? Our team is here, schedule a demo and get expert support.

Related blogs

Note: This blog was originally published at boldsign.com

Free Email QR Code Generator for Ready‑to‑Use Email Drafts

Vijay Amalan — Mon, 27 Apr 2026 05:34:12 +0000

We are excited to introduce the free BoldSign Email QR Code Generator, a simple and secure tool that helps anyone share a complete email template, including email address, subject, and message, with a quick scan. Whether you’re a freelancer adding contact details to business cards, a professional sharing support information on brochures, or a small business placing QR codes on packaging, this tool makes communication effortless. There is no software to install, no account required, and no cost. Everything runs inside your browser, keeping your information private and helping you connect faster.

Why choose the free BoldSign Email QR Code Generator

Our email QR code generator is built for convenience, privacy, and professional results. It works entirely inside your browser, so your email information is never stored. It is perfect for professionals, creators, and businesses who want a quick way for people to reach their inbox.

Here are the main reasons for choosing our tool:

Completely free: No sign up, no fees, and no restrictions. Create email QR codes online for free.
Privacy first: All processing happens on your device. Your information is never saved or shared.
Professional look: Generate clean and polished QR codes ideal for business cards, posters, menus, flyers, resumes, and printed materials.
Works everywhere: Create email QR codes from your phone, tablet, or computer without installing anything.
Fast and simple: Add your email address, subject, or message and generate a QR code in seconds.

Key features of the free Email QR Code Generator

Whether you’re sharing a support email or a personal contact address, these features make BoldSign your go‑to solution:

Custom email details: Add your email address along with a subject and an optional predefined message so people can contact you instantly with the right context.
High quality downloads: Download clear and print ready QR codes perfect for physical or digital use.
Unlimited creation: Generate as many email QR codes as you need. There are no limits and no watermarks.
Simple customization: Adjust the appearance of the QR code if supported on the page, so it matches your brand or design.
Beginner friendly: No technical knowledge is needed. Enter your details and download them immediately.

How to create an email QR code in three simple steps

Getting started takes only a few clicks. Follow these three steps to create your first email QR code:

Open the tool: Go to the free BoldSign Email QR Code Generator.
Enter your information: Type your email address, subject line, and optional message. Customize the appearance if needed.
Download your email QR Code: Save your QR code as PNG, SVG, or JPEG, and display it anywhere so guests can scan and connect instantly.

Start sharing your email smarter today

The free BoldSign Email QR Code Generator makes sharing your email address fast, simple, and accessible to everyone. Whether you are a freelancer, business owner, job seeker, or student, this tool helps people reach you instantly with a quick scan. There is no cost, no setup, and no technical skills required. Create your QR code in minutes and make communication easier than ever.

Ready to simplify your document workflows? Sign up for a free 30-day trial or connect with our support team for a personalized demo.

Related blogs

Note: This blog was originally published at boldsign.com