Solanasis Docs

documenso-esignature-playbook-solanasis (1)

15 min read

Solanasis E-Signature Landscape + Documenso AI Automation Playbook

Last updated: 2026-03-11

Purpose

This document is a handoff playbook for another AI or coding agent. It summarizes the current e-signature landscape for a bootstrapped team, explains why Documenso is the strongest long-term fit for Solanasis, and outlines how to use it with AI-generated PDFs and low-touch agreement workflows.

Executive Summary

Best choices by phase

Phase 0: Free, low-volume, minimal setup, no API required yet

  • OpenSign is the most attractive free/manual option.
  • Its free model allows unlimited signing/storage, but limits monthly invitation emails; you can work around that by copying the signing link and sending it from your own email.
  • Good when you want “almost free” and are willing to keep one small manual step.

Phase 1: Real automation with AI-generated PDFs

  • Documenso self-hosted Community Edition is the best strategic fit.
  • Why: it is open source, self-hostable, has documented API support for self-hosted base URLs, and does not appear to impose the same “pay to use API on your own infrastructure” gate that OpenSign and DocuSeal do.
  • Tradeoff: it is more ops-heavy than OpenSign and DocuSeal.

Phase 2: Fastest path to production if you decide not to self-host

  • Documenso Cloud is a good migration path because the same product family supports API, direct links, webhooks, templates, and self-hosting.
  • Free cloud accounts include API access but only 5 documents/month, so it is useful for proving the workflow before moving to self-hosting or a paid plan.

Market Landscape: What Actually Matters

For Solanasis, the real decision is not “which e-sign product is best.” It is:

  1. Can Claude Code or another agent upload generated PDFs and drive the workflow?
  2. Can we avoid high recurring SaaS cost?
  3. Can we self-host later without getting trapped by feature gating?
  4. Can we still use a simpler free/manual path in the meantime?

Three lanes in the market

1) Incumbents

Examples: DocuSign, Adobe Acrobat Sign, Dropbox Sign.

These are legally familiar and polished, but usually the wrong fit for a scrappy shop because pricing is worse and API access is usually not generous.

2) Cloud SMB/API tools

Examples: SignWell, Zoho Sign, PandaDoc, BoldSign.

These are better than incumbents if you want hosted convenience, but they still tend to meter documents and API usage.

3) Open-source / self-hosted tools

Examples: OpenSign, DocuSeal, Documenso.

This is the category most relevant to Solanasis.

Current Recommendation Stack

OpenSign

Use this when:

  • you want more than 3 docs/month
  • you want to spend as close to zero as possible
  • you are okay with one manual step
  • API is not required yet

Why it works:

  • Free positioning is strong.
  • Manual link-sharing lets you stretch the free tier.
  • Good fit for early-stage “generate PDF, upload, copy link, send from Gmail” workflows.

Why it is not the long-term recommendation:

  • The free self-hosted version does not support API token generation.
  • Live API/webhooks are tied to paid access.

Documenso self-hosted Community Edition

Use this when:

  • you want AI-driven document upload and sending
  • you want control of your own infrastructure and data
  • you want to avoid per-document API tax on your own server
  • you want a tool that can start simple and later become a real signing backend

Why this is the strongest fit:

  • Self-hosting is officially supported.
  • API docs explicitly support self-hosted base URLs.
  • The Community Edition includes core signing functionality and can be self-hosted.
  • Official authentication docs state the API is available on all plans and provide self-hosted base URLs.
  • Public user feedback specifically calls out Documenso as easier/better than OpenSign for self-hosted API use.

Good but not ideal

DocuSeal self-hosted

Why it is still relevant:

  • Easier/simpler self-host than Documenso.
  • Good if you want the quickest deployment.

Why it is not the top recommendation:

  • API and embedding pricing are charged per signed document even in self-hosted scenarios.
  • This creates the exact “vendor tax on my own server” problem many self-hosters hate.

Decision Matrix

NeedBest OptionWhy
Free now, low admin, no APIOpenSignBest free/manual value if you can send links yourself
Fastest hosted proof-of-concept with APIDocumenso Cloud FreeAPI available, 5 docs/month, same ecosystem as self-host
Long-term self-hosted signing backendDocumenso CEBest alignment with AI workflow + control
Simplest self-host install if willing to pay API taxDocuSealOperationally lighter, commercially less attractive

Why Documenso Is the Best Strategic Fit for Solanasis

1) It aligns with AI-native operations

Your real use case is not generic e-signature. It is:

  • AI generates agreement PDFs
  • AI or backend uploads them
  • recipients get a signing link or email
  • completion status comes back via webhook
  • signed PDF + audit trail are archived automatically

