Send Existing PDFs for E-Signature from Claude Desktop (send_document_pdf Guide)

1. Why Pre-Existing PDFs Cannot Be Rewritten into Markdown

Signbee's CommonMark Markdown compiler (markdown parameter) is ideal when an AI agent drafts an NDA, consulting agreement, or statement of work from scratch. However, regulated industries—including private wealth management, commercial real estate, cross-border M&A, and enterprise procurement—frequently operate on strict, pre-engineered PDF documents.

Consider an institutional Asset Management Agreement or a statutory regulatory filing exported from Adobe InDesign or LaTeX. These documents contain vector company crests, complex multi-column fee schedules, watermarked backgrounds, exact pagination footers, and externally audited clause numbering. Asking an LLM like Claude 3.7 Sonnet or Claude 4 Opus to extract the text from that PDF and re-emit it as Markdown introduces three unacceptable risks:

• Visual & Brand Destruction: Re-rendering through Markdown strips custom corporate typography, dual-column layouts, embedded vector diagrams, and regulatory form boxes.
• Pagination & Cross-Reference Drift: Legal exhibits that reference “the fee table on Page 4, Section 3.2(b)” break if text reflow changes the page count.
• Token Exhaustion & Hallucination Risk: Re-emitting a 15-page legal PDF word-for-word consumes thousands of output tokens, adding 25–40 seconds of latency and risking subtle transcription omissions.

That is why Signbee ranks among the best e-signature APIs for developers in 2026: it treats binary PDF ingestion as a first-class citizen alongside Markdown compilation, without the complex envelope XML coordinates or high per-seat fees analyzed in our DocuSign API pricing guide.

2. The Golden Rule of Binary PDF Signing: Upload Unsigned Documents

When preparing pre-existing PDF agreements for dispatch through Claude and Signbee, one operational rule governs every workflow: the PDF file must be completely unsigned by both parties before sending. Do not paste a JPEG image of your signature into the PDF in Preview or Acrobat before calling Signbee, and do not pre-sign the PDF with a local X.509 certificate that locks the PDF object tree against page appends.

3. Comparing the 3 Direct PDF Ingestion Pathways in Claude

Why does Signbee offer three distinct ways to submit a binary PDF? Because an LLM agent cannot efficiently emit a 500KB Base64 string through its conversational token stream (a 500KB binary PDF expands to ~683,000 Base64 characters, which equates to roughly 175,000 LLM tokens—exceeding output token caps and costing dollars per call). Instead, you should always route the binary bytes around the LLM token generator using one of these three architectures:

4. Method 1: Local File Path via send_document_pdf in Claude Desktop

If you use Claude Desktop on macOS or Windows, configuring the official signbee-mcp server gives Claude direct access to the send_document_pdf tool. Add the following configuration to ~/Library/Application Support/Claude/claude_desktop_config.json (macOS) or %APPDATA%\Claude\claude_desktop_config.json (Windows):

// 1. ~/Library/Application Support/Claude/claude_desktop_config.json
{
  "mcpServers": {
    "signbee": {
      "command": "npx",
      "args": ["-y", "signbee-mcp"],
      "env": {
        "SIGNBEE_API_KEY": "signbee_live_your_secret_key_here"
      }
    }
  }
}

// 2. Tool Call Payload Generated by Claude Desktop when you prompt:
// "Send ~/Documents/Altezza-Asset-Management-Agreement.pdf to Jane Smith (jane.smith@example.com)"
{
  "tool": "send_document_pdf",
  "arguments": {
    "file_path": "/Users/andrei/Documents/Altezza-Asset-Management-Agreement.pdf",
    "title": "Asset Management Agreement — Altezza & Jane Smith",
    "sender_name": "Andrei Ptitsyn",
    "sender_email": "ap@altezza.org",
    "recipient_name": "Jane Smith",
    "recipient_email": "jane.smith@example.com",
    "expires_in_days": 7
  }
}

Crucial UX Detail: Drag-and-Drop Attachments vs. Local File Paths

Many power users initially drag a PDF into the Claude Desktop chat box and say, “Send this attached PDF via Signbee.” When you attach a file to the chat window, Claude Desktop uploads the file into Anthropic's cloud vision/text buffer so Claude can read its contents, but it does not tell local MCP servers where that file lives on your hard drive.

To ensure Claude Desktop both reviews the clauses and sends the exact binary PDF via send_document_pdf, include the local path in your prompt (or right-click the file in Finder and press Option + Command + C to copy its POSIX path):

5. Method 2 & Method 3: Cloud URLs (pdf_url) and Base64 (pdf_base64) in Python & TypeScript

When you add our claude-direct-pdf-signing-guide.md instructions to a Claude Project (under Project Knowledge or Custom Instructions) or run an agent inside Claude Code, Python, or a TypeScript backend, your code or agent calls POST https://signb.ee/api/v1/send directly.

Below are production-ready Python and TypeScript implementations covering both local Base64 encoding (pdf_base64) and presigned S3 / Cloudflare R2 URL ingestion (pdf_url), complete with strict %PDF magic-byte validation and plan size checks:

import base64
import os
from pathlib import Path
import requests

SIGNBEE_ENDPOINT = "https://signb.ee/api/v1/send"

