# TurboDocx > AI-powered document automation platform. Stop writing documents, start closing deals. Every page on https://www.turbodocx.com, as markdown. Index: https://www.turbodocx.com/llms.txt --- --- title: "TurboDocx - Document, Signature & Quoting Automation" description: "Document, signature, and quoting automation, built into the tools you already run, from Salesforce to a legacy ERP. A tailored fit, without the tailor's price." url: "https://www.turbodocx.com" --- # Documents. Signatures. Quotes. Automated to fit your stack. > TurboDocx is document, signature, and quoting automation built into the tools you already run, from Salesforce to a legacy on-prem ERP, with AI agents in Slack and Microsoft Teams. It is delivered and maintained for you at software pricing. The homepage has two views, "For Teams" and "For Developers". Both are described below. Announcement: [Introducing TurboQuote, free CPQ built into every plan](https://www.turbodocx.com/newsroom/turboquote-launch.md). ## For Teams Connect the tools you already use and automate the documents, quotes and signatures that slow your team down. - 3,000+ documents generated - 98% time saved - 10K+ signatures sent Book a demo: https://www.turbodocx.com/demo . Just exploring? [Start free](https://app.turbodocx.com/) or grab an API key. ### Platform numbers | Stat | Value | | --- | --- | | Open source downloads | 180K+ per month, MIT licensed | | Countries | Trusted in 178 | | Organizations | 1,400+ trust TurboDocx | | Time saved | 98%, by embedding into custom workflows | | Documents generated | 3,000+ and counting | Trusted across industries: Technology, Legal, Real Estate, Financial Services, Insurance, Nonprofit / Education. The page also shows a rotating "Powered by TurboDocx" counter of signature fields, open source downloads, signatures sent, documents generated, and organizations on the platform. Trusted by leading solutions providers: Choice Solutions, ITSG, Connexxia, Connected Consultants, ThyTech Computers, Wrike. > "By making the tedious process of document creation painless, TurboDocx enabled me to focus on revenue-generating activities." Loralee C., CEO, Dynamic Cloud ## For Developers ### Legally binding signatures. One API call. Ship e-signatures in 5 minutes. Not 5 meetings. - 180K+ monthly open source downloads, 10K+ e-signatures sent, 6 SDKs (TypeScript, Python, PHP, Go, Java, Ruby) - 5 free / month - Audit trail included Links: [E-Sign API docs](https://docs.turbodocx.com/docs/SDKs/javascript), [Get an API key free](https://app.turbodocx.com/), [GitHub SDKs](https://github.com/TurboDocx/sdk), [e-signature API](https://www.turbodocx.com/e-signature-api.md), [API and SDK](https://www.turbodocx.com/products/api-and-sdk.md), [open source](https://www.turbodocx.com/products/open-source.md). Example (TypeScript, "send-for-signature.ts"), which returns "Signature request sent" in the animated demo: ```typescript import { TurboSign } from "@turbodocx/sdk"; // Configure SDK with your credentials TurboSign.configure({ apiKey: process.env.TURBODOCX_API_KEY, orgId: process.env.TURBODOCX_ORG_ID, }); // Send for signature using template anchor tags const result = await TurboSign.sendSignature({ fileLink: "https://example.com/contract.pdf", documentName: "Service Agreement", recipients: [ { name: "John Doe", email: "john@acme.com", signingOrder: 1 } ], fields: [ { type: "signature", recipientEmail: "john@acme.com", template: { anchor: "{SignHere}", placement: "replace", size: { width: 200, height: 50 }, }, }, ], }); ``` Guides by language: [JavaScript](https://www.turbodocx.com/guides/sign-documents-with-javascript.md), [TypeScript](https://www.turbodocx.com/guides/sign-documents-with-typescript.md), [Python](https://www.turbodocx.com/guides/sign-documents-with-python.md), [PHP](https://www.turbodocx.com/guides/sign-documents-with-php.md), [Go](https://www.turbodocx.com/guides/sign-documents-with-go.md), [Java](https://www.turbodocx.com/guides/sign-documents-with-java.md). ### Open source: @turbodocx/html-to-docx Powering the internet's document generation infrastructure. Production-ready, battle-tested, MIT licensed. 170 GitHub stars, 180K+ downloads per month. [GitHub](https://github.com/turbodocx/html-to-docx), [npm](https://www.npmjs.com/package/@turbodocx/html-to-docx). ```bash npm install @turbodocx/html-to-docx ``` ```javascript // HTML to a Document file in 3 lines import HtmlToDocx from "@turbodocx/html-to-docx" const html = "

Hello world