Documenso is unusually well-positioned for this because it already thinks in terms of:

  • API-driven document creation
  • recipients and fields
  • templates/direct links
  • webhooks
  • self-hosting

2) It supports a phased rollout

You do not need to solve everything on day one.

You can phase it like this:

Phase A — Manual / proof-of-concept

  • Use OpenSign or Documenso Cloud Free.
  • Human uploads PDF and sends.

Phase B — AI-assisted but still low-touch

  • Claude Code generates the PDF and saves it locally.
  • A small script uploads to Documenso.
  • Human reviews metadata/recipients before final send.

Phase C — Fully automated send + archive

  • Agent generates PDF.
  • Backend uploads it to Documenso.
  • Backend distributes it.
  • Webhook updates CRM/project system.
  • Signed PDF is stored in your document repository.

3) It avoids a likely future migration

If you start with a random hosted tool today and later need self-hosting/API control, you risk redoing everything. Documenso reduces that risk because the cloud and self-hosted story are connected.

Key Documenso Facts That Matter

API

  • The documented production base URL is https://app.documenso.com/api/v2.
  • Self-hosted instances use https://your-domain.com/api/v2.
  • API V1 is deprecated; V2 is the current target for new integrations.
  • API tokens have full account access; there is currently no scoped-token model.

Community Edition / Self-hosting

  • Community Edition is AGPL-3.0 and includes core document-signing functionality.
  • Self-hosting is officially supported.
  • Minimum prerequisites include PostgreSQL 14+, SMTP/email provider credentials, domain, SSL, and a signing certificate.

Signing certificate requirement

  • Self-hosted Documenso requires an X.509 signing certificate in .p12 form.
  • A self-signed certificate is acceptable for many ordinary business use cases.
  • Tradeoff: Adobe Acrobat may not show a full trust checkmark, and recipients may see a validation warning if the cert is self-signed.
  • Direct links are a powerful low-friction option for repeat agreements.
  • They work on templates, not individual one-off documents.
  • You can share a link and let the signer fill in name/email and sign.
  • This is useful for standard NDAs, intake forms, or approval documents.

Webhooks

  • Documenso supports webhooks for events like document completion.
  • This is key for CRM updates, internal notifications, and automatic archiving.

Risks / Caveats With Documenso

1) API tokens are high-trust

There are no scoped tokens right now. That means any token you give to an AI agent or integration effectively has broad account access.

Mitigation

  • Use a dedicated Documenso team/account just for automation.
  • Use separate tokens per integration.
  • Set expiration dates.
  • Rotate tokens.
  • Restrict where the token lives.
  • Put the token behind your own thin backend if possible, instead of handing it directly to every agent.

2) Self-hosting is not zero-effort

Documenso is stronger strategically, but it is not the easiest app in the world to self-host. Recent user feedback shows some people still struggle with self-hosting configuration.

Mitigation

  • Start in a disposable staging environment.
  • Use Docker Compose.
  • Get SMTP and certificate handling sorted early.
  • Keep reverse proxy/TLS simple.

3) Certificate trust and recipient perception

A self-signed certificate is cheap, but recipients opening the signed PDF in Acrobat may see the signature as untrusted. That does not necessarily make the agreement invalid, but it may look less polished.

Mitigation

  • For internal or ordinary service agreements, self-signed may be acceptable.
  • If client perception matters, buy a CA-issued signing certificate later.

Best near-term architecture

flowchart LR
    A[Claude Code or AI agent] --> B[Generate agreement PDF]
    B --> C[Local staging folder]
    C --> D[Small upload/send script]
    D --> E[Documenso API]
    E --> F[Recipient gets Documenso email OR Solanasis sends signing URL]
    E --> G[Webhook endpoint]
    G --> H[Update CRM / PM system / log]
    G --> I[Archive signed PDF + audit trail]

Why this is the right shape

  • Claude Code should not be the only thing holding secrets and business logic.
  • Let Claude Code generate the PDF and trigger a controlled script or internal API.
  • Keep the Documenso API key on your backend or orchestration layer when possible.

Two Good Operational Patterns

Pattern 1 — Agent-assisted, human-approved send

Best early production pattern.

Flow

  1. Claude Code generates the agreement PDF.
  2. Script uploads draft to Documenso.
  3. Human reviews recipients/title/message.
  4. Human clicks send, or script sends after approval.
  5. Signed result is archived automatically.

Why this is smart

  • Lower risk.
  • Lets you validate field placement and recipients.
  • Reduces chance of an agent sending the wrong document.

Pattern 2 — Full backend automation

Best once your templates and logic are stable.

Flow

  1. Agent generates PDF from approved template/data.
  2. Backend creates document via API.
  3. Backend distributes immediately.
  4. Signing URLs are logged and optionally emailed through your own mail system.
  5. Webhook marks completion and stores final artifacts.