def send_local_pdf_agreement(
    pdf_file_path: str,
    recipient_name: str,
    recipient_email: str,
    title: str = "Asset Management Agreement",
    sender_name: str = "Andrei Ptitsyn",
    sender_email: str = "ap@altezza.org",
    expires_in_days: int = 7,
    api_key: str | None = None,
) -> dict:
    resolved_key = api_key or os.environ["SIGNBEE_API_KEY"]
    raw_bytes = Path(pdf_file_path).expanduser().read_bytes()

    # Verify PDF magic header (%PDF-) before network transmission
    if not raw_bytes.startswith(b"%PDF"):
        raise ValueError(f"File {pdf_file_path} is not a valid binary PDF document.")

    payload = {
        "title": title,
        "pdf_base64": base64.b64encode(raw_bytes).decode("utf-8"),
        "sender_name": sender_name,
        "sender_email": sender_email,
        "recipient_name": recipient_name,
        "recipient_email": recipient_email,
        "expires_in_days": expires_in_days,
    }

    response = requests.post(
        SIGNBEE_ENDPOINT,
        headers={
            "Authorization": f"Bearer {resolved_key}",
            "Content-Type": "application/json",
        },
        json=payload,
        timeout=30,
    )
    response.raise_for_status()
    return response.json()

# Expected 200 OK JSON Response:
# {
#   "document_id": "cmu6xyz123000...",
#   "status": "pending_recipient",
#   "sender": "Andrei Ptitsyn",
#   "recipient": "Jane Smith",
#   "expires_at": "2026-09-30T10:00:00.000Z"
# }

And here is the corresponding Node.js / TypeScript implementation supporting both pdf_base64 and pdf_url, plus HMAC webhook registration for downstream CRM updates:

import fs from "node:fs";

export interface SendPdfOptions {
  title: string;
  filePath?: string;
  pdfUrl?: string;
  senderName?: string;
  senderEmail?: string;
  recipientName: string;
  recipientEmail: string;
  expiresInDays?: number;
  webhookUrl?: string;
  apiKey: string;
}

export async function sendExistingPdfViaSignbee(opts: SendPdfOptions) {
  if (!opts.filePath && !opts.pdfUrl) {
    throw new Error("Provide either filePath (for pdf_base64) or pdfUrl (for pdf_url)");
  }

  const bodyPayload: Record<string, unknown> = {
    title: opts.title,
    sender_name: opts.senderName ?? "Andrei Ptitsyn",
    sender_email: opts.senderEmail ?? "ap@altezza.org",
    recipient_name: opts.recipientName,
    recipient_email: opts.recipientEmail,
    expires_in_days: opts.expiresInDays ?? 7,
    webhook_url: opts.webhookUrl,
  };

  if (opts.filePath) {
    const pdfBuffer = fs.readFileSync(opts.filePath);
    if (!pdfBuffer.subarray(0, 5).toString("ascii").startsWith("%PDF")) {
      throw new Error("Invalid PDF binary: missing %PDF header");
    }
    bodyPayload.pdf_base64 = pdfBuffer.toString("base64");
  } else {
    bodyPayload.pdf_url = opts.pdfUrl;
  }

  const res = await fetch("https://signb.ee/api/v1/send", {
    method: "POST",
    headers: {
      "Authorization": `Bearer ${opts.apiKey}`,
      "Content-Type": "application/json",
    },
    body: JSON.stringify(bodyPayload),
  });

  if (!res.ok) {
    const errText = await res.text();
    throw new Error(`Signbee send failed (${res.status}): ${errText}`);
  }

  return await res.json();
}

6. Deep Dive: How Signbee Computes the Two-Pass SHA-256 Certificate on Binary PDFs

When you upload a pre-existing PDF via pdf_base64 or pdf_url, how does Signbee seal the document without corrupting internal PDF cross-reference tables (`xref`) or modifying your original pages?

Signbee's cryptographic engine uses pdf-lib to parse the Abstract Syntax Tree (AST) of your uploaded PDF buffer directly in memory:

1. Header & Data-URI Sanitization: On POST /api/v1/send, Signbee strips any optional data:application/pdf;base64, prefix, decodes the buffer into raw bytes, and verifies pdfBuffer.subarray(0, 5).toString().startsWith("%PDF").
2. Immutable Source Persistence: The untouched binary PDF is uploaded to encrypted blob storage and linked to the document record alongside Party A's execution metadata (senderSignedAt, senderIp, and verified account identity).
3. Two-Pass Certificate Sealing on Party B Completion: When Party B completes the signing ceremony at https://signb.ee/sign/[token], Signbee loads the original PDF into PDFDocument.load(originalBytes). In Pass 1, it constructs a dedicated A4 Certificate of Completion page containing Party A and Party B's names, verified emails, IP addresses, ISO-8601 UTC timestamps, Party B's drawn or typed signature graphic, and the public verification URL (https://signb.ee/verify/[id]). In Pass 2, it computes the crypto.createHash("sha256") digest across the finalized PDF byte stream, stamps the digest onto the certificate, and stores the immutable hash in PostgreSQL for permanent public verification.

7. Plan Payload Limits, HTTP Error Handling & Pricing Tiers

Before deploying automated PDF pipelines into production, review Signbee's binary size limits and deterministic HTTP status codes. Unlike self-hosted stacks analyzed in our open-source e-signature API comparison—where large PDFs often crash Sidekiq workers or exceed SMTP attachment caps—Signbee validates payload sizes upfront before incrementing your monthly document counter. You can also explore our affordable e-signature API integration guide, 2026 e-signature API pricing comparison, white-label e-signature API documentation, and free e-signature API tier details.

8. Frequently Asked Questions: Direct PDF Signing in Claude