" const docx = await HtmlToDocx(html) ``` ### Agentic Quickstart Skill Skip the boilerplate. Run one command and your AI coding agent installs the SDK and writes a working TurboDocx integration for you, with no copy-pasting from the docs. Works with Claude Code, Cursor, GitHub Copilot, OpenCode, Codex CLI, Gemini CLI. [How it works](https://www.turbodocx.com/quickstart.md). ```bash npx skills add TurboDocx/quickstart ``` ## Build a Document Workflow around your Business Needs Connect the tools your business already uses. ### 1. Connect Your Data Connect to the tools your business already uses: CRMs, Meetings, Transcripts, PM Tools, Knowledge. Data syncs in real time. ### 2. Create your document Three ways to turn a template into a finished document: - **Fill your template with your data.** Pull straight from the tools you connected (CRMs, Meetings, Transcripts, PM Tools, Knowledge). - **Point & Click.** Drop in values by hand, no formulas. Choose pre-approved content, full manual control, brand consistency guaranteed. - **Let AI do it.** AI fills the whole document for you. Auto-fill all variables, generate custom sections, adapt tone and style. ### 3. Your Perfect Document Professionally formatted and ready to send. The example shows a finished file, "Sales_Proposal_Final.docx", marked "Ready", with Download and Continue actions. ### Agents: skip the clicks, just ask Prompt a TurboDocx agent in Slack, Teams, or your own agent harness. It reads the request, builds the document, and hands it back for review, right where your team already works. Example prompt shown in Slack, Microsoft Teams and an agent harness: "Draft a quote for Acme Corp: 2 managed servers, RMM for 10 endpoints, Microsoft 365 Business Premium for 10 users, and onboarding." The agent matches 4 catalog items, prices them from your rate card, creates a draft, and returns a quote card (Quote #Q-2026-00015, status "Ready for review"): | Line item | Detail | Price | | --- | --- | --- | | Managed Servers | 2 x Standard Managed Server | $1,000 / mo | | RMM | 10 Endpoints | $350 / mo | | Microsoft 365 Business Premium | 10 Seats | $220 / mo | | Onboarding | Implementation and setup | $1,500 one-time | Monthly recurring: $1,570 / mo. One-time: $1,500. Actions: Open quote, View details. ### 4. TurboSign E-Signatures Also works as a standalone product, no template needed. Fast, secure, and legally binding e-signatures. Works with TurboDocx or independently for any PDF. Instant sending, legally binding, audit trails. Free: 5 / month. [Learn more about TurboSign](https://www.turbodocx.com/products/turbosign.md). ## Built to fit the way you work Document, signature, and quoting automation, wired into the tools your team already runs and implemented for you. - [Document Automation](https://www.turbodocx.com/products/turbodocx-templating.md): Generate contracts, proposals, and reports from your CRM and PSA data in seconds. - [Signature Automation](https://www.turbodocx.com/products/turbosign.md): TurboSign built in. Add a Sign button right inside Salesforce. Legally binding, audit trail included. - [Quoting Automation](https://www.turbodocx.com/newsroom/turboquote-launch.md): TurboQuote CPQ built into every plan. Build and send quotes from live pricing, no separate tool. - [Deep Integrations](https://www.turbodocx.com/products/api-and-sdk.md): Salesforce, your PSA, SharePoint, even a legacy on-prem ERP. We build the connector and keep it running. - [Done For You](https://www.turbodocx.com/demo): The tailored integration you'd hire a systems integrator for, delivered and maintained at software pricing. - [180K+ Downloads](https://www.turbodocx.com/products/open-source.md): Open-source core trusted by thousands. Battle-tested in production at scale. Just need a signature image? Try the [free signature maker](https://www.turbodocx.com/tools/digital-signature-maker.md), or [convert a photo of your signature](https://www.turbodocx.com/tools/image-to-signature.md). ## Simple Pricing Start for free and upgrade as you need. | Plan | Price | Includes | | --- | --- | --- | | Free | $0 / user | 1,000 AI Credits / month; Free E-Signature, 5 / month; 5 Quotes / month; 5 TurboDocx Generations / month (Document & Presentation Templates); Unlimited TurboDocx Templates; Unlimited Standard Integrations; Single User; PDF only; API Access (5 Signatures and 5 Quotes per month via API key, the same limits as in-app usage) | | Team (Promotional) | $10 / user per month (was $20, save 50%) | 2,500 AI Credits / month; 15 Signatures / month and 15 Quotes / month (both include API access, shared across in-app and API-key usage); 10 TurboDocx Generations / month; Unlimited TurboDocx Templates; Full Document, Slide Deck export; Everything in the Free plan | | Pro (Best Value, Most Popular) | $20 / user per month (was $35, save 43%) | Unlimited AI Credits / month; Unlimited Signatures / month; Unlimited Quotes; Unlimited TurboDocx Generations; Unlimited TurboDocx Templates; Bulk Signature Sending; API access: 60 Quotes + 60 Signatures / mo, rate-limited AI; SMS one-time passcodes for signers; Everything in the Team plan | | Enterprise | Contact us | Unlimited +; Unlimited Quotes + Custom Workflows; Customizable AI Packages; Bring your own AI models; Auditing and Compliance; Self-hosted solution option; SAML/OIDC SSO; SMS one-time passcodes for signers; Custom API limits | Notes: - Bulk Signature Sending: send personalized documents for e-signature to hundreds of recipients at once using a spreadsheet. Upload a CSV or Excel file, map columns to template variables, configure signature fields, and submit the entire batch in minutes. Also available via the Bulk API (`POST /turbosign/bulk/ingest`). - Pro API access: API-key (programmatic) usage is metered separately from in-app usage. Pro API keys get 60 Quotes and 60 Signatures per month, with per-minute burst limits. Named users logged into the TurboDocx UI keep the unlimited limits. AI endpoints are rate-limited per fair-use policy (429 on overflow, retry with backoff). Contact us for volume pricing. - Enterprise custom API limits: API rate limits and monthly caps are negotiated per contract. Dedicated capacity available. - SMS one-time passcodes for signers (Pro and Enterprise): signers can verify by text message as well as email. Texts go through your own Twilio or RingCentral account, so your provider bills them at your rates. Email passcodes are included on every plan. Full pricing: https://www.turbodocx.com/pricing.md ## The Hidden Cost of Document Creation An interactive calculator estimates what manual document creation really costs. Inputs (defaults): People Involved (2), Hours per Doc (3), Hourly Rate ($75), QA & Review Hours (2). Cost Per Document = people x (hours per doc + QA hours) x hourly rate; with the defaults that is $750 per document, or $15,000/month for just 20 documents. The page then says "See How TurboDocx Saves You 90%". ## Ready to see it in your stack? Join the solutions providers automating documents, signatures, and quotes inside the tools they already run. Book a 20-minute demo, see it wired into your stack, no commitment. (Developers view: "Ready to Ship Faster? Join thousands of developers building with TurboDocx. Get your API key today. No credit card required, free to start, cancel anytime.") [Book a demo](https://www.turbodocx.com/demo) --- --- title: "About Us | TurboDocx | TurboDocx" description: "Learn more about us and our passion, dedication behind TurboDocx's mission of making document creation more efficient, easy, and enjoyable." url: "https://www.turbodocx.com/about-us" --- # Revolutionizing the Way You Create and Reuse Content > TurboDocx is an AI-assisted document and slide deck templating platform designed to empower professionals to build documents quickly by eliminating tedious copy-pasting and leveraging AI. ## Our Story TurboDocx was born from challenges faced by consulting and sales professionals who spent excessive time creating presentations and documentation. We saw talented people spending hours on tedious copy-paste work instead of focusing on what they do best. We started with simple text swaps, evolved to a robust content "building blocks" engine, and eventually integrated AI capabilities to enhance content creation. Today, TurboDocx empowers teams to quickly fill out company-approved templates using a centralized content knowledge base. We're not just building a product; we're fostering an environment of growth and support. We emphasize collaboration with customers, actively listening and iterating to create scalable solutions. ## Our Values - **People-First**: We put our customers and team at the center of everything we do. - **Efficiency**: We obsess over saving our customers time through smart automation. - **Innovation**: We continuously improve and push the boundaries of what's possible. ## What Makes Us Different - **AI-Powered Generation**: GPT technology generates intelligent content from your approved materials. - **Modular Content Blocks**: Deconstruct documents into reusable building blocks for rapid assembly. - **Centralized Knowledge Base**: One source of truth for all your team's approved content. - **Slide Deck Templating**: Beyond documents, create presentations with the same efficiency. ## Results - **180K+ Monthly Downloads** of the open source @turbodocx/html-to-docx package (the live count is fetched from npm; 180K+ is the value shipped as the fallback). - **10x Faster Document Creation** - **50% Cost Reduction** ## Our Mission To simplify and improve document creation for professionals and businesses worldwide by leveraging modular, centralized content and cutting-edge AI technologies, making content creation faster, smarter, and more efficient. ## Get Started Join teams who have already revolutionized their document creation. [Get a Demo](https://www.turbodocx.com/demo). --- --- title: "Adobe Sign Alternative: Modern eSignature Platform | TurboDocx | TurboDocx" description: "Looking for an Adobe Sign alternative? TurboSign offers better pricing, a free tier, native document automation, and powerful API. No Adobe lock-in." url: "https://www.turbodocx.com/adobe-sign-alternative" --- # The Adobe Acrobat Sign Alternative for End-to-End Document Workflows > Adobe Acrobat Sign handles e-signatures inside Adobe's PDF suite. TurboDocx takes a different path: one platform to generate documents from templates, build quotes, and collect legally binding signatures, from first call to signed contract. Add a developer-first API, open-source tooling, and transparent per-user pricing with a free tier. ## Why TurboSign - **5 Free**: signatures per month, no credit card - **$20/user/mo**: unlimited signatures on Pro - **All-in-One**: generate, quote, and sign in one workflow - **6 SDKs: TS, Python, PHP, Go, Java, Ruby**: official SDKs plus REST and e-signature API ## TurboSign vs Adobe Acrobat Sign: Side-by-Side Comparison How TurboDocx compares to Adobe Acrobat Sign across pricing, features, and developer experience. Competitor details are cited below. | Feature | TurboDocx (TurboSign) | Adobe Acrobat Sign | | --- | --- | --- | | Pricing model | Per-user monthly subscription with a free tier; unlimited signatures on Pro, and standard plans that are not metered per envelope (per-envelope pricing is optional) | Subscription-based; Individual and Team plans billed per user, Business and Enterprise billed either per user or by expected transaction volume | | Published pricing | Public pricing page you can self-serve without a sales call | Individual and Team plans are self-serve on the pricing page; Business and Enterprise are quote-based through Adobe sales, with exact amounts not shown publicly | | Free plan | Free tier, no credit card required | No permanently free paid e-signature plan; a 30-day free trial is offered | | Free developer sandbox | Free tier (no credit card) to build and test against the live API | Free Acrobat Sign Developer Edition account to build and test integrations; test documents carry a test label | | API and webhooks | Developer-first REST and e-signature API with webhooks for real-time signature events, including event filtering and retry and dead-letter handling | REST API (current v6) plus a legacy SOAP API with migration guidance; webhooks and event management supported | | Prebuilt integrations | Salesforce, HubSpot, ConnectWise PSA, and Wrike to generate documents and proposals from live CRM, PSA, and project data | Microsoft 365, Salesforce, Workday, and ServiceNow, among others | | Signature types | Legally binding electronic signatures under the U.S. ESIGN Act and UETA, with detailed audit trails and signer identity verification by email or SMS one-time passcode (SMS through your own Twilio or RingCentral account) or your own identity verification provider, plus eIDAS Advanced Electronic Signatures (AES) with HSM-protected keys and long-term validation | Electronic signatures plus certificate-based digital signatures cryptographically bound to the document | ### Sources Verified July 2026. Competitor pricing and features may change; confirm current details on the vendor site. - [Adobe Acrobat Sign pricing plans](https://www.adobe.com/acrobat/business/pricing-plans.html) - [Adobe Acrobat Sign developer docs](https://developer.adobe.com/acrobat-sign/) - [Adobe Acrobat Sign integrations](https://www.adobe.com/acrobat/business/integrations.html) - [Adobe Acrobat Sign product page](https://www.adobe.com/acrobat/business/sign.html) ## Why Teams Choose TurboDocx - One platform instead of a stack: generate documents from templates (DOCX, PPTX, PDF), build quotes with TurboQuote, and collect legally binding signatures with TurboSign, so you go from first call to signed contract in a single workflow rather than bolting signing onto a PDF tool. - Developer-first and open source: a REST and e-signature API, real-time webhooks with filtering and retry and dead-letter handling, official SDKs for six languages (JavaScript/TypeScript, Python, PHP, Go, Java, Ruby), and the MIT-licensed @turbodocx/html-to-docx library with no headless browser or external binary needed. - Transparent per-user pricing with a free tier and unlimited signatures on Pro, standard plans that are not metered per envelope (per-envelope pricing is optional), and no mandatory sales call to see what you will pay. - Enterprise-ready without lock-in: SAML/OIDC single sign-on, self-hosted deployment, bring-your-own AI models, plus multi-signer and bulk sending with ESIGN and UETA-compliant audit trails. ## Frequently Asked Questions ### How do I move from Adobe Acrobat Sign to TurboDocx? Bring your existing PDF or Word documents into TurboDocx, place signature, date, name, and initial fields with drag-and-drop, and send. Developers can automate the same flow through the REST and e-signature API or the official SDKs, so signing lives directly inside your own application. You can start on the free tier with no credit card while you set things up. ### How is TurboDocx pricing different from Adobe Acrobat Sign? TurboDocx uses a per-user monthly subscription with a free tier and unlimited signatures on the Pro plan; its standard plans are not metered per envelope, and per-envelope pricing is available only as an option. Adobe Acrobat Sign sells Individual and Team plans self-serve per user, while Business and Enterprise plans are quote-based through Adobe sales and can be billed per user or by expected transaction volume, with exact amounts not shown on the public pricing pages. ### Does TurboDocx match Adobe Acrobat Sign on e-signature features? TurboSign covers the core workflow: multi-signer documents (up to 10 signers with color-coded field assignments), drag-and-drop fields, bulk sending to hundreds of recipients, and detailed audit trails that are legally binding under ESIGN and UETA. Adobe additionally offers certificate-based digital signatures bound to a digital ID; if a certificate-based digital signature is a hard requirement for your use case, confirm that fit before switching. ### Can developers build on TurboDocx the way they build on Adobe API? Yes. TurboDocx ships a developer-first REST and e-signature API plus official SDKs for six languages (JavaScript/TypeScript, Python, PHP, Go, Java, and Ruby), where one package per language covers signing, document generation, quoting, and webhooks. Adobe offers a free Developer Edition account and downloadable sample clients; with TurboDocx you can build and test on the free tier and avoid polling by using real-time webhook events. ### Is TurboDocx only for e-signatures? No. Where Acrobat Sign is the e-signature solution within Adobe's PDF platform, TurboDocx is an all-in-one document operations platform: template-based generation of DOCX, PPTX, and PDF files, sales quoting with TurboQuote, and legally binding e-signatures with TurboSign, so a single workflow runs from first call to signed contract. ## Explore more [E-signatures with TurboSign](https://www.turbodocx.com/products/turbosign.md), template-based [document generation](https://www.turbodocx.com/products/turbodocx-templating.md), [CPQ quoting](https://www.turbodocx.com/products/turboquote.md), the [e-signature API and SDKs](https://www.turbodocx.com/e-signature-api.md), our [open-source tooling](https://www.turbodocx.com/products/open-source.md), and e-signature compliance in the [US](https://www.turbodocx.com/resources/us-esignature-compliance.md) and the [EU (eIDAS and AES)](https://www.turbodocx.com/resources/european-esignature-compliance.md). See how [MSP teams](https://www.turbodocx.com/use-cases/msps.md) use it end to end. ## Related Resources Learn more about TurboDocx and how it compares to Adobe Acrobat Sign. - [TurboSign eSignature Platform](https://www.turbodocx.com/products/turbosign.md): No lock-in to proprietary PDF ecosystems - [Best E-Signature API Comparison](https://www.turbodocx.com/best-esignature-api-comparison.md): Modern alternatives to Adobe Sign - [TurboDocx Template Engine](https://www.turbodocx.com/products/turbodocx-templating.md): Native document generation without Adobe tools - [Adobe Sign API Alternative](https://www.turbodocx.com/adobe-sign-api-alternative.md): Modern API without Adobe ecosystem lock-in [Sign up free](https://app.turbodocx.com) --- --- title: "Adobe Sign API Pricing: Billed per Transaction | TurboDocx" description: "150 transactions per user a year on Business and Enterprise licenses, API for enterprise and developer tiers: Adobe Sign API pricing and limits vs TurboSign." url: "https://www.turbodocx.com/adobe-sign-api-alternative" --- # Adobe Sign API (Acrobat Sign): Pricing, Rate Limits, SDKs and Webhooks > Adobe reserves Acrobat Sign API access for enterprise and developer tier accounts, publishes no API price, and bills by transaction, with 150 transactions per user per year on Acrobat Sign Business and Enterprise user licenses. This page covers what Adobe documents about developer accounts, embedded signing, SDKs, throttling and webhooks, and how TurboSign compares. Adobe Sign API vs TurboSign. 10K+ signatures sent, 6 SDKs (TS, Python, PHP, Go, Java, Ruby). ## Quick answer 150 transactions per user per year is the allowance Adobe lists for Acrobat Sign Business and Enterprise user licenses (Acrobat Standard and Pro are listed as unlimited), and every agreement sent through the API counts as one. Adobe's API FAQ limits API access to enterprise and developer tier accounts, Adobe publishes no API price, and Adobe directs enterprise plan inquiries to its sales team. The free Developer Edition covers testing. Throttled calls return HTTP 429 with a Retry-After value, and identical GET calls are capped at 3 per minute on enterprise and developer tiers. TurboSign includes API access on every tier, 5 free signatures a month, SDKs in 6 languages and webhooks, and is ranked against DocuSign, DocuSeal, SignNow and Dropbox Sign in the [eSignature API comparison](https://www.turbodocx.com/best-esignature-api-comparison.md). Agentic Quickstart Skill: install the TurboDocx integration skill with `npx skills add TurboDocx/quickstart` ([how it works](https://www.turbodocx.com/quickstart.md)). ## Which Acrobat Sign plan includes API access, and what does it cost? Adobe's [Acrobat Sign API FAQ](https://helpx.adobe.com/sign/web/developers/rest-apis/api.html) (last updated June 19, 2026) opens with one line: API access is reserved exclusively for enterprise and developer tier accounts. Adobe's [developer quickstart](https://developer.adobe.com/acrobat-sign/docs/overview/developer_guide/gstarted) adds that granting group-level or account-level OAuth scopes requires the Business or Enterprise edition of Acrobat Sign. Adobe does not publish an API price. The [Acrobat plans and pricing page](https://www.adobe.com/acrobat/business/pricing/plans.html) lists Acrobat Standard, Pro and Studio without any mention of API access, and sends larger organizations to Adobe's sales team for volume licensing. Adobe's [Acrobat Sign page](https://www.adobe.com/acrobat/business/sign.html) presents Acrobat Sign as its standalone e-signature solution for medium and large businesses and routes plan and pricing questions to Contact Sales. What Adobe does publish is the billing basis. A [transaction](https://helpx.adobe.com/sign/web/system-level-resources/adobesign-transaction-consumption.html) occurs each time a document, or a set of related documents, is sent to recipients, and an agreement sent from your own app through the Acrobat Sign API is billable the same way as one sent from the web app. Per Adobe's [transaction limits](https://helpx.adobe.com/sign/web/system-level-resources/transaction-limits.html) page, Acrobat Sign Business and Enterprise plans sold as user licenses include 150 transactions per user per year unless your contract says otherwise (Acrobat Standard and Pro are listed as unlimited), and high-volume business and enterprise customers can buy a total volume of transactions with unlimited users through their sales agent. The same page caps Business and Enterprise agreements at 25 signers and 10 MB per uploaded file, with 100 pages per transaction on Business and 500 on Enterprise. TurboSign includes API access on every tier: Free with 5 signatures a month, Team (currently $10/user/mo) with 15 signatures a month, Pro (currently $20/user/mo) with unlimited in-app signing and 60 a month via API key, and Enterprise with custom limits. See [TurboSign pricing](https://www.turbodocx.com/pricing.md) for current details. ## Adobe Sign developer account and API documentation Adobe offers a [free Developer Edition of Acrobat Sign](https://www.adobe.com/acrobat/business/developer-form.html) with no commitment. Per the [developer guide](https://developer.adobe.com/acrobat-sign/docs/overview/developer_guide/), it includes access to the Acrobat Sign API plus testing for document exchange, execution and emailing copies of signed agreements, and test documents carry a "test" label. Adobe classes developer accounts as non-billable; if you promote one to a billable plan, existing transactions count as consumed once they are modified. The [Acrobat Sign Sandbox](https://helpx.adobe.com/sign/web/developers/sandbox/overview.html) is a different product: a separately entitled, pay-for-access environment that requires an enterprise-level production account with an assigned success manager, and one Sandbox per account. For the Adobe Sign API documentation itself, Adobe points developers to the [REST API v6 reference](https://secure.na1.adobesign.com/public/docs/restapi/v6), the [API usage guide](https://developer.adobe.com/acrobat-sign/docs/overview/developer_guide/apiusage) on developer.adobe.com and a [Postman workspace](https://www.postman.com/adobe/adobe-acrobat-sign/overview). Adobe's FAQ notes that support for the legacy SOAP API ended in May 2021. ## What are the Adobe Sign API rate limits? Adobe's [API throttling rules](https://developer.adobe.com/acrobat-sign/docs/overview/developer_guide/apiusage) limit requests per endpoint at the minute, hour and day levels, applied per user (or per IP address when no user is known), and Adobe says your service plan determines your rate. Throttled calls return HTTP 429 with a `THROTTLING_TOO_MANY_REQUESTS` code and a Retry-After value in seconds. For accounts created after May 20, 2025, retrying inside that interval throttles the call again and resets the wait. Adobe publishes hard numbers for repeated polling and for webhooks: | Acrobat Sign throttling rule | Limit | | --- | --- | | REST API requests | Per endpoint, per minute, hour and day; set by your service plan | | Identical GET calls (GLOBAL, ENTERPRISE, DEVELOPER tiers) | 3 per minute | | Identical GET calls (all other tiers) | 3 per 3 minutes | | Concurrent webhook creation requests | 10 per account | | Concurrent webhook and callback notifications | 30 per account | | Over the limit | HTTP 429 with Retry-After (seconds) | ## Does the Adobe Sign API support embedded signing? Adobe documents [`GET /agreements/{agreementId}/signingUrls`](https://developer.adobe.com/acrobat-sign/docs/overview/developer_guide/apiusage), which returns an `esignUrl` for each signer once the agreement is ready, and describes it for in-person signing on a device. Its developer guide also lists embedding a signing UI in your app. If your product needs to access multiple Acrobat Sign accounts or sign on behalf of other customers, Adobe treats you as an [Acrobat Sign Embed partner](https://developer.adobe.com/acrobat-sign/docs/overview/embedpartner/), a program you join by contacting Adobe. TurboSign handles embedding through a signing URL your server requests on demand, with per-recipient identity verification. The [embedded signing page](https://www.turbodocx.com/embed-electronic-signature.md) walks through the flow. ## Which SDKs does Adobe offer for Acrobat Sign? Adobe's [SDK downloads page](https://developer.adobe.com/acrobat-sign/docs/overview/sdks/) lists C#, Java, JavaScript and OpenAPI SDKs plus REST samples, all in the [adobe/acrobat-sign](https://github.com/adobe/acrobat-sign) GitHub repository. The same page (last updated January 4, 2024) says the SDKs are obsolete and have not been in sync with the REST v6 API for a while, and points developers to the API endpoints and Postman instead. TurboSign ships official SDKs in 6 languages (TypeScript, Python, PHP, Go, Java, Ruby), all on [GitHub](https://github.com/TurboDocx/sdk), and the code samples below show a full signature request. ## How do Adobe Sign API webhooks work? Acrobat Sign [webhooks](https://developer.adobe.com/acrobat-sign/docs/overview/acrobat_sign_events/) are created through the REST API or the web app, at account, group, user or resource scope (user and resource scope only through the API). Before registering one, Adobe sends a verification request, and your HTTPS endpoint must answer with a 2XX and echo the `X-AdobeSign-ClientId` value. Adobe's [webhook overview](https://helpx.adobe.com/sign/web/developers/webhooks/overview.html) says that if your endpoint is down it retries over 72 hours, doubling the interval from 1 minute up to every 12 hours (15 retries); after that, with no successful delivery in 7 days, the webhook is disabled and notifications sent while it is off are lost. TurboSign sends real-time webhook notifications for signature events. ## Adobe Sign API vs TurboSign API The same 7 questions, answered from each vendor's published documentation. | Question | Adobe Sign API (Acrobat Sign) | TurboSign API | | --- | --- | --- | | Plan needed for API access | API FAQ: enterprise and developer tier accounts only. Group and account OAuth scopes need the Business or Enterprise edition | API access on every tier: Free, Team, Pro and Enterprise. Pro includes 60 signatures a month via API key | | Published API price | None published. Billed by transaction; Acrobat Sign Business and Enterprise user licenses include 150 transactions per user per year unless your contract says otherwise (Adobe lists Acrobat Standard and Pro as unlimited) | Free tier with API access; paid plans listed on the pricing page, with a price match guarantee | | Free testing | Free Developer Edition (test documents carry a "test" label). The Sandbox environment is paid and enterprise-only | Free plan with 5 signatures a month | | Rate limits | Per endpoint per minute, hour and day, set by plan. Identical GET calls: 3 per minute or 3 per 3 minutes by tier | Custom API rate limits on Enterprise | | Embedded signing | GET /agreements/{agreementId}/signingUrls returns an esignUrl per signer; multi-account platforms go through the Embed partner program | Signing URL your server requests, with per-recipient identity verification | | Official SDKs | C#, Java, JavaScript, OpenAPI and REST samples, which Adobe calls obsolete (not in sync with REST v6) | 6: TypeScript, Python, PHP, Go, Java, Ruby | | Webhooks | Account, group, user or resource scope; 15 retries over 72 hours, then the webhook can be disabled | Real-time webhook notifications | Comparing more than two vendors? The [best eSignature API comparison](https://www.turbodocx.com/best-esignature-api-comparison.md) covers six platforms side by side. ## Start Building in Minutes Choose between the TypeScript SDK or the REST API directly. Each has a "Template Tags (Recommended)" variant that auto-positions fields at anchor tags, and a "Coordinates" variant that uses exact positions. ### TypeScript SDK, template tags (recommended) ```typescript import { TurboSign } from '@turbodocx/sdk'; // Configure SDK with your credentials TurboSign.configure({ apiKey: process.env.TURBODOCX_API_KEY, orgId: process.env.TURBODOCX_ORG_ID, }); // Send for signature using template anchor tags const result = await TurboSign.sendSignature({ fileLink: 'https://example.com/contract.pdf', documentName: 'Service Agreement', recipients: [ { name: 'John Doe', email: 'john@acme.com', signingOrder: 1 } ], fields: [ { type: 'signature', recipientEmail: 'john@acme.com', template: { anchor: '{SignHere}', placement: 'replace', size: { width: 200, height: 50 }, }, }, { type: 'date', recipientEmail: 'john@acme.com', template: { anchor: '{DateHere}', placement: 'replace', size: { width: 150, height: 30 }, }, }, ], }); // Returns: { success: true, documentId: "...", message: "..." } // Recipients automatically receive signing invitation via email ``` ### TypeScript SDK, coordinates Same call, with fields positioned by `page`, `x`, `y`, `width` and `height` instead of a `template` anchor (signature at page 1, x 100, y 650, 200 by 50; date at page 1, x 320, y 650, 150 by 30). ### REST API, template tags ```javascript // Auto-position fields using template anchor tags const formData = new FormData(); formData.append('file', pdfFile); formData.append('recipients', JSON.stringify([ { name: 'John Doe', email: 'john@acme.com', signingOrder: 1 }, { name: 'Jane Smith', email: 'jane@acme.com', signingOrder: 2 } ])); // Fields auto-position at anchor tags like {SalesSigner} formData.append('fields', JSON.stringify([ { recipientEmail: 'john@acme.com', type: 'signature', template: { anchor: '{SalesSigner}', placement: 'replace', size: { width: 200, height: 50 } } }, { recipientEmail: 'john@acme.com', type: 'date', template: { anchor: '{SalesDate}', placement: 'replace', size: { width: 150, height: 30 } } } ])); formData.append('documentName', 'Service Agreement'); const response = await fetch('https://api.turbodocx.com/turbosign/single/prepare-for-signing', { method: 'POST', headers: { 'Authorization': `Bearer ${apiKey}`, 'x-rapiddocx-org-id': orgId }, body: formData }); const { success, documentId, message } = await response.json(); // Returns: { success: true, documentId, message } // Signers automatically receive email with signing link ``` ### REST API, coordinates Same endpoint and headers, with each field given `page`, `x`, `y`, `width` and `height` (for example signature at page 1, x 100, y 700, 200 by 50; date at page 1, x 100, y 640, 150 by 30) instead of a `template` anchor. ### Other SDKs Official SDKs in 6 languages (TypeScript, Python, PHP, Go, Java, Ruby): production-ready, with full type definitions, documentation and working examples. Open source (MIT licensed) and actively maintained: https://github.com/TurboDocx/sdk Need help integrating? Join the Discord community: https://discord.gg/NYKwz4BcpX. Full documentation: https://docs.turbodocx.com. ## Adobe Sign API FAQ ### Which Adobe Acrobat Sign plan includes API access? Adobe's Acrobat Sign API FAQ (last updated June 19, 2026) says API access is reserved exclusively for enterprise and developer tier accounts. Adobe's developer quickstart adds that granting group-level or account-level OAuth scopes requires the Business or Enterprise edition of Acrobat Sign. The Acrobat pricing page (Standard, Pro and Studio plans) does not list API access, and it points larger organizations to Adobe's sales team for volume licensing. ### How much does the Adobe Sign API cost? Adobe does not publish a price for Acrobat Sign API access. Billing is based on transactions: a transaction occurs each time a document (or set of related documents) is sent to recipients, and an agreement sent through the API is billable the same way as one sent from the web app. Acrobat Sign Business and Enterprise plans sold as user licenses include 150 transactions per user per year unless your contract says otherwise (Acrobat Standard and Pro are listed as unlimited), and high-volume business and enterprise customers can buy a total volume of transactions with unlimited users through their sales agent. ### Is there a free Adobe Sign developer account? Yes. Adobe offers a free Developer Edition of Acrobat Sign with no commitment. It includes access to the Acrobat Sign API and testing for document exchange, execution and emailing copies of signed agreements, and test documents carry a "test" label. Adobe treats developer accounts as non-billable; if you later promote that account to a billable plan, existing transactions count as consumed once they are modified. The separate Acrobat Sign Sandbox is a paid environment that requires an enterprise-level account with an assigned success manager. ### What are the Adobe Sign API rate limits? Adobe enforces limits per endpoint at the minute, hour and day levels, applied per user (or per IP address when no user is known), and says your service plan determines your rate. Throttled calls return HTTP 429 with a THROTTLING_TOO_MANY_REQUESTS code and a Retry-After value in seconds. Identical GET calls are capped at 3 per minute on GLOBAL, ENTERPRISE and DEVELOPER tiers and 3 per 3 minutes on all other tiers. For accounts created after May 20, 2025, retrying before the Retry-After interval ends resets the wait. ### Does the Adobe Sign API support embedded signing? Adobe documents GET /agreements/{agreementId}/signingUrls, which returns an esignUrl for each signer, and describes it for in-person signing on a device. Its developer guide also lists embedding a signing UI in your app. Platforms whose product needs to access multiple Acrobat Sign accounts fall under the Acrobat Sign Embed partner program, which Adobe asks you to contact it about. ### Which SDKs does Adobe offer for Acrobat Sign? Adobe lists C#, Java, JavaScript and OpenAPI SDKs plus REST samples in its adobe/acrobat-sign GitHub repository, but its SDK page (last updated January 4, 2024) says the SDKs are obsolete and have not been in sync with the REST v6 API for a while. Adobe directs developers to the REST v6 API reference and its Postman workspace instead. ### How do Adobe Sign API webhooks work? You create webhooks through the REST API or the Acrobat Sign web app, at account, group, user or resource scope (user and resource only through the API). Adobe first sends a verification request and your HTTPS endpoint must echo the X-AdobeSign-ClientId value. If your endpoint is down, Adobe retries over 72 hours, doubling the interval from 1 minute up to every 12 hours (15 retries), and an account can receive at most 30 concurrent webhook and callback notifications. ### How does TurboSign compare to the Adobe Sign API? TurboSign includes API access on every tier (Free, Team, Pro and Enterprise) and ships official SDKs in 6 languages (TypeScript, Python, PHP, Go, Java, Ruby), real-time webhooks and embedded signing through signing URLs your server requests. The Free plan includes 5 signatures a month, and the Pro plan includes 60 signatures a month via API key, with unlimited in-app signing. Paid plans come with a price match guarantee. ## Sources Adobe Acrobat Sign details checked against Adobe's own documentation in October 2026. 1. [Adobe Help Center: Adobe Acrobat Sign API FAQ](https://helpx.adobe.com/sign/web/developers/rest-apis/api.html) 2. [Adobe Help Center: Understand transaction limits](https://helpx.adobe.com/sign/web/system-level-resources/transaction-limits.html) 3. [Adobe Help Center: Understand transaction consumption](https://helpx.adobe.com/sign/web/system-level-resources/adobesign-transaction-consumption.html) 4. [Adobe Help Center: Acrobat Sign Sandbox overview](https://helpx.adobe.com/sign/web/developers/sandbox/overview.html) 5. [Adobe Help Center: Acrobat Sign webhook overview](https://helpx.adobe.com/sign/web/developers/webhooks/overview.html) 6. [Adobe Developer: Acrobat Sign developer guide](https://developer.adobe.com/acrobat-sign/docs/overview/developer_guide/) 7. [Adobe Developer: API usage (throttling and signing URLs)](https://developer.adobe.com/acrobat-sign/docs/overview/developer_guide/apiusage) 8. [Adobe Developer: Create an application quickstart](https://developer.adobe.com/acrobat-sign/docs/overview/developer_guide/gstarted) 9. [Adobe Developer: Acrobat Sign SDK downloads](https://developer.adobe.com/acrobat-sign/docs/overview/sdks/) 10. [Adobe Developer: Webhooks in Acrobat Sign](https://developer.adobe.com/acrobat-sign/docs/overview/acrobat_sign_events/) 11. [Adobe Developer: Acrobat Sign Embed partner guide](https://developer.adobe.com/acrobat-sign/docs/overview/embedpartner/) 12. [Adobe: Free Developer Edition of Acrobat Sign](https://www.adobe.com/acrobat/business/developer-form.html) 13. [Adobe: Acrobat plans and pricing](https://www.adobe.com/acrobat/business/pricing/plans.html) 14. [Adobe: Acrobat Sign for business](https://www.adobe.com/acrobat/business/sign.html) 15. [Adobe: Acrobat Sign REST API v6 reference](https://secure.na1.adobesign.com/public/docs/restapi/v6) 16. [GitHub: adobe/acrobat-sign](https://github.com/adobe/acrobat-sign) ## Related Resources Explore more about TurboSign API and developer resources. - [TurboSign API & SDKs](https://www.turbodocx.com/products/api-and-sdk.md): Modern REST API with multiple SDKs - [Adobe Sign Product Alternative](https://www.turbodocx.com/adobe-sign-alternative.md): Why teams leave Adobe Sign for TurboSign - [Best E-Signature API Comparison](https://www.turbodocx.com/best-esignature-api-comparison.md): Developer-focused API comparison - [Developer Use Cases](https://www.turbodocx.com/developers.md): Fast integration without Adobe dependencies - [Bulk Signature Sending Guide](https://www.turbodocx.com/resources/bulk-signature-sending-guide.md): Implement eSignatures without Adobe SDK complexity - [API Integration Best Practices](https://www.turbodocx.com/resources/api-integration-best-practices.md): Production-ready eSignature integration patterns ## Ready to Build with TurboSign API? Start with 5 free signatures a month, API access on every plan, SDKs in 6 languages and real-time webhooks. Paid plans come with a price match guarantee. [Start Building Free](https://app.turbodocx.com) or [read the docs](https://docs.turbodocx.com). --- --- title: "6 eSignature APIs Compared: 2026 Pricing & SDKs | TurboDocx" description: "6 eSignature API platforms compared on pricing, SDKs, embedded signing, and webhooks: TurboSign, DocuSign, DocuSeal, PandaDoc, SignNow, and Dropbox Sign." url: "https://www.turbodocx.com/best-esignature-api-comparison" --- # eSignature API Platforms Compared: Pricing, SDKs & Features > Side-by-side comparison of the best eSignature API platforms and digital signature APIs for developers in 2026: features, pricing, SDKs, and integration capabilities. **The best eSignature API platforms compared:** [TurboSign](https://www.turbodocx.com/e-signature-api.md) (best overall digital signature API for developers: TypeScript SDK, free tier, integrated CPQ, price match guarantee), **DocuSeal** (best open-source, $20/user/mo Pro seat + $0.20 per completed document), **DocuSign** (best enterprise, API plans from $50/mo), **PandaDoc** (best all-in-one for sales, production API key on Enterprise), **SignNow** (best mid-market value, API plans from $84/mo billed annually), and **Dropbox Sign** (best for Dropbox ecosystem, API plans from $75/mo billed yearly). All 6 support embedded signing, webhooks, and UETA/ESIGN compliance, though some gate embedded signing behind higher plans. ## Agentic Quickstart Skill Skip the boilerplate: your AI coding agent writes the integration. Install with: ```bash npx skills add TurboDocx/quickstart ``` [How it works](https://www.turbodocx.com/quickstart.md) ## E-Signature API Platform Feature Comparison | Feature | TurboSign | DocuSeal | DocuSign | PandaDoc | SignNow | Dropbox Sign | | --- | --- | --- | --- | --- | --- | --- | | Free tier | 5/month | Yes (no API on cloud free) | Dev sandbox only | Free sandbox | Dev mode + trial | Test mode only | | API pricing (entry) | Free | $20/user/mo + $0.20/doc | From $50/mo (annual) | Enterprise plan | From $84/mo (annual) | From $75/mo (annual) | | TypeScript SDK | Yes | Yes | Node.js (JavaScript) | Types via Node SDK | Yes | Types via Node SDK | | Official server SDKs | 6 languages | 7 languages | 6 languages | 4 languages | 5 languages | 6 languages | | Embedded signing | Yes | Pro plan | Enhanced plan only (per pricing page) | Enterprise (requires API plan) | Yes | Standard plan+ | | White-label | Yes | On-prem Pro | Custom branding | Custom branding | Yes | Premium plan | | Webhooks | Yes | Yes | Yes | Yes | Yes | Yes | | Integrated CPQ | Included | No | No | Paid add-on | No | No | | Document automation | Native | DOCX variables (Pro) | Limited | Yes | DOCX to PDF pre-fill | No | | n8n integration | Official node | Official node | No | No | No | No | | UETA/ESIGN compliant | Yes | Yes | Yes | Yes | Yes | Yes | | On-premises | Enterprise | Yes | No | No | Yes | No | | Price matching | Guaranteed | No | No | No | No | No | Competitor plans and prices are taken from each vendor's own pricing and developer pages, checked October 2026. DocuSign, SignNow, and Dropbox Sign entry prices are billed annually. SDK counts treat JavaScript and TypeScript as one language (TurboSign: TypeScript/JavaScript, Python, PHP, Go, Java, Ruby). TurboSign self-hosting is offered on the Enterprise plan; see [TurboDocx pricing](https://www.turbodocx.com/pricing.md). Sources are listed under the pricing comparison below. ## Which E-Signature API Should You Choose? - **TurboSign (Best Overall):** Developer-first API with TypeScript SDK, free CPQ, 5 free signatures/month, and price match guarantee. Free API access (5 signatures/mo), price match guarantee. [Learn more](https://www.turbodocx.com/e-signature-api.md) - **DocuSeal (Best Open-Source):** Open-source with a free self-hosted edition that includes a basic API. Full API and embedding need a Pro seat plus a per-document fee. $20/user/mo + $0.20 per completed document. - **DocuSign (Best Enterprise):** Industry leader with extensive compliance, global presence, and advanced audit capabilities for large enterprises. API plans from $50/mo (40 envelopes/mo, billed annually). [DocuSign API alternative](https://www.turbodocx.com/docusign-api-alternative.md) - **PandaDoc (Best All-in-One):** All-in-one platform combining proposals, quotes, contracts, and signatures for sales teams. Free sandbox; production API key on Enterprise. [PandaDoc API alternative](https://www.turbodocx.com/pandadoc-api-alternative.md) - **SignNow (Best Mid-Market):** Part of the airSlate business automation platform, with published API pricing, a free dev mode, and an on-premises appliance option. API plans from $84/mo (billed annually). - **Dropbox Sign (Best Dropbox Ecosystem):** Formerly HelloSign. Developer-friendly API with clean design and deep Dropbox integration. API plans from $75/mo (billed yearly). [HelloSign API alternative](https://www.turbodocx.com/hellosign-api-alternative.md) ## In-Depth E-Signature API Reviews Each digital signature API platform reviewed on SDK coverage, pricing model, pros and cons, and the team it fits best. ### TurboSign by TurboDocx Developer-first eSignature API with integrated CPQ, a type-safe TypeScript SDK, and native document automation in one platform. Pros: - TypeScript SDK with full type safety, autocomplete, and compile-time checks - Free integrated CPQ for quote-to-signature workflows - Official n8n node connecting 400+ apps for no-code automation - White-label support, API access on every plan, and a price matching guarantee - 5 free signatures per month, no credit card required Cons: - Newer player with less brand recognition than DocuSign Best for: Developers building SaaS platforms with quote-to-signature workflows, agencies creating white-label solutions, and MSPs or channel partners seeking recurring revenue with developer-friendly tools. ### DocuSeal Open-source eSignature platform with both cloud and self-hosted deployment for teams that value transparency and cost control. Pros: - Open-source, transparent codebase - Self-hosted deployment option - Active community development Cons: - Full API and embedding require a Pro seat ($20/user/mo) plus $0.20 per completed document - Free cloud plan has no API access - Full white-label branding is limited to the on-premises Pro edition Best for: Cost-conscious teams, open-source advocates, and organizations that need on-premises deployment and full control over their infrastructure. ### DocuSign The enterprise industry leader, with the broadest compliance certifications and global support for highly regulated organizations. Pros: - Industry-leading brand trust - Extensive enterprise compliance - Global presence and support - Advanced security and audit trails Cons: - Higher cost structure aimed at enterprises - Embedded signing is listed only on the Enhanced plan on DocuSign's pricing page - Starter API plan ($50/mo) excludes custom branding - No free production tier (free developer sandbox only) Best for: Large enterprises with complex compliance needs and high signing volumes, especially in regulated industries such as healthcare, finance, and legal. ### PandaDoc All-in-one document platform combining proposals, contracts, and eSignatures, built for sales teams closing deals. Pros: - Proposals and signatures in one platform - Strong sales workflow features - Built-in analytics and tracking - CRM integrations Cons: - Production API key requires the Enterprise plan plus activation - No standalone TypeScript SDK (types ship with the Node client) - CPQ is a paid add-on on Enterprise Best for: Sales teams that want proposals, quotes, contracts, and signatures in one tool and prioritize sales workflows over developer flexibility. ### SignNow Reliable mid-market eSignature capability inside the broader airSlate business automation platform. Pros: - Part of the airSlate automation platform - Published API pricing from $84/mo (billed annually) - Free dev mode plus a 250-invite production trial - On-premises private cloud appliance option Cons: - Professional API plan is billed annually - Quotas are counted in signature invites per year Best for: Teams already in the airSlate ecosystem and mid-market companies that need reliable signing without enterprise-level costs. ### Dropbox Sign (HelloSign) Developer-friendly API with clean design and deep integration into the Dropbox ecosystem. Pros: - Developer-friendly with good documentation - Dropbox integration and ecosystem - Official SDKs in 6 languages - Free test mode across all API endpoints Cons: - Embedded signing starts on the Standard plan ($250/mo, billed yearly) - Full white-label branding requires the Premium plan - Test mode requests are watermarked and not legally binding Best for: Teams heavily invested in the Dropbox ecosystem who value clean API design and solid documentation. ## E-Signature API Pricing Comparison Pricing is one of the most critical factors when choosing an e-signature API. Here's how the pricing models compare: | Provider | Pricing Model | Starting Cost | Free Tier | | --- | --- | --- | --- | | TurboSign | Price match guarantee | Free: 5 sigs/mo | Yes | | DocuSeal | Pro seat + per completed document | $20/user/mo + $0.20/document | Free plan (no cloud API) | | DocuSign | Annual plan with monthly envelope quota | $50/mo for 40 envelopes/mo (billed annually, $600/yr) | Dev sandbox only | | PandaDoc | Enterprise plan for production API key | Enterprise (price via sales) | Free sandbox | | SignNow | Annual plan with invite quota | $84/mo for 500 invites/yr (billed annually) | Dev mode + trial | | Dropbox Sign | Annual plan with monthly request quota | $75/mo for 50 requests/mo (billed yearly) | Test mode only | Sources (checked October 2026): [DocuSeal pricing](https://www.docuseal.com/pricing), [DocuSign API plans](https://ecom.docusign.com/plans-and-pricing/developer), [PandaDoc production API key](https://developers.pandadoc.com/reference/production-api-key), [SignNow API pricing](https://snseats.signnow.com/purchase/api/pricing), [Dropbox Sign API pricing](https://sign.dropbox.com/products/dropbox-sign-api/pricing). Enterprise tiers at DocuSign, PandaDoc, SignNow, and Dropbox Sign are quoted through sales. SDK and feature sources: [DocuSeal SDKs](https://github.com/docusealco), [DocuSeal API (DOCX variables)](https://www.docuseal.com/docs/api), [DocuSign SDKs](https://github.com/docusign), [PandaDoc SDKs](https://developers.pandadoc.com/reference/sdk), [SignNow SDKs](https://www.signnow.com/developers), [SignNow document generation](https://www.signnow.com/release-notes/signnow-api), [SignNow on-premises](https://www.signnow.com/private-cloud-solution), [Dropbox Sign SDKs](https://developers.hellosign.com/docs/sdks/overview/), [DocuSeal n8n node](https://n8n.io/integrations/docuseal/). **TurboSign price matching guarantee:** We match or beat any competitor's published API pricing. [Contact us](https://www.turbodocx.com/demo) for custom enterprise pricing. ## How to Choose the Right Digital Signature API Platform When comparing eSignature API platforms and digital signature APIs for developers, evaluate these critical factors based on your specific needs: - **SDK Quality & Language Support:** Type-safe SDKs prevent runtime errors and speed up integration. Check for your preferred language. - **Pricing Transparency:** Avoid "contact sales" pricing traps. Look for published rates and free tiers for testing. - **Embedded Signing:** Critical for SaaS platforms: keep users in your app instead of redirecting to a third-party page. - **Workflow Automation:** Webhooks, n8n nodes, and Zapier integrations for automating post-signature workflows. - **Legal Compliance:** UETA/ESIGN Act compliance is table stakes for legally binding electronic signatures in the US. - **Documentation Quality:** Good API docs with code examples in multiple languages dramatically reduce integration time. ## Frequently Asked Questions ### What is the best eSignature API platform in 2026? The best eSignature API platform depends on your needs. TurboSign is the best digital signature API for developers wanting a TypeScript SDK with integrated CPQ and free tier. DocuSeal is best for open-source and self-hosting. DocuSign is best for enterprise compliance. PandaDoc is best for sales teams needing all-in-one proposals and signatures. ### Which digital signature API has the best developer experience? TurboSign and DocuSeal offer the best developer experience among digital signature API platforms in 2026. TurboSign provides a type-safe TypeScript SDK, comprehensive REST API documentation, webhook support, and an official n8n node for workflow automation. DocuSeal offers clean API design with self-hosted deployment options. ### How much do e-signature APIs cost? E-signature API pricing varies widely. TurboSign: 5 free signatures/month with price match guarantee on paid plans. DocuSeal: full API needs a Pro seat at $20/user/month plus $0.20 per completed document, and the free self-hosted open-source edition includes a basic API. DocuSign API plans start at $50/month for 40 envelopes (billed annually). PandaDoc offers a free API sandbox, and its developer docs say a production API key requires the Enterprise plan. SignNow API plans start at $84/month for 500 signature invites per year, billed annually. Dropbox Sign API plans start at $75/month for 50 signature requests, billed yearly. Enterprise tiers are quoted through sales. Prices checked October 2026. ### Can I embed e-signatures into my application? Yes. TurboSign, DocuSeal, DocuSign, PandaDoc, SignNow, and Dropbox Sign all offer embedded signing that keeps the signing experience inside your web or mobile application. Check plan requirements: DocuSign lists embedded signing only on the Enhanced plan on its pricing page, Dropbox Sign includes it from the Standard plan, and DocuSeal requires Pro. ### Which e-signature APIs are UETA and ESIGN Act compliant? All 6 platforms (TurboSign, DocuSign, DocuSeal, PandaDoc, SignNow, and Dropbox Sign) state compliance with the UETA (Uniform Electronic Transactions Act) and the ESIGN Act, which makes their electronic signatures legally binding in the United States. ## Related Resources - [Document Generation API & SDK](https://www.turbodocx.com/products/api-and-sdk.md): REST API and multi-language SDKs for signatures and document automation - [TurboSign E-Signature API](https://www.turbodocx.com/e-signature-api.md): API docs, SDK examples, and developer reference for TurboSign - [Bulk Signature Sending Guide](https://www.turbodocx.com/resources/bulk-signature-sending-guide.md): Send documents to multiple signers at once with spreadsheet-driven workflows ## Simple Pricing Start for free and upgrade as you need. | Plan | Price | Includes | | --- | --- | --- | | Free | $0 / user | 1,000 AI Credits / month; Free E-Signature, 5 / month; 5 Quotes / month; 5 TurboDocx Generations / month (Document & Presentation Templates); Unlimited TurboDocx Templates; Unlimited Standard Integrations; Single User; PDF only; API Access (5 Signatures and 5 Quotes per month via API key, the same limits as in-app usage) | | Team (Promotional) | $10 / user per month (was $20, save 50%) | 2,500 AI Credits / month; 15 Signatures / month and 15 Quotes / month (both include API access, shared across in-app and API-key usage); 10 TurboDocx Generations / month; Unlimited TurboDocx Templates; Full Document, Slide Deck export; Everything in the Free plan | | Pro (Best Value, Most Popular) | $20 / user per month (was $35, save 43%) | Unlimited AI Credits / month; Unlimited Signatures / month; Unlimited Quotes; Unlimited TurboDocx Generations; Unlimited TurboDocx Templates; Bulk Signature Sending; API access: 60 Quotes + 60 Signatures / mo, rate-limited AI; SMS one-time passcodes for signers; Everything in the Team plan | | Enterprise | Contact us | Unlimited +; Unlimited Quotes + Custom Workflows; Customizable AI Packages; Bring your own AI models; Auditing and Compliance; Self-hosted solution option; SAML/OIDC SSO; SMS one-time passcodes for signers; Custom API limits | Notes: - Bulk Signature Sending: send personalized documents for e-signature to hundreds of recipients at once using a spreadsheet. Upload a CSV or Excel file, map columns to template variables, configure signature fields, and submit the entire batch in minutes. Also available via the Bulk API (`POST /turbosign/bulk/ingest`). - Pro API access: API-key (programmatic) usage is metered separately from in-app usage. Pro API keys get 60 Quotes and 60 Signatures per month, with per-minute burst limits. Named users logged into the TurboDocx UI keep the unlimited limits. AI endpoints are rate-limited per fair-use policy (429 on overflow, retry with backoff). Contact us for volume pricing. - Enterprise custom API limits: API rate limits and monthly caps are negotiated per contract. Dedicated capacity available. - SMS one-time passcodes for signers (Pro and Enterprise): signers can verify by text message as well as email. Texts go through your own Twilio or RingCentral account, so your provider bills them at your rates. Email passcodes are included on every plan. Full pricing: https://www.turbodocx.com/pricing.md ## Start Building with TurboSign 5 free signatures per month. No credit card required. TypeScript SDK with full type safety. Price matching guarantee on all plans. [Try TurboSign free](https://app.turbodocx.com/signup) or [get custom API pricing](https://www.turbodocx.com/demo). --- --- title: "Blog | TurboDocx | TurboDocx" description: "Dive into the TurboDocx blog for unique insights on leveraging AI in document automation to boost efficiency and transform your document workflows." url: "https://www.turbodocx.com/blog" --- # TurboDocx Blog > Insights, guides, and updates on document automation. ## All posts Newest first. - [The Future of SaaS: Build, Buy, or Integrate? (Podcast)](https://www.turbodocx.com/blog/cool-kids-table-podcast-future-of-saas.md): Nicolas Fry joined The Cool Kids Table podcast from Helpt to talk about how AI changes build versus buy, why integrations win, and loop engineering. Watch, listen, and read. (Podcast, Nicolas Fry, Oct 16, 2026) - [n8n CPQ Quoting: Draft Sales Quotes from Slack with AI](https://www.turbodocx.com/blog/n8n-turboquote-cpq-slack.md): Ask for a quote in plain English in Slack; an AI agent maps it to real catalog SKUs and TurboQuote drafts a priced quote with a review link. The AI picks products, never prices. A published n8n workflow. (Sales Automation, Nicolas Fry, Aug 27, 2026) - [n8n E-Signature from Airtable, Filed Back to Google Drive](https://www.turbodocx.com/blog/n8n-esignature-airtable.md): Generate a personalised agreement per Airtable row, send each for e-signature, chase anyone unsigned after 3 days, then archive the signed PDF and audit trail back to Drive. A published n8n workflow. (E-Signature, Nicolas Fry, Aug 26, 2026) - [n8n E-Signature from Excel with a Slack Approval Step](https://www.turbodocx.com/blog/n8n-esignature-excel-slack.md): Queue contracts in an Excel table, generate them with TurboDocx, approve in Slack, then send for e-signature and file the signed PDF back to SharePoint. A published, importable n8n workflow. (E-Signature, Nicolas Fry, Aug 25, 2026) - [Your Agent Can Do Everything Except Finish the Paperwork](https://www.turbodocx.com/blog/ai-agents-last-mile-documents.md): An AI agent reads the ticket, queries the CRM, and drafts a perfect summary, then hands you markdown and a human opens Word. Why the last step is a different kind of problem, and what actually closes it. (AI for Developers, Yacine Kahlerras, Aug 24, 2026) - [The AsyncAPI Packages Were Signed, Verified, and Malicious](https://www.turbodocx.com/blog/asyncapi-npm-attack-provenance-attestations.md): Malicious npm versions shipped through AsyncAPI's own CI with valid provenance attestations and a payload that fires on import. Why signing and provenance verify origin, not intent, and what actually defends you. (Security, Amit Sharma, Jul 24, 2026) - [If the Agents Write the Code, They Can Document It Too](https://www.turbodocx.com/blog/automate-product-documentation-with-ai-agents.md): We open-sourced Guidewright: an Agent Skill that writes and reviews product docs by driving your live app, with an accurate red box on the exact element each step tells the user to click. One skill replaced a stack of SaaS subscriptions. (AI for Developers, Nicolas Fry, Jun 22, 2026) - [I Vibe-Coded a Signable Invoice App in ~12 Minutes](https://www.turbodocx.com/blog/i-built-a-signable-invoice-app-with-lovable.md): No traditional development, just Lovable, three plain-English prompts, and the TurboDocx Quickstart Skill. The full play-by-play of building an invoice generator that produces a signable PDF and emails it for signature in about 12 minutes. (AI for Developers, Alex Martinez, Jun 9, 2026) - [Lovable Review: Build an App From Prompts?](https://www.turbodocx.com/blog/lovable-review.md): An honest Lovable review using one real case study: a signable invoice app built in three prompts and about twelve minutes. The pros, the one self-healed hiccup, and the verdict. (AI for Developers, Alex Martinez, Jun 8, 2026) - [TurboDocx + Lovable: Step-by-Step Integration Guide](https://www.turbodocx.com/blog/turbodocx-lovable-integration-guide.md): The developer walkthrough to add e-signatures to a Lovable app: install the Quickstart Skill, set one sender variable, and send a real signature with sendSignature. The SDK deep dive behind a ~12 minute build. (AI for Developers, Alex Martinez, Jun 8, 2026) - [How Long to Build an E-Signature App?](https://www.turbodocx.com/blog/how-long-to-build-an-esignature-app.md): We timed it. A signable invoice app in about 12 minutes across three prompts, with the timestamps to prove it, plus an honest estimate of the same build from scratch. (AI for Developers, Alex Martinez, Jun 8, 2026) - [How to Add E-Signatures to a Lovable App](https://www.turbodocx.com/blog/add-esignature-to-lovable.md): Lovable builds the UI, but a drawn squiggle is not a legally-binding signature. Here is what it means to add e-signatures to a Lovable app, and how three prompts shipped a signable invoice in under 15 minutes. (AI for Developers, Alex Martinez, Jun 8, 2026) - [Vibe Coding Legal Documents](https://www.turbodocx.com/blog/vibe-coding-legal-documents.md): Vibe coding fits document-heavy work like contracts, invoices, and NDAs. Here is what is safe to automate, what still needs human review, and how to ship the document and the e-signature flow together. (E-Signature, Monica Talbert, Jun 7, 2026) - [The No-Code E-Signature Stack](https://www.turbodocx.com/blog/no-code-esignature-stack.md): You do not need an engineer to get contracts signed online. Here are the three pieces a real e-signature workflow needs, and how to assemble them without code. (E-Signature, Monica Talbert, Jun 7, 2026) - [Add E-Signatures to Invoices Without Code](https://www.turbodocx.com/blog/add-esignatures-to-invoices-without-code.md): Collect a signature on your invoice without a developer. A fully hosted browser flow plus an AI-builder route for a branded, signable invoice app. (E-Signature, Monica Talbert, Jun 6, 2026) - [Signable PDFs Explained](https://www.turbodocx.com/blog/signable-pdfs-explained.md): What actually makes a PDF signable, how interactive signature fields work, and the fastest practical ways to create one, from doing it by hand to letting an AI build generate the whole flow. (E-Signature, David González, Jun 6, 2026) - [E-Signatures for Invoices: Why and How to Start](https://www.turbodocx.com/blog/esignature-for-invoices.md): Signed invoices mean documented approvals, fewer disputes, and faster payment. Here is why e-signatures on invoices matter and how to start collecting them, including a no-code path. (E-Signature, Monica Talbert, Jun 6, 2026) - [What Is an Electronic Signature?](https://www.turbodocx.com/blog/what-is-an-electronic-signature.md): A plain-English guide to electronic signatures: what they are, how they differ from digital signatures, whether they are legally binding, and how to add one. (E-Signature, David González, Jun 5, 2026) - [AI Document Generation + E-Signature in One Flow](https://www.turbodocx.com/blog/vibecode-docs-and-signatures.md): Generate the document and send it for signature in a single AI-built flow. Combine HTML-to-DOCX generation with TurboSign e-signatures using one Quickstart Skill. (AI for Developers, Alex Martinez, Jun 5, 2026) - [Ship E-Signature in an Afternoon](https://www.turbodocx.com/blog/ship-esignature-in-an-afternoon.md): A realistic hour-by-hour account of adding a working e-signature flow in one afternoon using an AI coding agent and the TurboDocx Quickstart Skill. (AI for Developers, Alex Martinez, Jun 5, 2026) - [E-Signature Without a Backend: The Indie Dev Guide](https://www.turbodocx.com/blog/esignature-without-a-backend.md): You do not need to run signing infrastructure to add e-signatures. Call a hosted API from a serverless function, edge route, or script. (AI for Developers, Alex Martinez, Jun 5, 2026) - [Vibecode an E-Signature Flow: Add Signing with AI in Minutes](https://www.turbodocx.com/blog/vibecode-an-esignature-flow.md): Vibe coding works for backend plumbing too. Add a real, audited e-signature flow by prompting Claude Code or Cursor with the TurboDocx Quickstart Skill. (AI for Developers, Alex Martinez, Jun 5, 2026) - [Install the TurboDocx SDK via Agent Skill](https://www.turbodocx.com/blog/install-turbodocx-sdk-via-ai-agent-skill.md): Hand the open-source Quickstart Skill to your AI coding agent and it installs the TurboDocx SDK, configures the environment, and writes a working integration in one prompt. (AI for Developers, Alex Martinez, May 11, 2026) - [Webhook Security for E-Signature API Integrations](https://www.turbodocx.com/blog/how-to-webhook-hmac-guide.md): Webhooks are how e-signature and document APIs tell your app a contract was signed. Learn why HMAC verification matters and how to build a verified webhook receiver in Node.js. (Backend Architecture, Nicolas Fry, May 7, 2026) - [The Mail Merge Comeback: From Word 6.0 to Bulk E-Signatures](https://www.turbodocx.com/blog/the-mail-merge-comeback.md): Like vinyl records and Brendan Fraser, mail merge refused to stay dead. The nostalgic history of document automation and why 2026 is its renaissance year. (Product, Nicolas Fry, May 5, 2026) - [Beyond the First Name: Hyper-Personalization in B2B Sales Assets](https://www.turbodocx.com/blog/hyper-personalization-b2b-sales-assets.md): If your proposal looks like everyone else's, you've already lost. Learn how CRM-driven document automation creates hyper-personalized proposals, SOWs, and sales assets that close deals faster. (Sales & Operations, Monica Talbert, May 2, 2026) - [Serverless Backend Architecture: Complete Guide (2026)](https://www.turbodocx.com/blog/serverless-backend-architecture.md): Build modern serverless backends with AWS Lambda, edge computing, and WebAssembly. From cold start optimization to cost-efficient scaling patterns. (Backend Architecture, Amit Sharma, Mar 24, 2026) - [Event-Driven Architecture for Document Automation](https://www.turbodocx.com/blog/microservices-event-driven-architecture.md): The microservices patterns behind reliable document automation: event sourcing, CQRS, saga orchestration, and Kafka messaging for resilient, scalable systems. (Backend Architecture, Amit Sharma, Mar 23, 2026) - [15 React Hooks That Will Make You a 10x Developer in 2026](https://www.turbodocx.com/blog/react-hooks-you-need-to-know.md): Stop writing repetitive React code. These 15 built-in and custom hooks, useTransition, useOptimistic, useDebounce, and more, will transform how you build apps. (Frontend Development, Yacine Kahlerras, Mar 15, 2026) - [React Design Patterns: The Complete Guide](https://www.turbodocx.com/blog/react-design-patterns.md): Master 10 essential React design patterns, custom hooks, compound components, render props, server components, and more. Practical code for scalable apps. (Frontend Development, Yacine Kahlerras, Mar 14, 2026) - [React Performance Optimization: The Complete Guide](https://www.turbodocx.com/blog/react-performance-optimization.md): Master React performance with memoization, code splitting, list virtualization, and advanced techniques. Practical patterns to eliminate unnecessary re-renders. (Frontend Development, Yacine Kahlerras, Mar 13, 2026) - [Best Claude Code Plugins, Skills & MCP Servers (2026)](https://www.turbodocx.com/blog/best-claude-code-skills-plugins-mcp-servers.md): The 7 Claude Code plugins, skills, and MCP servers I use daily. What each does, when to use it, and how they work together as an AI development toolkit. (Developer Productivity, Nicolas Fry, Mar 11, 2026) - [How to Write a CLAUDE.md File That Actually Works: Best Practices for API Projects](https://www.turbodocx.com/blog/how-to-write-claude-md-best-practices.md): Best practices for structuring your Claude Code context file, from single projects to monorepos to API integrations. Based on official Anthropic docs and real-world usage. (Developer Productivity, Nicolas Fry, Mar 9, 2026) - [MSP Automation with n8n: The Complete Guide to Workflow Integration 2025](https://www.turbodocx.com/blog/msp-automation-n8n-workflows.md): Discover how MSPs can automate their entire tech stack with n8n workflows. From RMM and PSA to documentation and security, learn how automation drives profit margins and happier customers. (MSP & IT Automation, Alex Martinez, Dec 15, 2025) - [Why Your Sales Team Hates Your Proposal Process (And How to Fix It)](https://www.turbodocx.com/blog/why-sales-teams-hate-proposals.md): Learn how to eliminate copy-paste errors, centralize content, and tailor every proposal, without the manual work that wastes hours. (Sales & Operations, Nicolas Fry, Dec 7, 2025) - [The Power of Maintaining Open Source Software](https://www.turbodocx.com/blog/the-power-of-maintaining-open-source.md): Our commitment to maintaining @turbodocx/html-to-docx, our SDK ecosystem, and what it means to build tools that thousands of developers depend on in their automation workflows and API integrations. (Engineering & Open Source, Nicolas Fry, Dec 6, 2025) - [Top 10 n8n Workflow Integrations for Sales Teams](https://www.turbodocx.com/blog/top-10-n8n-integrations-sales-teams.md): Discover the best n8n workflow integrations for sales automation. Learn how TurboDocx, HubSpot, Salesforce, and 8 other powerful nodes can automate your sales processes. (Sales Automation, Alex Martinez, Nov 28, 2025) - [Why Every Channel Partner Should Be Selling E-Signature in 2025](https://www.turbodocx.com/blog/why-channel-partners-should-sell-esignature.md): E-signature delivers predictable recurring revenue with minimal overhead. Why MSPs and VARs are adding it to their portfolios. (Channel Strategy, David González, Nov 10, 2025) - [How to Write a Clear and Effective Statement of Work (SOW)](https://www.turbodocx.com/blog/how-to-write-effective-sow.md): Master the art of creating SOWs that prevent scope creep and ensure project success. From project overview to fees, learn the essential sections every SOW needs. (Best Practices, Nicolas Fry, Oct 10, 2024) - [A Complete Guide to Document Automation](https://www.turbodocx.com/blog/a-complete-guide-to-document-automation.md): Learn everything you need to know about automating your document workflows (Guide, Nicolas Fry, Apr 26, 2024) - [Optimizing IT Workflow: A Guide to TurboDocx Templating](https://www.turbodocx.com/blog/optimizing-it-workflow-a-guide-to-turbodocx-templating.md): How IT teams can save hours every week with document automation (Use Cases, TurboDocx Team, Mar 5, 2024) - [Revolutionizing IT Workflows](https://www.turbodocx.com/blog/revolutionizingitworkflows.md): The future of IT documentation and automation (Industry Trends, TurboDocx Team, Feb 28, 2024) - [TurboDocx Enhances SCIM User Provisioning](https://www.turbodocx.com/blog/turbodocx-enhances-scim-user-provisioning-for-efficient-identity-management.md): Enterprise-grade identity management made simple (Product Updates, TurboDocx Team, Feb 20, 2024) --- --- title: "A Complete Guide to Document Automation | TurboDocx" description: "Explore our comprehensive guide to mastering document automation with TurboDocx, enhancing efficiency and accuracy across your business. Read More!" url: "https://www.turbodocx.com/blog/a-complete-guide-to-document-automation" --- # A Complete Guide to Document Automation > Everything you need to know about automating document workflows. Explore how document automation works, why businesses need it, and how to use TurboDocx to enhance efficiency and accuracy across your business. By Nicolas Fry (Founder & CEO, TurboDocx). Published April 26, 2024. 8 min read. Category: Guide. Document automation (also known as document generation or document assembly) is a process that enables users to streamline document workflows. Organizations can use document automation to create and send essential documents to stakeholders faster, improve business efficiencies, and scale productivity. This article provides a comprehensive guide on what document automation is, why modern businesses need this powerful solution, and how you can use TurboDocx's document automation and templating platform to enhance business operations. ## What Does Document Automation Look Like? Document automation involves using automation to consolidate and compile data from different sources to create a new, usable document. The documents can include contracts, proposals, statements of work, runbacks, onboarding materials, and more. Here are the general components of document automation software and solutions. ### Document Templating The first step to document automation involves creating templates for documents your business frequently uses, from master service agreements (MSPs) to term sheets. You can build your own templates, or select pre-existing ones. The automation technology will insert the right text, paragraphs, images, and more into the appropriate section of the document. ### Document Generation Once the templates are stored onto the platform, the automation software will fill out the necessary information to complete each document. Users can review, edit, and personalize the initial draft of the document as needed. This ability streamlines processes and helps organizations produce new documents at scale. ### Document Management Users can store all of their documents on document automation systems. These solutions also come with other features, like third-party integrations with data sources, file conversion capabilities, and team collaboration tools. Your organization will be able to reduce the friction of document workflows end-to-end with document automation solutions. ## Why Your Business Needs Document Automation? Document automation can bring numerous benefits for your business operations for any and all teams. Here's what you can experience in your organization. ### Efficient Document Workflows Document automation can help your business save time on document creation. Instead of manually copying-and-pasting information from various sources into a new template, you'll be able to automate this process. Document automation solutions include integrations with major third-party data sources, like Salesforce, to help users pull all of the information they need into one place, making document creation a painless process. ### Error Reduction Automating tedious tasks will also minimize the risk of human error. With automation, teams will be able to deliver more accurate and reliable deliverables faster than ever. Document automation will not only minimize document turnaround times, it can also help teams ensure they never miss another deadline. ### Standardized Branding Automating the document creation process with templates will ensure the consistency of your team's documents to stakeholders. As the quality and style of documents reflects brand values, you'll be able to build recognition and establish trust and professionalism with consistent documents. ### High-Quality Production at Scale With document automation, you'll be able to scale high-quality document creation and sharing for all major stakeholders. By automating repetitive tasks, you can ensure quality, consistency, and reliability in your processes. This ability will help your team stay ahead of deadlines and complete deals faster so you can focus more time on other high-growth priorities. ### Enhanced Client Relationships Respond to client needs more quickly with document automation. By sending high-quality documents like contracts, proposals, or legal documents in a timely manner, you'll be able to build trust and maintain your professional reputation with clients. ## How Different Teams and Industries Can Use Document Automation? Document automation can be used in any industry from law firms to healthcare services. Industries that depend on accuracy, reliability, and compliance can utilize document automation to reduce risk and maximize operational workflows. Various teams within specific industries can also take advantage of document automation to enhance productivity. From IT teams, legal teams, sales teams, and more, users will be able to generate whatever documents they need more efficiently. - Legal Teams - Sales Teams - IT Teams - Compliance ## What Features to Look for in Document Automation Software When trying to choose the right document automation solution for your business, evaluate your organization's needs. Narrowing down on your business' use cases will help you figure out the best solution for your business. For example, consider features, such as template customization options, what integrations are available, ease of use, pricing options, and more. Choosing a solution based on features that fit your organization's needs will help you choose the right document automation solution. - Template Customization - Third-Party Integrations - Ease of Use - Pricing Flexibility - Team Collaboration - Security & Compliance ## Automate Documents with TurboDocx Document automation is essential for modern businesses looking to optimize and scale their operations. By understanding the benefits of document automation, you'll be able to choose the right solution for your organization, streamline document workflows, and open up new growth opportunities. Take the first step toward transforming your business with document automation by trying TurboDocx for free. Or, if your business has specific needs, schedule a personalized demo of TurboDocx today. ## Ready to Transform Your Document Workflows? Start automating your documents today and experience the efficiency of TurboDocx. - [Schedule a Demo](https://www.turbodocx.com/demo) [Try TurboDocx Free](https://app.turbodocx.com/signup) --- --- title: "How to Add E-Signatures to a Lovable App | TurboDocx" description: "Add legally-binding e-signatures to a Lovable app in under 15 minutes. Three prompts plus the TurboDocx Quickstart Skill, and TurboSign handles the audit trail." url: "https://www.turbodocx.com/blog/add-esignature-to-lovable" --- # How to Add E-Signatures to a Lovable App > Your Lovable app can render a contract or invoice, but turning that into a legally-binding signed record is a separate problem. Here's what it means to add e-signatures to a Lovable app, why you'd want to, and how a single command wires up real signing. By Alex Martinez (Developer Relations & Automation Lead). Published June 8, 2026. 6 min read. Category: AI for Developers. Built with Lovable + TurboDocx. [Lovable](https://www.turbodocx.com/blog/lovable-review.md) turns a plain-English description into a working web app, which makes it one of the most popular ways to ship a project without writing the scaffolding by hand. The catch shows up the moment your app needs a real signature on a contract, an invoice, or an onboarding form. A drawn squiggle in a canvas element is not a legally-binding e-signature. You need an audit trail, a tamper-evident record, and compliance handling. "Adding e-signatures to a Lovable app" means connecting the app Lovable generated to a real e-signature service so a recipient can sign a document and you get back a verifiable, signed PDF. With [TurboSign](https://www.turbodocx.com/products/turbosign.md) and [the TurboDocx Quickstart Skill](https://www.turbodocx.com/quickstart.md), that connection takes just three short prompts. This post is the overview. For the line-by-line SDK walkthrough, jump to [the full step-by-step integration guide](https://www.turbodocx.com/blog/turbodocx-lovable-integration-guide.md). ## Why add e-signatures to a Lovable app? Most apps that handle agreements eventually need a signature: invoices, statements of work, NDAs, waivers, lease forms, partner contracts. Lovable can render a beautiful version of any of those documents. What it cannot do on its own is produce the legal artifact, the signed record with a timestamp, signer identity, and an audit trail that holds up if anyone questions it later. You could try to build signing yourself: a canvas to draw on, a database to store the image, some logic to stamp it onto a PDF. That path looks short and is not. A realistic from-scratch build would run several days once you account for the moving parts, roughly a day or two for the signing UI and PDF stamping, another day for storing signed documents and their metadata durably, and a day or more wiring up email delivery, status tracking, and the audit logging that makes the signature defensible. None of that is your product. Connecting a hosted signing API skips all of it, and the [US e-signature compliance](https://www.turbodocx.com/resources/us-esignature-compliance.md) and [European e-signature compliance](https://www.turbodocx.com/resources/european-esignature-compliance.md) work stays on TurboDocx infrastructure rather than your weekend project. There's a maintenance argument too. A hand-rolled signing flow is code you now own forever: you patch it when a browser changes how canvas events fire, you reissue certificates, you answer the support ticket when a signed PDF won't open. Pointing your Lovable app at a hosted signing API moves all of that off your plate. Your app keeps doing the one thing it's good at, presenting the document, while the signing service owns the parts that have to be exactly right every time. ## Wiring TurboSign in with one command We ran this end to end on June 8, 2026, starting from an empty Lovable project. The whole build took about 12 minutes across three prompts, including one Vite dependency hiccup that Lovable fixed on its own by restarting the dev server. The point is how little signing-specific work it took: once the Quickstart Skill is installed, you describe what you want in plain English and the agent makes the right TurboSign calls. The full timestamped walkthrough is on the hub: [I built a signable invoice app with Lovable](https://www.turbodocx.com/blog/i-built-a-signable-invoice-app-with-lovable.md). ## The one command that wires it up The second prompt is the whole trick. Instead of pasting API docs and hoping the model guesses the right method names, you install [the TurboDocx Quickstart Skill](https://www.turbodocx.com/quickstart.md) so Lovable gets ground truth. From the project, run the open-source `skills` CLI: ```bash npx skills add TurboDocx/quickstart ``` Create a free account at [app.turbodocx.com](https://app.turbodocx.com) (your first 5 signatures each month are free), grab your key from Settings, then API Keys, and add the integration's environment variables: ```bash TURBODOCX_API_KEY=your_api_key_here TURBODOCX_ORG_ID=your_org_id_here TURBODOCX_SENDER_EMAIL=you@company.com TURBODOCX_SENDER_NAME=Your Company Name ``` With the skill installed and the key in place, you tell Lovable what you want in plain English and it does the wiring. The skill reads your key from the environment rather than baking it into source, so nothing sensitive ends up in your generated code. ## Send immediately, or stage a review first By default the first version of the app created a signature that sat in an "under review" state, a deliberate staging step before anything reaches the signer. The third prompt fixed that in one go: "skip the review step and go straight to the full send." Behind the scenes that swaps `createSignatureReviewLink` for `sendSignature`, which emails the document to the recipient immediately. Two methods, one decision: stage a review, or fire and forget. You choose by describing the behavior you want, and the agent picks the right call. ## What TurboSign gives your Lovable app - **Hosted compliance**: Tamper-evident audit trails, certificate generation, and [ESIGN](https://www.govinfo.gov/app/details/PLAW-106publ229), [UETA](https://www.uniformlaws.org/committees/community-home?CommunityKey=2c04b76c-2b7d-4399-977e-d5876ba7e034), and [eIDAS](https://eur-lex.europa.eu/eli/reg/2014/910/oj/eng) alignment run on TurboDocx infrastructure, not inside your Lovable project. - **One API call to send**: A single sendSignature call emails the document, tracks status, and returns a signing link. No webhook plumbing required to get your first signature. - **Prompt-native setup**: The Quickstart Skill teaches Lovable the exact install command, the real SDK surface, and to read your key from an environment variable instead of hardcoding it. Because TurboSign is a hosted service exposed through the [e-signature API](https://www.turbodocx.com/e-signature-api.md), your Lovable app stays small. It collects a name and email, calls one endpoint, and shows status. Everything legally load-bearing lives on the server side. If you want the same capability outside of Lovable, the same SDK powers our [API and SDK](https://www.turbodocx.com/products/api-and-sdk.md) across JavaScript, Python, Go, PHP, and Java. ## Related Resources - [TurboDocx + Lovable Integration Guide](https://www.turbodocx.com/blog/turbodocx-lovable-integration-guide.md): The full step-by-step SDK walkthrough for wiring up signing. - [I Built a Signable Invoice App](https://www.turbodocx.com/blog/i-built-a-signable-invoice-app-with-lovable.md): The original ~12-minute build, prompt by prompt. ## Add signing to your Lovable app today Install the Quickstart Skill, open Lovable, and tell it to add e-signatures. Your first 5 each month are free. [Install the Quickstart Skill](https://www.turbodocx.com/quickstart.md) Lovable is a trademark of its respective owner. TurboDocx is an independent product and is not affiliated with or endorsed by Lovable. --- --- title: "How to Add E-Signatures to Invoices Without Code | TurboDocx" description: "Add a signature to your invoices without a developer. Two no-code paths: a hosted browser flow, and an AI-builder route for a branded, signable invoice app." url: "https://www.turbodocx.com/blog/add-esignatures-to-invoices-without-code" --- # How to Add E-Signatures to Invoices Without Writing Code > You do not need a developer to collect a signature on an invoice. Here are two paths that get a signature onto your invoice today: a fully hosted flow where you upload and send in your browser, and an AI-builder path for a branded, signable invoice app. By Monica Talbert (Solutions Architect). Published June 6, 2026. 6 min read. Category: E-Signature. Getting a client to formally sign off on an invoice used to mean printing, scanning, or chasing an email approval that never quite counts as a signature. It does not have to. A signed invoice gives you a clear, dated record that the client agreed to the amount, which protects you when a payment gets disputed and speeds up the ones that do not. If you want the business case first, our overview of [why e-signatures matter for invoices](https://www.turbodocx.com/blog/esignature-for-invoices.md) walks through it. This guide is for business owners, finance teams, and freelancers, not engineers. Everything below is no-code first, and it fits inside the broader category of tools we cover in [the no-code e-signature stack](https://www.turbodocx.com/blog/no-code-esignature-stack.md). If you are a developer who wants to wire signing into a serverless function instead, read our companion piece on [adding e-signatures without a backend](https://www.turbodocx.com/blog/esignature-without-a-backend.md) instead. That one is the developer route. This one is for people who do not want to touch code at all. ## Path 1: The hosted flow (zero code, five minutes) If you just need a signature on one invoice, or a handful, you never have to build anything. You upload the invoice and send it for signature directly in your browser. There is no app to install and nothing to set up beyond a free account. 1. Create a free account at app.turbodocx.com. 2. Upload your invoice as a PDF (export it from QuickBooks, Stripe, Wave, or your spreadsheet). 3. Drop a signature field, a date field, and an amount field onto the page by clicking where they go. 4. Type the client name and email, then hit send. 5. Your client gets an email, signs in their browser, and you both receive the signed copy with an audit trail. That is the entire flow. Your client never creates an account or installs anything; they click the link, sign in their browser, and they are done. You can reuse the same invoice layout for every client, so the second invoice takes seconds. Create your [free account at app.turbodocx.com](https://app.turbodocx.com) to try it, and remember that your first 5 signatures each month are free. ## Path 2: Build a branded, signable invoice app with AI The hosted flow is perfect for sending invoices one at a time. But if you want your own branded page where customers review a total and sign to approve it, or you want signing baked into a tool your team already uses, you can build that with an AI app builder and still write no code yourself. You describe the app in plain English and the AI generates it. We did exactly this with Lovable, an AI app builder. In [a real no-code build](https://www.turbodocx.com/blog/i-built-a-signable-invoice-app-with-lovable.md), the signable invoice app came together in about 12 minutes. The trick is giving the AI builder the right instructions for the signing piece so it does not guess. That is what [the TurboDocx Quickstart Skill](https://www.turbodocx.com/quickstart.md) provides: it teaches your AI builder the exact way to send an invoice for signature, so the generated app actually works on the first try. You add the skill to your project once with the open-source `skills` CLI: ```bash npx skills add TurboDocx/quickstart ``` Then you describe what you want, and the builder writes it. Prompts that work well for an invoice app: - "Build me an invoice app where clients can review the total and sign to approve it" - "When a customer signs the invoice, send them and me a copy of the signed PDF" - "Add a status badge that shows whether each invoice is sent, signed, or declined" Under the hood, the skill uses TurboDocx's `sendSignature` so the invoice goes straight to your client to sign, skipping any internal review step. If you want a deeper walkthrough of how the builder and TurboDocx connect, see [the developer integration guide](https://www.turbodocx.com/blog/turbodocx-lovable-integration-guide.md), and for the broader toolkit of no-code parts that fit together, read about [the no-code e-signature stack](https://www.turbodocx.com/blog/no-code-esignature-stack.md). ## Connecting your account to the builder The one setup step for the AI-builder path is connecting your TurboDocx account so the app can send invoices on your behalf. You grab your key from Settings then API Keys inside [app.turbodocx.com](https://app.turbodocx.com), and the builder reads it from environment variables rather than pasting it into the page: ```bash TURBODOCX_API_KEY=your_api_key_here TURBODOCX_ORG_ID=your_org_id_here TURBODOCX_SENDER_EMAIL=you@company.com TURBODOCX_SENDER_NAME=Your Company Name ``` If you do not have a key yet, tell the builder and the skill walks you through signing up and pasting it in. You can always start with the hosted flow first and add the branded app later. For teams that eventually want to script this into their own systems, the [API and SDK](https://www.turbodocx.com/products/api-and-sdk.md) and the [e-signature API](https://www.turbodocx.com/e-signature-api.md) are there when you are ready, and [the TurboDocx Quickstart Skill](https://www.turbodocx.com/quickstart.md) works inside AI coding agents the same way it works inside app builders. ## Why you do not need to build signing yourself It is worth seeing what you are skipping. A from-scratch signable-invoice build would realistically run something like this, and these are illustrative estimates, not a quoted project: - Pick and learn an e-signature provider SDK: **half a day** - Build the upload, field-placement, and send screens: **2 to 3 days** - Wire webhooks, store signed PDFs, handle declines and expiry: **2 days** - Audit trail, retention, and compliance review: **a few more days** Both paths above let you skip all of it. The signing engine, the recipient experience, the signed-PDF storage, and the tamper-evident audit trail are handled on TurboDocx infrastructure, so a non-developer can collect a real signature today. ## Will a signed invoice hold up? A common worry about going paperless is whether the signature counts. The relevant frameworks (the [ESIGN Act](https://www.govinfo.gov/app/details/PLAW-106publ229) and [UETA](https://www.uniformlaws.org/committees/community-home?CommunityKey=2c04b76c-2b7d-4399-977e-d5876ba7e034) in the United States, [eIDAS](https://eur-lex.europa.eu/eli/reg/2014/910/oj/eng) in Europe) are handled on TurboDocx infrastructure, including the tamper-evident audit trail that records who signed, when, and from where. You do not have to implement any of that yourself. For the details, see our [US e-signature compliance](https://www.turbodocx.com/resources/us-esignature-compliance.md) and [European e-signature compliance](https://www.turbodocx.com/resources/european-esignature-compliance.md) guides. As always, treat these as general information rather than legal advice for your specific situation. ## Related Resources - [I Built a Signable Invoice App with Lovable](https://www.turbodocx.com/blog/i-built-a-signable-invoice-app-with-lovable.md): A real no-code build, start to finish. - [E-Signatures for Invoices](https://www.turbodocx.com/blog/esignature-for-invoices.md): Why signing your invoices speeds up payment. - [The No-Code E-Signature Stack](https://www.turbodocx.com/blog/no-code-esignature-stack.md): The tools that fit together without engineering. ## Send a signable invoice today Start with the hosted flow in your browser, or hand the Quickstart Skill to your AI builder for a branded app. Your first 5 signatures each month are free. [Get the Quickstart Skill](https://www.turbodocx.com/quickstart.md) or explore the [E-Signature API](https://www.turbodocx.com/e-signature-api.md). --- --- title: "AI Agents Still Cannot Finish the Paperwork | TurboDocx" description: "Agents reason, call tools, and write code, but still cannot hand you a finished on-brand document. Why the last mile of document generation is its own problem." url: "https://www.turbodocx.com/blog/ai-agents-last-mile-documents" --- # Your Agent Can Do Everything Except Finish the Paperwork > It reads the ticket, queries the CRM, and drafts a perfect summary. Then it hands you markdown, and a human opens Word. Here is why the last step is a different kind of problem, and what actually closes it. By Yacine Kahlerras (Software Engineer, Platform & UX at TurboDocx). Published August 24, 2026. Last updated August 2026. 9 min read. Category: AI for Developers. I watched an agent do something genuinely impressive a few weeks ago. It read a support thread, pulled the account record, worked out which contract terms applied, and wrote a clear, accurate summary of what we owed the customer and by when. Start to finish, maybe forty seconds. Then it printed the summary into the chat, and a person copied it into Word, fixed the heading styles, dropped in the logo, fought with a table, saved it as a PDF, and emailed it. That part took eleven minutes. We keep calling this an AI problem. It is not. Everything the model was asked to think about, it did. The failure is in the last step, and the last step has never been a language problem. ## Five steps, and only one of them is stuck Break any "have the agent produce the document" task into its real steps and the picture gets clearer. Four of the five are in good shape. One is not, and it happens to be the one the reader actually receives. 1. **Understand the request** (Handled): Read the thread, the ticket, the CRM record, and work out what document is actually being asked for. 2. **Gather the inputs** (Handled): Call the tools. Pull the account, the line items, the dates, the owner, the terms. This is what tool use and connection protocols are for. 3. **Draft the content** (Handled): Write the summary, the scope, the recommendation. Models are genuinely good at this now. 4. **Produce the artifact** (The gap): Emit a real file: the company template, the right fonts, the logo in the header, the table that does not break across pages. 5. **Deliver it** (Partly): Store it, route it for approval, send it for signature, write the result back to the system of record. ## MCP solved the wiring, not the output The Model Context Protocol, introduced by Anthropic in November 2024, fixed something that badly needed fixing. Before it, every agent-to-tool integration was bespoke. After it, there is a standard way for a host application and its servers to exchange context and expose capabilities, and the ecosystem converged on it quickly. It is worth being precise about what that buys you, though. MCP is a connection standard. It tells an agent how to reach your systems and call your tools. It says nothing about what a finished contract should look like, and it does not turn tokens into a valid Word file. Plugging an agent into twelve MCP servers gives it twelve new ways to gather input and exactly zero new ways to hand you a signed-looking PDF. You can see the same instinct in how the platforms handled output reliability. OpenAI added function calling in June 2023 and schema-guaranteed structured outputs in August 2024. Anthropic made tool use generally available in May 2024 and shipped structured outputs in public beta in November 2025. The pattern is consistent: when the industry needed dependable machine-readable output, it did not write a better prompt. It constrained the model to a schema and let code take it from there. > Connection protocols answer "how does the agent reach the thing?" They do not answer "what does the thing produce?" Those are separate problems, and the second one is still mostly yours to solve. ## Why asking the model to emit the file does not work ### The file formats are archives, not text A .docx or .pptx is a zip container full of XML parts, relationships, and content types that must agree with each other. A language model emits tokens. It can describe the document perfectly and still not be able to hand you valid bytes. ### Brand fidelity is not a style suggestion Your template already encodes the fonts, the margins, the numbering, the cover page, and the legal footer that someone signed off on. Asking a model to recreate that from scratch every run means it drifts every run. ### Layout has to be deterministic The same input should produce the same document. Generation that reinvents the structure each time turns every output into something a human has to re-check before it can leave the building. ### Prose is the easy half The hard half is everything around the prose: the header, the totals that must add up, the version, the approval block. That part is plumbing, and plumbing wants code, not creativity. If you want the strongest evidence for this, look at how the model vendors handle it themselves. Anthropic publishes source-available document skills for Word and PowerPoint, and neither one asks the model to emit the file. They instruct it to write a script against a generation library, run the script, and then run a validator on the result. The guidance is blunt about why: round-tripping the packed XML through a generic parser corrupts the document, and a single malformed value is enough for the app to reject the whole file. The fix they prescribe is to fix your generator, not to hand-edit the output. None of this is a knock on the models. It is the same reason you do not ask a very smart colleague to hand-write the PDF bytes. The task wants a deterministic renderer, and we already know how to build those. ## The shape that actually works Split the job along the line where the difficulty changes. The agent handles judgment: what is being asked, which record matters, what the summary should say. Code handles production: take that content and fill a template that was approved once and never has to be re-derived. That is the whole trick. You build the branded file once in Word or PowerPoint, mark the variables, and expose a generator the agent can call with structured data. With [TurboDocx templating](https://www.turbodocx.com/products/turbodocx-templating.md) the template is a document your team already knows how to edit, and the [REST API and SDKs](https://www.turbodocx.com/products/api-and-sdk.md) return DOCX, PDF, or PPTX from JSON. The agent never has to know what a content type override is. If you want to hand this to your coding agent rather than wire it yourself, the [TurboDocx Quickstart Skill](https://www.turbodocx.com/quickstart.md) installs the integration in one prompt and works with Claude Code, Cursor, GitHub Copilot, OpenCode, OpenAI Codex CLI, and Gemini CLI. There is a [full walkthrough of that install](https://www.turbodocx.com/blog/install-turbodocx-sdk-via-ai-agent-skill.md) if you want to see what it generates. And if you just need HTML turned into a Word file inside your own service, the [open-source html-to-docx converter](https://www.turbodocx.com/products/open-source.md) is MIT licensed and does that one job well. **The rule:** let the model decide what goes in the document. Never let it decide what a document is. The first is judgment and it is why you hired an agent. The second is a solved engineering problem, and solving it again on every run is how you get drift. ## Where this shows up first The gap hurts most wherever the document is a recurring output rather than a one-off. If your team produces the same artifact over and over with different data, you are paying the eleven-minute tax every single time. - **Product and platform teams** embedding generation into their own app, where [a document API is just another service](https://www.turbodocx.com/developers.md) the backend calls. - **Automation builders** stitching workflows together, who need the final step to emit a real file instead of a message. That is the [automator's version of the same problem](https://www.turbodocx.com/use-cases/automators.md). - **Anyone whose agent already drafts well.** If the writing is good and the output is still a copy-paste, the missing piece is a generator, not a better prompt. ## Frequently asked questions ### Why can an AI agent write a great draft but not produce a finished document? Because those are two different problems. Drafting is a language problem, and models are good at it. Producing a finished document is a file-format and brand-fidelity problem: a .docx or .pptx is a zip archive of interdependent XML parts, and your company template already encodes fonts, margins, numbering, and legal footers that someone approved. A model emits tokens, not valid archive bytes, so the reliable pattern is to let the agent decide the content and let code fill a real template with it. ### What is the Model Context Protocol, and does it generate documents? The Model Context Protocol (MCP) is an open protocol introduced by Anthropic in November 2024 that standardizes how AI applications connect to external tools and data. It defines how a host application, its clients, and servers exchange context and invoke capabilities. It is a connection standard, not an output-format standard: MCP can let an agent reach the system that generates a document, but it does not itself produce DOCX, PPTX, or PDF files. ### Should the agent write the file, or call something that writes the file? Call something that writes the file. Let the agent do what it is good at: understanding the request, gathering inputs, and drafting content. Then hand that content to a deterministic generator that fills an approved template and returns the artifact. You get repeatable output, brand compliance, and a much smaller surface area to review, and you stop paying tokens to re-derive layout that never changes. ### How do I give an AI agent the ability to generate real documents? Give it a tool that produces the artifact. In practice that means a document generation API the agent can call with structured data: you build the branded template once in Word or PowerPoint, mark the variables, and the API fills it and returns DOCX, PDF, or PPTX. The TurboDocx Quickstart Skill installs that integration into a project in one prompt and works with Claude Code, Cursor, GitHub Copilot, OpenCode, OpenAI Codex CLI, and Gemini CLI. ### Is this just the old mail merge with an AI label on it? The template-plus-data mechanism is genuinely old, and that is the point: it is the part that already works. What is new is who fills in the data. Instead of a human exporting a spreadsheet and running a merge, an agent reads the systems, decides what belongs in the document, and calls the generator. The deterministic half stays deterministic, and the judgment half moves to the model. ## Related Resources - [Install the SDK in One Prompt](https://www.turbodocx.com/blog/install-turbodocx-sdk-via-ai-agent-skill.md): The open-source Quickstart Skill that wires document generation into a project from a single prompt. - [Agents That Document the Product](https://www.turbodocx.com/blog/automate-product-documentation-with-ai-agents.md): Guidewright drives your live app to write and maintain end-user docs, instead of guessing from the code. - [Skills, Plugins and MCP Servers](https://www.turbodocx.com/blog/best-claude-code-skills-plugins-mcp-servers.md): The tools that turn a single coding session into something closer to an engineering org. - [The Mail Merge Comeback](https://www.turbodocx.com/blog/the-mail-merge-comeback.md): The old template-plus-data idea, back in a modern form because it is the part that never stopped working. ## Give your agent a way to finish the job Build the branded template once, then let an agent fill it through a REST API and get back DOCX, PDF, or PPTX. No copy-paste at the end. [Explore the API and SDK](https://www.turbodocx.com/products/api-and-sdk.md) or [install the Quickstart Skill](https://www.turbodocx.com/quickstart.md). --- --- title: "AsyncAPI npm Attack: Signed, Verified, Malicious | TurboDocx" description: "Malicious npm packages shipped through AsyncAPI's own CI with valid provenance attestations, and a payload that fires on import. What actually defends you." url: "https://www.turbodocx.com/blog/asyncapi-npm-attack-provenance-attestations" --- # The AsyncAPI Packages Were Signed, Verified, and Malicious > On July 14, 2026, five npm versions shipped from AsyncAPI's own release pipeline carrying valid provenance attestations. Six days after npm disabled install scripts by default, the payload fired on import instead. Here is what broke, and what actually holds. By Amit Sharma (Software Engineer, Backend Architecture at TurboDocx). Published July 24, 2026. Last updated August 2026. 12 min read. Category: Security. On July 14, 2026, an attacker published five malicious versions across four `@asyncapi` npm packages. They did not steal a maintainer's npm token. They obtained push access to two AsyncAPI repositories and let the projects' own GitHub Actions release pipelines do the publishing, which meant the packages arrived on the registry with valid OIDC provenance attestations. The payload contained no install scripts. It executed on `require()`, which meant the mitigation the entire ecosystem had just adopted (npm 12 disabling lifecycle scripts by default, shipped six days earlier) did nothing. Two of the industry's most-recommended supply chain controls were in place and neither one was in the attack path. This is the counterpart to the axios supply chain attack we covered earlier this year. That one was a hijacked maintainer account delivering a RAT through a postinstall hook, and the fix was lockfile discipline plus script blocking. This one routes around both. It is worth understanding precisely why. Every technical detail below is drawn from the published analyses by Microsoft Security and StepSecurity. All external claims are linked inline and listed in the numbered Sources section at the end. ## What happened on July 14? The attack ran for roughly four hours across two AsyncAPI repositories. According to [StepSecurity's analysis](https://www.stepsecurity.io/blog/compromised-next-branch-pushes-malicious-asyncapi-generator-generator-helpers-and-generator-components-to-npm), the malicious commits were authored under a placeholder identity, "Your Name" with the address `you@example.com` and the GitHub login `invalid-email-address`. The generator packages were exposed for 4 hours and 2 minutes; specs 6.11.2 for 2 hours and 48 minutes. ### Incident timeline | Time | Event | | --- | --- | | July 8, 2026 | npm 12 ships with dependency lifecycle scripts disabled by default. GitHub had called those scripts the single largest code-execution surface in the npm ecosystem. | | July 14, 2026 - 06:58 UTC | The attack begins against the AsyncAPI generator repository. | | July 14, 2026 - 07:10 UTC | Three generator packages are published to npm with malicious code, through the project's own release workflow. | | July 14, 2026 - 08:06 to 08:30 UTC | Two @asyncapi/specs versions are published from the second repository. | | July 14, 2026 - 11:12 to 11:18 UTC | All five malicious versions are unpublished from npm. Generator exposure window: 4h 2m. Specs 6.11.2 exposure window: 2h 48m. | | July 15, 2026 | Microsoft publishes its analysis of the compromise and the import-time delivery mechanism. | ### Affected versions | Package | Malicious version | Last safe version | | --- | --- | --- | | @asyncapi/generator | 3.3.1 | 3.3.0 | | @asyncapi/generator-helpers | 1.1.1 | 1.1.0 | | @asyncapi/generator-components | 0.7.1 | 0.7.0 | | @asyncapi/specs | 6.11.2 | 6.11.1 | | @asyncapi/specs | 6.11.2-alpha.1 | 6.11.1 | ## How did malware get a valid provenance attestation? The attestation was valid because it was accurate. npm provenance answers exactly one question: which repository, commit, and workflow produced this artifact. In this case the honest answer was the real AsyncAPI repository, running the real release workflow, on a commit that genuinely existed in the branch. Every one of those statements was true. None of them was reassuring. StepSecurity puts the limitation plainly: the packages carry legitimate SLSA provenance attestations "proving only that the project's authorized workflow produced them, not that the triggering commits were legitimate." Microsoft's writeup reaches the same conclusion, noting the attestations [accurately identified the legitimate repositories, commits, and workflows](https://www.microsoft.com/en-us/security/blog/2026/07/15/unpacking-asyncapi-npm-supply-chain-compromise-import-time-payload-delivery/) even though the triggering commits were unauthorized. This matters because provenance has been marketed, informally, as a trust signal. It is a build-integrity signal. It closes the gap between "the source repository" and "the published tarball." It says nothing whatsoever about the gap between "a maintainer intended this" and "this reached the source repository." The attacker simply moved one step upstream of where the control sits. **Provenance is a chain-of-custody receipt, not a code review.** Keep using it. A missing or mismatched attestation is still a strong negative signal. Just stop treating a green checkmark as evidence that the code is safe, and never let it substitute for branch protection on the branch your release pipeline builds from. ## Why did blocking install scripts not help? Because there were no install scripts to block. The timing here is almost unkind. In its [June 9, 2026 changelog announcing the change](https://github.blog/changelog/2026-06-09-upcoming-breaking-changes-for-npm-v12/), GitHub called install-time lifecycle scripts "the single largest code-execution surface in the npm ecosystem," noting that a single compromised package anywhere in the tree can run arbitrary code on a developer machine or CI runner. npm 12 shipped on July 8, 2026 with `allowScripts` defaulting to off, so preinstall, install, and postinstall scripts from dependencies no longer run unless explicitly approved. Git dependencies (`--allow-git`) and remote tarball dependencies (`--allow-remote`) both default to none in the same release. Six days later, the AsyncAPI dropper went around it. The obfuscated loader sat in the module body and fired when the library was imported. That is not an exotic technique; it is simply how JavaScript modules work. Anything that runs at the top level of a module executes the first time something requires it, which in a normal project means during your build, your test run, or your application boot. ```javascript // What defenders expected to find, and did not: { "name": "@asyncapi/generator", "version": "3.3.1", "scripts": { // No preinstall. No install. No postinstall. // Nothing here to block. } } // Where the dropper actually lived: the module body. // It runs the moment anything require()s or import()s the package, // which happens in your build, your tests, and your app startup. spawn("node", ["-e", stage2], { detached: true, // survives the parent process stdio: "ignore", // no output in your CI logs windowsHide: true, // no console window }); // npm install --ignore-scripts does not help here. // npm 12's allowScripts default does not help here. // The code runs because you imported the library, as intended. ``` **The mitigation moved, so the attacker moved.** This is what defense evolution looks like in practice. Install-script blocking is still worth having; it retires an entire generation of attacks, including the axios one. But a control that closes one execution path pushes attackers to the next one, and for a library you actually import, the next one is trivially available. ## What did the payload actually do? The first stage spawned a hidden, detached Node process with output suppressed, then fetched an encrypted second-stage runtime of roughly 8.2 MB (named `sync.js`) from IPFS, decrypted it, and executed the Miasma remote access framework. Miasma installed persistence and established command and control. The interesting part is the resilience of the C2 design. Primary control ran over `85.137.53.71` on ports 8080 for commands, 8081 for uploads, and 8091 for proxy management. Fallback channels included Nostr relays, the BitTorrent DHT via `router.bittorrent.com:6881`, and an Ethereum mainnet contract. Blocking one IP address does not retire this implant. One module deserves separate attention. StepSecurity documents an `ai-tool-poisoner.js` component and advises treating AI coding assistant sessions on an affected machine as potentially compromised. That is the same trust boundary the Azure DevOps MCP disclosure attacks from the other direction: one poisons what the agent reads from a pull request, the other poisons the agent's local tooling from a dependency. Both end with your agent following someone else's instructions using your credentials. ## Which assumptions did this attack break? Four widely held beliefs about npm security failed here at the same time. Each one is a reasonable rule of thumb that happens to describe the previous generation of attacks rather than this one. | What we assumed | What happened | | --- | --- | | A signed provenance attestation means the package is trustworthy | The attestation was valid and accurate. It proved the package came from the real repository, commit, and workflow. It said nothing about whether the commit was authorized. | | Blocking install scripts stops malicious packages | The packages had no install scripts. The dropper ran on require(), so the new npm 12 default and --ignore-scripts both miss it entirely. | | A compromised maintainer account is the thing to watch for | No npm token was stolen. The CI pipeline was the credential. Push access to a branch was enough to reach publish. | | A short exposure window means low risk | Four hours is long enough for CI to resolve a caret range, install the version, import it, and execute. Lockfiles and caches then keep it around. | ## How do I check whether I was affected? Check two things: whether your lockfile ever resolved one of the five versions, and whether the second-stage artifact is sitting on disk. All five versions have been unpublished, so a fresh install will not reach them, but a cached lockfile from July 14 still can. Note that a build during the window is enough. You do not need to have shipped anything. ```bash #!/usr/bin/env bash # Check whether you resolved any of the malicious versions, # then look for the on-disk artifact the dropper leaves behind. set -uo pipefail BAD=( "@asyncapi/generator@3.3.1" "@asyncapi/generator-helpers@1.1.1" "@asyncapi/generator-components@0.7.1" "@asyncapi/specs@6.11.2" "@asyncapi/specs@6.11.2-alpha.1" ) echo "== Lockfile check ==" for pkg in "${BAD[@]}"; do name="${pkg%@*}"; version="${pkg##*@}" if grep -q "\"${name}\": \"\?${version}" package-lock.json 2>/dev/null; then echo "HIT: ${pkg} present in package-lock.json" fi done echo "== Drop file check ==" for path in \ "$HOME/.local/share/NodeJS/sync.js" \ "$HOME/Library/Application Support/NodeJS/sync.js" \ "$LOCALAPPDATA/NodeJS/sync.js" do [ -f "$path" ] && echo "HIT: dropper artifact at $path" done echo "Done. Any HIT means: rotate credentials and rebuild the host." ``` ### If you get a hit Treat it as code execution on that host, not as a dependency to bump. The published remediation guidance is: - Delete and regenerate lockfiles, and purge npm and Yarn caches. - Remove the `sync.js` drop file from the NodeJS application data directory for your platform. - Rotate every credential the host could reach: npm tokens, GitHub personal access tokens, SSH keys, and cloud credentials. - Audit build logs for outbound traffic to IPFS gateways, the C2 address, DHT bootstrap nodes, or Nostr relays. - Rebuild affected machines from a clean baseline rather than cleaning them in place. - Treat AI coding assistant sessions on the host as potentially compromised, given the AI tool poisoning module. ## What actually defends against this class of attack? Split the answer by which side of the registry you are on. If you publish packages, your job is to make push access insufficient to reach publish. If you consume packages, your job is to make a four-hour exposure window something your pipeline sleeps through. ### 1. Fix the trigger that leaked the token Microsoft attributes the initial access to a workflow using `pull_request_target`, which runs in a privileged context with repository secrets available. Checking out the pull request head under that trigger runs a stranger's code with your tokens in the environment. This is a well-documented footgun and it is still everywhere. ```yaml # The root cause, per Microsoft's analysis: pull_request_target # runs in a PRIVILEGED context with access to repository secrets. # Checking out the pull request head under that trigger executes # attacker-controlled code with your tokens in the environment. # VULNERABLE on: pull_request_target: jobs: build: steps: - uses: actions/checkout@v4 with: ref: ${{ github.event.pull_request.head.sha }} # attacker code - run: npm ci && npm run build # with secrets # SAFE: untrusted code runs under pull_request, which has no secrets. on: pull_request: jobs: build: permissions: contents: read steps: - uses: actions/checkout@v4 - run: npm ci --ignore-scripts && npm run build # If you genuinely need pull_request_target (to label or comment), # never check out the head ref, and never run the PR's code. ``` ### 2. Publishers: put a human between push and publish Trusted publishing removed the long-lived npm token, which is a real improvement. It also means the branch is now the credential. If your release workflow publishes on every push to a branch, then push access to that branch is publish access, and provenance will faithfully attest to whatever it builds. Protect the branch, gate the publish job behind a GitHub Environment with required reviewers, and pin actions to commit SHAs. ```yaml # Make "push access" insufficient to reach publish. # 1. Protect the branch your release workflow builds from. # The AsyncAPI publish pipeline built from 'next'. # Require a review from a code owner on every push to it. # 2. Gate publish behind a GitHub Environment with required reviewers. jobs: publish: environment: name: npm-production # add required reviewers in repo settings permissions: id-token: write # OIDC trusted publishing contents: read steps: - uses: actions/checkout@v4 - run: npm ci --ignore-scripts - run: npm publish --provenance --access public # 3. Pin every action to a full commit SHA, not a tag. # - uses: actions/checkout@b4ffde6... # v4.2.2 # 4. Put an egress allowlist on the runner. The AsyncAPI dropper # had to reach an IPFS gateway to fetch stage two. A default-deny # egress policy turns a full RAT install into a failed request. ``` ### 3. Consumers: refuse to be the first to install anything This is the single highest-leverage control for a consuming team, and it is one line of config. Malicious versions get caught and unpublished in hours. A cooling-off period converts almost every one of these incidents into something you read about rather than something you respond to. It would have covered all five AsyncAPI versions with days to spare. ```bash # .npmrc - slow down the blast radius on the consuming side. # Refuse any version published in the last N days. The five malicious # AsyncAPI versions were live for under four hours; a cooling-off # period means your CI would never have seen them. # Requires npm v11.10.0+ min-release-age=7 # npm 12 blocks dependency lifecycle scripts by default. Set this # explicitly so older npm versions in your fleet behave the same way. # (In npm 12 the allowlist of packages permitted to run scripts is # managed with 'npm approve-scripts', not with this key.) ignore-scripts=true # Always npm ci in CI, never npm install. ci installs exactly what # the lockfile says and fails if package.json and the lock disagree. ``` ### 4. Default-deny egress on build runners The dropper was a stager. It had to reach an IPFS gateway to fetch the 8.2 MB payload that did the actual work. An egress allowlist on your runners (registry, source control, your own artifact store, nothing else) turns full remote access into a failed HTTP request and a log line. StepSecurity reports that its Harden-Runner tooling detected this attack precisely by capturing outbound connection attempts. Runtime network visibility is what caught it, not static analysis of the package. **The principle: assume a malicious dependency will eventually execute, and constrain what it can reach.** Every control that tried to decide whether the package was trustworthy failed here, because the package looked exactly like a legitimate release. The controls that would have worked never asked that question. They delayed the install, restricted the network, or required a second person to approve a publish. ## What this says about the next one Three npm incidents in the space of a few months tell a consistent story. The axios compromise took a maintainer account and used a postinstall hook. The Claude Code source map leak needed no attacker at all, just a default nobody had turned off. This one took a CI trigger and used the module system. In each case the failure was at a seam between systems that each behaved correctly on their own. The uncomfortable part is that the controls being retired here are the ones we recommend. Install-script blocking is good. Provenance is good. Both are worth adopting today. Neither is a decision procedure for "is this package safe," and the moment we treat them as one, we stop building the controls that assume the answer is no. If your team is leaning harder on AI agents to write and review this code, the agent-side version of this same problem is worth reading next, and the curl project's experience with AI-generated vulnerability reports is a useful counterweight on the noise side. For the broader maintainer perspective on why these projects are load-bearing and chronically under-resourced, our piece on [maintaining open source](https://www.turbodocx.com/blog/the-power-of-maintaining-open-source.md) covers the part of this that no config file fixes. And if you are picking the agent stack that will be running `npm ci` on your behalf, our comparison of Cursor, Claude Code, and OpenCode and our [guide to writing a CLAUDE.md](https://www.turbodocx.com/blog/how-to-write-claude-md-best-practices.md) cover where to encode these limits so they are enforced by default. ## Sources and citations 1. Microsoft Security Blog, "Unpacking the AsyncAPI npm supply chain compromise and import-time payload delivery," July 15, 2026 (root cause, affected versions, provenance analysis, payload behavior). [microsoft.com](https://www.microsoft.com/en-us/security/blog/2026/07/15/unpacking-asyncapi-npm-supply-chain-compromise-import-time-payload-delivery/) 2. StepSecurity, "Coordinated AsyncAPI Supply Chain Attack: Miasma RAT Delivered via Compromised CI/CD Pipelines in Two Repositories," July 2026 (timeline, exposure windows, C2 infrastructure, remediation steps). [stepsecurity.io](https://www.stepsecurity.io/blog/compromised-next-branch-pushes-malicious-asyncapi-generator-generator-helpers-and-generator-components-to-npm) 3. GitHub Changelog, "Upcoming breaking changes for npm v12," June 9, 2026 (primary source for the allowScripts, --allow-git, and --allow-remote defaults, the npm approve-scripts command, and the "single largest code-execution surface in the npm ecosystem" description). [github.blog](https://github.blog/changelog/2026-06-09-upcoming-breaking-changes-for-npm-v12/) 4. The Hacker News, "npm 12 Disables Install Scripts by Default to Reduce Supply Chain Risk," July 2026 (npm 12 ship date of July 8, 2026). [thehackernews.com](https://thehackernews.com/2026/07/npm-12-disables-install-scripts-by.html) 5. npm CLI documentation, configuration reference (`min-release-age`, added in npm v11.10.0, and `ignore-scripts`). [docs.npmjs.com](https://docs.npmjs.com/cli/v11/using-npm/config) 6. Palo Alto Networks Unit 42, "The npm Threat Landscape: Attack Surface and Mitigations," updated July 15, 2026. [unit42.paloaltonetworks.com](https://unit42.paloaltonetworks.com/monitoring-npm-supply-chain-attacks/) 7. GitHub Docs, security hardening guidance for GitHub Actions, including the `pull_request_target` trigger and untrusted input. [docs.github.com](https://docs.github.com/en/actions/security-for-github-actions/security-guides/security-hardening-for-github-actions) 8. npm Docs, generating provenance statements and trusted publishing (what an attestation does and does not assert). [docs.npmjs.com](https://docs.npmjs.com/generating-provenance-statements) Indicators of compromise are reproduced from the published StepSecurity and Microsoft analyses for detection purposes. Verify against those sources before acting on them, and check for updates published after July 15, 2026. ## Frequently asked questions ### Which AsyncAPI packages were compromised? Five versions across four packages: @asyncapi/generator 3.3.1, @asyncapi/generator-helpers 1.1.1, @asyncapi/generator-components 0.7.1, and @asyncapi/specs 6.11.2 plus 6.11.2-alpha.1. The last safe versions are 3.3.0, 1.1.0, 0.7.0, and 6.11.1 respectively. All five malicious versions were unpublished from the npm registry between 11:12 and 11:18 UTC on July 14, 2026. ### How did malicious packages get a valid npm provenance attestation? Because the attestation was telling the truth. The attacker did not steal an npm token. They obtained push access to the repository and let the project's real GitHub Actions release workflow publish the packages through npm's OIDC trusted publishing. The resulting attestation accurately named the legitimate repository, commit, and workflow. Provenance proves where a package was built, not that the code going in was authorized. ### Does npm install --ignore-scripts protect against this attack? No. The malicious packages contained no preinstall, install, or postinstall scripts at all. The obfuscated dropper lives in the module body and executes when the library is imported or required, which happens during your build, your tests, or your application startup. Disabling install scripts, including the new npm 12 default, does nothing against an import-time payload. ### What did the AsyncAPI payload do once it ran? It spawned a hidden detached Node process, downloaded an encrypted runtime of roughly 8.2 MB named sync.js from IPFS, decrypted it, and executed the Miasma remote access framework. Miasma installed persistence and connected to command and control at 85.137.53.71 on ports 8080, 8081, and 8091, with fallback channels over Nostr relays, the BitTorrent DHT, and an Ethereum mainnet contract. ### How did the attacker get push access to the AsyncAPI repositories? Microsoft's analysis attributes it to a misconfigured GitHub Actions workflow using the pull_request_target trigger, which executed attacker-controlled pull request code in a privileged context and exposed the asyncapi-bot personal access token. That token was then used to push to the next branch, which the release pipeline builds from. ### What should I do if my lockfile contains one of the affected versions? Assume code execution on any machine that installed and imported the package. Delete and regenerate lockfiles, purge npm and Yarn caches, and remove the sync.js drop file from the NodeJS application data directory for your OS. Rotate every credential the affected machine could reach, including npm tokens, GitHub personal access tokens, SSH keys, and cloud credentials. Because the payload included an AI tool poisoning module, treat AI coding assistant sessions on that machine as potentially compromised too. ## Related resources - [Why Maintaining Open Source Is Load-Bearing](https://www.turbodocx.com/blog/the-power-of-maintaining-open-source.md): The maintainer perspective on why these projects are chronically under-resourced, the part of the problem no config file fixes. - [How to Webhook: HMAC and Secure Integrations](https://www.turbodocx.com/blog/how-to-webhook-hmac-guide.md): Why signature verification is the difference between a webhook you can trust and one anyone can forge, explained end to end. ## Fewer Dependencies in Your Document Pipeline TurboDocx replaces a stack of document generation and signing libraries with one audited, API-first service. Less code you did not write running in your build. [Schedule a demo](https://www.turbodocx.com/demo) | [Explore the API](https://www.turbodocx.com/products/api-and-sdk.md) --- --- title: "Automate End-User & Product Documentation with AI | TurboDocx" description: "Guidewright, an open-source Agent Skill, writes end-user documentation and reviews product docs by driving your live app. Works with Claude Code, Cursor, and more." url: "https://www.turbodocx.com/blog/automate-product-documentation-with-ai-agents" --- # If the agents write the code, they can document it too > We open-sourced Guidewright: an Agent Skill that writes end-user documentation and reviews your product docs by driving your live app, with an accurate red box on the exact element each step tells the user to click. By Nicolas Fry (Founder & CEO, TurboDocx). Published June 22, 2026. 6 min read. Category: AI for Developers. Install both skills in any project: ```bash npx skills add TurboDocx/guidewright ``` I got tired of spending thousands of dollars a year on SaaS tools just to keep our documentation alive. One subscription to record click-by-click walkthroughs. Another to annotate the screenshots. A knowledge-base platform to host the result. And the screenshots still went stale the moment we shipped a UI change, so we paid the tools _and_ paid the time to redo the work. Meanwhile, the same coding agents that ship our features can already open a browser, click through a flow, and see exactly what a user sees. So the question got hard to ignore: if the agents write the code, why can't they document it too? That is [Guidewright](https://github.com/TurboDocx/guidewright): an open-source [Agent Skill](https://agentskills.io) that produces and maintains end-user documentation by driving your live product, not by reading your code. It replaced a pile of subscriptions with one skill any coding agent can run. ## The documentation tax Documentation is one of those costs that hides in plain sight. The tools are recurring. The labor is recurring. And the output decays: a guide is only correct until the next release renames a button or moves a setting. You are not buying documentation once, you are renting it forever. > The insight behind Guidewright is that the decay problem and the cost problem have the same fix. If re-documenting a flow is just re-running an agent, then keeping docs current stops being a budget line and becomes a command. The same approach we use to ship features with an agent works for the docs that describe them. ## Two skills that work as a pair ### guidewright-capture Drives your app through Chrome DevTools MCP, screenshots each step with a red box on the exact element to click, and authors or refreshes the how-to page. You get: An annotated, click-by-click walkthrough that matches the live UI. ### guidewright-review Walks the path an existing doc describes in the live product and returns a prioritized review (Blocker, Major, Minor) with paste-ready fixes. You get: A specific critique that catches stale screenshots, renamed buttons, and dead ends. Capture makes the walkthrough. Review holds it to a standard distilled from established practice: the Diataxis framework, Every Page Is Page One, minimalist instruction, Nielsen Norman Group reading research, and the Google and Microsoft style guides. ## Why it drives the live app Most doc tooling works from a recording or from the code. Guidewright works from the running product, and that changes the quality of the output in two concrete ways. **The red box is real.** Instead of painting a rectangle onto a finished PNG, capture renders the highlight into the live page using the target element's own bounding rectangle, the same handle it used to click. The box lands dead-on and scales with the screenshot, so it points at the actual button a user needs, not an approximate spot. **The review actually walks the path.** A read-only review can only judge the words on the page. Guidewright's review opens the product and follows the documented steps, so it catches the failures that matter: a screenshot that no longer matches, a button that got renamed, a step that is now missing, a flow that dead-ends. When the UI changes, you re-run the skill and the guide updates itself. ## Install Guidewright follows the open [Agent Skills](https://agentskills.io) standard, so the same skill is portable across every supported agent. The `npx skills` CLI auto-detects which agents you have installed and drops the skills into the right place. From any project: Both skills (recommended): ```bash npx skills add TurboDocx/guidewright ``` Just the capture skill: ```bash npx skills add TurboDocx/guidewright --skill guidewright-capture ``` Just the review skill: ```bash npx skills add TurboDocx/guidewright --skill guidewright-review ``` Guidewright needs the Chrome DevTools MCP server, which the skills use to drive the browser. Once installed, just ask: _"document how to create a template"_ runs capture, and _"review this guide for clarity"_ runs review. ## Supported agents - Claude Code - GitHub Copilot (VS Code) - Cursor - OpenCode - OpenAI Codex CLI - Gemini CLI Plus any other tool that supports the Agent Skills standard. Both skills are product-agnostic: point them at any app and any docs site. They assume a Docusaurus site by default and adapt to other setups. ## Documentation is the next thing agents take off your plate We already trust agents to write code, open pull requests, and run tests. Documentation is the obvious next step, because it is exactly the kind of work that is high-effort, low-glamour, and constantly out of date. The thing standing in the way was never capability. It was that most tools made the agent guess from a recording or a description. Give the agent the live product instead, and the guesswork disappears. It clicks the real button, captures the real screen, and writes the step. That is the whole idea, and it is why we shipped Guidewright as open source under the MIT license. Point it at your own product and stop paying a subscription to keep your guides honest. ## Frequently asked ### What is Guidewright? Guidewright is an open-source Agent Skills plugin with two skills, guidewright-capture and guidewright-review, that write and maintain product documentation by driving your live app through the Chrome DevTools MCP server. Capture screenshots each step with a red box on the exact element to click; review walks the documented path and returns prioritized fixes. ### How is Guidewright different from a screen recorder or screenshot tool? It drives the running product instead of working from a recording or from your code. The red box is rendered into the live page from the target element's own bounding rectangle, so it lands exactly on target and scales with the screenshot. Review actually walks the path, which catches stale screenshots, renamed buttons, missing steps, and dead ends a read-only pass never sees. ### Which AI coding agents work with Guidewright? Claude Code, GitHub Copilot in VS Code, Cursor, OpenCode, OpenAI Codex CLI, and Gemini CLI. Any tool that supports the open Agent Skills standard from agentskills.io. It also needs the Chrome DevTools MCP server, which the skills use to drive the browser. ### How do I install Guidewright? Run "npx skills add TurboDocx/guidewright" in any project to install both skills. To add just one, use --skill guidewright-capture or --skill guidewright-review. The CLI auto-detects which AI agents you have installed and drops the skills into the right config directory. ### Does Guidewright work with any product and docs site? Yes. Both skills are product-agnostic, so you can point them at any app and any docs site. They assume a Docusaurus docs site by default and adapt to other setups. ## Point it at your product Install Guidewright, then ask your agent to document a feature or review an existing guide. The walkthrough writes itself. ```bash npx skills add TurboDocx/guidewright ``` - [View on GitHub](https://github.com/TurboDocx/guidewright) - [Find it on skills.sh](https://skills.sh/TurboDocx/guidewright) - [Get a free API key](https://app.turbodocx.com/?utm_source=blog&utm_medium=guidewright&utm_campaign=launch) ## Related reading - [Guidewright Launch Announcement](https://www.turbodocx.com/newsroom/turbodocx-launches-guidewright-agent-skill.md): The official press release in the TurboDocx newsroom. - [Install the TurboDocx SDK via Agent Skill](https://www.turbodocx.com/blog/install-turbodocx-sdk-via-ai-agent-skill.md): Our other open-source skill: integrate in one prompt. - [How to Build a Claude Code Skill](https://www.turbodocx.com/resources/claude-skills-guide.md): Author your own agent skill from scratch. - [Best Claude Code Skills & Plugins](https://www.turbodocx.com/blog/best-claude-code-skills-plugins-mcp-servers.md): The tools worth installing for AI development. - [CLAUDE.md Guide](https://www.turbodocx.com/blog/how-to-write-claude-md-best-practices.md): Give your agent the context to do great work. - [TurboDocx API & SDK](https://www.turbodocx.com/products/api-and-sdk.md): The full developer surface for document automation. --- --- title: "Best Claude Code Plugins, Skills & MCP Servers (2026) | TurboDocx" description: "The 7 Claude Code plugins, skills, and MCP servers I use daily — plus how they compare to gstack. What each does and how they fit together." url: "https://www.turbodocx.com/blog/best-claude-code-skills-plugins-mcp-servers" --- # The Best Claude Code Plugins, Skills & MCP Servers I Use Every Day > Seven tools that turn Claude Code from a smart assistant into a full engineering team. What each one does, when to reach for it, and how they fit together. By Nicolas Fry (Founder & CEO, TurboDocx). Published March 11, 2026. 10 min read. Category: Developer Productivity. I wrote about how I use Claude Code to ship features in one session, covering the Director/Manager/Team mental model and the four-step workflow that changed how I build software. But that post covers the _methodology_. This one covers the _toolkit_. A Director of Engineering is only as good as the team they hire. These seven plugins, skills, and MCP servers are that team. Each one handles a specific job, from feature architecture to live documentation lookup, and together they turn a single Claude Code session into something that feels like an entire engineering org. A [well-structured CLAUDE.md](https://www.turbodocx.com/blog/how-to-write-claude-md-best-practices.md) is the foundation that makes all of them effective. | Tool | Type | What It Does | Best For | | --- | --- | --- | --- | | feature-dev | Plugin | Guided 7-phase feature development with multi-agent exploration | New features | | frontend-design | Plugin | Production-grade UI that avoids generic AI aesthetics | User-facing work | | /batch | Built-in | Parallel execution across isolated worktrees with auto PR creation | Multi-file changes | | /simplify | Built-in | Three parallel review agents for reuse, quality, and efficiency | Post-implementation | | /code-review | Plugin | Four independent reviewers with confidence scoring | Pre-merge gate | | Context7 | MCP Server | Live, version-specific library documentation from Upstash | Third-party libraries | | Context Hub | MCP Server | Curated API specs with agent annotations from Andrew Ng's team | API integrations | ## Official Skills (Build Phase) ### feature-dev (Plugin) This is the skill that turns a feature brief into working code. With over 89,000 installs, it's the most popular Claude Code plugin for a reason: it imposes the same structured process that senior engineers use instinctively. When you invoke `/feature-dev`, Claude doesn't just start writing code. It runs a seven-phase workflow: requirements gathering, codebase exploration (using parallel agents to study your architecture, existing patterns, and conventions), architecture design, implementation, testing, review, and documentation. It's the difference between asking someone to "build a thing" and handing them a rigorous engineering process. **When to use it:** Any feature larger than a quick fix. If you're adding a new page, building an integration, or creating a component system, feature-dev is the right starting point. For trivial changes (typo fixes, config tweaks, single-line edits) it's smart enough to skip the full workflow. ### frontend-design (Plugin) Every developer who's used AI for frontend work has seen the result: perfectly functional code that looks like every other AI-generated page. Same layouts, same gradients, same generic feel. frontend-design exists to fix that. The skill guides Claude through four design dimensions (purpose, tone, constraints, and differentiation) before writing a single line of CSS. It pushes for unexpected font pairings, asymmetric layouts, orchestrated scroll-triggered animations, and layered visual depth. The output feels intentional and branded, not templated. Think of it as a design team in your pocket. It doesn't just build what you describe, it gives you mockups and alternative suggestions, speeding up the entire UX cycle. Instead of going back and forth with a designer for days, you iterate on layouts, spacing, and interaction patterns in minutes. I pair this with feature-dev for full-stack features: feature-dev handles the architecture and backend logic, frontend-design handles the interface layer. They complement each other naturally: one cares about how it works, the other cares about how it feels. ### Worth knowing about: Garry Tan's gstack Y Combinator CEO Garry Tan open-sourced [gstack](https://github.com/garrytan/gstack), six Claude Code skills that bundle planning, review, and shipping into one installable package. Where our toolkit separates building (feature-dev, frontend-design) from review (/simplify, /code-review), gstack takes a different angle: CEO-level product thinking, automated PR shipping, and browser-based QA. They're complementary, not competitive. I wrote a full comparison of gstack vs. our approach, and you can see how the Director/Manager/Team model maps to both. ## Built-In Commands (Orchestration & Quality) ### /batch (Built-in) `/batch` is the command that makes Claude Code feel like it has a team behind it. Give it a description of what needs to change, and it decomposes the work into 5-30 independent units, spins up isolated git worktrees for each, executes them in parallel, and creates pull requests automatically. The key insight is the **isolation model**. Each unit runs in its own worktree with no context bleed from the others. This means a failure in one unit doesn't contaminate the rest. It's the same principle I use when running multiple features in parallel with worktrees, but automated. ``` # Refactor across the entire codebase /batch replace all lodash imports with native equivalents # Add types to an untyped codebase /batch add TypeScript type annotations to all untyped function parameters # Build out a feature across multiple files /batch add comprehensive error handling to all API route handlers ``` **When to use it:** Any task with independent sub-problems: multi-file refactors, migration scripts, test suite generation, or [workflow automations](https://www.turbodocx.com/use-cases/automators.md) that touch many endpoints. If the units of work don't depend on each other, /batch can parallelize them. ### /simplify (Built-in) After every implementation, before I even think about committing, I run `/simplify`. It spawns three parallel review agents that look at your changed files from different angles: - **Reuse Checker:** Finds duplicate logic, missed abstractions, and opportunities to use existing utilities. - **Quality Checker:** Catches logic errors, missing edge cases, and integration issues. - **Efficiency Checker:** Spots unnecessary iterations, missed concurrency, and redundant operations. In my experience, /simplify catches three to five real issues per feature branch. Not cosmetic nitpicks, but the kind of bugs that slip through manual review and surface in production two weeks later. I treat it like a senior staff engineer reviewing every PR before it ships. ### /code-review (Plugin) While /simplify is your post-implementation sanity check, /code-review is the final gate before merge. It runs four independent agents in parallel, each analyzing from a different angle: two agents audit for CLAUDE.md compliance (redundancy for thoroughness), one scans for obvious bugs in changes, and one analyzes git blame and history for context-based issues. What makes it powerful is the **confidence scoring system**. Every finding gets a score from 0-100, and only issues above the threshold (default 80) make it into the report. This filters out the noise that plagues traditional linters and gives you a focused list of things that actually matter: security vulnerabilities, performance regressions, [API contract violations](https://www.turbodocx.com/resources/api-integration-best-practices.md). **How to install:** /code-review is a free plugin from Anthropic's [official plugin marketplace](https://github.com/anthropics/claude-plugins-official). Install it and the command is available in any Claude Code session, with no plan gate required. ## MCP Servers (Context & Documentation) Skills handle code generation. MCP (Model Context Protocol) servers handle _knowledge_. They give Claude Code access to external tools, databases, and live documentation that would otherwise be stale or missing from its training data. These two solve the most common frustration with AI coding assistants: outdated API references and hallucinated parameters. ### Context7 (MCP Server) Built by [Upstash](https://github.com/upstash/context7) (open source), Context7 delivers up-to-date, version-specific library documentation directly into your Claude Code session. Instead of relying on training data that might be months old, Claude gets the actual docs for the exact version of React, Next.js, Prisma, or whatever library you're using. It exposes two core tools: `resolve-library-id` to look up a library, and `query-docs` to fetch specific documentation. When Claude uses Context7, it stops guessing at API signatures and starts referencing the actual source of truth. **When to use it:** Any work involving third-party libraries, especially fast-moving ones where APIs change between versions. If you've ever had Claude write code using a deprecated method or a parameter that doesn't exist in your version, Context7 is the fix. ### Context Hub (MCP Server) Built by [Andrew Ng's team](https://www.marktechpost.com/2026/03/09/andrew-ngs-team-releases-context-hub-an-open-source-tool-that-gives-your-coding-agent-the-up-to-date-api-documentation-it-needs/) (open source), Context Hub tackles a related but different problem. While Context7 focuses on library documentation, Context Hub provides curated, versioned **API specifications**, the kind of documentation you need when you're consuming external services, not just importing packages. The registry currently covers 68+ APIs, and it's growing. What sets it apart is the **agent annotation system**: when Claude discovers a workaround or undocumented behavior during a coding session, it can save that note back to Context Hub. Over time, the documentation gets smarter with every session. It's a feedback loop between your AI coding agent and the docs it relies on. This is particularly valuable when building [API integrations](https://www.turbodocx.com/developers.md), such as consuming payment processors, CRM APIs, or services like our own [TurboDocx document generation API](https://www.turbodocx.com/products/api-and-sdk.md). Context Hub ensures Claude uses the current API spec, not whatever was in its training data. ## How They Work Together These seven tools aren't isolated utilities. They map directly to the Director/Manager/Team model from my workflow post: 1. **You write the brief (Director).** Define the problem, acceptance criteria, and constraints. Your [CLAUDE.md](https://www.turbodocx.com/blog/how-to-write-claude-md-best-practices.md) provides the codebase context. 2. **/batch orchestrates the work (Engineering Manager).** Decomposes into parallel units. Each unit can use **feature-dev** for architecture, **frontend-design** for UI, and **Context7** + **Context Hub** for live documentation. 3. **/simplify reviews the output (Staff Engineer).** Three parallel agents catch reuse opportunities, quality issues, and efficiency problems before you even look at the diff. 4. **/code-review is the final gate (Security, QA, Deep Staff Review).** Four independent agents with confidence scoring ensure nothing ships that shouldn't: security issues, performance regressions, standards violations. The beauty of this stack is that each tool has a clear lane. There's no overlap, no redundancy. Feature-dev and frontend-design handle the _building_. Context7 and Context Hub handle the _knowledge_. /simplify and /code-review handle the _quality_. And /batch ties it all together. It's the same separation of concerns we apply when building software like our [open-source tools](https://www.turbodocx.com/blog/the-power-of-maintaining-open-source.md), just applied to the development process itself. Garry Tan's [gstack](https://github.com/garrytan/gstack) takes a similar role-based approach with different packaging, bundling planning, review, and shipping into a single skill set rather than separating build from review. ## Related Resources - [How to Write a CLAUDE.md That Actually Works](https://www.turbodocx.com/blog/how-to-write-claude-md-best-practices.md): The foundation that makes every tool on this list effective. Structure, progressive disclosure, and best practices. - [API Integration Best Practices](https://www.turbodocx.com/resources/api-integration-best-practices.md): Production-ready patterns for authentication, error handling, webhooks, and rate limiting. ## Build Faster with the Right Toolkit These are the same tools we use to build TurboDocx. See how document automation and e-signatures can accelerate your team. [Schedule a demo](https://www.turbodocx.com/demo) or [explore the API](https://www.turbodocx.com/products/api-and-sdk.md). --- --- title: "Future of SaaS: Build, Buy, or Integrate? | TurboDocx" description: "TurboDocx founder Nicolas Fry on The Cool Kids Table podcast: how AI changes build versus buy, why integrations win, and loop engineering. Watch or listen." url: "https://www.turbodocx.com/blog/cool-kids-table-podcast-future-of-saas" --- # The Future of SaaS: Build, Buy, or Integrate? > TurboDocx founder Nicolas Fry joined The Cool Kids Table podcast from Helpt to talk about where software is headed, how AI changes build versus buy, and why integrations matter more than ever. Nicolas Fry on The Cool Kids Table, a podcast by [Helpt](https://gethelpt.com). By Nicolas Fry (Founder & CEO, TurboDocx). Published October 16, 2026. 3 min read. ## Watch and listen - [Watch on YouTube](https://youtu.be/q7COhxIyT6o) - [Listen on Spotify](https://open.spotify.com/episode/7eJvyvhWoOAGC53kCHFhHc) - [Discuss on LinkedIn](https://www.linkedin.com/posts/gethelpt_ai-techpodcast-softwaredevelopment-activity-7516144459965689856-pkPe) ## What we talked about Most teams live in a small set of tools every day. Software that cannot earn a spot in that set tends to get routed around, no matter how good it is. In this episode of The Cool Kids Table, Nicolas argues that the next generation of software companies may win by fitting into the workflows businesses already run, not by asking people to open one more tab. - Why the future of software may depend on the handful of apps people already use every day. - How AI changes the decision to build software or buy it. - Whether loop engineering could be the next step in working with AI. - What companies should think about as AI agents take on more of the work. ## How this shapes TurboDocx The integrate-first idea is how we build TurboDocx. Instead of another app to log into, documents, signatures, and quotes get generated from where your data already lives: your CRM, your PSA, your project tool, or an [n8n workflow](https://www.turbodocx.com/integrations/n8n.md). See every connector on our [integrations page](https://www.turbodocx.com/integrations.md), or go straight to [document templating](https://www.turbodocx.com/products/turbodocx-templating.md), [TurboSign e-signatures](https://www.turbodocx.com/products/turbosign.md), and [TurboQuote](https://www.turbodocx.com/products/turboquote.md). Building it into your own product? Start with the [API and SDKs](https://www.turbodocx.com/products/api-and-sdk.md). The loop engineering segment builds on a post we wrote earlier this year: [Loop Engineering: Building With AI Agents the Right Way](https://www.turbodocx.com/blog/loop-engineering.md). Thanks to the [Helpt](https://gethelpt.com) team for having us at the table. ## More from Helpt - [The Future of SaaS: Build, Buy, or Integrate?](https://gethelpt.com/podcasts/the-future-of-saas-build-buy-or-integrate): Episode page on Helpt - [The Seventh Tab Problem: Is Your Software Being Used?](https://gethelpt.com/articles/the-seventh-tab-problem): Helpt blog feature ## Related reading - [Loop Engineering: Building With AI Agents the Right Way](https://www.turbodocx.com/blog/loop-engineering.md) - [Best Claude Code Plugins, Skills & MCP Servers](https://www.turbodocx.com/blog/best-claude-code-skills-plugins-mcp-servers.md) - [How to Write a CLAUDE.md File That Actually Works](https://www.turbodocx.com/blog/how-to-write-claude-md-best-practices.md) - [A Complete Guide to Document Automation](https://www.turbodocx.com/blog/a-complete-guide-to-document-automation.md) ## Generate documents, signatures, and quotes from the tools you already use [Try TurboDocx](https://www.turbodocx.com/pricing.md) --- --- title: "E-Signatures for Invoices: Why and How to Start | TurboDocx" description: "Signed invoices mean documented approvals, fewer disputes, faster payment. Why invoice e-signatures matter and how to get one signed, from your browser to your own app." url: "https://www.turbodocx.com/blog/esignature-for-invoices" --- # E-Signatures for Invoices: Why You Need Them and How to Set Them Up > A signed invoice is more than a formality. It is a documented approval, a defense against disputes, and a faster path to getting paid. This guide covers why signatures on invoices matter and how to start collecting them, whether you send one from your browser today or build signing into your own invoicing app. By Monica Talbert (Solutions Architect, TurboDocx). Published June 6, 2026. 5 min read. Category: E-Signature. Most invoices travel from your billing system to a customer's inbox and then disappear into a folder. They confirm an amount, but they rarely confirm an agreement. That gap is where slow approvals, payment delays, and end-of-quarter disputes live. Adding an e-signature to an invoice closes that gap. It captures a real sign-off from the person who approved the charge, attaches it to that exact version of the document, and produces an audit trail you can pull up months later. This guide covers why invoice signatures matter for finance and operations teams, the everyday scenarios where they pay off, and the fastest ways to start collecting them, from sending a single invoice in your browser to building signing into your own product. ## Why signatures on invoices matter If you have ever chased down who approved a charge, or watched an invoice sit unpaid because nobody was sure it was authorized, you already understand the problem. A signature is the smallest possible step that turns an invoice from a notification into a commitment. Once you see why it matters, the practical next step is to [add e-signatures to your invoices without code](https://www.turbodocx.com/blog/add-esignatures-to-invoices-without-code.md). ### A clear approval record A signature turns "I think someone okayed this" into a documented sign-off. Whoever approved the amount, the scope, and the terms is named, dated, and locked to that exact version of the invoice. ### Fewer disputes, faster resolution When a charge gets questioned weeks later, a signed invoice is the simplest possible answer. There is a signer, a timestamp, and the document they agreed to, so the conversation moves from "did we agree?" to "here is what was agreed." ### Faster payment cycles An invoice stuck waiting on an internal approval is an invoice that is not getting paid. Routing it for a signature the moment it is ready removes the ambiguity about who needs to act next. ### An audit trail you can hand over Finance reviews, partner reconciliations, and year-end audits all go smoother when every approved invoice carries a tamper-evident trail showing who signed, when, and from where. ## Try TurboSign on your next invoice Upload an invoice, drop a signature field on it, and send it for signing in minutes. Your first 5 signatures each month are free, no credit card required. See [how TurboSign works](https://www.turbodocx.com/products/turbosign.md). ## Common scenarios where invoice sign off helps Invoice signatures are not only for high-value contracts. They earn their place in the routine moments where an unconfirmed amount creates friction. A few of the most common: - **Project sign-off before billing.** A client signs the invoice to confirm the milestone was delivered as scoped before your accounting team releases payment terms. - **Internal spend approval.** A department lead countersigns vendor invoices above a threshold so finance has a documented authorization on file. - **Change orders and revised totals.** When scope shifts and the amount changes, a fresh signature ties the new total to a specific approver instead of a buried email thread. - **Partner and reseller reconciliation.** Both sides sign the same invoice, so monthly reconciliation starts from an agreed number rather than a back-and-forth. ## Are signed invoices legally meaningful? Electronic signatures are widely recognized for business documents, and a properly captured invoice signature carries the same weight as a wet-ink one in most commercial contexts. If you are new to the format, our overview of [what an electronic signature is](https://www.turbodocx.com/blog/what-is-an-electronic-signature.md) explains how it works and why it holds up. The mechanics that make it durable, identity capture, a tamper-evident audit trail, and certificate generation, are handled on TurboDocx infrastructure, so the legal frameworks (the [ESIGN Act](https://www.govinfo.gov/app/details/PLAW-106publ229) and [UETA](https://www.uniformlaws.org/committees/community-home?communitykey=2c04b76c-2b7d-4399-977e-d5876ba7e034) in the United States, [eIDAS](https://eur-lex.europa.eu/eli/reg/2014/910/oj/eng) in Europe) are addressed for you. For the specifics, see the [US e-signature compliance](https://www.turbodocx.com/resources/us-esignature-compliance.md) and [European e-signature compliance](https://www.turbodocx.com/resources/european-esignature-compliance.md) guides. ## How to get invoices signed You do not need to replace your accounting software to start collecting signatures. There are two ways in, and the right one depends on who you are. **If you just need invoices signed.** This is the fastest route for a finance, operations, or owner-operator team, with no engineering at all. Create a free account at [app.turbodocx.com](https://app.turbodocx.com), upload an invoice, drop a signature field on it, and send. The signer gets an email, signs in their browser, and you get back a completed, audit-trailed PDF. Your first 5 signatures each month are free, so you can run real invoices through it before committing. This is exactly what [TurboSign](https://www.turbodocx.com/products/turbosign.md) is built for. ## If you are a builder If you want signing baked into a branded invoice page or a small internal app, you can assemble one without writing integration code. We walk through exactly that in [add e-signatures to invoices without code](https://www.turbodocx.com/blog/add-esignatures-to-invoices-without-code.md), and the broader toolkit is laid out in [the no-code e-signature stack](https://www.turbodocx.com/blog/no-code-esignature-stack.md). For a real, end-to-end example, see [the signable invoice build](https://www.turbodocx.com/blog/i-built-a-signable-invoice-app-with-lovable.md), where a working app went from idea to a signable invoice in about 12 minutes. Under the hood, both paths use the same signing engine. The simplest way to wire it into a project is [the TurboDocx Quickstart Skill](https://www.turbodocx.com/quickstart.md), which installs the integration for your AI coding agent in one command: ```bash npx skills add TurboDocx/quickstart ``` From there you point it at an invoice PDF and tell it to send for signature. Behind the scenes the integration uses TurboSign to deliver the document straight to the signer and skip the internal review step, so the recipient can sign the moment the invoice lands. If you would rather work directly against the API, the [e-signature API](https://www.turbodocx.com/e-signature-api.md) and the [API and SDK](https://www.turbodocx.com/products/api-and-sdk.md) overview cover the developer surface in full. ## From one invoice to a repeatable workflow Signing a single invoice is the easy part. The value compounds when the step becomes automatic: every invoice over a threshold routes for approval, every signed copy lands in the same place, and every audit trail is filed without anyone thinking about it. When you reach that point, sending many invoices at once is worth a look, and [the bulk signature sending guide](https://www.turbodocx.com/resources/bulk-signature-sending-guide.md) covers how to do it cleanly. Teams that want to script the whole thing can lean on [the Quickstart Skill](https://www.turbodocx.com/quickstart.md) to generate the integration and keep the approval loop entirely inside their own systems. ## Frequently asked questions ### Are e-signatures on invoices legally binding? In most commercial contexts, yes. Frameworks such as the ESIGN Act and UETA in the United States and eIDAS in Europe give a properly captured electronic signature the same legal standing as a wet-ink one, provided the signer intended to sign and agreed to do business electronically. ### Why would I add a signature to an invoice? A signature turns an invoice from a notification into a documented approval. It records who authorized the amount and terms, ties that sign-off to one exact version of the document, and gives you an audit trail that settles disputes and speeds up payment. ### How do I get an invoice signed without changing my accounting software? You do not need to replace your billing system. Upload the invoice to the hosted app, add a signature field, and send it, or use the Quickstart Skill to wire signing into a branded page or internal app. Your first 5 signatures each month are free. ### Who should sign an invoice, the customer or someone internal? It depends on the workflow. A customer can sign to confirm a milestone before billing, or a department lead can countersign vendor invoices above a threshold for internal authorization. Both sides can also sign the same invoice to agree on a number ahead of reconciliation. ## Related - [Add E-Signatures to Invoices Without Code](https://www.turbodocx.com/blog/add-esignatures-to-invoices-without-code.md): Stand up a signable invoice flow with no integration code. - [The Signable Invoice Build](https://www.turbodocx.com/blog/i-built-a-signable-invoice-app-with-lovable.md): A working invoice app, idea to signature, in about 12 minutes. - [Bulk Signature Sending Guide](https://www.turbodocx.com/resources/bulk-signature-sending-guide.md): Send many invoices for signature at once without the mess. ## Get your next invoice signed Send an invoice straight from the hosted app, or wire signing into your own product with the Quickstart Skill. Either way, your first 5 signatures each month are free. [Start signing with TurboSign](https://www.turbodocx.com/products/turbosign.md) --- --- title: "E-Signature Without a Backend: Indie Dev Guide | TurboDocx" description: "You do not need to stand up signing infrastructure to add e-signatures. Call a hosted e-signature API from a serverless function, edge route, or one-off script." url: "https://www.turbodocx.com/blog/esignature-without-a-backend" --- # E-Signature, No Backend, No Problem > You do not need to stand up signing infrastructure to collect a legally-binding signature. If you can call an API, you can add e-signatures. Here is how to do it without a backend. By Alex Martinez (Developer Relations & Automation Lead). Published June 5, 2026. 6 min read. Category: AI for Developers. You can ship e-signatures without running any signing infrastructure of your own. No document database, no signing UI, no certificate handling, and no tamper-evident audit log to maintain. A single serverless function or edge route is enough to send a document out for signature, and that is exactly the kind of footprint a side project or an MVP wants. The shortcut: use a hosted e-signature API. With TurboDocx, signing, delivery, audit trails, and compliance run on TurboDocx infrastructure. Your job shrinks to one thing, which is making an API call from somewhere safe. That "somewhere" does not have to be a backend you own. ## What "no backend" actually means You still need a place to make the call, because your API key must never live in client-side code. But that place can be tiny and serverless. Any of these is enough: - **Serverless function**: A Vercel, Netlify, or Lambda function that fires when a form submits or a deal closes. - **Edge / route handler**: A Next.js route handler or edge function that proxies the request and keeps your key server-side. - **A one-off script**: A Node or Python script you run from your laptop or a cron job. No web server at all. ## Let the agent write the call The fastest path is to let your AI coding agent write the integration. Install the [TurboDocx Quickstart Skill](https://www.turbodocx.com/quickstart.md), then describe what you want. The skill detects whether you are on Next.js, Express, a serverless function, or plain Node, and writes a call that fits. ```bash npx skills add TurboDocx/quickstart ``` Then, in your agent: "Add a serverless function that sends a PDF for signature with TurboSign." Step-by-step versions live in the [Claude Code guide](https://www.turbodocx.com/guides/add-esignature-with-claude-code.md) and the [Cursor guide](https://www.turbodocx.com/guides/add-esignature-with-cursor.md). If you would rather see the raw SDK call, the [JavaScript guide](https://www.turbodocx.com/guides/sign-documents-with-javascript.md) has it. ## The whole thing in one serverless function Here is the entire feature as a single Next.js route handler. The same shape works as a Vercel function, a Netlify function, or a Lambda: parse the request, configure the SDK from environment variables, and call `sendSignature`. There is no document database to set up, no signing page to build, and no audit trail to store. The recipient gets an email with a signing link, and TurboSign takes it from there. ```typescript // app/api/send-signature/route.ts import { TurboSign } from '@turbodocx/sdk'; import { readFileSync } from 'fs'; TurboSign.configure({ apiKey: process.env.TURBODOCX_API_KEY, // server-side only orgId: process.env.TURBODOCX_ORG_ID, senderEmail: process.env.TURBODOCX_SENDER_EMAIL, senderName: process.env.TURBODOCX_SENDER_NAME, }); export async function POST(request: Request) { const { recipientName, recipientEmail } = await request.json(); // Validate the incoming request before you spend a signature if (!recipientEmail) { return Response.json({ error: 'recipientEmail required' }, { status: 400 }); } const pdfBuffer = readFileSync('contract.pdf'); const result = await TurboSign.sendSignature({ file: pdfBuffer, documentName: 'Partnership Agreement', recipients: [{ name: recipientName, email: recipientEmail, signingOrder: 1 }], fields: [ { type: 'signature', recipientEmail, template: { anchor: '{signature1}', placement: 'replace', size: { width: 100, height: 30 } }, }, ], }); return Response.json({ documentId: result.documentId }); } ``` That single file is the whole integration. For the full reference (every field option, recipient setting, and template anchor), see [the standalone TypeScript signing guide](https://www.turbodocx.com/guides/sign-documents-with-typescript.md). Notice that the API key is read from `process.env` inside the function and never leaves the server. Never call the signing API from the browser, and never ship `TURBODOCX_API_KEY` in your frontend bundle or a `NEXT_PUBLIC_` variable. A leaked key is not just an account detail: anyone who has it can send signature requests on your behalf, spend your quota, and put your name on documents you never authorized. The key belongs in exactly one place, which is the serverless function's environment. It is also worth being honest about the phrase "no backend." What you are really doing is borrowing someone else's backend, the hosted signing API, so you do not have to run one yourself. That is a great trade, but it does not remove every responsibility. You still own the request that triggers the call. Validate the inputs (the snippet above rejects a missing recipient before spending a signature) and authenticate the caller so a stranger cannot hit your route and fire off documents in your name. The signing infrastructure is outsourced; the gate in front of it is yours. For the full SDK surface and field options, see the [JavaScript guide](https://www.turbodocx.com/guides/sign-documents-with-javascript.md), or install the [Quickstart Skill](https://www.turbodocx.com/quickstart.md) and let your agent wire it up. ## The one rule: keep the key off the client "No backend" does not mean "call the API from the browser." Your API key grants access to your account, so it has to stay server-side, even if that server is a function that runs for 200 milliseconds. Read it from an environment variable, never bake it into your frontend bundle, and let the serverless layer be the only thing that talks to the signing API. The Quickstart Skill follows this rule by default, reading your key from `.env` rather than hardcoding it. Everything else that makes signatures legally defensible, including tamper-evident audit trails and ESIGN, UETA, and eIDAS alignment, is handled on the API side. You can read more on the [US compliance](https://www.turbodocx.com/resources/us-esignature-compliance.md) and [European compliance](https://www.turbodocx.com/resources/european-esignature-compliance.md) guides. ## Related Resources - [Vibecode an E-Signature Flow](https://www.turbodocx.com/blog/vibecode-an-esignature-flow.md): The full workflow, from blank project to first signature. - [E-Signature API](https://www.turbodocx.com/e-signature-api.md): The hosted API behind every example here. ## Add signing without the infrastructure Install the Quickstart Skill and let your agent write the call. Your first 5 signatures each month are free. [Install the Quickstart Skill](https://www.turbodocx.com/quickstart.md) or read the [Claude Code guide](https://www.turbodocx.com/guides/add-esignature-with-claude-code.md). --- --- title: "How Long to Build an E-Signature App, Really? | TurboDocx" description: "We timed building an e-signature app. About 12 minutes and 3 prompts, with the timestamps to prove it, plus an honest estimate of the same build from scratch." url: "https://www.turbodocx.com/blog/how-long-to-build-an-esignature-app" --- # How Long Does It Take to Build an E-Signature App? We Timed It. > About 12 minutes. Three prompts. We have the timestamps. Here is the full benchmark, and an honest look at what the same build costs from scratch. By Alex Martinez (Developer Relations & Automation Lead, TurboDocx). Published June 8, 2026. 5 min read. Category: AI for Developers. "How long does it take to build an e-signature app?" is one of those questions where the honest answer used to be "longer than you think." Auth, PDF generation with real form fields, a signing flow, an audit trail, completion notifications. Each piece is small, but together they eat weeks. So we ran an actual benchmark. We opened Lovable, described a signable invoice app, dropped in [the TurboDocx Quickstart Skill](https://www.turbodocx.com/quickstart.md), and timed the whole thing. The result: a working, sendable e-signature app in about 12 minutes across three prompts. The full timestamped walkthrough is on the hub. If you want the long-form writeup, [the full build](https://www.turbodocx.com/blog/i-built-a-signable-invoice-app-with-lovable.md) walks through it screen by screen. ## What actually ate the clock The whole build took about 12 minutes across three prompts, including one Vite dependency hiccup that Lovable fixed on its own by restarting the dev server. No editing or retries were cut out, so the number reflects the real, unfiltered run. The full timestamped walkthrough is on the hub: [I Built a Signable Invoice App with Lovable](https://www.turbodocx.com/blog/i-built-a-signable-invoice-app-with-lovable.md). ## What it really costs to build from scratch A few weeks of work can get you a demo: a form that emails a PDF with a signature box. But that is not what TurboSign actually gives you. To match a signature you would defend in a dispute, you are not building an invoice form, you are building a signing platform: HSM-backed keys, certificate-based sealing, a tamper-evident audit trail, and ESIGN, UETA, and eIDAS compliance. The figures below are illustrative, not measured, but they reflect that real scope: | Phase | Estimate | What it covers | | --- | --- | --- | | App shell (form, PDF, send flow) | 3 to 4 weeks | Invoice form, PDF rendering with embedded signature fields, status states, send and reminder flow. | | HSM-backed signing and PKI | 5 to 7 months | FIPS 140-3 validated key storage inside a hardware security module, certificate issuance and lifecycle, cryptographic signature sealing. | | Tamper-evident audit trail | 3 to 4 months | Cryptographically sealed event log, document hashing, court-defensible evidence of who signed what and when. | | Compliance (ESIGN, UETA, eIDAS) | 4 to 6 months | Multi-jurisdiction legal review, consent capture, advanced vs qualified signature tiers, retention policy. | | Security hardening and testing | 3 to 4 months | Threat modeling, penetration testing, and the remediation cycles that follow. | | Reliability, scale, and on-call | 3 to 4 months | Redundancy, monitoring, incident response, and the maintenance that never really ends. | Add those up and a from-scratch, compliance-grade signing platform realistically runs around two years, call it 24 months, before it is something you would stake a real contract on. That is the part the 12-minute build quietly skips over, because the HSM-backed signing, certificate handling, and tamper-evident audit trail are already built, certified, and maintained for you. It is worth understanding what that layer actually does: see how the cryptography works in [how electronic signatures work](https://www.turbodocx.com/resources/how-electronic-signatures-work.md), and the legal backing in the [US](https://www.turbodocx.com/resources/us-esignature-compliance.md) and [European](https://www.turbodocx.com/resources/european-esignature-compliance.md) e-signature compliance guides. Once that platform is handled for you, replicating the build itself is just [a few prompts](https://www.turbodocx.com/blog/turbodocx-lovable-integration-guide.md). ## Run the same benchmark yourself The single line that compressed the timeline is the skill install. From your project, run the open-source `skills` CLI: ```bash npx skills add TurboDocx/quickstart ``` Create a free account at [app.turbodocx.com](https://app.turbodocx.com) (your first 5 signatures each month are free), then add your credentials to `.env`: ```bash TURBODOCX_API_KEY=your_api_key_here TURBODOCX_ORG_ID=your_org_id_here TURBODOCX_SENDER_EMAIL=you@company.com TURBODOCX_SENDER_NAME=Your Company Name ``` From there, prompt your agent the way the benchmark did. To send immediately and skip the review step, ask it to use `sendSignature` rather than `createSignatureReviewLink`, exactly the one-prompt change described above. The full walkthrough lives in [the TurboDocx Quickstart Skill](https://www.turbodocx.com/quickstart.md), and the building blocks are documented in the [e-signature API](https://www.turbodocx.com/e-signature-api.md) overview and the [API and SDK](https://www.turbodocx.com/products/api-and-sdk.md) reference. ## Why 12 minutes is honest, not a shortcut The reason the number holds up is that the hard parts were never skipped, they were moved. Signing is a legal instrument, so tamper-evident audit trails, certificate handling, and ESIGN, UETA, and eIDAS alignment all run on TurboDocx infrastructure rather than your weekend project. You can read the high-level mechanics in the [US e-signature compliance](https://www.turbodocx.com/resources/us-esignature-compliance.md) and [European compliance](https://www.turbodocx.com/resources/european-esignature-compliance.md) guides. The one hiccup proves the point rather than undercutting it. When the dev environment hit a Vite dependency-optimizer snag, the kind of thing that normally sends you to a GitHub issue thread for 20 minutes, it took zero user action: Lovable restarted the dev server on its own and the build continued. That is the difference between a demo and a workflow. The tooling absorbed the failure instead of handing it to you. It is worth understanding what vibe coding is before you read too much into a 12-minute number. You are not skipping engineering, you are describing intent and reviewing a diff, so the boring plumbing collapses while the parts that need judgment stay yours. For a balanced take on the tool itself, see [our Lovable review](https://www.turbodocx.com/blog/lovable-review.md). What you still own is judgment: review the generated diff, verify completion webhooks before trusting them, and handle the decline and expiry cases, not just the happy path. That review takes minutes because you are reading a small, purpose-built module instead of an SDK's internals. ## Frequently asked questions ### How long does it really take to build an e-signature app? In our timed benchmark, a working, sendable e-signature app took about 12 minutes across three prompts. That number holds because the signing platform itself already exists. Building the same compliant infrastructure from scratch, including HSM-backed keys and a tamper-evident audit trail, realistically runs around 24 months. ### Can an AI agent build a compliant signing platform on its own? No, and it does not need to. An AI agent wires your app to an existing signing platform in minutes, but the compliance-grade machinery, certificate sealing, tamper-evident audit trails, and ESIGN, UETA, and eIDAS alignment, runs on TurboDocx infrastructure that is already built, certified, and maintained for you. ### Why does building from scratch take so much longer than 12 minutes? The 12-minute build reuses a finished signing platform. From scratch you would build that platform yourself: HSM-backed key storage, certificate issuance, a court-defensible audit trail, multi-jurisdiction compliance, security hardening, and on-call reliability. Each phase takes months, which is why a real from-scratch estimate lands near 24 months. ### Is the 12-minute build production-ready? The signing layer is, because the cryptography, audit trail, and compliance run on certified infrastructure. What you still own is judgment: review the generated diff, verify completion webhooks, and handle the decline and expiry cases, not just the happy path. That review takes minutes because you are reading a small, purpose-built module. ## Related Resources - [I Built a Signable Invoice App with Lovable](https://www.turbodocx.com/blog/i-built-a-signable-invoice-app-with-lovable.md): The full build, screen by screen. - [TurboDocx + Lovable Integration Guide](https://www.turbodocx.com/blog/turbodocx-lovable-integration-guide.md): How to replicate the benchmark yourself. - [Our Lovable Review](https://www.turbodocx.com/blog/lovable-review.md): A balanced take on the tool that ran this build. - [E-Signature API](https://www.turbodocx.com/e-signature-api.md): The signing infrastructure you do not have to build. - [TurboDocx Quickstart Skill](https://www.turbodocx.com/quickstart.md): One command to teach your agent TurboDocx. ## Beat our 12 minutes Install the Quickstart Skill, open your agent, and time your own e-signature build. Your first 5 signatures each month are free. [Install the Quickstart Skill](https://www.turbodocx.com/quickstart.md) --- --- title: "Webhook Security for E-Signature API Integrations | TurboDocx" description: "How to secure webhooks for e-signature and document API integrations with HMAC. Verify signatures in Node.js with timingSafeEqual and SHA-256." url: "https://www.turbodocx.com/blog/how-to-webhook-hmac-guide" --- # Webhook Security for E-Signature API Integrations > Webhooks are how e-signature and document APIs tell your app that a contract was signed. But without verification, anyone can fake that event. This is HMAC webhook security, explained so you can implement it before lunch. By Nicolas Fry (Founder & CEO, TurboDocx). Published May 7, 2026. 15 min read. Category: Backend Architecture. If you integrate an e-signature or document API, you need to know the instant a payment succeeds on Stripe, a document gets signed on [TurboSign](https://www.turbodocx.com/products/turbosign.md), or a task changes status in your project management tool. You _could_ write a loop that asks "anything new?" every five seconds. But that's like calling the pizza place every minute to ask if your order is ready. Sure, it technically works, but they'll hate you and you're wasting everyone's time. Enter **webhooks**: instead of asking, you give the pizza place your phone number and they _call you_ when it's ready. In API terms, you give the service a URL, and they send a POST request to that URL whenever the event you care about fires. Simple, efficient, real-time. But there's a catch. If anyone on the internet can send a POST request to your URL, how do you know it actually came from the service you trust? That's where **HMAC** comes in. It's not as scary as the acronym sounds. Let's break it down. ## Part 1: What Even Is a Webhook? A webhook is an HTTP callback. When an event happens in System A, it sends an HTTP POST request to a URL that System B controls. That's it. No magic, no special protocol. Just a regular HTTP request triggered by an event. The word "webhook" is just a fancy way of saying "a URL that receives automated HTTP requests." If you've ever built an Express route that handles a POST request, congratulations. You already know 80% of what you need. ### The Mental Model ``` // Without webhooks (polling): Your App → "Any new orders?" → Stripe Your App → "How about now?" → Stripe Your App → "...now?" → Stripe Your App → "NOW?" → Stripe // (999 empty responses later...) Stripe → "Yes, one order." → Your App // With webhooks: Your App → "Here's my URL, ping me when something happens." → Stripe // (silence... your app does other things) Stripe → POST /your-webhook-url { "event": "payment_succeeded" } → Your App ``` ### Webhooks vs. Polling: The Full Picture | Aspect | Polling | Webhooks | | --- | --- | --- | | How it works | Your app asks 'anything new?' on a loop | The source app tells you when something happens | | Latency | Depends on interval (5s? 30s? 5min?) | Near-instant (sub-second) | | Efficiency | Wastes requests when nothing changed | Only fires when there's actual data | | Complexity | Simple to build, expensive to run | Needs a public endpoint, but scales beautifully | | Real-world analogy | Checking your mailbox every 5 minutes | Having a doorbell | ### Real-World Webhook Examples Webhooks are everywhere. Here are some you've probably used without thinking about it: - **Stripe** sends a webhook when a payment succeeds or fails - **GitHub** notifies your CI/CD pipeline on every push - **Slack** fires a webhook when a message mentions your bot - **[TurboSign](https://www.turbodocx.com/products/turbosign.md)** notifies your system when all signers have signed a document - **[Wrike](https://www.turbodocx.com/newsroom/turbodocx-wrike-partnership.md) / Jira / Asana** trigger automations when a task status changes ## Part 2: The Problem. Anyone Can POST Here's the uncomfortable truth: your webhook endpoint is just a URL. If someone discovers it (and they will, because URLs leak through logs, configs, Postman collections, and ChatGPT screenshots), they can send whatever they want to it. Imagine your webhook handler processes a `payment_succeeded` event by marking an order as paid and shipping it. If an attacker can forge that webhook, they just got free stuff. Without verification, your webhook endpoint is basically an unlocked door with a sign that says "send me JSON and I'll do whatever it says." You need a way to answer two questions: - **Authenticity:** Did this request actually come from the service I registered with, or is someone spoofing it? - **Integrity:** Is this the exact payload the sender sent, or did someone intercept and modify it in transit? HMAC answers both questions with one mechanism. And it does it without transmitting any secrets over the wire. ## Part 3: HMAC, the Bouncer for Your Webhook HMAC stands for **Hash-based Message Authentication Code**. Let's unpack that name because each word matters: - **Hash-based**: it uses a hash function (like SHA-256) under the hood - **Message**: the thing you're verifying (the webhook payload) - **Authentication Code**: a short string that proves who sent the message and that it wasn't tampered with Think of it like a wax seal on a medieval letter. The seal proves who sent it (only the sender has that specific seal stamp), and if the letter was opened, the seal is broken. HMAC is the digital version of that wax seal. ### How HMAC Works in 4 Steps 1. **Share a secret.** You and the sender agree on a secret key. This key never travels with the webhook. Both sides already have it. 2. **Sender hashes the payload.** Before sending, the source computes HMAC-SHA256(secret, payload) and attaches the result as a header (e.g., X-Signature). 3. **You recompute the hash.** When the webhook arrives, you run the same HMAC-SHA256(secret, rawBody) on your end. 4. **Compare securely.** If your hash matches the header, the payload is authentic and untampered. Use timingSafeEqual, never ===. ### Inside the HMAC Black Box You might wonder: why not just hash the secret and message together? Like `SHA256(secret + message)`? Because that's vulnerable to something called a **length extension attack**. An attacker can take a valid hash and append extra data to the message while producing a valid hash for the longer message, without knowing the secret. HMAC's double-hash construction prevents this: ```typescript // What HMAC actually does (simplified) function hmac(secret, message) { // 1. XOR the secret with two different padding constants const innerKey = xor(secret, 0x36363636...); const outerKey = xor(secret, 0x5c5c5c5c...); // 2. Hash the inner key + message const innerHash = sha256(innerKey + message); // 3. Hash the outer key + that result return sha256(outerKey + innerHash); } // The double-hash is what makes HMAC stronger than // a naive hash(secret + message). It prevents // "length extension attacks" where an attacker appends // data to a message and forges a valid hash. ``` In practice, you never implement HMAC yourself because every language has a built-in. In Node.js, it's `crypto.createHmac()`. But understanding _why_ it's a double hash helps you appreciate that HMAC isn't just "hash with a key." It's specifically designed to be resistant to known cryptographic attacks. ## Part 4: Timing Attacks, the Bug You Can't See This is the part most tutorials mention in passing but don't really explain. It's also the part that separates code that _works_ from code that's actually _secure_. When you compare two strings with `===`, JavaScript (and most languages) uses **short-circuit evaluation**: it stops comparing at the first byte that doesn't match. This means: - Comparing `"aaaa"` to `"baaa"` fails immediately (first byte differs) - Comparing `"aaaa"` to `"aaab"` takes slightly longer (fails at the fourth byte) An attacker can measure these tiny timing differences (we're talking microseconds) and guess the correct signature one byte at a time. Start with `"00..."`, try every hex character for the first byte, keep the one that takes longest, move to the next byte. It's like cracking a combination lock by listening for clicks. The fix is `crypto.timingSafeEqual()`. It _always_ compares every byte, regardless of where (or if) there's a mismatch. Same input, same time. Always. ```typescript // BAD: vulnerable to timing attacks function insecureCompare(a: string, b: string): boolean { return a === b; // Returns false at the FIRST mismatched byte. // "aaaa" vs "abaa" → fails at index 1 (fast) // "aaaa" vs "aaab" → fails at index 3 (slow) // An attacker measures this difference to guess // the correct signature one byte at a time. } // GOOD: constant-time comparison function secureCompare(a: string, b: string): boolean { return crypto.timingSafeEqual( Buffer.from(a, "hex"), Buffer.from(b, "hex") ); // Always compares ALL bytes, even after a mismatch. // Takes the same time whether 0 or all bytes match. // No timing information leaks to an attacker. } ``` ## Part 5: Build a Verified Webhook Receiver Let's put it all together. Here's a complete webhook receiver in Node.js/Express that verifies HMAC signatures properly. This is production-ready, not a toy example. ```typescript import crypto from "crypto"; import express from "express"; const app = express(); // Critical: capture the raw body BEFORE parsing app.use("/webhooks", express.raw({ type: "application/json" })); app.post("/webhooks/incoming", (req, res) => { const secret = process.env.WEBHOOK_SECRET; const signature = req.headers["x-signature"]; if (!secret || typeof signature !== "string") { return res.status(400).json({ error: "Missing secret or signature" }); } // Step 1: Recompute the HMAC from the raw body const expectedSignature = crypto .createHmac("sha256", secret) .update(req.body) // raw Buffer, not parsed JSON .digest("hex"); // Step 2: Both must be the same byte length for timingSafeEqual const expectedBuf = Buffer.from(expectedSignature, "hex"); const providedBuf = Buffer.from(signature, "hex"); if (expectedBuf.length !== providedBuf.length) { return res.status(401).json({ error: "Invalid signature" }); } // Step 3: Compare using timingSafeEqual (NOT ===) const trusted = crypto.timingSafeEqual(expectedBuf, providedBuf); if (!trusted) { return res.status(401).json({ error: "Invalid signature" }); } // Step 4: Now it's safe to parse and process const payload = JSON.parse(req.body.toString()); console.log("Verified webhook:", payload); // Respond 200 immediately, process async if needed res.status(200).json({ received: true }); }); ``` ### Line-by-Line Breakdown 1. **`express.raw()`** This is the most important line. By default, Express parses JSON bodies automatically, which can alter the byte representation. We need the exact raw bytes that were sent so our HMAC matches. This middleware gives us a Buffer, not a parsed object. 2. **Guard clause for missing inputs.** If the secret is not configured or the sender didn't include a signature header, bail early. Never call `createHmac` with an undefined key. 3. **`createHmac("sha256", secret)`** Creates an HMAC instance using SHA-256 and our shared secret. SHA-256 is the industry standard; some services use SHA-1 (check their docs), but SHA-256 is what you should default to. 4. **Length check before comparison.** `timingSafeEqual` throws if the two buffers have different byte lengths. A valid SHA-256 hex digest is always 64 characters (32 bytes), so a length mismatch means the signature is definitely wrong. Reject it before comparing. 5. **`timingSafeEqual()`** Constant-time comparison. Both buffers are the same length (verified above), so this safely compares every byte without leaking timing information. 6. **Respond 200 immediately.** Most webhook senders have a timeout (typically 5-30 seconds). If you don't respond in time, they'll retry, and you'll process the same event multiple times. Ack fast, process async. Want to go deeper? Webhooks are just one piece of the distributed systems puzzle. See our [event-driven architecture guide](https://www.turbodocx.com/blog/microservices-event-driven-architecture.md) for patterns on message brokers, sagas, and resilient service-to-service communication. ## Part 6: Mistakes That Will Ruin Your Weekend Every one of these has bitten a developer in production. Most of them won't show up in your tests because your test payloads are well-formed and your test "attacker" is you. - **Using === to compare signatures.** Why it's dangerous: Vulnerable to timing attacks. An attacker can guess the hash one byte at a time. Fix: Always use crypto.timingSafeEqual(). - **Parsing the body before verifying.** Why it's dangerous: JSON.parse() can alter whitespace/encoding, changing the hash. Fix: Verify the raw body buffer first, then parse. - **Hardcoding the secret in source code.** Why it's dangerous: Secrets in git repos get leaked. It's a matter of when, not if. Fix: Use environment variables or a secrets manager. - **Not responding 200 quickly.** Why it's dangerous: Most senders retry on timeout, causing duplicate processing. Fix: Respond 200 immediately, process async. ## Part 7: Hardening Your Webhook in Production HMAC verification is necessary but not sufficient. Here are the other layers a production webhook receiver needs: ### Idempotency Webhook senders retry on failure (and sometimes on success, if they didn't get your 200 fast enough). Your handler must produce the same result whether it processes an event once or five times. Store the event ID and skip duplicates. ### Replay Protection An attacker who intercepts a valid webhook can replay it later. Many senders include a timestamp header. Reject webhooks older than a few minutes. Stripe, for example, sends a `t=` timestamp in their signature header. ### Rate Limiting Even with HMAC, protect your endpoint from being overwhelmed. If your handler triggers expensive work (generating documents, sending emails), rate-limit the endpoint to prevent accidental or malicious floods. ### Logging and Monitoring Log every webhook: received, verified, failed verification, processed, errored. When things go wrong (and they will), your logs are your only diagnostic tool. Track HMAC failures specifically. A spike in verification failures could mean a compromised secret or a misconfigured sender. ### Secret Rotation Secrets don't last forever. Plan for rotation from day one: accept both the current and previous secret during a transition window. Most webhook platforms support generating a new secret before revoking the old one. **How TurboDocx does it:** Our [integration webhook system](https://www.turbodocx.com/products/api-and-sdk.md) uses per-webhook API keys as the HMAC secret, automatic retry with exponential backoff, and idempotent document versioning. In some integrations, a single verified webhook triggers document generation, e-signatures, or PDF conversion and delivers the result back to the source system automatically. ## HMAC Cheat Sheet Pin this to your wall. Or your second monitor. Or wherever your sticky notes live. | Concept | One-Liner | | --- | --- | | Webhook | An HTTP POST sent to your URL when an event occurs | | HMAC | A keyed hash that proves authenticity + integrity | | Shared Secret | A key both sides know; never sent with the webhook | | Signature Header | The HMAC digest the sender attaches (e.g., X-Hub-Signature-256) | | timingSafeEqual | Constant-time comparison that blocks timing attacks | | express.raw() | Middleware to capture the unparsed body for HMAC computation | | Idempotency | Processing the same event twice produces the same result | | Replay Attack | Resending a valid old webhook; defend with timestamp checks | ## Frequently Asked Questions ### What is a webhook in simple terms? A webhook is a way for one application to send real-time data to another application the moment something happens. Instead of constantly asking 'any updates?' (polling), the source app pushes a notification to a URL you provide. Think of it like a doorbell instead of peeking through the window every 5 seconds. ### What does HMAC stand for and why is it used with webhooks? HMAC stands for Hash-based Message Authentication Code. It's used with webhooks to verify that the payload actually came from the expected sender and wasn't tampered with in transit. The sender computes a hash of the payload using a shared secret key, and the receiver recomputes it to confirm a match. ### How do I verify a webhook signature in Node.js? Use Node.js's built-in crypto module: compute an HMAC-SHA256 of the raw request body using your shared secret, then compare it to the signature header sent with the webhook using crypto.timingSafeEqual() to prevent timing attacks. ### What is the difference between webhooks and polling? Polling means your application repeatedly sends requests to check for updates (e.g., every 30 seconds), wasting bandwidth when nothing has changed. Webhooks flip the model: the source sends you a POST request the instant something happens, making them real-time, efficient, and scalable. ### Why should I use timingSafeEqual instead of === for HMAC comparison? A regular === comparison returns false as soon as it finds the first mismatched byte, and an attacker can measure this timing difference to guess the correct signature one byte at a time. crypto.timingSafeEqual() always takes the same amount of time regardless of where the mismatch occurs, blocking timing attacks. ## Build Webhook-Powered Automations with TurboDocx TurboDocx uses HMAC-verified webhooks to trigger document generation, e-signatures, and PDF conversion from tools like Wrike, Salesforce, and more. No polling, no manual steps. [Explore the API](https://www.turbodocx.com/products/api-and-sdk.md) or [see the Wrike integration](https://www.turbodocx.com/use-cases/wrike-document-automation.md). ## Keep Reading - [Microservices & Event-Driven Architecture](https://www.turbodocx.com/blog/microservices-event-driven-architecture.md): Event sourcing, CQRS, and Kafka patterns for distributed systems. - [Serverless Backend Architecture](https://www.turbodocx.com/blog/serverless-backend-architecture.md): Lambda, edge computing, and WebAssembly patterns for scalable backends. --- --- title: "How to Write a CLAUDE.md File That Actually Works: Best Practices for API Projects | TurboDocx" description: "Learn how to write an effective CLAUDE.md file for Claude Code. Best practices for structure, progressive disclosure, @imports, monorepo setup, and API integration projects." url: "https://www.turbodocx.com/blog/how-to-write-claude-md-best-practices" --- # How to Write a CLAUDE.md File That Actually Works > Best practices for structuring your Claude Code context file, from single projects to monorepos to API integrations. Based on official Anthropic docs, real-world usage, and lessons from our own codebase. By Nicolas Fry (Founder & CEO, TurboDocx). Published March 9, 2026. 12 min read. Category: Developer Productivity. Most CLAUDE.md files fall into one of two extremes: completely empty, or bloated with hundreds of lines that Claude never reads. After months of using [Claude Code](https://claude.ai/code) to build TurboDocx, across several repos spanning TypeScript backends, React frontends, a documentation site, open-source packages, and multiple SDKs, we've learned exactly what makes Claude Code productive and what wastes context tokens. This guide distills the official Anthropic recommendations, insights from the developer community, and our hands-on experience into actionable best practices. Whether you're configuring Claude Code for a solo project or an enterprise monorepo with [API integrations](https://www.turbodocx.com/resources/api-integration-best-practices.md), you'll walk away knowing exactly what to put in your CLAUDE.md, and what to leave out. ## The Golden Rule: Keep It Under 200 Lines Anthropic's official best practices documentation is clear: your CLAUDE.md should be concise. The recommended target is **under 200 lines**. Some teams go as low as 60 lines. The absolute ceiling is roughly 300 lines before Claude starts losing signal in the noise. Why? CLAUDE.md is loaded into context _every single session_. Every line consumes context window budget that could be spent on your actual code. Think of it like onboarding a new developer: you wouldn't hand them a 50-page document on their first day. You'd give them the essentials and point them to detailed docs when needed. **The test for every line:** Ask yourself: "If I remove this line, will Claude make mistakes?" If the answer is no, cut it. Every line must earn its place. ## What Belongs (and What Doesn't) The most common mistake is treating CLAUDE.md like documentation. It's not. It's a **context injection file**. Here's the definitive breakdown. ### Include | Content | Why | Example | | --- | --- | --- | | Project context (1-2 lines) | Orients Claude immediately | "SaaS document automation platform: Next.js, Express, MySQL" | | Essential commands | Claude uses these exact strings | npm run dev, npm run test, npm run build | | Architecture / directory map | Tells Claude where code lives | src/routes/ (API endpoints), src/models/ (DB models) | | Non-default conventions | Only rules Claude wouldn't guess | "Use Zustand stores, never Redux" | | Common gotchas | Prevents repeated mistakes | "Always run sync-pricing before build" | | Workflow rules | Can't be inferred from code | "Branch naming: feat/JIRA-123-description" | ### Exclude | Content | Why | | --- | --- | | Standard language conventions | Claude already knows TypeScript patterns | | Detailed API documentation | Link to docs instead, use @imports | | Code style enforced by linters | Don't send an LLM to do a linter's job | | File-by-file codebase descriptions | Claude can read files itself | | "Write clean code" instructions | Self-evident, wastes tokens | | Frequently changing information | Goes stale, causes confusion | ## The WHY / WHAT / HOW Structure The most effective CLAUDE.md files follow a clear information hierarchy. We call it the WHY/WHAT/HOW pattern. It mirrors how you'd brief a senior engineer joining your team: ````markdown # Project Name (WHAT: 1-2 lines) SaaS document automation platform. TypeScript monorepo: backend (Express), frontend (React/Gatsby), docs (Docusaurus). ## Commands (HOW: essential commands only) ```bash npm run dev # Start dev server npm run test # Run Jest tests npm run build # Production build ``` ## Project Structure (WHAT: directory map) ``` src/routes/ # API endpoints src/models/ # DB models (Objection.js) src/handlers/ # Business logic ``` ## Conventions (HOW: only non-default patterns) - Use Zustand for state management, never Redux - All API responses use `{ success, data, error }` shape - Database migrations go in src/database/migrations/ ## Reference Documents (progressive disclosure) ### API Architecture: `@docs/api-architecture.md` **Read when:** Adding or modifying API endpoints ```` Notice the pattern: context first, then commands, then structure, then conventions, then references. Each section is scannable, so Claude can extract exactly what it needs without reading every word. This is the same approach we use for our [TurboDocx API & SDK](https://www.turbodocx.com/products/api-and-sdk.md) projects where Claude Code helps us build and maintain the API layer. ## Progressive Disclosure: @imports, Rules, and Skills The single most powerful CLAUDE.md technique is **progressive disclosure**: keeping task-specific knowledge out of CLAUDE.md and loading it only when needed. Claude Code gives you several mechanisms for this. ### @imports Use `@path/to/file.md` syntax in CLAUDE.md to pull in external files on demand. Supports recursive imports up to 5 levels deep. Best for: READMEs, detailed SOPs, API architecture docs. ### .claude/rules/ Markdown files in `.claude/rules/` are auto-loaded alongside CLAUDE.md with the same priority. Best for: team-wide coding rules, review checklists. ### .claude/skills/ Skill files are loaded _on demand_ based on relevance. They have metadata (name, description) for discovery without loading the full content. Best for: domain knowledge, specialized workflows, complex procedures. ### docs/ Directory Reference detailed SOPs, architecture docs, and guides in CLAUDE.md with a "Read when" trigger so Claude knows when to look. Best for: long-form documentation, style guides, migration playbooks. Example: ```markdown ## Reference Documents ### Content SEO SOP: `@docs/CONTENT-SEO-SOP.md` **Read when:** Creating or editing ANY content page Covers metadata requirements, JSON-LD schemas, internal linking minimums ### API Architecture: `@docs/api-architecture.md` **Read when:** Adding or modifying API endpoints Defines route patterns, request/response shapes, auth middleware ``` This pattern tells Claude _when_ to read each document and _what_ it contains, without loading everything into context every session. At TurboDocx, our root CLAUDE.md references six detailed SOPs (content creation, SEO architecture, deployment, and more), but Claude only loads them when the task requires it. It's the same principle behind [how we manage our open-source projects](https://www.turbodocx.com/blog/the-power-of-maintaining-open-source.md): keep the surface area small, go deep only when needed. ## CLAUDE.md for API Integration Projects If you're building an application that integrates with external APIs, whether it's [adding document signing via JavaScript](https://www.turbodocx.com/guides/sign-documents-with-javascript.md), connecting to payment processors, or consuming AI services, your CLAUDE.md needs specific API context: ```markdown ## API Integrations - TurboDocx API: REST, Bearer token auth, base URL in TURBODOCX_API_URL - SDK: @turbodocx/sdk (TypeScript), always prefer SDK over raw fetch - Docs: https://docs.turbodocx.com/API - Webhooks: POST to /webhooks/turbodocx, verify X-Signature header ## Error Handling Conventions - All external API calls wrapped in try/catch - Retry transient errors (429, 503) with exponential backoff - Log API errors to structured logger, never swallow silently - Return standardized error shape: { code, message, retryable } ``` The key insight: document the _conventions around API usage_, not the API itself. Claude can read API docs. What it can't infer is your team's patterns for authentication, error handling, retry logic, and webhook processing. For a deeper dive into API integration patterns, see our [API integration best practices guide](https://www.turbodocx.com/resources/api-integration-best-practices.md). If you're working with the [TurboDocx API for document generation](https://www.turbodocx.com/developers.md), your CLAUDE.md might reference the SDK package, the base URL environment variable, and your webhook verification pattern. The full API reference stays in external docs. CLAUDE.md just points Claude in the right direction. ## File Placement and Hierarchy Claude Code loads CLAUDE.md files from multiple locations with a clear hierarchy. Understanding this lets you layer context appropriately: | Location | Scope | Commit? | | --- | --- | --- | | ~/.claude/CLAUDE.md | All sessions, all projects | No (personal) | | ./CLAUDE.md | Project root | Yes | | ./CLAUDE.local.md | Personal project overrides | No (.gitignore) | | parent/CLAUDE.md | Inherited by child directories | Yes | | child/CLAUDE.md | Loaded when working in that dir | Yes | | .claude/rules/*.md | Auto-loaded alongside CLAUDE.md | Yes | In a monorepo, put shared conventions in the root CLAUDE.md and service-specific context in child directories. For example, our TurboDocx backend has its own CLAUDE.md covering database migrations and API patterns, while the frontend directory has one covering component conventions and state management. ## Maintaining Your CLAUDE.md A CLAUDE.md file isn't set-and-forget. Treat it like code: review it when things go wrong, prune regularly, and commit changes to version control. - Run `/insights` weekly to surface patterns from your sessions and add rules - If Claude repeatedly ignores a rule, the file is too long: prune it - If Claude asks questions already answered in CLAUDE.md, the phrasing is ambiguous: rewrite it - Use **IMPORTANT** or **YOU MUST** prefixes for critical rules to improve adherence - When Claude makes a mistake, tell it to update the CLAUDE.md so it doesn't repeat the error That last point is the most underrated trick. When Claude gets something wrong (uses the wrong import path, breaks a naming convention, misunderstands your project structure), don't just fix it and move on. Tell Claude to add the correction to CLAUDE.md itself. Over time, your CLAUDE.md becomes a living record of your codebase's quirks and preferences, written by the same tool that consumes it. Claude effectively becomes self-aware of your patterns, your style, and the traps it fell into before. The file evolves from a static brief into a feedback loop. ## Quick Reference Checklist **Do** - Keep under 200 lines - Start with 1-2 line project context - List essential commands (dev, test, build) - Document non-default conventions only - Use @imports for detailed docs - Include a directory structure overview - Add "Read when" triggers for referenced docs - Use IMPORTANT for critical rules - Review and prune regularly **Don't** - Exceed 300 lines total - Duplicate what linters enforce - Include full API documentation - Write file-by-file descriptions - Add obvious instructions ("write clean code") - Store frequently changing information - Put task-specific instructions in CLAUDE.md - Forget to commit changes to git ### Starter Template ````markdown # Project Name One-line description of what this project does and its tech stack. ## Commands ```bash npm run dev # Development server npm run test # Run tests npm run build # Production build npm run lint # Lint code ``` ## Project Structure ``` src/ # Source code routes/ # API routes models/ # Data models handlers/ # Business logic tests/ # Test files docs/ # Documentation ``` ## Conventions - [List only non-obvious, non-default patterns] - [Things Claude would get wrong without being told] ## Reference Documents ### [Doc Name]: `@docs/filename.md` **Read when:** [trigger condition] [2-3 line summary] ```` ## Related Resources - [API Integration Best Practices](https://www.turbodocx.com/resources/api-integration-best-practices.md): Production-ready patterns for authentication, error handling, webhooks, and rate limiting. - [Best Claude Code Plugins, Skills & MCP Servers](https://www.turbodocx.com/blog/best-claude-code-skills-plugins-mcp-servers.md): The 7 tools that make your CLAUDE.md come alive. Skills, built-in commands, and MCP servers for the full toolkit. ## Build Faster with Claude Code + TurboDocx API Use Claude Code with a well-crafted CLAUDE.md to integrate document generation and e-signatures into your application in minutes, not days. [Explore the API](https://www.turbodocx.com/products/api-and-sdk.md) --- --- title: "How to Write an Effective Statement of Work (SOW) | TurboDocx Blog" description: "Learn how to write a clear Statement of Work (SOW) to manage project scope and deliverables. Essential tips for MSPs, project managers, and IT consultants." url: "https://www.turbodocx.com/blog/how-to-write-effective-sow" --- # How to Write a Clear and Effective Statement of Work (SOW) > From Reddit to Reality: A Complete Guide to SOWs That Prevent Scope Creep. Learn how to write a clear, effective Statement of Work (SOW) to manage project scope, expectations, and deliverables. Essential tips for MSPs, project managers, and consultants. By Nicolas Fry (Founder & CEO, TurboDocx). Published October 10, 2024. 10 min read. Category: Best Practices. So this post went popular on Reddit and I figured it would make sense to move it to our blog as well... Every few moons I see a post on "SOW vs SLA", "How to write an MSA", and other Client Facing Document related questions. I wanted to use this post as a springboard on my philosophies on the SOW side and eventually I'll write some more on the other Documents you'd give a client. Whether you're a one person shop, project manager, or part of a MSP with a consulting arm, getting the SOW right can make or break a project. A clear SOW helps manage expectations, avoid scope creep, and ensures everyone is on the same page from day one. Templates: - [SOW Template](https://docs.google.com/document/d/1eGVfPnr0tGR9ofVKria21Ep5Rw4dKHe-/edit?usp=sharing&ouid=101706568972642413390&rtpof=true&sd=true): Optimized for TurboDocx automation - [Example AWS Build SOW](https://docs.google.com/document/d/1gQnokrymECkCaF_MJ7fB62V2c-T5E_Bh/edit?usp=sharing&ouid=101706568972642413390&rtpof=true&sd=true): See a completed real-world example ## 1. Project Overview Although this is common sense, this section is all about defining what the project is and what the client is asking for. It's essential to set the tone and provide context. In the example I worked on, the client wanted us to build a web application and deploy it for five franchises. We also outlined that we'd evaluate the potential to expand this rollout to 2,500 franchises in the future. **Key Tip:** Make sure the overview clearly states what's included in the current phase and where future possibilities might lead. This helps prevent the annoying "But we thought this was included!" moment and lines you up for future work. ## 2. Scope Definition Here's where the magic happens. A good scope definition is clear and concise, and it's the cornerstone of your SOW. In my project, we used Scope Tables to outline exactly what was in scope for the deployment, and specified that only the first five franchises were included. I also call out specifics like "3 US Regions" and give brief but concise bullet points on what's included. > If it's not listed, it's not in scope. ### Best Practices - Use clear, specific language, and avoid vague terms - Break down scope into manageable tables or sections - Call out specific quantities and limitations (e.g., "5 franchises", "3 US Regions") - Create centralized scope tables that can be reused for future projects - Consider tying scope items to SKUs for cookie-cutter services ## 3. Out of Scope **Critical Section:** Again, common sense, but one of the most critical sections of any SOW. It is what you're not going to do. Seriously, this can save you from so much scope creep. ### Example: What We Marked Out of Scope - Adding any new features to the web app - Onboarding more than five franchises - Building new AWS infrastructure not mentioned in the Cloud Build Section - Any custom integrations beyond what's specified **Pro Tip:** Be super specific about what's not included. It helps prevent misunderstandings later and gives you room to negotiate additional services (and budgets!) if needed. ## For MSP/PS Shops with Enterprise Clients I would argue the next sections are for shops with enterprise styled clients, typically companies with a CIO or a company used to 5 figure+ engagements. I know some of the folks here service large brands and can relate to what I'm saying below... ## 4. Deliverables Clients love to know what they're getting for their money. In our SOW, we broke down the deliverables by phase: - **Cloud Infrastructure Review Memo**: Outlines findings and recommended next steps for infrastructure optimization - **Rollout Strategy Memo**: Details how to go-live smoothly at scale across all franchises - **Bug Report Memo**: Documents issues from the pilot and provides actionable fixes **Key Takeaway:** Make sure every deliverable is tied directly to the project's objectives. Vague deliverables like "provide support" won't cut it. ## 5. Project Management and Change Control Projects evolve. That's why a strong change management process is vital. We used a structured methodology for handling unexpected scope changes. 1. **Confirm the Need**: Validate that the change request is necessary and aligned with project goals 2. **Outline Deliverables**: Document exactly what additional work will be provided 3. **Estimate Impact**: Calculate the effect on budget, timeline, and resources 4. **Get Agreement**: Obtain written approval before proceeding with changes **Why This Matters:** This process ensures that both parties agree before moving forward with additional work, avoiding disputes down the line. Back to regularly scheduled programming applying to everyone: ## 6. Assumptions You can't predict everything, but you can prepare. Outline general assumptions that are important for the project to succeed. ### Key Assumptions for Success - The client will provide all necessary hardware and licenses - The client's team will be available for regular meetings and questions - Post-project agreement for ongoing services (or reference to MSA) - Access to required systems and credentials will be provided promptly **Important Note:** If any assumptions are not met, this can lead to delays or increased costs. Having these documented gives you leverage if things go off track. ## 7. Estimated Fees Don't forget the financials! We estimated the total consulting fees and laid out clear guidelines for any changes in staffing or scope. Make sure to provide a breakdown of fees based on the project's phases and possible contingencies. ### Time and Material - **Definition:** Billing based on actual work performed, tracked through timesheets or ongoing work logs. - **Example:** Billing weekly for tasks such as feedback, remediation, or any variable tasks that arise as part of ongoing project support. - **Practical use:** Useful for projects with uncertain scope or evolving requirements, where work effort and time may vary. ### Fixed Fee with Milestones - **Definition:** Predetermined fees billed upon the completion of specific project phases or milestones, helping manage cash flow. - **Example structure:** - Phase 1: Billing $5k upon completion of 'Assess Current Infrastructure' phase - Phase 2: Billing $10k upon completion of 'AWS Cloud Build' phase - Final: Remaining balance billed upon project completion - **Practical use:** Effective for projects with well-defined phases, allowing clients to make payments incrementally as key objectives are met. ### Project Closure Clause for Auto-Acceptance **Purpose:** To prevent project deadlock due to unresponsive clients, enabling project closure and final invoicing. Suggested text: > "The project will be considered closed upon the mutual acknowledgment of all deliverables as completed, or, if no response is received, within 4 weeks of work completion. This auto-acceptance clause prevents extended deadlock and allows timely revenue recognition." ## Final Thoughts A well-structured SOW is more than just a contract, it's a roadmap for success. Always remember to: - **Define Scope Explicitly**: Be crystal clear about what is and isn't included to prevent scope creep - **Include Change Management**: Have a structured process for handling changes and additional requests - **Set Clear Expectations**: Document deliverables, assumptions, and payment terms upfront I hope this breakdown helps you write better SOWs in your own projects. Curious to other people's thoughts and how they run shop. Excited to see how you can crank these SOWs out in seconds. Nicolas ## Create Professional SOWs in Seconds with TurboDocx Stop wasting hours on document creation. Use our intelligent templating system to generate perfect SOWs every time. - Pre-built SOW Templates - AI-Powered Automation - Brand Consistency [Get started free](https://app.turbodocx.com/signup) or [view the SOW template](https://docs.google.com/document/d/1eGVfPnr0tGR9ofVKria21Ep5Rw4dKHe-/edit?usp=sharing&ouid=101706568972642413390&rtpof=true&sd=true). ## Related Resources - [MSP Document Automation](https://www.turbodocx.com/use-cases/msps.md): Automate SOWs, QBRs, and technical documentation directly from your PSA - [Generate SOWs from CRM Data](https://www.turbodocx.com/resources/how-to-generate-sows-from-crm-data.md): Step-by-step guide to automating statement of work generation from your CRM - [MSP Automation with n8n](https://www.turbodocx.com/blog/msp-automation-n8n-workflows.md): Discover how MSPs automate their entire workflow with n8n integrations - [IT Consulting Automation](https://www.turbodocx.com/use-cases/it-consulting.md): Streamline client deliverables and project documentation for consulting firms --- --- title: "Hyper-Personalization in B2B Sales Assets | TurboDocx" description: "Stop sending generic proposals. Learn how hyper-personalization with CRM-driven document automation transforms B2B sales assets into deal-closing machines that feel handcrafted at scale." url: "https://www.turbodocx.com/blog/hyper-personalization-b2b-sales-assets" --- # Beyond the First Name: Hyper-Personalization in B2B Sales Assets > If your proposal looks like everyone else's, you've already lost. In 2026, the biggest B2B trend isn't AI. It's making every document feel like it was built for one buyer, at the speed of a thousand. By Monica Talbert (Solutions Architect). Published May 2, 2026. 14 min read. Category: Sales & Document Automation. Your buyer just sat through three vendor demos this week. They saw the same slide deck with a different logo in the corner. Then your proposal lands in their inbox and it opens with "Dear [First Name]." That's not personalization. That's mail merge. And your buyer knows the difference. Hyper-personalization is the biggest B2B marketing and sales trend of 2026. [Gartner predicted that 80% of B2B sales interactions would occur in digital channels by 2025](https://www.gartner.com/en/newsroom/press-releases/2020-09-15-gartner-says-80--of-b2b-sales-interactions-between-su), and [McKinsey reports that fast-growing companies drive 40% more of their revenue from personalization](https://www.mckinsey.com/capabilities/growth-marketing-and-sales/our-insights/the-value-of-getting-personalization-right-or-wrong-is-multiplying) than slower-growing peers. The bar has moved. Buyers expect proposals, SOWs, and sales assets to reflect their specific industry, their pain points, and even their brand voice. Not a recycled template with their name pasted in. The problem? Real personalization used to mean real work. Hours of copy-pasting, hunting for the right case study, rebuilding pricing tables, and praying nobody forgot to swap out the last client's logo. If you've felt that pain, you're not alone. [Most sales teams hate their proposal process](https://www.turbodocx.com/blog/why-sales-teams-hate-proposals.md) for exactly this reason. This article breaks down what hyper-personalization actually means in B2B sales documents, the psychology that makes it work, and how to pull it off at scale without sacrificing brand consistency or your team's sanity. ## Where Does Your Team Fall on the Personalization Spectrum? Not all personalization is created equal. Most B2B teams think they personalize because they swap in a company name. But there's a massive gap between mail merge and what top performers do. This is how the spectrum breaks down: | Level | What It Looks Like | Avg. Win Rate | Effort | | --- | --- | --- | --- | | Level 0: Generic | Same PDF for every prospect. Logo on the cover, nothing else changes. | ~15% | Zero | | Level 1: Mail Merge | First name, company name, maybe a date. The bare minimum. | ~20% | Low | | Level 2: Segment-Based | Industry-specific case studies and pain points. One template per vertical. | ~32% | Medium | | Level 3: Account-Based | CRM data drives every element: images, pricing, ROI calculations, testimonials, and tone. Unique per deal. | ~48% | High (manual) or Low (automated) | The jump from Level 1 to Level 3 is where the money is. But look at the effort column. Level 3 done manually is unsustainable. A sales rep building a fully personalized proposal by hand spends 3-5 hours per deal. Multiply that by 30 deals a month and you have a team that spends more time in PowerPoint than on the phone. The unlock is [document automation](https://www.turbodocx.com/blog/a-complete-guide-to-document-automation.md). When the system assembles the proposal from CRM data automatically, Level 3 effort drops to near-zero and the quality actually goes up because humans are no longer copy-pasting at 11 PM the night before a deadline. ## CRM-Driven Dynamic Content: The Engine Behind Hyper-Personalization The foundation of hyper-personalized sales assets isn't creative writing. It's data. Specifically, the data already sitting in your CRM that nobody is using to its full potential. Every field in Salesforce, HubSpot, or ConnectWise is a variable waiting to drive a smarter document. If you are already using Salesforce, you can go deeper with [Salesforce proposal automation](https://www.turbodocx.com/resources/salesforce-proposal-automation.md) or [HubSpot proposal automation](https://www.turbodocx.com/resources/hubspot-proposal-automation.md) to see how these integrations work in practice. ### Six CRM Fields That Transform a Generic Proposal | CRM field | How it is used | | --- | --- | | Industry / Vertical | Swap hero images, case studies, and compliance language | | Company Size (ARR / Headcount) | Select pricing tier, ROI model inputs, and deployment scope | | Pain Points (from discovery call notes) | Reorder sections to lead with what matters most to the buyer | | Decision-Maker Role | Adjust tone: CFO gets ROI tables, CTO gets architecture diagrams | | Existing Tech Stack | Show integration compatibility and migration paths | | Deal Stage | Proposal vs. SOW vs. contract. Different documents, same data source | The key insight is that these fields already exist. Sales reps capture this data during discovery calls, qualification, and deal progression. The problem is that the data stays trapped in the CRM while someone manually builds the proposal in a separate tool. You can learn more about bridging this gap in our guide on [how to generate SOWs from CRM data](https://www.turbodocx.com/resources/how-to-generate-sows-from-crm-data.md). ### Dynamic Image and Case Study Swapping Text personalization is table stakes. The next level is visual personalization. When a financial services prospect opens your proposal, they should see relevant industry imagery, compliance badges, and a case study from their sector, not a stock photo of a generic office and a manufacturing case study. With [TurboDocx templating](https://www.turbodocx.com/products/turbodocx-templating.md), you set up conditional content blocks that swap entire sections based on CRM fields. The industry field drives which hero image loads. The company size field determines whether you show the enterprise case study or the SMB success story. The deal stage field decides whether the document is a preliminary proposal or a detailed SOW with [proper scope and deliverables](https://www.turbodocx.com/blog/how-to-write-effective-sow.md). **Pro Tip:** Build a content library of 3-5 case studies per vertical, 2-3 hero images per industry, and a set of ROI calculator templates per company size bracket. This finite set of assets creates exponential variation when combined through conditional logic, covering hundreds of unique buyer combinations without ever creating a document from scratch. ## The Personalized ROI Calculator: Your Secret Weapon Generic ROI claims are white noise. "Save up to 40% on proposal creation time" means nothing to a buyer drowning in 200 deals a month. But "Your team of 12 reps spends an estimated 720 hours per month on proposals. That's $54,000 in labor costs. We cut that to 72 hours." That stops someone in their tracks. The magic is that you already have the inputs. Your CRM knows the team size, deal volume, and average deal value. Pull those numbers into a templated ROI section and the proposal does the math for you. Every buyer gets their own numbers, not hypothetical ones. ### What a Personalized ROI Section Looks Like Instead of a generic benefits page, imagine a table that automatically populates: | Metric | Current State (from CRM) | With TurboDocx | Annual Savings | | --- | --- | --- | --- | | Proposals/month | `{deal_count}` | Same volume, 90% less time | - | | Hours per proposal | 3.5 hrs (industry avg) | ~20 minutes | `{hours_saved * hourly_rate}` | | Win rate lift | `{current_win_rate}`% | +30-50% (personalized) | `{additional_revenue}` | | Error rate (wrong client name, stale data) | ~12% (manual process) | 0% (CRM-driven) | Priceless (brand trust) | Every number in that table is pulled from the buyer's actual CRM record. No guessing, no generic claims. The result is a business case that the buyer can take directly to their CFO because it already uses their numbers. If you want to understand the difference between proposals, quotes, and SOWs in this context, check out our breakdown of [proposal vs. quote vs. SOW](https://www.turbodocx.com/resources/proposal-vs-quote-vs-sow.md). ## The Psychology of "High-Touch" Automation Here's the paradox: the goal is to make a fully automated document feel like it took 10 hours of manual work. Not to deceive anyone, but to deliver the same care and attention that a handcrafted proposal communicates, at a scale that human effort can't match. Four psychological principles explain why personalized documents close more deals. This isn't academic. It's the difference between a proposal that gets forwarded to the decision-maker and one that gets filed in "maybe later." ### 1. The Cocktail Party Effect Humans are wired to notice their own name and context. When a buyer sees their company name, their industry's challenges, and their specific numbers in a document, attention spikes. The same cognitive bias that makes you hear your name across a crowded room makes personalized proposals impossible to skim past. **How to apply it:** Use CRM data to reference the buyer's company, industry, and specific pain points throughout the document, not just on the cover page. ### 2. Reciprocity Bias When someone clearly invests effort in you, you feel an obligation to reciprocate. A proposal that references a buyer's exact tech stack and calculates ROI against their actual revenue signals: 'We did the work.' The buyer reciprocates with attention, engagement, and trust. **How to apply it:** Include account-specific ROI calculations and reference details from discovery calls. The document should feel like it took hours even if it took seconds. ### 3. Cognitive Fluency Information that feels easy to process is perceived as more trustworthy. When a proposal speaks the buyer's language (their industry jargon, their KPIs, their scale) it requires less mental effort. Less effort means more trust, faster decisions, and fewer objections. **How to apply it:** Dynamically adjust terminology, metrics, and examples to match the buyer's vertical. Financial services gets compliance references and risk metrics. SaaS gets MRR and churn reduction. ### 4. Loss Aversion People are twice as motivated to avoid losses as they are to chase gains. A personalized ROI calculator showing what this specific company loses every month by not acting is way more persuasive than generic benefit statements. **How to apply it:** Pull the buyer's revenue or deal volume from CRM data and calculate the cost of inaction. 'Your team closes 200 deals/month. At 3 hours per proposal, that's 600 hours of manual work. $45,000/month in lost productivity.' **The bottom line:** Buyers choose the vendor that demonstrates understanding of their specific needs first. Hyper-personalized proposals aren't a nice touch. They're a competitive weapon. The first proposal that speaks the buyer's language wins. ## The TurboDocx Advantage: Brand Consistency Meets Infinite Variation The biggest objection to hyper-personalization is brand dilution. "If every rep customizes their own proposals, we will end up with 50 versions of our brand." That is a legitimate fear, and it's exactly what happens when you give sales teams a blank PowerPoint and say "make it personal." The solution isn't less personalization. It's **structured freedom**: a system where brand elements are locked and content zones are flexible. Think of it as a design system for your sales documents. ### Locked (Brand-Protected) - Company logo, placement, and sizing - Brand colors, fonts, and typography - Legal disclaimers and compliance language - Footer with contact info and social links - Document layout grid and margins - Terms and conditions boilerplate ### Flexible (Personalization Zones) - Hero images matched to buyer's industry - Case studies relevant to the vertical - ROI calculations with buyer's numbers - Section ordering based on pain points - Pricing tables for the right tier/plan - Executive summary tone (technical vs. business) With [TurboDocx's templating engine](https://www.turbodocx.com/products/turbodocx-templating.md), you build master templates with locked sections and variable content blocks. The marketing team controls the brand. The sales team gets personalized documents that are always on-brand. Nobody opens PowerPoint at midnight. This "freedom within a framework" model is the same approach that software teams use with component libraries. Instead of giving every developer a blank canvas, you give them pre-approved building blocks that compose into infinite layouts. Same principle applies to sales documents: pre-approved content blocks that compose into infinite proposals. For [sales teams](https://www.turbodocx.com/use-cases/sales-teams.md), this means every rep delivers the same quality regardless of experience level. A new hire's proposal looks just as polished as a 10-year veteran's because the system enforces consistency while the data drives personalization. ## The 5-Step Implementation Playbook Hyper-personalization doesn't require a six-month transformation project. You can go from generic PDFs to CRM-driven, fully personalized sales assets in weeks, not quarters. ### Step 1. Audit Your Current Proposals Pull the last 20 proposals your team sent. Highlight every element that was the same across all of them (brand, layout, boilerplate) and every element that changed (names, numbers, case studies). The unchanging parts become your locked template. The changing parts become your variable zones. ### Step 2. Map CRM Fields to Document Variables For each variable zone, identify which CRM field drives it. Industry drives case study selection. Company size drives pricing tier. Decision-maker role drives executive summary tone. Document these mappings. They're the blueprint for your template logic. ### Step 3. Build Your Content Library Create 3-5 case studies per vertical, 2-3 hero images per industry, an ROI calculator template per company size bracket, and role-specific executive summary variants. This finite library creates exponential output through combinatorial logic. ### Step 4. Set Up Template Logic in TurboDocx Use TurboDocx's conditional content blocks and variable insertion to wire your CRM data to your document template. Connect via the Salesforce or HubSpot integration, or use the API for custom CRM setups. Test with 5-10 real deals to validate the output. ### Step 5. Measure and Iterate Track win rates, time-to-proposal, and buyer feedback before and after. Teams that invest in personalization consistently report higher close rates and significant reduction in proposal creation time within the first quarter. Use these numbers to expand the approach to SOWs, contracts, and onboarding documents. For teams that want to go even further with workflow automation, our guide on [sales automation](https://www.turbodocx.com/resources/sales-automation-guide.md) covers the full pipeline from lead to signed contract, including how to chain document generation with [e-signatures](https://www.turbodocx.com/products/turbosign.md) for a frictionless close. ## Multi-Stakeholder Personalization: One Deal, Many Readers The average B2B deal involves 6-10 decision makers. The CTO cares about API documentation and integration architecture. The CFO cares about ROI and total cost of ownership. The VP of Sales cares about time-to-value and onboarding speed. One proposal can't serve all three unless it's built to adapt. Hyper-personalization at the stakeholder level means generating multiple document variants from the same data set. The core content stays the same, but the framing, emphasis, and supporting evidence shift based on the reader's role. | Role | Focus | Tone | | --- | --- | --- | | CTO / Technical Lead | Architecture, integrations, security, API docs | Technical depth, code examples, compliance certs | | CFO / Finance | ROI, TCO, payback period, risk mitigation | Numbers-first, comparison tables, executive summary | | VP Sales / Revenue | Time-to-value, onboarding, rep productivity | Outcome-driven, testimonials, quick-win metrics | This isn't about creating three separate proposals. It's about building one intelligent template that adjusts its emphasis based on the recipient field. When paired with [TurboQuote](https://www.turbodocx.com/products/turboquote.md) for pricing configuration, you can generate role-specific proposal variants with accurate, pre-approved pricing in a single workflow. For [consulting firms](https://www.turbodocx.com/use-cases/consulting.md) and [agencies](https://www.turbodocx.com/use-cases/agencies.md), this multi-stakeholder approach is the difference between a proposal that stalls in committee and one that gets unanimous sign-off. ## This Is What TurboDocx Was Built For TurboDocx connects directly to your CRM and uses conditional logic, dynamic variable insertion, and content block assembly to generate hyper-personalized DOCX, PDF, and PPTX documents in seconds. Every document is on-brand, error-free, and tailored to the specific buyer without anyone touching a template manually. Pair it with [TurboSign](https://www.turbodocx.com/products/turbosign.md) for digital signatures and [TurboQuote](https://www.turbodocx.com/products/turboquote.md) for CPQ, and you have a complete pipeline from CRM data to signed deal, fully automated and fully personalized. Explore [Templating](https://www.turbodocx.com/products/turbodocx-templating.md) or [book a demo](https://www.turbodocx.com/demo). ## 5 Hyper-Personalization Mistakes That Kill Deals ### 1. Over-personalizing to the point of creepiness **Fix:** Reference information the buyer shared directly (discovery call, RFP). Don't surface data they didn't explicitly provide, like their LinkedIn activity or Glassdoor reviews. ### 2. Personalizing the cover page but not the content **Fix:** If the executive summary, case studies, and pricing are still generic, the buyer will feel baited. Personalization must go deep, not just wide. ### 3. Stale CRM data driving wrong personalization **Fix:** A proposal that references the wrong industry or an outdated contact name is worse than a generic one. Validate CRM data freshness before generation. ### 4. No fallback for missing CRM fields **Fix:** Not every record has every field populated. Build graceful fallbacks. If industry is blank, default to a general-purpose case study instead of showing an empty section. ### 5. Ignoring the sales cycle stage **Fix:** A first-touch proposal should be concise and value-focused. A final SOW should be detailed and contractual. Using the same template for both stages signals tone-deafness. ## The Numbers Don't Lie: ROI of Hyper-Personalization - **40%**: More revenue from personalization at fast-growing companies vs. peers. Source: [McKinsey, 2021](https://www.mckinsey.com/capabilities/growth-marketing-and-sales/our-insights/the-value-of-getting-personalization-right-or-wrong-is-multiplying) - **80%**: Of B2B sales interactions predicted to occur in digital channels. Source: [Gartner, 2020](https://www.gartner.com/en/newsroom/press-releases/2020-09-15-gartner-says-80--of-b2b-sales-interactions-between-su) - **80%**: Of consumers more likely to buy when brands personalize. Source: [Epsilon, 2018](https://www.epsilon.com/us/about-us/pressroom/new-epsilon-research-indicates-80-of-consumers-are-more-likely-to-make-a-purchase-when-brands-offer-personalized-experiences) Beyond win rates, teams using automated personalization report shorter sales cycles because proposals ship faster and require fewer revision rounds. Buyers spend more time engaging with personalized proposals compared to generic ones, which means more internal forwarding and more champions inside the account. For organizations looking to integrate document automation into broader sales workflows, [n8n workflow integrations for sales teams](https://www.turbodocx.com/blog/top-10-n8n-integrations-sales-teams.md) show how to chain CRM triggers with document generation and e-signature in a single automated pipeline. And if you are building on the [TurboDocx API](https://www.turbodocx.com/products/api-and-sdk.md), the same personalization logic can power customer-facing portals, self-service quoting tools, and partner document generation. ## Frequently Asked Questions ### What is hyper-personalization in B2B sales? Hyper-personalization goes beyond inserting a first name into a template. It means dynamically assembling every element of a sales document (images, case studies, ROI calculations, pricing, even tone) based on real-time CRM data about the specific buyer, their industry, and their deal context. ### How is hyper-personalization different from regular personalization? Regular personalization swaps surface-level fields like name and company. Hyper-personalization uses CRM data to change the substance of the document: which case studies appear, how ROI is calculated, what integrations are highlighted, and how sections are ordered based on the buyer's pain points. ### Does hyper-personalization actually improve win rates? Yes. McKinsey reports that fast-growing companies drive 40% more of their revenue from personalization than slower-growing peers. Epsilon found that 80% of consumers are more likely to purchase when brands offer personalized experiences. ### How do I personalize proposals without breaking brand consistency? Use a template-driven approach with locked brand elements (logos, colors, fonts, legal disclaimers) and editable content zones for personalization. TurboDocx's templating system enforces brand guardrails while allowing infinite content variations per deal. ### What CRM data should I use for document personalization? Start with industry/vertical, company size, decision-maker role, pain points from discovery calls, existing tech stack, and deal stage. These six fields alone can transform a generic proposal into one that feels handcrafted. ### Can I automate hyper-personalized proposals with TurboDocx? Yes. TurboDocx connects to your CRM (Salesforce, HubSpot, and others) and uses conditional logic, dynamic image swapping, and variable-driven content blocks to generate fully personalized DOCX, PDF, and PPTX documents in seconds. No manual assembly required. ## Related Resources - [Sales Automation Guide](https://www.turbodocx.com/resources/sales-automation-guide.md): The full pipeline from lead to signed contract, including CRM-driven document generation. - [Why Sales Teams Hate Proposals](https://www.turbodocx.com/blog/why-sales-teams-hate-proposals.md): The copy-paste pain, the version chaos, and how to fix it with automation. - [Salesforce Proposal Automation](https://www.turbodocx.com/resources/salesforce-proposal-automation.md): Streamline your Salesforce workflows with automated proposal generation. - [Complete Guide to Document Automation](https://www.turbodocx.com/blog/a-complete-guide-to-document-automation.md): Everything you need to know about automating document creation with TurboDocx. ## Stop Sending Generic Proposals Your buyers expect documents that speak their language, reference their challenges, and show their numbers. TurboDocx makes that happen at scale. Every document personalized, every brand element protected, every deal moving faster. [Book a demo](https://www.turbodocx.com/demo) or read the [Sales Automation Guide](https://www.turbodocx.com/resources/sales-automation-guide.md). --- --- title: "Vibe-Coded a Signable Invoice App in 12 Minutes | TurboDocx" description: "I built a working signable invoice app in about 12 minutes using Lovable and the TurboDocx Quickstart Skill: just three prompts and zero traditional dev work." url: "https://www.turbodocx.com/blog/i-built-a-signable-invoice-app-with-lovable" --- # I Vibe-Coded a Signable Invoice App in About 12 Minutes > No traditional development. Just Lovable, three plain-English prompts, and the TurboDocx Quickstart Skill. By the end I had an invoice generator that produces a signable PDF and emails it for signature. Here is the full play-by-play. By Alex Martinez (Developer Relations & Automation Lead). Published June 9, 2026. 8 min read. Category: AI for Developers. Built with Lovable + TurboDocx. I wanted to see how far a single sitting could go. The goal was simple to say and historically annoying to build: an invoicing app that produces a PDF with a real signature field, then emails that invoice to a client so they can sign it. No starter template, no SDK archaeology, no afternoon lost to documentation. Just describe what I wanted and let the AI build it. That describe-it-and-let-the-AI-write-it loop is exactly what vibe coding is. It gets dismissed as a way to ship disposable frontends, but it shines on the work developers least enjoy: forms, file generation, and integration plumbing. A signable invoice app is all three. I used [Lovable](https://lovable.dev) for the app itself (see [the full Lovable review](https://www.turbodocx.com/blog/lovable-review.md) for a deeper look at the tool) and [the TurboDocx Quickstart Skill](https://www.turbodocx.com/quickstart.md) to teach it how to send documents for signature. Total time, start to working app: about 12 minutes. ## The short version of vibe coding Vibe coding means you describe the outcome you want in plain language and an AI agent writes the code. You stay in the loop as the editor, not the typist. The skill is in choosing the right prompts and reviewing what comes back, which is why this works best when the agent has ground truth for the tricky parts. For document signing, that ground truth comes from the Quickstart Skill: it gives the agent the exact install command, the real SDK surface, and the conventions to follow, so it does not guess at method names or hardcode secrets. The same Quickstart Skill is agent-agnostic, so if you prefer a code-first editor you can [vibecode an e-signature flow in Claude Code or Cursor](https://www.turbodocx.com/blog/vibecode-an-esignature-flow.md) with the identical prompts. ## The build, prompt by prompt Here is the actual timeline from June 8. Three user prompts, one self-healing hiccup in the middle, and a finished app at the end. Notice that the whole thing reads like a conversation, not a coding session. 1. **4:45 PM, Prompt 1.** Me: "Build a basic invoicing app that gives me a PDF with a signable field". Lovable scaffolded an invoice form plus a generated PDF with interactive signature and date fields that a recipient can sign in any PDF viewer. 2. **4:46 PM, Prompt 2.** Me: "Then use the TurboDocx Quickstart skill: npx skills add TurboDocx/quickstart". TurboSign got wired in. The app now takes a signer name and email, and a "Send for signature" button emails the invoice through the TurboDocx API. 3. **~4:50 PM, Automatic event (no prompt).** Vite dependency-optimizer hiccup. No user action needed. Lovable self-healed: it restarted the dev server on its own and the build continued without intervention. 4. **~4:55 PM, Prompt 3.** Me: "I see it says under review, can you skip the review step and go straight to the full send?". Done in one prompt. The app now calls sendSignature directly instead of createSignatureReviewLink, so the email goes out immediately. That is the entire build: three prompts, about 12 minutes, a production-ready signable invoice app. The middle row is worth calling out because it is the kind of thing that derails a manual project. A Vite dependency-optimizer hiccup popped up, and instead of stopping to ask me, Lovable restarted the dev server itself and carried on. No copy-pasting a stack trace into a search bar. ## How the TurboDocx integration actually works The second prompt did the heavy lifting. By pointing Lovable at the Quickstart Skill, I gave it a single command to teach itself everything it needed about signing: ```bash npx skills add TurboDocx/quickstart ``` That installs an open Agent Skill through the `skills` CLI. The skill gives the agent the real TurboSign SDK surface and reads credentials from environment variables instead of baking them into source. For this app the values were: ```bash TURBODOCX_API_KEY=your_api_key_here TURBODOCX_ORG_ID=your_org_id_here TURBODOCX_SENDER_EMAIL=you@company.com TURBODOCX_SENDER_NAME=Your Company Name ``` Grab those from a free account at [app.turbodocx.com](https://app.turbodocx.com) (your first 5 signatures each month are free). Behind the "Send for signature" button, TurboSign takes the generated invoice PDF, sends it to the signer's email, and collects the signature on hosted infrastructure. If you want the longer walkthrough, here is [the step-by-step TurboDocx and Lovable integration guide](https://www.turbodocx.com/blog/turbodocx-lovable-integration-guide.md) and [adding e-signature to a Lovable app](https://www.turbodocx.com/blog/add-esignature-to-lovable.md) in detail. ## One prompt to skip the review step The first version of the send flow stopped at a review step, so the recipient saw an "under review" status before the email went out. I did not want that for invoices, where the point is to get the document in front of the client immediately. So I asked for the change in one sentence, and Lovable swapped the call: instead of `createSignatureReviewLink`, the app now uses `sendSignature` directly, which fires the email right away with no review gate. That is the kind of distinction you would normally only find after reading the API docs carefully. Here, it was a single follow-up prompt. ## What the finished app does The result is a small but complete invoice generator. You fill in the invoice details, the app produces a PDF with interactive signature and date fields, and you can download that signable PDF directly. Enter a signer name and email, click "Send for signature," and TurboSign emails the invoice for the client to sign. Three screens, one real workflow, and every signature handled by a hosted API rather than my Friday afternoon. If the PDF mechanics are new to you, [how signable PDFs work](https://www.turbodocx.com/blog/signable-pdfs-explained.md) and [what an electronic signature is](https://www.turbodocx.com/blog/what-is-an-electronic-signature.md) are good primers, and [e-signatures for invoices](https://www.turbodocx.com/blog/esignature-for-invoices.md) covers why this matters for getting paid. ## What this means if you are not a developer The headline is not that I saved a few hours. It is that someone who cannot write a line of code could have run the same three prompts and gotten the same app. To put the 12 minutes in context, a from-scratch build would realistically run a few days once you add up the moving parts. As an illustrative estimate, not a measured benchmark: - Pick and read an e-signature SDK, set up an account, find the API key flow (half a day) - Build the invoice form and a PDF generator with real signature fields (a day or two) - Wire the send flow, handle the review-vs-direct-send distinction, test emails (another day) For a realistic deep dive on those numbers, see [how long it actually takes](https://www.turbodocx.com/blog/how-long-to-build-an-esignature-app.md) to build a signing app from scratch. The point of vibe coding is that the same outcome arrives in minutes because the AI handles the form, the PDF, and the integration while you stay focused on the result. You can see the whole approach in [add e-signatures to invoices without code](https://www.turbodocx.com/blog/add-esignatures-to-invoices-without-code.md) and [the no-code e-signature stack](https://www.turbodocx.com/blog/no-code-esignature-stack.md). A fair caveat: signatures are legal instruments, so the parts that need human judgment still need it. Read the diff, confirm the right people sign in the right order, and handle the decline and expiry cases, not just the happy path. [Vibe coding legal documents](https://www.turbodocx.com/blog/vibe-coding-legal-documents.md) covers where the AI build ends and careful review begins. The compliance heavy lifting (tamper-evident audit trails, ESIGN, UETA, and eIDAS alignment) runs on TurboDocx infrastructure, which you can read about in the [US e-signature compliance](https://www.turbodocx.com/resources/us-esignature-compliance.md) and [European compliance](https://www.turbodocx.com/resources/european-esignature-compliance.md) guides, and on the [e-signature API](https://www.turbodocx.com/e-signature-api.md) overview. Want to try the exact build yourself? Open your AI app builder, install [the TurboDocx Quickstart Skill](https://www.turbodocx.com/quickstart.md), and use the same three prompts. The Lovable project from this run lives at [this Lovable project link](https://lovable.dev/projects/94d5cbef-a38d-4e0a-96fa-cb682eb294a2) if you want a reference point. ## Read the full series This build is the hub for a deeper set of guides on vibe coding signable documents. Pick a thread. - [The Full Lovable Review](https://www.turbodocx.com/blog/lovable-review.md): A hands-on look at what Lovable does well and where it needs a human. - [TurboDocx + Lovable Integration Guide](https://www.turbodocx.com/blog/turbodocx-lovable-integration-guide.md): The step-by-step setup, from API key to first signed invoice. - [Add E-Signature to a Lovable App](https://www.turbodocx.com/blog/add-esignature-to-lovable.md): Drop signing into any Lovable project with one Quickstart command. - [Add E-Signatures to Invoices Without Code](https://www.turbodocx.com/blog/add-esignatures-to-invoices-without-code.md): The no-code path to signable invoices for non-developers. - [The No-Code E-Signature Stack](https://www.turbodocx.com/blog/no-code-esignature-stack.md): The tools that turn a prompt into a working signing flow. - [E-Signatures for Invoices](https://www.turbodocx.com/blog/esignature-for-invoices.md): Why putting a signature field on an invoice changes how you get paid. - [How Signable PDFs Work](https://www.turbodocx.com/blog/signable-pdfs-explained.md): What actually makes a PDF signable, in non-technical terms. - [What an Electronic Signature Is](https://www.turbodocx.com/blog/what-is-an-electronic-signature.md): The basics of e-signatures and what makes one count. - [How Long It Actually Takes](https://www.turbodocx.com/blog/how-long-to-build-an-esignature-app.md): A realistic look at building a signing app from scratch. - [Vibe Coding Legal Documents](https://www.turbodocx.com/blog/vibe-coding-legal-documents.md): Where the AI build ends and careful review begins. ## Related Resources - [TurboDocx Quickstart Skill](https://www.turbodocx.com/quickstart.md): One command to teach your AI builder how to send for signature. - [API and SDK](https://www.turbodocx.com/products/api-and-sdk.md): The building blocks behind TurboSign and document generation. ## Build your own signable invoice app Install the Quickstart Skill, open your AI app builder, and run the same three prompts. Your first 5 signatures each month are free. [Install the Quickstart Skill](https://www.turbodocx.com/quickstart.md) Lovable is a trademark of its respective owner. TurboDocx is an independent product and is not affiliated with or endorsed by Lovable. --- --- title: "Install the TurboDocx SDK via Agent Skill | TurboDocx" description: "Drop TurboSign, TurboPartner, or @turbodocx/html-to-docx into any project in one prompt. The Quickstart Agent Skill works with Claude Code, Cursor and more." url: "https://www.turbodocx.com/blog/install-turbodocx-sdk-via-ai-agent-skill" --- # Install the TurboDocx SDK in one prompt with the Agent Skill > Drop TurboSign, TurboPartner, or `@turbodocx/html-to-docx` into any project in one prompt. Works with Claude Code, Copilot, Cursor, OpenCode, Codex CLI, and Gemini CLI. By Alex Martinez (Developer Relations & Automation Lead). Published May 11, 2026. 6 min read. Category: Developer Productivity. Install both skills in any project: ```bash npx skills add TurboDocx/quickstart ``` If you have ever added an SDK to a project, you know the rhythm: open the docs, copy the install command, find the right place for the client, hunt down environment variables, write the first route, run it, fix a typo. None of those steps are hard. They are just *tax*, time you pay before you can do the actual work. Today we are open-sourcing the [TurboDocx Quickstart Skill](https://github.com/TurboDocx/quickstart), an [Agent Skill](https://agentskills.io) that pays the tax for you. Hand it to your AI coding agent and it installs the SDK, configures the environment, and writes a working integration that matches your existing code style. It works with Claude Code, GitHub Copilot in VS Code, Cursor, OpenCode, OpenAI Codex CLI, and Gemini CLI. One install command, six tools. ## What is an Agent Skill? Agent Skills are a portable format for AI agent capabilities. A skill is just a folder of instructions and reference material that an agent can load on demand. When your agent sees a skill matches the user's request, it follows the skill's instructions step by step. The TurboDocx skill lives at [github.com/TurboDocx/quickstart](https://github.com/TurboDocx/quickstart). The format is the open standard from [agentskills.io](https://agentskills.io), so the same skill works across every supported agent without modification. **Why we chose Agent Skills over a CLI generator:** a generator gives you scaffolding at one moment in time. A skill follows the agent into the conversation and can reason about *your* codebase (where your routes live, how you load config, whether you use TypeScript or plain JS) and produce code that matches. ## The two skills | Skill | What it does | Languages | Frameworks | | --- | --- | --- | --- | | `turbodocx-sdk` | TurboSign (e-signature) + TurboPartner (partner/org management) | JavaScript / TypeScript, Python, Go, PHP, Java | Express, Next.js, Fastify, NestJS, FastAPI, Flask, Django, Spring Boot, Laravel, Gin, Echo, and others | | `turbodocx-html-to-docx` | Convert HTML strings to Microsoft Word documents | JavaScript / TypeScript (Node.js and browser) | Express, Next.js (API routes), Fastify, NestJS, static HTML, Vite, Webpack | ## Install The `npx skills` CLI from [vercel-labs/skills](https://github.com/vercel-labs/skills) auto-detects which agents you have installed and drops the skills into the right place. From the root of any project: Both skills (recommended): ```bash npx skills add TurboDocx/quickstart ``` Just the SDK skill: ```bash npx skills add TurboDocx/quickstart --skill turbodocx-sdk ``` Just the html-to-docx skill: ```bash npx skills add TurboDocx/quickstart --skill turbodocx-html-to-docx ``` Globally, available in every project: ```bash npx skills add TurboDocx/quickstart -g ``` Claude Code users can also install via the plugin command: `claude plugin add turbodocx/quickstart`. ## Supported agents - Claude Code - GitHub Copilot (VS Code) - Cursor - OpenCode - OpenAI Codex CLI - Gemini CLI Plus any other tool that supports the Agent Skills standard. The CLI knows where each agent stores its skills and routes the install accordingly. ## What it generates After install, invoke the skill in your editor or terminal: ``` /turbodocx-sdk ``` ### TurboSign integration - SDK client configured with environment variable loading - `sendSignature()` helper that sends documents for legally-binding e-signature - `getStatus()` helper that checks document and recipient state - A route handler wired into your existing application ### TurboPartner integration - Partner client configured with environment variables - `createOrganization()` helper that provisions customer orgs - `listOrganizations()` helper that lists managed organizations - A route handler wired into your existing application ### `@turbodocx/html-to-docx` integration - Helper module that matches your framework (Express, Next.js API route, Fastify, NestJS, etc.) - A working endpoint that returns a `.docx` response - For static HTML projects, the polyfilled ` ``` If you already own the iframe, use the pure handler. It holds the same origin and source checks the components use, without rendering anything. ```tsx import { handleTurboSignMessage } from '@turbodocx/embed'; const iframe = document.querySelector('iframe#signing') as HTMLIFrameElement; window.addEventListener('message', (event) => { handleTurboSignMessage(event, { expectedOrigin: 'https://app.turbodocx.com', expectedSource: iframe.contentWindow, // reject forged messages from other frames onCompleted: ({ documentId }) => console.log('Signed:', documentId), }); }); ``` ## Want signing that fits your product without building it? The widget is the fast path for a dev team. If you would rather have the whole flow (document generation, signer verification, the embedded step, and the write-back into your systems) built and maintained for you, our team does that as part of your subscription. [Book a demo](https://www.turbodocx.com/demo). ## Related - [Embed Signing with createSigningUrl](https://www.turbodocx.com/guides/embed-signing-with-createsigningurl.md) (server side): Mint signing URLs for existing documents, and use redirect or new-tab placement instead of an iframe. - [Embedded E-Signature](https://www.turbodocx.com/embed-electronic-signature.md) (overview): What embedded signing looks like in your product, the integration options, and pricing. - [Signer Identity Verification](https://www.turbodocx.com/electronic-signature-identity-verification.md) (security): Email and SMS passcodes, your own identity provider, or an explicit override, per recipient. - [E-Signature API](https://www.turbodocx.com/e-signature-api.md): Send, track, and download signed documents with the REST API and 5 server SDKs. ## Resources - [Embedded Signing docs](https://docs.turbodocx.com/docs/TurboSign/embedded-signing): Request and response reference for signing URLs and verification modes. - [Runnable example app](https://github.com/TurboDocx/SDK/tree/main/examples/embedded-web-app): Widget, raw iframe, and sequential in-person signing paths side by side. - [TurboDocx open source](https://www.turbodocx.com/products/open-source.md): Every MIT-licensed package we publish, including @turbodocx/embed. ## Frequently Asked Questions ### How do I embed an e-signature in a React app? Allow-list your app origin in the TurboSign E-Signature settings, mint a per-recipient embed URL on your server with TurboSign.createEmbeddedSignature, then render `` from @turbodocx/embed/react. The component frames the signing page, checks every message against the pinned origin and its own iframe, and calls onCompleted when the signer finishes. ### Why does onCompleted never fire? Almost always it is one of two settings. First, the origin prop: if it is missing or empty, the component fails closed and ignores every message, with a one-time console warning. Set it to your TurboSign origin, for example https://app.turbodocx.com. Second, the embedding domain: if your app origin is not in Allowed embedding domains, the signing page will not render in the iframe at all, so there is nothing to complete. ### Does onCompleted mean the whole document is signed? No, only that recipient. The completion payload carries scope: "recipient", which means this signer finished their step. On a multi-signer document other recipients may still be pending, so confirm the document status on your server with TurboSign.getStatus or listen for the signature.document.completed webhook before you treat the agreement as fully executed in your system. ### Can I use @turbodocx/embed without React? Yes. The `` custom element works in plain HTML, Vue, Angular, Svelte, or any framework that renders DOM, and dispatches a bubbling turbosign:completed event. For full control, keep your own iframe and call the pure handleTurboSignMessage function from your message listener, passing the expected origin and the iframe contentWindow. ## Put signing inside your app this week Create a free account, allow-list your origin, and render your first embedded signing step. [Get API key free](https://app.turbodocx.com) or [book a demo](https://www.turbodocx.com/demo). --- --- title: "How to Embed Signing with createSigningUrl | TurboDocx" description: "Generate an embedded signing URL with createSigningUrl: allow-list your domain, create the request, verify the signer, then mount the URL in an iframe." url: "https://www.turbodocx.com/guides/embed-signing-with-createsigningurl" --- # How to Embed Signing with createSigningUrl > In five steps, you allow-list your domain, create an embedded request with `createEmbeddedSignature`, verify the signer, then call `createSigningUrl` to get a signing URL and mount it in an iframe, redirect, or new tab. No signing-request email is sent. The signer stays inside your product and is verified before the document opens. Developer Guide by Amit Sharma (Software Engineer, Backend Architecture at TurboDocx). Published September 18, 2026. Updated October 7, 2026. Quick install: [Agentic Quickstart Skill](https://www.turbodocx.com/quickstart.md), `npx skills add TurboDocx/quickstart`. - **10 min** setup time - **3 modes**: iframe, redirect, or new tab - **5 min**: single-use link for external identity verification Links: [GitHub SDK](https://github.com/TurboDocx/SDK/tree/main/packages/js-sdk) and [Identity Verification](https://www.turbodocx.com/electronic-signature-identity-verification.md). ## Key takeaways - Add each https origin to the allow-list first. The signing page will not render in an iframe on any domain you have not added. - No signing-link emails go out by default: createEmbeddedSignature sets sendEmail to false, so the signer only signs inside your app. - Passcode and unverified signers get a reusable link that is valid until the document expires. - Signers verified by your own identity provider get a single-use link that expires after 5 minutes, and minting a new one revokes the old one. **SDK versions:** the method names below are the embedded-signing surface of the TurboDocx SDK. Confirm the exact parameters for your SDK version against the [SDK reference](https://docs.turbodocx.com/docs/SDKs/javascript). ## Step 1: Allow-list your embedding domain Embedding is deny-by-default. The signing page refuses to render in an iframe until you add your app's exact `https` origin to your allowed embedding domains in your [embedded e-signature](https://www.turbodocx.com/embed-electronic-signature.md) settings. This is the clickjacking control, so nothing can frame the signer's screen without your say-so. An organization admin opens Settings, Features and integrations, Configure E-Signature, selects Identity Verification, then the Identity & embedding tab, and adds the origin under Allowed embedding domains, pressing Enter after each one. Allowed embedding domains lives on the Identity & embedding tab of the E-Signature settings, alongside "Allow external identity verification" and "Allow identity verification override". ```text https://app.yourcompany.com ``` **Local dev only:** you may add an `http://localhost` origin to test, but remove every `http://` origin and use `https` before production. ## Step 2: Create an embedded signature request Call `createEmbeddedSignature` from your backend. Unlike `sendSignature`, it sends no signing-link email by default, and it returns a `recipientId` for each signer plus an `embedUrl` for whoever can sign now. Keep your API key on the server; it must never reach the browser. ```typescript import { TurboSign } from '@turbodocx/sdk'; import { readFileSync } from 'fs'; TurboSign.configure({ apiKey: process.env.TURBODOCX_API_KEY, orgId: process.env.TURBODOCX_ORG_ID, senderEmail: process.env.TURBODOCX_SENDER_EMAIL, senderName: process.env.TURBODOCX_SENDER_NAME, }); // createEmbeddedSignature sends no signing-link email (sendEmail defaults to false). const { documentId, recipients } = await TurboSign.createEmbeddedSignature({ file: readFileSync('contract.pdf'), documentName: 'Order Form', recipients: [ { name: 'John Doe', email: 'john@example.com', auth: { emailOtp: true }, // step 3: passcode before the document opens fields: { signature: '{signature1}', date: '{date1}' }, }, ], }); const { recipientId, embedUrl, status } = recipients[0]; // status 'ready' means embedUrl is set and can be mounted now (step 5). ``` ### Developer resources - Drop the signing page into your app with the React widget: ```bash npm install @turbodocx/embed ``` ```tsx import { TurboSignForm } from '@turbodocx/embed/react'; markSigned(documentId)} /> ``` - Complete embedded signing sample app: four working flows (the widget, your own iframe, external identity verification, and a kiosk). Clone it and run it locally. [View on GitHub](https://github.com/TurboDocx/SDK/tree/main/examples/embedded-web-app). - Read the docs: [React widget](https://docs.turbodocx.com/docs/TurboSign/embedded-signing/react-widget), [Requesting a signing URL](https://docs.turbodocx.com/docs/TurboSign/embedded-signing/reference#requesting-a-signing-url). - Packages: [@turbodocx/embed](https://www.npmjs.com/package/@turbodocx/embed), [@turbodocx/sdk](https://www.npmjs.com/package/@turbodocx/sdk). ## Step 3: Verify the signer Choose how to confirm the signer. For a one-time passcode, set `auth` on the recipient: email or SMS. The signing page asks for the code before the document opens. Either way, the method is recorded on the certificate of completion. Compare every method under [e-signature identity verification](https://www.turbodocx.com/electronic-signature-identity-verification.md). Passcodes are enabled on the One-time passcode tab of the E-Signature settings. With "Only when requested" selected, the passcode applies to the recipients whose request asks for it, such as an embedded request with auth set. SMS must be allowed there, with your SMS provider connected, before you use auth.sms. ```typescript auth: { emailOtp: true } // email passcode auth: { sms: { phoneNumber: '+13055551234' } } // SMS passcode // omit auth to use your organization's default channel ``` Already verify signers with your own identity provider? Create the recipient with `sendSignature`, `sendEmail: false`, and `identityVerification: { mode: 'external_idv', provider }`, then pass the assertion in step 4. The [bring your own identity verification](https://www.turbodocx.com/resources/bring-your-own-identity-verification-esignature.md) walkthrough covers every field and check. ## Step 4: Request a signing URL with createSigningUrl Call `createSigningUrl` with the document id and recipient whenever you need a URL: the signer comes back later, it becomes the next signer's turn, or the signer is externally verified. What you get depends on how the signer is verified: - **Passcode or no verification:** the signer's reusable `?token=` link. It stays valid until the document expires (`expiresAt` is the document's expiry, or null), and the passcode gate still applies. - **External identity verification (or an admin-enabled override):** a single-use `?sut=` link that expires 5 minutes after it is issued. It opens once, and minting a new one revokes the previous link, so request it at the moment of signing. ```typescript // Passcode or no verification: returns the reusable signing link. const { url, expiresAt, pendingChecks } = await TurboSign.createSigningUrl(documentId, { recipientId, returnUrl: 'https://app.yourcompany.com/signed', }); // pendingChecks: ['email_otp'] tells you the page will ask for a passcode. // external_idv recipient: assert what your own identity provider verified. // Returns a single-use URL that expires 5 minutes after issue. const { url: verifiedUrl } = await TurboSign.createSigningUrl(documentId, { recipientId, identityAssertion: { provider: 'your-idv-vendor', // must match the recipient's provider verificationId: idvResult.id, verifiedAt: idvResult.completedAt, // ISO 8601 subjectEmail: 'john@example.com', // must match the recipient's email }, returnUrl: 'https://app.yourcompany.com/signed', }); ``` ## Step 5: Mount the signing URL Send the URL to the browser and open it one of three ways. Use an iframe for a fully in-app experience, a redirect for the simplest integration, or a new tab when you want the signer to keep your app open behind them. ```tsx // 1) Iframe: signer never leaves your app