Why this is smart

  • Very low admin load.
  • Easy to integrate with CRM/project workflows.
  • Makes Documenso a real signing backend.

Exact AI/API Workflow With Documenso

Core API lifecycle

Step 1: Generate the PDF

Claude Code or another agent produces a PDF agreement locally.

Recommended practice:

  • keep a stable filename convention
  • attach your own externalId / contract ID
  • preserve a JSON sidecar with metadata

Example metadata:

{
  "externalId": "sol-msa-2026-00017",
  "clientName": "Example Client LLC",
  "docType": "MSA",
  "owner": "dmitri",
  "sourceSystem": "claude-code",
  "createdAt": "2026-03-11T18:00:00Z"
}

Step 2: Upload the document to Documenso

Use POST /api/v2/envelope/create with multipart/form-data.

The payload can include:

  • title
  • external ID
  • recipients
  • fields
  • document meta (email subject/message/redirect URL)
  • the PDF file itself

Documenso docs also note support for placeholder scanning in uploaded PDFs, which can auto-create fields when the PDF contains supported placeholder patterns.

Step 3: Distribute for signing

Call POST /api/v2/envelope/distribute.

This moves the document from DRAFT to PENDING and returns recipient signing URLs.

Step 4: Delivery strategy

You have two options:

Option A — Let Documenso email recipients

Good for simplicity.

Option B — Use the returned signingUrl yourself

Good when you want:

  • emails to come from your own mailbox/domain/process
  • custom follow-up logic
  • a cleaner AI-orchestrated workflow

This second option is especially attractive for Solanasis.

Step 5: Receive completion events

Configure a webhook endpoint to receive events such as DOCUMENT_COMPLETED.

Use this to:

  • update CRM/project records
  • trigger a “fully executed agreement received” task
  • archive signed PDF and certificate/audit artifacts
  • notify internal Slack/email

Step 6: Store final artifacts

Your system should persist:

  • original generated PDF
  • signed PDF
  • audit trail / completion metadata
  • recipient + send timestamps
  • webhook log

This makes client disputes much easier to handle.

Strong Recommendation: Use Your Own Email for Delivery Even With API

Even once the Documenso API is live, Solanasis may want to send the signing link from its own email stack rather than relying entirely on platform-generated invitation emails.

Why

  • Better brand continuity
  • Better control of email copy and tone
  • Easier integration with existing outreach/inbox habits
  • Lets you keep one consistent thread with the client

Practical model

  1. Backend creates/distributes Documenso document.
  2. Backend gets signingUrl.
  3. Your own email system sends the link in a normal human-looking email.
  4. Documenso still handles the secure signing experience and audit trail.

This is a very strong middle ground.

Best Documenso Use Cases for Solanasis

1) Standard service agreements

  • MSA
  • SOW
  • NDA
  • subcontractor agreement
  • assessment authorization

2) Repeatable template-based documents

  • security assessment authorization
  • disaster recovery verification scope approval
  • data migration authorization / assumptions signoff
  • AI implementation statement of work

Best for documents where the signer can initiate the action.

Examples:

  • inbound NDA
  • intake consent/authorization
  • partner referral agreement
  • simple independent contractor packet

Direct links are especially compelling for repeated agreements where you want minimal admin overhead.

Best Practices for Building the AI Integration

1) Do not let the agent directly own every secret

Prefer this:

  • AI creates document inputs
  • controlled script or backend performs signing-system actions

Avoid this:

  • raw Documenso token embedded in prompts, repos, or shared agent configs

2) Use external IDs aggressively

Every document should have a unique external ID from your own system.

Example:

  • sol-nda-2026-0004
  • sol-sow-2026-0018

This makes reconciliation across Documenso, CRM, and storage much easier.

3) Template aggressively

If a document repeats, make it a template. Do not reinvent field placement every time.

4) Keep a human approval checkpoint early on

Especially until:

  • recipient mapping is stable
  • field placement is reliable
  • email copy is finalized

5) Log every state transition

At minimum log:

  • draft created
  • distributed
  • recipient viewed (if available)
  • recipient signed
  • completed
  • archived

6) Separate environments

Have at least:

  • staging Documenso instance or team
  • production Documenso instance or team

Do not test against live client agreements.

Suggested Data Model for Solanasis

{
  "agreementId": "sol-sow-2026-0018",
  "documensoEnvelopeId": "envelope_abc123xyz",
  "clientId": "client_204",
  "projectId": "proj_581",
  "docType": "SOW",
  "status": "PENDING",
  "recipientEmails": ["ops@exampleclient.com"],
  "signingUrls": ["https://your-documenso-domain/sign/abc123xyz"],
  "createdBy": "claude-code",
  "createdAt": "2026-03-11T18:00:00Z",
  "completedAt": null,
  "storagePathOriginal": "contracts/original/sol-sow-2026-0018.pdf",
  "storagePathSigned": null
}

Example TypeScript Skeleton

Note: this is a practical starter pattern, not a complete production integration.

import fs from 'node:fs';
import FormData from 'form-data';
import fetch from 'node-fetch';
 
const BASE_URL = process.env.DOCUMENSO_BASE_URL!; // e.g. https://sign.solanasis.com/api/v2
const API_KEY = process.env.DOCUMENSO_API_KEY!;
 
async function createAndSendAgreement(pdfPath: string) {
  const form = new FormData();
 
  const payload = {
    title: 'Solanasis Service Agreement',
    externalId: 'sol-msa-2026-00017',
    recipients: [
      {
        name: 'Jane Client',
        email: 'jane@example.com',
        role: 'SIGNER',
        signingOrder: 1
      }
    ],
    meta: {
      subject: 'Please review and sign your agreement',
      message: 'Please review and sign at your earliest convenience.',
      redirectUrl: 'https://solanasis.com/thanks'
    }
  };
 
  form.append('payload', JSON.stringify(payload));
  form.append('files', fs.createReadStream(pdfPath));
 
  const createRes = await fetch(`${BASE_URL}/envelope/create`, {
    method: 'POST',
    headers: {
      Authorization: API_KEY
    },
    body: form as any
  });
 
  if (!createRes.ok) {
    throw new Error(`Create failed: ${createRes.status} ${await createRes.text()}`);
  }
 
  const created = await createRes.json();
  const envelopeId = created?.id || created?.data?.id;
 
  const sendRes = await fetch(`${BASE_URL}/envelope/distribute`, {
    method: 'POST',
    headers: {
      Authorization: API_KEY,
      'Content-Type': 'application/json'
    },
    body: JSON.stringify({ envelopeId })
  });
 
  if (!sendRes.ok) {
    throw new Error(`Distribute failed: ${sendRes.status} ${await sendRes.text()}`);
  }
 
  const distributed = await sendRes.json();
  return distributed;
}

Production hardening to add

  • schema validation on request/response
  • retry logic for transient failures
  • structured logging
  • secret isolation
  • webhook signature verification
  • storage/archival pipeline
  • human approval gate before distribute

Suggested Claude Code Role Split

What Claude Code should do

  • draft agreement text
  • generate structured data for the agreement
  • populate a template
  • generate the PDF
  • call your internal script/backend
  • update project records after response

What Claude Code should not directly own long-term

  • production Documenso API token everywhere
  • certificate material
  • raw SMTP credentials
  • all lifecycle logic without validation gates

Implementation Roadmap

Option A — Very scrappy now

  1. Keep using free/manual signing.
  2. Use OpenSign for links if you want zero spend.
  3. Standardize PDF generation and file naming.
  4. Build the storage/archive discipline first.

Option B — Best proof-of-concept for the future state

  1. Create a Documenso cloud free account.
  2. Validate PDF → API → distribute → signing URL → webhook → archive.
  3. Only after that, self-host Documenso.

Option C — Go straight to self-hosted Documenso

  1. Spin up staging with Docker Compose.
  2. Configure PostgreSQL, SMTP, TLS, and signing certificate.
  3. Generate a dedicated API token.
  4. Build upload/distribute/webhook/archive pipeline.
  5. Start with one document type (NDA or MSA).
  6. Template aggressively after the first few sends.

My recommendation

For Solanasis, the best sequence is:

  1. Prove the workflow on Documenso Cloud Free
  2. Then move to self-hosted Documenso
  3. Use OpenSign only if you need a zero-cost manual bridge meanwhile

That gets you speed now without locking you into a weaker architecture.

What Another AI Should Conclude

Strategic conclusion

Documenso is the best long-term e-signature backend for Solanasis because it best matches these priorities:

  • self-hosting
  • AI-generated PDFs
  • API-driven workflows
  • webhook-based automation
  • low long-term SaaS dependence

Tactical conclusion

If immediate spend must stay near zero and API can wait, use OpenSign manually. If the goal is to build the real automation path, prioritize Documenso and treat it as a signing backend, not just a UI tool.

Architecture conclusion

The correct architecture is not “Claude Code directly controls everything forever.” The correct architecture is:

  • AI generates documents and metadata
  • a controlled integration layer talks to Documenso
  • webhooks feed status back into your systems
  • signed artifacts are archived automatically

Source Notes / References

Official Documenso

Official OpenSign

Official DocuSeal

User-reported / community sentiment

Final Recommendation in One Sentence

Use OpenSign only as a temporary free/manual bridge; build toward Documenso as the long-term self-hosted signing backend for AI-generated agreements and automated status tracking.

Graph View