DEV Community: Kevin

Placet: An Open Source Human-in-the-Loop Platform for AI Agents and Automation Workflows

Kevin — Tue, 31 Mar 2026 20:58:44 +0000

AI agents are getting better every week. They write code, analyze data, generate reports, moderate content, and propose infrastructure changes. In many cases that output is good enough to act on directly.

But for most business-critical workflows a human still needs to be in the loop (HITL). Not because the AI is unreliable, but because accountability, context, and final judgment still matter.

The question is: where does that human review actually happen?

In most teams the answer is Slack, Teams, Telegram, or email. Someone builds a bot, it sends a message, attaches some context, asks for a thumbs-up. It works, barely. But these tools were designed for human-to-human communication and they were never built for structured agent-human collaboration.

I built Placet to fix that.

What is Placet?

Placet (Latin for "it pleases" or "approved") is a self-hostable, open source inbox purpose-built for human-in-the-loop (HITL) workflows. It provides:

A REST API that any agent, script, or automation tool can call via standard HTTP
A web UI where humans review messages, respond to structured requests, and annotate files
A plugin system for rendering custom message types inside sandboxed iframes
A webhook and long-polling system to deliver review responses back to the agent

The design philosophy is simple: be the cURL of human interaction. If your tool can make an HTTP request, it can integrate with Placet. No SDK required, no framework coupling.

Why Not Just Use Slack or Telegram?

This question comes up every time. The short answer: an approval button in Slack is a hack, not a feature.

Problem	Slack / Telegram / Teams	Placet
Structured approval with styled buttons	Button text only, no visual hierarchy	Primary / Danger / Default button styles
Multi-field form submission	Impossible without a custom app	Native form review type (12 field types)
Rich file previews inline	Images only, limited context	PDF, DOCX, XLSX, MP4, audio, code, SVG all inline
Image annotation	Not possible	Canvas overlay: pen, arrow, rectangle, text
Review expiry with webhook callback	Manual workaround required	Built-in, configurable per review
Delivery status tracking	Not available	WhatsApp-style: `sent` to `delivered` to `agent_received`
Agent status heartbeat	Not available	4 states with full history timeline
Self-hosted, no cloud dependency	SaaS only or complex setup	One `docker compose up`
Open source	No	Yes

I personally replaced my Telegram-based approval flows with Placet and the difference was immediate. Review context stays in one place, responses are structured JSON instead of freeform text, and I can annotate AI-generated images without switching to another tool.

Core Concepts

Agents and Channels

Every integration is an agent: an entity that holds an API key and has its own chat channel in the UI. You can have as many agents as you want, one per LangChain workflow, one per CI/CD pipeline, one per cron job.

Each agent gets:

Its own isolated channel (like a dedicated chat thread)
A configurable webhook URL for receiving review responses
An optional avatar and description for identification
A status heartbeat system with full history

The Five Review Types

Placet ships with five built-in review primitives:

Type	When to use	Response shape
Approval	Binary or small set of choices (approve/reject)	`{ selectedOption, comment? }`
Selection	Single or multi-select from a list of items	`{ selectedIds: [...] }`
Form	Structured data entry with multiple typed fields	`{ fieldName: value, ... }`
Text Input	Open-ended freeform response with optional markdown preview	`{ text: "..." }`
Freeform	Custom JSON, rendered and submitted by a plugin	any JSON

All review types support:

expiresInSeconds or expiresAt (default 24 hours, max 36 hours)
Per-message webhook callbacks
Long-polling via GET /api/v1/reviews/:id/wait
A review:expired webhook callback when the timer runs out

How Agents Receive Responses

When a human responds to a review, the agent can receive it via one of three connection types:

Webhook callback: Placet POSTs the response to your configured URL
Long-polling: The agent waits on GET /api/v1/reviews/:id/wait for up to 30 seconds
WebSocket: Subscribe to real-time events via Socket.io (e.g. review:responded, review:expired, message:created)

The WebSocket connection is particularly useful for agents that want to stay permanently connected and react instantly without the overhead of repeated polling. Here is a minimal example using the Socket.io client:

import { io } from 'socket.io-client';

const socket = io('https://your-placet-instance.com', {
  auth: { token: 'hp_your_api_key' },
});

socket.on('review:responded', (event) => {
  const { messageId, channelId, response } = event;
  console.log(`Review ${messageId} completed:`, response);
});

socket.on('review:expired', (event) => {
  console.log(`Review ${event.messageId} expired without a response`);
});

Webhook Resolution: Three Layers

When a human responds to a review, Placet resolves where to send the callback in a fixed priority chain:

Priority	Source	How to set it
1 (highest)	Message-level webhook	Pass `webhookUrl` in the `POST /api/v1/messages` body
2	Agent-level default webhook	Set once in the agent settings panel
3	Legacy inline callback	A `callback` field inside the review payload (backwards compat)

The message-level override exists because real pipelines are rarely that uniform. A single agent might dispatch review requests from multiple concurrent LangChain runs, each needing its response routed somewhere different: a per-run callback URL, a short-lived ngrok tunnel, a specific Lambda invocation. Passing webhookUrl per message solves this cleanly without spinning up a new agent for each run.

WebSocket events (review:responded, review:expired) always fire in parallel with the HTTP callback, regardless of which tier is active. When a webhook call fails, the message flips to a webhook_failed delivery status, visible as a red indicator in the UI. A single click retries delivery without touching the review state.

Push-Only vs Bidirectional Channels

Not every workflow needs a free-text chat box. Placet channels support two practical communication patterns, and which one applies is determined by how the agent is configured.

Push-only (watch mode): The agent sends messages to the inbox and may request structured responses. Humans respond exclusively through the built-in review UI: clicking an approval button, selecting options, filling a form, drawing annotations. The free-text message input is present in the UI but serves no purpose for the agent, because there is no webhook to receive unstructured user messages. This is the right pattern for automated pipelines where the agent controls the agenda and the human is there to gate-keep specific decision points.

Bidirectional (chat mode): When the agent has a webhook configured, human-typed messages (stored with senderType: "user") are forwarded to that same webhook in real time, alongside review responses and delivery events. The agent can react to free-text input, ask follow-up questions, or run a full conversational loop. The LangChain example in the repository demonstrates this pattern: the agent pauses mid-task to ask a question, the human types an answer in the chat box, and the agent continues with the new context.

The distinction matters when you are designing a workflow. A production deploy gate needs only structured approval buttons. A research assistant that takes mid-run guidance needs the full chat loop. Placet does not force a choice: configure the webhook and you get both structured reviews and free-text input from the same channel.

Upcoming Integrations

Beyond the REST API and WebSocket, two more connection types are actively in development:

Integration	Status	What it will enable
MCP server	In development	Claude, Cursor, and other MCP-compatible agents can call Placet tools (send message, request approval, wait for response) natively without an HTTP wrapper
n8n node	In development	Native Placet node for n8n workflows: trigger on review response, send messages, request approvals directly from the n8n canvas
Make.com module	In development	Same native integration for Make (formerly Integromat) automation scenarios

Once the MCP server ships, agents running in Claude or any MCP-compatible runtime will be able to integrate with Placet with zero REST boilerplate. The n8n and Make.com integrations will make Placet accessible to no-code automation builders without writing a single line of code.

The API in Practice

Sending a message is a single HTTP call. No SDK, no special client library required:

curl -X POST https://your-placet-instance.com/api/v1/messages \
  -H "Authorization: Bearer hp_your-key-here" \
  -H "Content-Type: application/json" \
  -d '{"channelId": "your-agent-id", "text": "Analysis complete.", "status": "success"}'

Adding a human approval request takes a few more fields:

curl -X POST https://your-placet-instance.com/api/v1/messages \
  -H "Authorization: Bearer hp_your-key-here" \
  -H "Content-Type: application/json" \
  -d '{
    "channelId": "your-agent-id",
    "text": "Deploy v2.1 to production?",
    "review": {
      "type": "approval",
      "payload": {
        "options": [
          {"id": "deploy", "label": "Deploy", "style": "primary"},
          {"id": "cancel", "label": "Cancel", "style": "danger"}
        ]
      }
    }
  }'

From Python, using requests:

import requests

BASE_URL = "https://your-placet-instance.com"
API_KEY = "hp_your-api-key"
CHANNEL_ID = "your-agent-id"

resp = requests.post(
    f"{BASE_URL}/api/v1/messages",
    headers={"Authorization": f"Bearer {API_KEY}"},
    json={
        "channelId": CHANNEL_ID,
        "text": "Please review the attached report.",
        "status": "warning",
        "review": {
            "type": "approval",
            "payload": {
                "options": [
                    {"id": "approve", "label": "Approve", "style": "primary"},
                    {"id": "reject",  "label": "Reject",  "style": "danger"},
                ],
            },
        },
    },
).json()

# Long-poll for the human response (synchronous, max 30s per call)
review = requests.get(
    f"{BASE_URL}/api/v1/reviews/{resp['id']}/wait",
    headers={"Authorization": f"Bearer {API_KEY}"},
).json()

print(review["message"]["review"]["response"]["selectedOption"])  # "approve" or "reject"

The full API reference is available at docs.placet.io.

Agent Status Heartbeat

Beyond sending messages, agents can report their current operational status so humans have a live health dashboard across all running workflows:

curl -X POST http://localhost:3001/api/v1/status/ping \
  -H "Authorization: Bearer hp_your-key-here" \
  -H "Content-Type: application/json" \
  -d '{"status": "busy", "message": "Processing 847 records from the data pipeline"}'

The four status values are active, busy, error, and offline. The UI shows the current badge next to the agent name and maintains a full history timeline, which is useful for debugging why an agent went silent or when a pipeline stalled.

The Plugin System

One of Placet's more distinctive features is its plugin system. You can define custom message renderers as static HTML files loaded in sandboxed iframes. All built-in review types use this same system internally; there is no special-casing.

A plugin is a directory with three files. That is all it takes:

packages/plugins/my-plugin/
  plugin.json   - manifest: name, version, input schema, HTTP permissions
  render.html   - the UI: plain HTML + CSS + JS, no build step required
  icon.svg      - optional icon shown in the Settings UI

The plugin receives message data from the host via postMessage and submits responses the same way. Outbound HTTP requests are proxied server-side with a per-plugin domain allowlist, so plugins can call external APIs without exposing credentials to the browser or opening SSRF vectors.

Plugins are decoupled from the review system. A plugin controls how a message is rendered; a review controls whether user input is required. You can use either independently or combine them on the same message.

Two example plugins are included in the repository to use as a starting point:

Plugin	What it does	Source
`form-submit`	Renders a dynamic form and POSTs the response to a configurable webhook URL	packages/plugins/form-submit
`kroki-diagram`	Renders Mermaid, PlantUML, D2, Graphviz, and more via a Kroki server	packages/plugins/kroki-diagram

File Handling

Placet treats files as first-class citizens of the review workflow. Supported formats are previewed inline without any application switching.

Category	Formats
Images	JPG, PNG, GIF, WebP, SVG
Video	MP4, WebM, MOV (inline player)
Audio	MP3, WAV, OGG, M4A (inline player)
Documents	PDF, DOCX, ODT
Spreadsheets	XLSX, XLS, ODS, CSV
Presentations	PPTX
Code / Text	40+ languages with Shiki syntax highlighting
Markdown	GitHub Flavored Markdown rendered inline

Image annotation is built directly into the review flow. When an agent generates images, diagrams, or screenshots, the human reviewer can open an annotation canvas in-chat and draw with pen, arrows, rectangles, and text labels. The annotated image is saved back into the conversation. No external markup tool needed.

Additional file features: JWT-based share links (1-hour expiry), bulk ZIP download, full-text search in the file browser, and presigned S3-compatible uploads via MinIO.

Self-Hosting in Three Minutes

Prerequisites: Git, Node.js 22+, Docker with Docker Compose v2, 2 GB RAM.

git clone https://github.com/placet-io/placet.git
cd placet
cp .env.example .env
make setup

make setup installs dependencies, builds all packages, starts the full Docker Compose stack (PostgreSQL + MinIO + backend + frontend), runs database migrations, and creates the initial user. Everything runs locally with zero cloud dependencies.

Services available after setup:

Service	URL
Frontend	http://localhost:3000
Backend API	http://localhost:3001
API docs	https://docs.placet.io
MinIO Console	http://localhost:9001

Default login: admin@placet.local / changeme (configurable in .env)

Once you are in:

Go to Settings → API Keys and create a key
Go to Settings → Agents and create an agent
Send your first message:

curl -X POST http://localhost:3001/api/v1/messages \
  -H "Authorization: Bearer hp_your-key-here" \
  -H "Content-Type: application/json" \
  -d '{"text": "Hello from my agent!", "status": "success"}'

Open the agent channel in the UI and your message appears in real time.

For production deployments, a Traefik overlay (docker-compose.traefik.yml) is included and handles automatic HTTPS via Let's Encrypt.

How I Use Placet in My Own Workflows

I run Placet as the central review layer across several of my personal and business automation workflows. Here are three concrete examples:

Document approval pipeline. An AI pipeline processes incoming data, generates a weekly summary PDF, and sends it to Placet with an approval request before distribution. I open the rendered PDF directly in the chat, annotate sections if needed, and click "Approve" or "Hold for Revision." The pipeline receives the structured response and acts on it.

CI/CD production gating. Pipeline steps that affect production infrastructure gate on a Placet approval before continuing. I review a summary of what is about to happen, approve or reject, and the pipeline proceeds or aborts accordingly. This replaced a fragile Telegram bot that had no audit trail and broke regularly after API changes.

LangChain agents with mid-run questions. LangChain agents running multi-step tasks hit decision points where they genuinely need human judgment. They call the Placet API, present the question with full context, and wait. When I respond, they continue. The full conversation history that led to the question is visible in the chat.

The advantage over Telegram or Slack is not just the UI quality. It is having all reviews in one structured place, with delivery receipts, history, and a consistent response schema that the downstream code can rely on.

Open Source: Contributions Are Very Welcome

Placet is open source and contributions of any size are genuinely appreciated.

Whether you are:

Fixing a typo in the docs
Reporting a bug you hit while integrating Placet into your workflow
Suggesting a missing feature or integration
Submitting a pull request for a new review type, plugin, or API capability
Just dropping a GitHub star

All of it matters. Bug reports are contributions too, and they are often the most valuable ones because they come from real usage.

The repo is at github.com/placet-io/placet. If you are building something on top of Placet or using it in your own workflows, I would love to hear about it. Open an issue, start a discussion, or reach out directly.

Closing

Human-in-the-loop workflows are not a temporary workaround before full AI autonomy arrives. As agents become more capable and more autonomous, the seams where humans and agents interact become more important, not less. Those seams deserve better tooling than a Telegram bot.

Placet is my attempt at building that tooling in the open. It is early, it is opinionated, and it is actively developed.

Links:

GitHub: github.com/placet-io/placet
Self-host: make setup (see the README)
Docs: docs.placet.io

Stop Fighting Outdated DOCX Libraries: Modern API-Based Generation for SaaS

Kevin — Thu, 26 Mar 2026 08:46:46 +0000

Every document library starts with promise. You install docxtemplater, configure python-docx, or wrap docx4j, and for simple templates it works. Then the edge cases pile up. Nested tables break layout. Images refuse to align. Bullet lists lose formatting. You spend days debugging XML interpolation instead of shipping features.

The maintenance burden compounds. Each Microsoft Word update risks breaking your carefully crafted templates. Support tickets roll in about corrupted files and missing fonts. What should be a simple "generate contract" feature becomes a multi-week project.

There is a cleaner path. Modern REST APIs for document generation eliminate library maintenance entirely. Your code sends structured data, the API returns a finished PDF or DOCX. No XML wrangling. No dependency conflicts.

The Library Problem

Traditional DOCX libraries manipulate Office Open XML directly. This format has thousands of elements and complex relationships. A simple paragraph with bold text requires understanding w:p, w:r, w:rPr, and w:b elements. Tables involve nested w:tbl, w:tr, and w:tc structures.

Common failure points:

Edge cases everywhere: Libraries like docx or python-docx cover the basics but break on complex formatting. Nested tables? Often unsupported. Cross-references? Manual work. Automatic indices like table of contents? You are building them yourself.
Template fragility: A user editing the template in Word can break your code by changing a style or moving a placeholder.
No native PDF output: You need additional tools for conversion. Projects like LibreOffice headless or Gotenberg add deployment complexity.

To be clear: no solution handles everything perfectly. Autype also has limitations, nested tables for example are not supported. But the difference is that an API-based approach centralizes the complexity. Your application does not carry it.

Template-Based Generation with Variables

The core pattern: define a template once, inject data repeatedly. Autype uses {{variable}} syntax directly in your content.

Basic Example: Contract Generation

const AUTYPE_API_KEY = process.env.AUTYPE_API_KEY;
const BASE_URL = 'https://api.autype.com/api/v1/dev';

async function generateContract(clientData) {
  const response = await fetch(`${BASE_URL}/render/markdown`, {
    method: 'POST',
    headers: {
      'Content-Type': 'application/json',
      'X-API-Key': AUTYPE_API_KEY
    },
    body: JSON.stringify({
      content: `
# Service Agreement

**Client:** {{clientName}}  
**Date:** {{agreementDate}}  
**Project:** {{projectTitle}}

## Deliverables

{{deliverables}}

**Total Value:** {{projectValue}}
      `,
      document: { type: 'pdf', size: 'A4' },
      variables: {
        clientName: clientData.name,
        agreementDate: new Date().toLocaleDateString(),
        projectTitle: clientData.project,
        deliverables: clientData.deliverables.map(d => `- ${d}`).join('\n'),
        projectValue: clientData.value
      }
    })
  });

  return response.json();
}

The API returns a job ID immediately. Rendering happens asynchronously. Poll the status endpoint or register a webhook for completion.

Python Example: Invoice Generation

import requests
import os

AUTYPE_API_KEY = os.environ['AUTYPE_API_KEY']
BASE_URL = 'https://api.autype.com/api/v1/dev'

def generate_invoice(invoice_data):
    response = requests.post(
        f'{BASE_URL}/render/markdown',
        headers={'X-API-Key': AUTYPE_API_KEY},
        json={
            'content': """
# INVOICE

**Invoice #:** {{invoiceNumber}}  
**Date:** {{invoiceDate}}

## Items

| Description | Quantity | Price | Total |
|-------------|----------|-------|-------|
{{invoiceRows}}

**Total:** {{total}}
            """,
            'document': {'type': 'pdf', 'size': 'A4'},
            'variables': invoice_data
        }
    )

    return response.json()

Batch Processing for Scale

SaaS applications often generate documents in batches: monthly invoices, personalized certificates, client reports. The bulk render endpoint handles this with parallel processing.

async function generateClientReports(templateDocumentId, clientData) {
  const response = await fetch(`${BASE_URL}/bulk-render`, {
    method: 'POST',
    headers: {
      'Content-Type': 'application/json',
      'X-API-Key': AUTYPE_API_KEY
    },
    body: JSON.stringify({
      documentId: templateDocumentId,
      format: 'PDF',
      items: clientData.map(client => ({
        clientName: client.name,
        reportPeriod: client.period,
        metrics: client.metrics
      }))
    })
  });

  return response.json();
}

The bulk endpoint accepts up to 100 variable sets per job. Each set produces a unique document. Processing happens in parallel.

Webhook Integration

For production systems, register a webhook URL with your render request. The API POSTs when the job completes.

// Webhook receiver (Express.js)
app.post('/webhooks/autype-complete', (req, res) => {
  const { jobId, status, downloadUrl, error } = req.body;

  if (status === 'COMPLETED') {
    saveDocumentUrl(jobId, downloadUrl);
  } else if (status === 'FAILED') {
    alertTeam(jobId, error);
  }

  res.status(200).send('OK');
});

The webhook payload includes job ID, status, download URL, and any error message.

Why This Beats Library Maintenance

Concern	DOCX Libraries	API-Based Generation
Setup	XML parsers, rendering tools	One HTTP client
Deployment	Additional dependencies	None
PDF output	Requires conversion tool	Native
Batch processing	Build your own queue	Built-in bulk endpoint
Error handling	Debug XML errors	HTTP status codes
Automatic indices	Build yourself	Built-in support
Cross-references	Manual implementation	Native support

The time investment shifts from maintaining fragile document code to building your application logic.

Getting Started

Create an account at autype.com (free tier available)
Generate an API key in Dashboard → Settings → API Keys
Build your first template in the visual editor or define it in JSON
Start with single renders, then move to bulk as needed

Document generation should not consume your development cycles. With a modern API approach, you ship features in hours instead of weeks.

When HTML to PDF Works (And When It Doesn't): A Developer's Guide to PDF Generation

Kevin — Sun, 22 Mar 2026 15:45:02 +0000

You have a simple task: generate a PDF from your web app. The instinct is obvious: render HTML, print to PDF, done. After all, you already know HTML and CSS, and your content is probably already in some templated HTML format.

This works fine until it doesn't. Page breaks split tables in half. Fonts render differently on your server versus your laptop. Headers and footers need manual positioning. And don't get started on multi-column layouts or page numbers in table of contents.

Here's when HTML-to-PDF makes sense, when it falls apart, and what to use instead.

The HTML-to-PDF Illusion

HTML was designed for screens, not paper. When you convert HTML to PDF, you're forcing a screen layout engine to think in pages. This works reasonably well for:

Simple reports with linear content flow
Existing HTML content you can't easily restructure
Quick prototypes where pixel-perfect output isn't critical

The common tools in this space all share the same underlying approach: spin up a headless browser, render your HTML, capture the output.

# Puppeteer example
npx puppeteer print ./report.html ./report.pdf

# wkhtmltopdf
wkhtmltopdf --page-size A4 report.html report.pdf

# Gotenberg (self-hosted API)
curl -X POST http://localhost:3000/convert/html \
  -F "file=@report.html" \
  -o report.pdf

The problem isn't that these tools don't work. They work fine for simple cases. The problem is what happens when your requirements grow beyond "simple case."

Where HTML-to-PDF Breaks Down

Page Breaks and Layout Control

CSS has page-break-before, page-break-after, and break-inside: avoid. In theory, these give you control. In practice, browser rendering engines optimize for screens first. Complex layouts with multi-column sections, fixed headers, and footers often produce unpredictable breaks.

Your CSS says "don't break inside this table," but the browser engine has already calculated the page height differently than expected. Now your table header sits alone on page 7 while the data spills to page 8.

Consistency Across Environments

Your local Chrome produces a perfect PDF. Your CI pipeline running Chromium produces something almost identical, but the line spacing is slightly different and one image is 2 pixels lower. Same HTML, same CSS, different output.

This isn't a bug in the tools. It's the nature of browser engines. They're designed for interactive rendering with font substitution, sub-pixel positioning, and GPU acceleration. None of these optimize for deterministic document output.

Complex Document Features

Try implementing these in pure HTML/CSS:

Automatic table of contents with page numbers
Cross-references like "see Figure 3 on page 12"
Academic citations with auto-generated bibliography
Multi-column layouts that reflow correctly across page boundaries
Headers and footers with page numbers, section titles, and total page count

Each is possible with enough JavaScript and post-processing. But you're now building a document engine on top of a layout engine that was never meant for documents.

Decision Framework: Which Approach to Use

Use this mental model:

Your Need	Best Approach	Why
Simple invoice from existing HTML	HTML-to-PDF	One-time conversion, no complex layout
Report with charts and TOC	Native document engine	Automatic indices, deterministic output
500 personalized contracts	Template fill + bulk render	Reuse template, fill variables at scale
Real-time document from app data	Markdown/JSON via API	Schema validation, AI-friendly generation
Complex academic paper	Native with citations	Bibliography, cross-references, math

Let's look at each approach with code examples.

Approach 1: Native Document Generation

Instead of HTML, you define documents in a structured format designed for paper. Markdown extended with document primitives, or a JSON schema that describes every element explicitly.

The key difference: the rendering engine thinks in pages from the start, not after the fact.

Here's generating a report with a chart and table of contents using the Autype API:

curl -X POST https://api.autype.com/api/v1/dev/render/markdown \
  -H "X-API-Key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "content": "# Quarterly Report\n\n:::toc\n:::\n\n## Executive Summary\n\nRevenue increased by 23% compared to the previous quarter.\n\n## Sales Data\n\n:::chart{\n  type: \"bar\",\n  width: 400,\n  height: 200\n}\nlabels: [\"Q1\", \"Q2\", \"Q3\", \"Q4\"]\ndatasets:\n  - label: \"Revenue (M$)\"\n    data: [12.4, 15.2, 18.1, 22.3]\n:::\n\n### Breakdown by Region\n\n| Region | Sales | Growth |\n|--------|-------|--------|\n| Europe | 8.2M  | +18%   |\n| NA     | 9.1M  | +25%   |\n| APAC   | 5.0M  | +31%   |\n",
    "document": {
      "type": "pdf",
      "size": "A4"
    },
    "defaults": {
      "fontFamily": "Helvetica",
      "fontSize": 11,
      "header": {
        "left": "Quarterly Report",
        "right": "{{pageNumber}}/{{totalPages}}"
      }
    }
  }'

Response:

{
  "jobId": "r_8f3a2b1c4d5e",
  "status": "PROCESSING",
  "format": "PDF",
  "creditCost": 5,
  "createdAt": "2024-12-15T10:30:00Z"
}

The engine handles:

Page breaks that respect content boundaries
Automatic table of contents with page numbers
Charts rendered inline without external libraries
Consistent typography across all output

You can also use JSON for more granular control:

const documentJson = {
  document: {
    type: "pdf",
    size: "A4",
    orientation: "portrait"
  },
  defaults: {
    fontFamily: "Helvetica",
    fontSize: 11,
    header: {
      left: "Quarterly Report",
      right: "{{pageNumber}}/{{totalPages}}"
    }
  },
  sections: [
    {
      id: "main",
      type: "flow",
      content: [
        { type: "h1", text: "Quarterly Report" },
        { type: "toc", title: "Contents" },
        { type: "h2", text: "Executive Summary" },
        { type: "text", text: "Revenue increased by 23% compared to the previous quarter." },
        {
          type: "chart",
          config: {
            type: "bar",
            data: {
              labels: ["Q1", "Q2", "Q3", "Q4"],
              datasets: [{ label: "Revenue (M$)", data: [12.4, 15.2, 18.1, 22.3] }]
            }
          },
          width: 400,
          height: 200
        }
      ]
    }
  ]
};

// Validate before rendering
await fetch("https://api.autype.com/api/v1/dev/render/validate", {
  method: "POST",
  headers: {
    "X-API-Key": process.env.AUTYPE_API_KEY,
    "Content-Type": "application/json"
  },
  body: JSON.stringify({ config: documentJson })
});

This validates the schema before you spend credits on rendering. If the structure is invalid, you get specific error paths.

Approach 2: Template-Based Bulk Generation

When you have a contract template and need 500 personalized versions, you don't generate each from scratch. You define a template once, mark the variable placeholders, and fill them programmatically.

The template can be defined in the Autype editor with visual tools, then rendered via API:

# Bulk render from a saved template
curl -X POST https://api.autype.com/api/v1/dev/bulk-render \
  -H "X-API-Key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "documentId": "d_contract_template_2024",
    "format": "PDF",
    "items": [
      {
        "clientName": "Acme Corporation",
        "contractDate": "2024-12-15",
        "amount": "€50,000",
        "projectDescription": "Annual maintenance agreement"
      },
      {
        "clientName": "Beta Industries",
        "contractDate": "2024-12-16",
        "amount": "€125,000",
        "projectDescription": "Platform development phase 2"
      }
    ]
  }'

You can also upload a CSV or Excel file with hundreds of rows:

curl -X POST https://api.autype.com/api/v1/dev/bulk-render/file \
  -H "X-API-Key: YOUR_API_KEY" \
  -F "file=@contracts.csv" \
  -F "documentId=d_contract_template_2024" \
  -F "format=PDF"

Each row generates one PDF. All documents render in parallel, and you get a ZIP download when complete.

Integrating with Automation Tools

n8n Workflow

You can connect document generation to any data source using n8n. The Autype n8n node provides 40+ operations:

# n8n workflow concept
Workflow:
  - Trigger: Webhook receives form submission
  - Node 1: Extract form data (client name, service, amount)
  - Node 2: Autype → Render from Markdown template
  - Node 3: Google Drive → Upload PDF
  - Node 4: Gmail → Send PDF to client

The node handles async job polling automatically. You submit the render job, n8n waits for completion, then passes the download URL to the next node.

Make.com Integration

For no-code automation, the Make.com integration uses a slightly different variable syntax to avoid conflicts with Make's own templating:

# Use ${varName} instead of {{varName}} in your templates
Dear ${clientName},

Your invoice for ${amount} is attached.

This lets Make process its own variables while passing the correct values to Autype.

When to Stick with HTML-to-PDF

None of this means HTML-to-PDF is always wrong. Use it when:

Your content is already HTML and restructuring would be expensive
Layout requirements are simple (linear flow, no complex tables or multi-column)
You're generating a few documents and can manually verify output
You need self-hosting and already have the infrastructure for headless browsers

The tools are mature and well-documented. Just know their limits.

Performance Comparison

For a 50-page document with charts, tables, and headers:

Method	Render Time	Output Consistency	Complex Features
Puppeteer (HTML)	8-15 seconds	Varies by environment	Manual implementation
wkhtmltopdf	5-12 seconds	Varies by environment	Manual implementation
Native engine (Autype)	< 8 seconds	Deterministic	Built-in

Native engines render faster because they don't spin up a browser context. The output is deterministic because the renderer is purpose-built for documents.

The Real Question

When choosing a PDF generation approach, the question isn't "which tool is best." The question is "what kind of documents do you actually need to generate?"

Simple, one-off documents from HTML: HTML-to-PDF tools work fine
Professional documents with TOC, charts, citations: Use a native document engine
High-volume personalized documents: Template fill with bulk rendering
AI-generated documents: Markdown/JSON input with schema validation

HTML is excellent for web pages. Documents are not web pages. Using the right tool for the medium saves hours of debugging layout issues that shouldn't exist in the first place.

OCR vs VLM: Why You Need Both (And How Hybrid Approaches Win)

Kevin — Thu, 19 Mar 2026 21:39:09 +0000

Document processing has been stuck in a binary choice for years: use traditional OCR for speed and reliability, or use AI vision models for understanding. The industry treated these as competing approaches. That framing was wrong.

The best document processing systems today combine both. Traditional OCR handles what it excels at: extracting raw text with high accuracy and minimal computational cost. Vision Language Models (VLMs) handle what OCR cannot: understanding layout, detecting styles, reconstructing document structure.

This is not a competition. It is a stack.

What Traditional OCR Actually Does Well

Optical Character Recognition has been around since the 1950s. Modern OCR engines like Tesseract or cloud-based APIs are remarkably good at one specific task: converting pixels to characters.

When you throw a scanned document at a traditional OCR engine, it performs several steps:

Binarization — Convert the image to black and white to isolate text
Layout analysis — Identify text regions vs. image regions
Line and word segmentation — Break text into processable units
Character recognition — Match glyphs to characters using trained models
Post-processing — Apply language models to fix recognition errors

The output is a stream of text. Sometimes with bounding boxes. Sometimes with basic formatting hints.

# Typical OCR output structure
ocr_result = {
    "text": "Invoice #12345\nDate: 2024-01-15\nTotal: $1,250.00",
    "confidence": 0.94,
    "blocks": [
        {"text": "Invoice #12345", "bbox": [100, 50, 300, 80]},
        {"text": "Date: 2024-01-15", "bbox": [100, 90, 280, 120]},
        {"text": "Total: $1,250.00", "bbox": [100, 130, 280, 160]}
    ]
}

This works well for straightforward documents. Clean scans. Simple layouts. Text-heavy content.

But traditional OCR has a fundamental blind spot: it sees characters, not documents.

Where Traditional OCR Fails

Consider what OCR loses when processing a professional document:

Typography and styling — OCR extracts "Introduction" but does not capture that it is a 24pt bold heading in the corporate font, colored in brand blue.

Spatial relationships — OCR reads columns sequentially, often mangling multi-column layouts where text flows left-to-right, then continues in the next column.

Tables — OCR extracts cell contents as a linear text stream. The structure of rows and columns must be reconstructed through heuristics, often incorrectly.

Headers and footers — OCR treats repeated page headers as content, duplicating text across every page.

Images and figures — OCR either ignores images entirely or provides no context about their position, captions, or relationship to surrounding text.

Section hierarchy — OCR cannot distinguish between a chapter heading, a section heading, and a paragraph. The document's outline is lost.

The result is a flat text file where all document semantics have been stripped away. For search indexing, this might be sufficient. For document reconstruction, it is useless.

What Vision Language Models Bring

Vision Language Models take a fundamentally different approach. Instead of processing text as a sequence of characters, they process the entire page as an image and generate structured output based on visual understanding.

A VLM sees the document the way a human does. It recognizes that large bold text at the top is a title. It understands that text arranged in a grid with borders is a table. It notices that a page number in the footer should not be part of the content.

# VLM-style structured output
vlm_result = {
    "title": "Q4 Financial Report",
    "sections": [
        {
            "heading": "Executive Summary",
            "level": 1,
            "content": "Revenue increased by 23% year-over-year..."
        },
        {
            "heading": "Regional Breakdown",
            "level": 2,
            "table": {
                "headers": ["Region", "Revenue", "Growth"],
                "rows": [
                    ["North America", "$2.1M", "+18%"],
                    ["Europe", "$1.8M", "+27%"],
                    ["Asia Pacific", "$0.9M", "+31%"]
                ]
            }
        }
    ],
    "metadata": {
        "page_count": 12,
        "has_cover_page": true,
        "contains_charts": true
    }
}

VLMs excel at understanding document structure. They can identify:

Document type (invoice, contract, report, letter)
Section hierarchy and nesting
Tables with proper cell relationships
Figures, charts, and their captions
Reading order in complex layouts
Styling patterns (headings, body text, emphasis)

But VLMs have their own weaknesses.

Where VLMs Struggle

Vision Language Models are computationally expensive. Processing a single page through a capable VLM takes significantly longer than traditional OCR. For bulk document processing, this adds up quickly.

More importantly, VLMs can hallucinate. They might:

Invent text that does not exist in the document
Misread specific numbers or proper nouns
Transcribe similar-looking characters incorrectly (O vs 0, l vs 1)
Generate plausible but incorrect structural assumptions

For a legal contract or financial statement, hallucinated text is unacceptable. A missing zero in a dollar amount changes the meaning entirely.

Traditional OCR, despite its limitations, is deterministic. The same input produces the same output. It does not invent content. Its confidence scores are calibrated and reliable.

The Hybrid Approach: Using Both Together

The solution is not to choose one or the other. The solution is to use each for what it does best.

Architecture pattern: OCR for extraction, VLM for structure

Here is how a hybrid pipeline works in practice:

Step 1: OCR extracts text and bounding boxes

The OCR engine processes each page and returns character-level extraction with coordinates. This provides the authoritative text content.

Step 2: VLM analyzes layout and structure

The same page image goes to a VLM with a prompt focused on structure, not transcription:

Analyze this document page. Identify:
1. Document type and structure
2. Section headings and their hierarchy (h1-h6)
3. Table locations and dimensions
4. Image and figure positions
5. Reading order for multi-column layouts
6. Header/footer regions
7. Styling patterns (fonts, colors, emphasis)

Do not transcribe text. Describe structure only.

Note: This is a simplified example prompt. In production, 
you would include more specific instructions about output 
format, error handling, and edge cases for your document types.

Step 3: Merge OCR text with VLM structure

The structured output from the VLM is populated with text from the OCR extraction. Where the VLM identified a heading, insert the OCR text from that region. Where the VLM detected a table, use OCR results to fill cells accurately.

Step 4: Validation and confidence scoring

Cross-reference the OCR text against the VLM's transcription. Flag discrepancies for human review. High-confidence OCR text takes precedence over VLM transcription for critical fields like numbers and proper nouns.

Real-World Applications

Invoice Processing

Traditional OCR extracts line items and totals but often mangles table structures. A VLM identifies the table grid, maps columns to their headers, and understands that the total at the bottom is the sum. Combined, you get accurate financial data extraction.

Contract Analysis

OCR provides verbatim text for compliance checking. VLM identifies clauses, obligations, dates, and parties. Together, they enable automated contract review where both accuracy and structure matter.

Document Digitization

Converting scanned archives to editable formats requires more than text. Page layouts, fonts, section breaks, and styling must be preserved. Hybrid processing reconstructs the document as it originally appeared, not just its text content.

This is exactly what Autype Lens does. It uses a hybrid approach where OCR handles reliable text extraction while AI vision models analyze layout, detect styling patterns, and reconstruct document structure. The output is not flat text but a fully styled, editable document. You can try it at autype.com/lens.

Performance Considerations

Hybrid processing is not free. You are running two models per page. But the tradeoff is worth it for most document processing workflows:

Approach	Accuracy	Structure	Speed	Cost
OCR only	High	None	Fast	Low
VLM only	Medium*	High	Slow	High
Hybrid	High	High	Medium	Medium

*VLM accuracy varies significantly based on document complexity and model capability.

For high-volume processing where structure does not matter (search indexing, archival), stick with OCR. For document reconstruction, analysis, or conversion, hybrid is the right choice.

The Future Is Not Either-Or

The document processing industry spent years debating OCR versus AI. The debate missed the point. These are layers in a stack, not alternatives in a menu.

Traditional OCR provides the foundation: reliable, deterministic text extraction. Vision Language Models provide the understanding: structure, semantics, layout. Together, they transform flat text back into documents.

If you are building document processing pipelines, do not choose. Use both.

5 Business Automations That Save 20+ Hours Per Week

Kevin — Wed, 18 Mar 2026 10:16:50 +0000

Document automation has evolved far beyond simple templates. In 2026, businesses are building intelligent pipelines that generate contracts, invoices, and marketing assets directly from structured data. This reduces manual work, eliminates errors, and scales effortlessly.

This article covers five proven document automation and media generation workflows. Each includes an architecture diagram, implementation details, and real-world benefits you can apply today.

Use Case 1: Automated Contract Generation from CRM Data

After a deal closes, sales teams waste hours populating contracts manually. Document automation solves this by generating contracts directly from CRM data using Autype.

Architecture

Implementation

When a deal stage changes to "Closed Won" in your CRM, a webhook triggers an n8n workflow. The workflow extracts client details, deal terms, and pricing, then calls the Autype API:

curl -X POST https://api.autype.com/api/v1/dev/render \
  -H "X-API-Key: your-api-key" \
  -H "Content-Type: application/json" \
  -d '{
    "config": {
      "document": {
        "type": "pdf",
        "size": "A4"
      },
      "variables": {
        "clientName": "Acme Corporation",
        "dealValue": "€45,000",
        "startDate": "2026-04-01",
        "contractDuration": "12 months"
      },
      "sections": [
        {
          "id": "contract-body",
          "type": "flow",
          "content": [
            {
              "type": "h1",
              "text": "Service Agreement"
            },
            {
              "type": "text",
              "text": "This agreement is between **{{clientName}}** and YourCompany..."
            }
          ]
        }
      ]
    }
  }'

Poll for completion, download the PDF, and send it via email or DocuSign.

Benefits

15-20 minutes saved per contract
Zero copy-paste errors
Complete audit trail

Use Case 2: Bulk Invoice Generation from CSV Data

Month-end invoice runs bottleneck finance teams. Bulk document automation on Autype generates hundreds of invoices in minutes.

Architecture

Implementation

Create an invoice template with variables for client name, invoice number, and line items. Upload your CSV and trigger bulk rendering:

curl -X POST https://api.autype.com/api/v1/dev/bulk-render/file \
  -H "X-API-Key: your-api-key" \
  -F "file=@invoices-march-2026.csv" \
  -F "documentId=550e8400-e29b-41d4-a716-446655440000" \
  -F "format=PDF"

The API processes up to 100 invoices in parallel. Download the ZIP when complete.

Benefits

100 invoices in under 2 minutes
Consistent branding across all documents
Works with any ERP or accounting system

Use Case 3: Social Media Video Generation Pipeline

Content teams waste hours creating video variants for different platforms. Automated media pipelines from JsonCut generate multiple formats from a single configuration.

Architecture

Implementation

Define videos as JSON configurations with template variables:

{
  "type": "video",
  "config": {
    "width": 1080,
    "height": 1920,
    "defaults": {
      "duration": 6,
      "transition": { "name": "fade", "duration": 0.5 }
    },
    "clips": [
      {
        "layers": [
          { "type": "video", "path": "/uploads/product-demo.mp4" },
          { "type": "title", "text": "{{productName}}", "position": "bottom" }
        ]
      }
    ]
  }
}

Change dimensions per platform, swap variables, and render variants automatically.

Benefits

30-90 seconds per video
No video editing skills required
Integrates with n8n and Make

Use Case 4: Customer Onboarding Document Package

New customers need welcome letters, agreements, and guides. Document automation on Autype creates complete packages on demand.

Architecture

Implementation

Render each document with customer data, then merge them:

curl -X POST https://api.autype.com/api/v1/dev/tools/pdf/merge \
  -H "X-API-Key: your-api-key" \
  -H "Content-Type: application/json" \
  -d '{
    "fileIds": [
      "welcome-letter-file-id",
      "service-agreement-file-id",
      "sla-document-file-id"
    ]
  }'

Email the merged PDF package automatically.

Benefits

Professional first impression
Reduced support tickets
Scales without manual work

Use Case 5: Marketing Image Generation for E-commerce

Product teams need hundreds of marketing images. Automated image generation on JsonCut creates them from product feeds.

Architecture

Implementation

Define an image template once, then loop through your product catalog:

{
  "type": "image",
  "config": {
    "width": 1200,
    "height": 630,
    "layers": [
      {
        "type": "gradient",
        "gradient": { "colors": ["#667eea", "#764ba2"], "direction": "diagonal" }
      },
      {
        "type": "image",
        "path": "{{productImage}}",
        "x": 40, "y": 40,
        "width": 200, "height": 200,
        "borderRadius": 12
      },
      {
        "type": "text",
        "text": "{{productName}}",
        "x": 280, "y": 80,
        "fontSize": 36,
        "color": "#ffffff"
      },
      {
        "type": "text",
        "text": "{{price}}",
        "x": 280, "y": 140,
        "fontSize": 24,
        "color": "#f0f0f0"
      }
    ]
  }
}

Generate each image in 2-10 seconds.

Benefits

Consistent brand guidelines
Full catalog in hours, not weeks
Easy updates for pricing changes

Why Document Automation Works

All five patterns follow the same principle: structured data in, professional output out.

Use Case	Input	Output	Time Saved
Contract generation	CRM data	PDF contract	15-20 min/contract
Bulk invoices	CSV data	ZIP of PDFs	Hours per month
Social videos	JSON config	MP4 files	Hours per video
Onboarding package	Customer data	Merged PDF	30 min/customer
Marketing images	Product feed	PNG/JPEG files	Minutes per image

Both Autype (documents) and JsonCut (media) use JSON configurations. This enables programmatic generation without template files or manual intervention.

Getting Started

Both platforms offer free tiers:

Autype: 50 AI credits/month for document automation testing
JsonCut: 2,000 tokens/month for media generation

Connect these tools to your CRM, ERP, or product database. Webhooks and CSV exports transform manual document creation into fully automated workflows.

Integrating Autype with LLM Agents (MCP): Templates, Schema Validation and Feedback Loops

Kevin — Mon, 16 Mar 2026 09:06:54 +0000

When you connect an LLM agent to a document generation system, you quickly hit a wall. The agent produces output, but the output needs to fit a strict schema. One missing field, one wrong type, and the document fails to render. Then there's the feedback problem. How does the agent know what went wrong? How does it fix errors without human intervention?

Autype solves this through the Model Context Protocol (MCP). Instead of hoping your LLM generates valid documents, you give it tools that enforce validation, provide structured error messages, and enable iterative refinement. This article shows how to build robust LLM-powered document workflows with Autype's MCP server.

The MCP Architecture

Autype's MCP server lives at https://mcp.autype.com/mcp/. It implements MCP 2025-03-26 over Streamable HTTP, which means no installation. Point any MCP-compatible client at the URL and you're connected.

Supported clients: Claude Desktop, Claude Code (CLI), Cursor, Windsurf, VS Code with GitHub Copilot, and the MCP Inspector.

The server exposes two categories of resources:

Tools — Actions the LLM can take (render documents, create sessions, manage sections)
Schema Resources — Machine-readable schemas the LLM reads to understand valid document structure

Schema resources are particularly important. Instead of hardcoding document templates, your LLM fetches the current schema from:

autype://schemas/document — Complete document JSON schema
autype://schemas/defaults — Styling defaults
autype://schemas/variables — Template variable definitions

The LLM reads these schemas and constructs valid documents from first principles.

Building a Template with Schema-First Validation

The key to reliable LLM document generation is validating before rendering. Autype provides a validation endpoint that returns structured errors the LLM can parse and fix.

Here's how the flow works:

import httpx
import json

AUTYPE_API_KEY = "your-api-key"
BASE_URL = "https://api.autype.com/api/v1/dev"

# Step 1: LLM generates document JSON based on schema
document_json = {
    "document": {
        "type": "pdf",
        "size": "A4",
        "title": "Q4 Financial Report"
    },
    "variables": {
        "companyName": "Acme Industries",
        "reportDate": "2024-12-15",
        "totalRevenue": {"type": "number", "value": 2847500}
    },
    "defaults": {
        "fontFamily": "Helvetica",
        "fontSize": 11,
        "color": "#1a1a1a"
    },
    "sections": [
        {
            "id": "cover",
            "type": "page",
            "align": "center",
            "content": [
                {"type": "h1", "text": "{{companyName}}"},
                {"type": "text", "text": "Quarterly Financial Report"},
                {"type": "text", "text": "{{reportDate}}", "fontSize": 14}
            ]
        },
        {
            "id": "summary",
            "type": "flow",
            "content": [
                {"type": "h2", "text": "Executive Summary"},
                {"type": "text", "text": "Total revenue for Q4: ${{totalRevenue}}"}
            ]
        }
    ]
}

# Step 2: Validate without consuming credits
validate_response = httpx.post(
    f"{BASE_URL}/render/validate?strict=true",
    headers={"X-API-Key": AUTYPE_API_KEY, "Content-Type": "application/json"},
    json={"config": document_json}
)

result = validate_response.json()

if not result["valid"]:
    # LLM parses errors and fixes them
    for error in result.get("errors", []):
        print(f"Error at {error['path']}: {error['message']}")
    # Feed errors back to LLM for correction...
else:
    print("Document is valid, ready to render")

The validation endpoint returns structured error objects with a path field pointing to the exact location in the JSON. This makes it trivial for an LLM to understand what went wrong and apply a fix.

Example validation error response:

{
  "valid": false,
  "errors": [
    {
      "path": "sections.0.content.2.type",
      "message": "Invalid element type 'paragraph'. Did you mean 'text'?",
      "code": "INVALID_ELEMENT_TYPE"
    },
    {
      "path": "variables.totalRevenue",
      "message": "Number variables require 'type' and 'value' properties",
      "code": "SCHEMA_VIOLATION"
    }
  ],
  "warnings": [
    {
      "path": "defaults.fontFamily",
      "message": "Font 'Helvetica' not found, falling back to 'Roboto'",
      "code": "FONT_FALLBACK"
    }
  ]
}

The Interactive Document Builder Pattern

For complex documents, the MCP server provides an iterative builder workflow. Instead of generating the entire document at once, the LLM creates a session and adds sections incrementally.

This pattern works well for:

Long documents where you want to validate each section
Documents that require multiple rounds of human feedback
Templates where structure is fixed but content varies

Here's the MCP tool sequence:

Create session: builder_create_session returns a session ID
Set defaults: builder_update_defaults defines fonts, colors, spacing
Set variables: builder_set_variables defines template placeholders
Add sections: builder_add_section adds content section by section
Render: builder_render produces the final output
Cleanup: builder_delete_session removes temporary state

The LLM can call builder_update_section at any point to fix issues without starting over.

Agent Prompt Template for Document Generation

Here's a prompt template you can use with Claude or other LLMs connected to Autype's MCP server:

You are a document generation agent connected to Autype via MCP.

WORKFLOW:
1. Fetch the document schema from autype://schemas/document
2. Create a builder session using builder_create_session
3. Set document defaults (fonts, colors) using builder_update_defaults
4. Define template variables using builder_set_variables
5. Add sections one at a time using builder_add_section
6. After each section, validate the session state
7. If validation fails, fix errors and retry
8. When complete, render using builder_render

VALIDATION RULES:
- Every section must have: id, type ("flow" or "page"), content array
- Every content element must have a valid "type": text, h1-h6, image, table, list, code, math, chart
- Variable names must match pattern: ^[a-zA-Z][a-zA-Z0-9_]*$
- Variable placeholders in text: {{varName}} or ${varName}

ERROR HANDLING:
- Parse validation errors carefully
- Fix the specific path mentioned in the error
- Re-validate before attempting to render
- Never guess schema structure — always reference the schema

OUTPUT:
- Return the download URL from the render response
- Summarize what was generated

Variable Types and Data Binding

Autype supports multiple variable types beyond simple text. This matters when your LLM agent needs to inject structured data like tables or images.

Variable type schema:

{
  "companyName": "Acme Industries",
  "logo": {
    "type": "image",
    "src": "https://cdn.example.com/logo.png",
    "width": 200,
    "align": "center"
  },
  "features": {
    "type": "list",
    "items": ["Real-time collaboration", "Version control", "API access"],
    "ordered": false
  },
  "pricingTable": {
    "type": "table",
    "columns": ["Plan", "Price", "Credits"],
    "data": [
      ["Free", "€0", "50/month"],
      ["Writer", "€9", "400/month"],
      ["Pro", "€25", "1,500/month"]
    ]
  },
  "annualRevenue": {
    "type": "number",
    "value": 1250000
  }
}

When the LLM generates a document with these variables, placeholders like {{companyName}} get replaced, while structured types (image, list, table) render as full elements.

Human-in-the-Loop Feedback

The real power of MCP integration emerges when you add human feedback to the loop. Here's a typical workflow:

LLM generates initial document
Human reviews in Autype's web editor or downloads the PDF
Human provides feedback: "Add a third column to the pricing table" or "Change the accent color to blue"
LLM receives feedback and calls builder_update_section or builder_update_defaults
Document re-renders with changes applied

Because MCP maintains session state, the LLM doesn't need to regenerate the entire document. It modifies specific sections or defaults and re-renders.

Example: Iterative Style Refinement

Let's say the human wants to change the document's visual style after reviewing the first draft:

# LLM receives feedback: "Make headings dark blue and increase font size"

style_update = {
    "defaults": {
        "fontFamily": "Roboto",
        "fontSize": 12,
        "styles": {
            "h1": {
                "fontSize": 28,
                "fontWeight": "bold",
                "color": "#1e3a5f"
            },
            "h2": {
                "fontSize": 22,
                "fontWeight": "bold",
                "color": "#2c5282"
            }
        }
    }
}

# MCP call: builder_update_defaults
# Then: builder_render to get updated PDF

The document structure stays the same, but styling updates cascade through all sections.

Bulk Generation for Scale

Once your LLM agent has a validated template, you can scale to hundreds of documents via the bulk render API. This is useful for personalized reports, contracts, or invoices.

# Bulk render with variable sets
bulk_job = {
    "documentId": "template-doc-uuid",  # Saved template from builder
    "format": "PDF",
    "items": [
        {"companyName": "Acme Corp", "totalRevenue": {"type": "number", "value": 1200000}},
        {"companyName": "Beta LLC", "totalRevenue": {"type": "number", "value": 850000}},
        {"companyName": "Gamma Inc", "totalRevenue": {"type": "number", "value": 2100000}}
    ],
    "webhook": {
        "url": "https://your-app.com/webhook/autype-complete",
        "headers": {"X-Webhook-Secret": "your-secret"}
    }
}

response = httpx.post(
    f"{BASE_URL}/bulk-render",
    headers={"X-API-Key": AUTYPE_API_KEY},
    json=bulk_job
)

# Returns: {"bulkJobId": "job-uuid", "status": "PENDING", "totalItems": 3}

Each item in the array produces one document. The webhook fires when all documents are ready, or you can poll the status endpoint.

Error Recovery Patterns

Robust LLM workflows need error recovery. Here's a pattern for handling common failure modes:

async def render_with_retry(document_json, max_attempts=3):
    for attempt in range(max_attempts):
        # Validate first
        validation = await validate_document(document_json)

        if not validation["valid"]:
            # Feed errors back to LLM for correction
            corrected = await llm_fix_errors(document_json, validation["errors"])
            document_json = corrected
            continue

        # Attempt render
        render_result = await render_document(document_json)

        if render_result["status"] == "FAILED":
            # Parse error and determine if retryable
            if "insufficient credits" in render_result.get("error", ""):
                raise CreditsExhaustedError()

            # Re-validate in case of runtime errors
            continue

        return render_result

    raise MaxRetriesExceededError()

async def llm_fix_errors(document_json, errors):
    # Construct prompt with error details
    error_context = "\n".join([
        f"- {e['path']}: {e['message']} (code: {e['code']})"
        for e in errors
    ])

    prompt = f"""
    The document JSON failed validation with these errors:
    {error_context}

    Return corrected JSON that fixes all issues.
    Reference the schema at autype://schemas/document for valid structure.
    """

    # LLM call to fix the document
    corrected = await call_llm(prompt)
    return json.loads(corrected)

This pattern creates a self-healing loop where validation errors become context for the LLM to apply fixes.

Practical Integration with Claude Code

If you're using Claude Code (the CLI), connecting to Autype is straightforward:

# In your Claude Code config (claude_desktop_config.json or .claude/config.json)
{
  "mcpServers": {
    "autype": {
      "url": "https://mcp.autype.com/mcp/"
    }
  }
}

Once connected, Claude has access to all Autype tools. You can say things like:

"Create a quarterly report template with variables for company name, date, and revenue"
"Validate this document JSON before rendering"
"Add a two-column layout section to the existing document"
"Generate 50 personalized contracts from this template using the data in contracts.csv"

Claude reads the schemas, constructs valid JSON, validates, and renders.

Cost Considerations

Each operation has a credit cost. Understanding this helps you design efficient workflows:

Operation	Credits
Validate JSON	Free
Single render	5
Bulk render (per document)	4
AI document generation	80-100

Validation is free, so always validate before rendering. The bulk render discount (4 vs 5 credits) makes it more economical for batch operations.

Summary

Integrating LLM agents with document generation requires three things: a schema the LLM can read, validation that returns structured errors, and tools for iterative refinement. Autype's MCP server provides all three.

The key patterns:

Schema-first generation: LLM fetches schemas, generates valid JSON from the start
Validation loops: Free validation endpoint catches errors before credits are consumed
Builder sessions: Incremental document construction with mid-process corrections
Human feedback integration: MCP sessions persist state, enabling real-time refinement
Bulk scaling: Validated templates feed bulk render for personalized documents at scale

The combination of MCP tools and REST API gives you flexibility. Use MCP for interactive agent workflows, REST for programmatic automation. Both produce the same output formats: PDF, DOCX, ODT.

For production deployments, wrap the MCP calls in error recovery logic that feeds validation errors back to the LLM. This turns brittle document generation into a robust, self-correcting process.

Resources:

MCP Server: https://mcp.autype.com/mcp/
LLM Schemas: https://autype.com/llm-resources/
API Docs: https://docs.autype.com/api-reference
n8n Node: n8n-nodes-autype

Building Scalable Document Pipelines: Mastering Autype API for Bulk Rendering and Webhooks

Kevin — Sun, 15 Mar 2026 19:04:19 +0000

Enterprise document workflows share a common challenge: generating hundreds or thousands of personalized documents without creating a maintenance nightmare. Invoice batches, quarterly reports, personalized contracts, compliance certificates, each requires unique data merged into a consistent template.

The Autype API solves this with a dedicated bulk rendering endpoint that processes up to 100 documents per job in parallel, with webhook callbacks for real-time completion notifications. This guide shows you how to architect production-ready document pipelines that scale.

The Architecture: How Bulk Rendering Works

Autype separates job submission from rendering. When you submit a bulk render job, it enters a queue and processes asynchronously. Each document in the batch renders independently, and the API collects all outputs into a single ZIP file.

This architecture means your application never blocks waiting for renders. You submit the job, receive a job ID, and continue processing other tasks. When rendering completes, Autype either calls your webhook or you poll for status.

Setting Up Your Environment

Before making API calls, you need an API key from your Autype dashboard (Settings → API Keys). All requests use the X-API-Key header for authentication.

# Store your API key as an environment variable
export AUTYPE_API_KEY="your-api-key-here"

# Base URL for all API calls
BASE_URL="https://api.autype.com/api/v1/dev"

Understanding Template Variables

The bulk rendering system relies on template variables defined in your document. Variables are placeholders that get replaced with actual data at render time. Autype supports several variable types.

Simple Text Variables

The most common use case is text substitution. In your document template, use {{variableName}} syntax:

# Invoice for {{clientName}}

Date: {{invoiceDate}}
Due: {{dueDate}}

Total: {{currency}}{{totalAmount}}

When rendering, you provide the values:

{
  "clientName": "Acme Corporation",
  "invoiceDate": "2024-01-15",
  "dueDate": "2024-02-15",
  "currency": "€",
  "totalAmount": "12,500.00"
}

Complex Variable Types

For more sophisticated templates, Autype supports structured variable types:

List Variables for dynamic bullet points:

{
  "services": {
    "type": "list",
    "items": ["Consulting", "Implementation", "Training"],
    "ordered": true
  }
}

Table Variables for invoice line items or product catalogs:

{
  "lineItems": {
    "type": "table",
    "columns": ["Description", "Quantity", "Unit Price", "Total"],
    "data": [
      ["Consulting Hours", "40", "€150", "€6,000"],
      ["Software License", "1", "€5,000", "€5,000"],
      ["Support Package", "12", "€125", "€1,500"]
    ]
  }
}

Image Variables for logos and signatures:

{
  "companyLogo": {
    "type": "image",
    "src": "https://your-cdn.com/logo.png",
    "width": 200,
    "align": "center"
  }
}

Creating a Bulk Render Job

The POST /bulk-render endpoint accepts a JSON payload with your template document ID, output format, and an array of variable sets.

Basic Bulk Render Request

curl -X POST "https://api.autype.com/api/v1/dev/bulk-render" \
  -H "X-API-Key: $AUTYPE_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "documentId": "550e8400-e29b-41d4-a716-446655440000",
    "format": "PDF",
    "items": [
      {
        "clientName": "Acme Corporation",
        "invoiceDate": "2024-01-15",
        "totalAmount": "€12,500.00"
      },
      {
        "clientName": "Beta Industries",
        "invoiceDate": "2024-01-15",
        "totalAmount": "€8,750.00"
      },
      {
        "clientName": "Gamma Solutions",
        "invoiceDate": "2024-01-15",
        "totalAmount": "€15,200.00"
      }
    ]
  }'

The response includes a bulkJobId for tracking:

{
  "bulkJobId": "bulk_abc123def456",
  "status": "PENDING",
  "format": "PDF",
  "totalItems": 3,
  "completedItems": 0,
  "failedItems": 0,
  "createdAt": "2024-01-15T10:30:00.000Z"
}

Using Files for Bulk Data

For large batches, uploading a CSV or Excel file is more practical than embedding data in JSON. The POST /bulk-render/file endpoint accepts multipart form data:

curl -X POST "https://api.autype.com/api/v1/dev/bulk-render/file" \
  -H "X-API-Key: $AUTYPE_API_KEY" \
  -F "file=@invoices.csv" \
  -F "documentId=550e8400-e29b-41d4-a716-446655440000" \
  -F "format=PDF"

Your CSV file should have column headers matching your variable names:

clientName,invoiceDate,totalAmount
Acme Corporation,2024-01-15,€12,500.00
Beta Industries,2024-01-15,€8,750.00
Gamma Solutions,2024-01-15,€15,200.00

Implementing Webhook Callbacks

Polling works for small batches, but webhooks are essential for production systems. When you include a webhook configuration, Autype sends a POST request to your URL when the job completes or fails.

Webhook Configuration

Add the webhook object to your bulk render request:

curl -X POST "https://api.autype.com/api/v1/dev/bulk-render" \
  -H "X-API-Key: $AUTYPE_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "documentId": "550e8400-e29b-41d4-a716-446655440000",
    "format": "PDF",
    "items": [...],
    "webhook": {
      "url": "https://your-app.com/webhooks/autype/bulk-complete",
      "headers": {
        "X-Webhook-Secret": "your-webhook-secret"
      }
    }
  }'

Handling Webhook Payloads

Your webhook endpoint receives a POST with the job status:

{
  "bulkJobId": "bulk_abc123def456",
  "status": "COMPLETED",
  "format": "PDF",
  "totalItems": 100,
  "completedItems": 98,
  "failedItems": 2,
  "downloadUrl": "https://api.autype.com/api/v1/dev/bulk-render/bulk_abc123def456/download?token=signed-token",
  "completedAt": "2024-01-15T10:35:22.000Z"
}

A typical webhook handler in Node.js:

// Express.js webhook handler
app.post('/webhooks/autype/bulk-complete', async (req, res) => {
  const { bulkJobId, status, downloadUrl, completedItems, failedItems } = req.body;

  // Verify webhook secret
  const secret = req.headers['x-webhook-secret'];
  if (secret !== process.env.WEBHOOK_SECRET) {
    return res.status(401).send('Invalid secret');
  }

  if (status === 'COMPLETED') {
    console.log(`Bulk job ${bulkJobId} completed: ${completedItems} successful, ${failedItems} failed`);

    // Download the ZIP file
    const response = await fetch(downloadUrl);
    const buffer = await response.buffer();

    // Process the ZIP (store in S3, send to users, etc.)
    await storeDocuments(bulkJobId, buffer);

    // Trigger next workflow step
    await notifyComplete(bulkJobId, completedItems, failedItems);
  } else if (status === 'FAILED') {
    console.error(`Bulk job ${bulkJobId} failed`);
    await alertTeam(bulkJobId);
  }

  res.status(200).send('OK');
});

Polling for Job Status

If webhooks are not an option, poll the status endpoint:

curl "https://api.autype.com/api/v1/dev/bulk-render/bulk_abc123def456" \
  -H "X-API-Key: $AUTYPE_API_KEY"

Response when processing:

{
  "bulkJobId": "bulk_abc123def456",
  "status": "PROCESSING",
  "format": "PDF",
  "totalItems": 100,
  "completedItems": 45,
  "failedItems": 0,
  "createdAt": "2024-01-15T10:30:00.000Z"
}

Response when complete:

{
  "bulkJobId": "bulk_abc123def456",
  "status": "COMPLETED",
  "format": "PDF",
  "totalItems": 100,
  "completedItems": 100,
  "failedItems": 0,
  "downloadUrl": "https://api.autype.com/api/v1/dev/bulk-render/bulk_abc123def456/download?token=...",
  "completedAt": "2024-01-15T10:35:22.000Z"
}

Implementing Exponential Backoff Polling

For production systems, implement exponential backoff:

import time
import requests

def wait_for_bulk_job(bulk_job_id, api_key, max_wait_seconds=600):
    base_url = "https://api.autype.com/api/v1/dev"
    headers = {"X-API-Key": api_key}

    wait_time = 2  # Start with 2 seconds
    elapsed = 0

    while elapsed < max_wait_seconds:
        response = requests.get(
            f"{base_url}/bulk-render/{bulk_job_id}",
            headers=headers
        )
        data = response.json()

        if data["status"] == "COMPLETED":
            return data["downloadUrl"]
        elif data["status"] == "FAILED":
            raise Exception(f"Bulk job failed: {data.get('error')}")

        # Still processing, wait and retry
        time.sleep(wait_time)
        elapsed += wait_time
        wait_time = min(wait_time * 1.5, 30)  # Cap at 30 seconds

    raise TimeoutError(f"Bulk job did not complete within {max_wait_seconds} seconds")

Downloading the Results

When a bulk job completes, download the ZIP file containing all rendered documents:

# Using the signed download URL (no API key needed)
curl -o batch.zip "https://api.autype.com/api/v1/dev/bulk-render/bulk_abc123def456/download?token=..."

# Or with API key authentication
curl -o batch.zip \
  -H "X-API-Key: $AUTYPE_API_KEY" \
  "https://api.autype.com/api/v1/dev/bulk-render/bulk_abc123def456/download"

The ZIP file structure preserves order, with documents named by their index:

batch.zip
├── document_001.pdf
├── document_002.pdf
├── document_003.pdf
└── ...

Error Handling and Retry Logic

Production pipelines need robust error handling. Bulk jobs can have partial failures where some documents succeed and others fail.

Handling Partial Failures

Check the failedItems count in the webhook payload or status response:

if (data.failedItems > 0) {
  // Log which items failed
  console.warn(`${data.failedItems} documents failed to render`);

  // Your retry logic here
  const failedIndices = await identifyFailedItems(data.bulkJobId);
  await retryFailedItems(failedIndices);
}

Validation Before Submission

Use the validation endpoint to catch errors before submitting a bulk job:

curl -X POST "https://api.autype.com/api/v1/dev/render/validate" \
  -H "X-API-Key: $AUTYPE_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "config": {
      "document": { "type": "pdf" },
      "variables": { "testVar": "value" },
      "sections": [...]
    }
  }'

Response for invalid documents:

{
  "valid": false,
  "errors": [
    {
      "path": "sections.0.content.2.text",
      "message": "Variable {{undefinedVar}} not found in variables object",
      "code": "UNDEFINED_VARIABLE"
    }
  ]
}

Performance Considerations

Bulk rendering performance depends on document complexity. For typical business documents:

Document Size	Batch of 10	Batch of 50	Batch of 100
5 pages	4 seconds	15 seconds	28 seconds
20 pages	12 seconds	45 seconds	85 seconds
50 pages	25 seconds	90 seconds	180 seconds

Each bulk render item costs 4 credits (vs. 5 for single renders), making bulk rendering both faster and more cost-effective for batches.

Real-World Example: Monthly Invoice Generation

Here is a complete example generating monthly invoices from a CRM export:

import fs from 'fs';
import fetch from 'node-fetch';

const API_KEY = process.env.AUTYPE_API_KEY;
const BASE_URL = 'https://api.autype.com/api/v1/dev';

async function generateMonthlyInvoices(invoiceData, templateId) {
  // Submit bulk job
  const response = await fetch(`${BASE_URL}/bulk-render`, {
    method: 'POST',
    headers: {
      'X-API-Key': API_KEY,
      'Content-Type': 'application/json'
    },
    body: JSON.stringify({
      documentId: templateId,
      format: 'PDF',
      items: invoiceData,
      webhook: {
        url: 'https://api.mycompany.com/webhooks/invoices/complete',
        headers: { 'X-Internal-Secret': process.env.INTERNAL_SECRET }
      }
    })
  });

  const job = await response.json();
  console.log(`Started bulk job ${job.bulkJobId} with ${job.totalItems} invoices`);

  return job.bulkJobId;
}

// Load invoice data from CSV export
const csvData = fs.readFileSync('./monthly_invoices.csv', 'utf8');
const invoices = parseCsv(csvData);

// Generate all invoices
generateMonthlyInvoices(invoices, '550e8400-e29b-41d4-a716-446655440000');

Summary

Autype's bulk rendering API provides the foundation for scalable document automation. Key takeaways:

Submit once, render in parallel - Jobs process asynchronously with up to 100 documents per batch
Use webhooks - Eliminate polling in production; let Autype notify you when work completes
Validate early - Catch template errors before submitting large batches
Handle partial failures - Monitor failedItems and implement retry logic for failed documents
Leverage file uploads - CSV and Excel support simplifies large batch submission

The combination of parallel processing, webhook notifications, and flexible variable types makes this API suitable for everything from monthly invoice runs to real-time contract generation in your sales pipeline.

For more details on the document JSON schema and variable types, see the Autype API documentation.

Word Is for Writers. LaTeX Is for Academics. Neither Is for Developers.

Kevin — Sat, 07 Mar 2026 10:17:56 +0000

There's a third option, and it lives in the editor you already have open.

Pick any developer who regularly writes documents longer than a README. Ask them what they use. You'll get one of three answers: Word (reluctantly), Google Docs (with apologetic hand-waving about version control), or LaTeX (with the haunted look of someone who has debugged one too many undefined control sequence errors at midnight).

None of them will say they enjoy it. The reason is simple: all three tools were built for someone else.

The Wrong Tools for the Job

Word was designed for typing letters. Its fundamental model (WYSIWYG editing where formatting is baked directly into the document) hasn't changed since the early nineties. That works fine if you need to print a letter. It falls apart when you need to version-control a contract, keep styling consistent across a 30-page document touched by six people, or reproduce the same report next quarter without reformatting it from scratch.

LaTeX is the other extreme. Structurally brilliant, genuinely painful to use. The syntax is verbose and unforgiving. Error messages are famously useless. There is no live preview: you compile, wait, check what broke, fix it, compile again. Nobody who isn't forced to use it chooses it voluntarily in 2026.

The gap between these two is where most developers are stuck.

Markdown Was Already the Answer (Partly)

Developers already solved the documentation problem with Markdown. It's plain text, version-controllable, readable without rendering, writable in any editor. READMEs, changelogs, docs sites, pull request descriptions: all Markdown. No proprietary format, no binary blobs, no formatting drift when someone else opens the file.

The limitation is that standard Markdown was never designed for professional output. No page layouts, no headers and footers, no auto-numbered figures, no equations, no styled tables, no citations. For a README it's enough. For a quarterly report, a scientific paper, or a client-facing specification it isn't.

That's the gap Autype closes.

Why Not Just Use LaTeX for Serious Documents?

This is the reasonable counterargument. LaTeX does have proper content-layout separation. Its output quality is excellent. Cross-references and bibliographies are handled correctly by default. There's a reason it's still the standard in academic publishing.

The problem is the entry cost and the daily friction. Setting up a working LaTeX environment (distribution, packages, compiler, editor) is its own project before you've written a single word. The workflow is a loop of write-compile-debug that never fully goes away. And when someone outside your team needs to edit or comment on the document, you're converting to DOCX via Pandoc and hoping for the best.

With Autype, equations use the same LaTeX syntax ($$E = mc^2$$). The output quality is comparable. But the rest of the document is normal Markdown, the setup is an extension install and an API key, and exporting to DOCX is a single click. You keep the math without the ceremony.

What Extended Markdown Actually Looks Like

Autype's syntax is a strict superset of standard Markdown. Everything you already write keeps working. What's added is the layer that turns a text file into a print-ready document.

This is a single excerpt from the business report example that ships with the extension:

## Revenue Overview {#revenue-overview}

Total revenue for Q4 {{fiscalYear}} was **$4,215,000**, driven by strong
performance across all product lines.

:::chart{type="bar" title="Quarterly Revenue ($K)" caption="Revenue by Quarter" anchor="fig-revenue"}
labels: Q1, Q2, Q3, Q4
dataset: Subscription | 1850, 2100, 2450, 3035 | #3b82f6
dataset: Services     |  720,  810,  980, 1180 | #22c55e
:::

As shown in [Figure {num}](#fig-revenue), subscription revenue grew
consistently throughout the year. The quarter-over-quarter growth rate:

$$
\text{QoQ Growth} = \frac{R_{Q4} - R_{Q3}}{R_{Q3}} \times 100\% = 22.9\%
$$

:::table{caption="Financial Summary" anchor="tab-financial"
         headerBg="#1e293b" headerColor="#ffffff" rowAltBg="#f8fafc"}
| Metric            | Q3 2024    | Q4 2024    | Change  |
|-------------------|------------|------------|---------|
| Total Revenue     | $3,430,000 | $4,215,000 | +22.9%  |
| Gross Margin      | 75.0%      | 78.0%      | +3.0 pp |
| Operating Margin  | 15.2%      | 18.5%      | +3.3 pp |
:::

See [Table {num}](#tab-financial) for the full breakdown.

{{fiscalYear}} is a variable substituted at render time. The bar chart is defined inline (no Excel, no screenshot). The equation is rendered as proper print-quality typography. The styled table has a dark header, alternating rows, a caption, and an anchor. The cross-references ([Figure {num}], [Table {num}]) resolve to sequential numbers in the rendered document, the same way LaTeX's \ref{} works, without the setup cost.

The full set of supported elements: bar, line, pie, doughnut, radar, scatter, bubble, and polar area charts; LaTeX math; styled tables with captions and anchors; QR codes (URL, WiFi, vCard); auto-generated table of contents, list of figures, list of tables, list of abbreviations, bibliography; multi-column layouts; page breaks with optional orientation changes; cross-references; headers and footers with logos and page numbers. All plain text.

The VS Code Extension

The Autype extension makes this workflow native to VS Code. Open a Markdown file, click Render, and the PDF appears in a side panel next to your editor.

A project is a folder with an autype.json config alongside your content files:

my-report/
├── autype.json      ← page size, margins, fonts, headers, footers, variables
├── report.md        ← main document
├── appendix.mdd     ← additional document in the same project
└── images/          ← local images, uploaded and cached automatically

A folder can contain any number of .md and .mdd files. Each renders as an independent document, but all share the same autype.json. A project folder can hold a main report, an executive summary, and an appendix, all with identical styling and zero config duplication.

autype.json is where the design lives: font family, sizes, colors, heading hierarchy, header (logo and document title), footer (page numbers), variables. Content and design are completely separate. Change the font or update the logo without touching the Markdown. Commit both to git, and the exact output is reproducible by anyone with the extension installed.

The insert toolbar

The preview panel has a vertical toolbar with one-click inserts for every extended element: headings, bold, italic, images, charts, styled tables, math equations, QR codes, page breaks, column layouts, variables, table of contents, list of figures, list of tables, and more. Every insert drops a ready-to-edit block into the document at the cursor position. You don't need to memorize the syntax to get started.

Local images

Drop an image into the images/ folder and reference it with a standard Markdown path: ![caption](images/logo.png). On the first render, the extension uploads it to the rendering API and caches it by content hash. Unchanged images aren't re-uploaded on subsequent renders. The path in the Markdown stays local and relative; the file is part of the repository.

Automatic indices and cross-references

::toc generates a table of contents from the actual headings. ::listOfFigures and ::listOfTables produce numbered lists of every captioned figure and table. Every chart, captioned image, and styled table gets an auto-incremented number you can reference with [Figure {num}](#anchor) or [Table {num}](#anchor). The numbers stay correct regardless of what gets added or reordered before them. Bibliography citations work the same way: define sources in autype.json, cite inline with @[id], and the reference list is generated automatically.

Getting started

Install Autype for VS Code from the Marketplace
Create a free account at app.autype.com and copy your API key
Run Autype: Set API Key from the command palette (Cmd+Shift+P) and paste it in
Right-click any folder in the Explorer and choose Autype: Create New Document to scaffold the project (creates autype.json, a .mdd file, and an images/ folder)
Open the .mdd file, click the Autype icon in the editor title bar, and hit Render

The extension connects to Autype's rendering API. The free plan covers unlimited preview renders (watermarked) and rate-limited PDF exports. No credit card required.

Export: PDF, DOCX, and ODT

The most common objection to Markdown-based documents is: "My colleagues work in Word." Fair point. It's not a problem.

Autype exports the same document as PDF, DOCX, and ODT. The DOCX output is a proper Word document: it opens in Microsoft Word, LibreOffice, and Google Docs, can be edited further, and preserves formatting. The developer writes in Markdown in VS Code, the colleague in the business team gets a DOCX they can annotate and return, the client gets a PDF. All three come from the same source file.

This is also the practical advantage over LaTeX for most teams. Converting a LaTeX document to an editable DOCX is a project in itself. In Autype it's a dropdown in the export panel.

Documents Belong in the Repository

Because the document is plain text, it fits naturally into a git workflow. The report lives in the same repo as the code it describes. Changes are commits. Drafts are branches. Reviews are pull requests, with real diffs, inline comments, and approvals. git blame shows who changed the revenue figures and when. The autype.json that defines the visual design is committed alongside the content, so the output is reproducible by anyone with the extension.

A .docx file can't do any of this. Word documents are binary blobs with no meaningful diff, no merge strategy, and no version history that doesn't require SharePoint.

Word and LaTeX aren't going anywhere. If you write one document a quarter and don't care about reproducibility or version control, switching tools isn't worth the effort.

But if you write documents regularly as part of a development workflow (reports, specs, API references, papers, anything that needs to look professional and survive review cycles), the friction you've been absorbing isn't inherent to the problem. It's just a consequence of using tools built for different people.

The documentation is at docs.autype.com. The full syntax reference is at https://docs.autype.com/markup-reference/overview.

Save Hours of Document Work with n8n and Autype: Automatic Watermarking and PDF Protection

Kevin — Thu, 05 Mar 2026 12:33:13 +0000

tl;dr: Every time someone uploads a PDF to a Google Drive folder, this n8n workflow automatically creates two secured versions: one with a diagonal "CONFIDENTIAL" watermark, one password-protected. Both are saved back to Drive. No code, no manual steps, no re-uploading. It runs in the background, every minute, forever.

Most teams have a document problem they don't even recognize as one yet.

Someone exports a contract as PDF. Sends it to a colleague to review. That colleague pastes it into an email without a watermark. Someone forwards it externally. Now your internal draft is sitting in a client's inbox with no indication that it was never meant to leave the building.

The fix isn't a policy memo. It's automation.

In this post I'll walk you through a concrete n8n workflow that watches a Google Drive folder and automatically produces a watermarked and a password-protected version of every new PDF that lands there. Using Autype for the document processing and the n8n Google Drive Trigger, the whole thing takes about 10 minutes to set up and then runs completely hands-free.

This is part of an ongoing series on document automation with n8n and Autype. More workflows are coming.

The Problem with Manual Document Security

Watermarking a PDF manually is a solved problem in the same way that manually backing up files is a solved problem: technically feasible, practically never done consistently.

You need a PDF editor. You open the file. You add the watermark. You export again. You remember to also add a password. You do this for every document. Every time. Or you don't, and you hope nothing goes wrong.

The real cost isn't the 3 minutes per document. It's the 100% probability that someone on your team skips it eventually because they were in a hurry, because they forgot, or because nobody told them the process changed.

Automation removes the human variable. If the workflow runs, the file is secured. No exceptions.

What the Workflow Does

The workflow triggers automatically whenever a new PDF appears in a watched Google Drive folder. From there:

The PDF is downloaded and uploaded to Autype´s Document API (a single upload, the file ID is reused by both branches)
In parallel, two operations run:
- Watermark branch: a diagonal "CONFIDENTIAL" stamp is applied and the result is saved back to Drive as filename-watermark.pdf
- Protection branch: the PDF is encrypted with a user password and an owner password, then saved as filename-protected.pdf

Both outputs land in the same Google Drive folder within seconds. The original file stays untouched.

The parallel structure matters here: instead of watermarking first and then re-uploading the watermarked file for protection (which adds a full round-trip), both operations work from the same uploaded file ID simultaneously. The result is faster and cleaner.

Setting It Up

You need three things before you start:

A self-hosted n8n instance
An Autype account with an API key (free tier works)
The n8n-nodes-autype community node installed via Settings > Community Nodes

Step 1: Google Drive Trigger

Set the trigger to watch a specific folder for the fileCreated event. Replace YOUR_FOLDER_ID with the ID from your folder URL (https://drive.google.com/drive/folders/YOUR_FOLDER_ID). The trigger polls every minute by default.

Step 2: Download and Upload to Autype

After the trigger fires, a Google Drive node downloads the file binary. That binary goes straight into the Autype File Upload node. The upload returns a file ID that both parallel branches use.

Step 3: Watermark Branch

The Add Watermark node takes the file ID and stamps "CONFIDENTIAL" diagonally across every page at 30% opacity, 45-degree rotation, font size 50. All of this is configurable.

The output binary goes directly to a Google Drive upload node. The filename is derived from the original using an n8n expression:

{{ $('Download PDF from Drive').item.json.name.replace(/\.pdf$/i, '') }}-watermark.pdf

No Code node needed. Just an expression in the filename field.

Step 4: Protection Branch (runs in parallel)

The Password-Protect node uses the same Autype file ID from the upload. It encrypts the PDF with a user password (required to open) and an owner password (required to change permissions or print).

Same filename expression, different suffix:

{{ $('Download PDF from Drive').item.json.name.replace(/\.pdf$/i, '') }}-protected.pdf

Both branches save their outputs to the same Google Drive folder as the original. Three files in, three files out.

You can find the full workflow JSON here: Get Workflow JSON

What You Can Customize

This workflow is deliberately minimal. Here's where to extend it:

Change the watermark text to your company name, "DRAFT", "INTERNAL USE ONLY", or anything else
Adjust watermark style (opacity, rotation, font size) directly in the Autype node parameters
Use separate input and output folders if you want to keep the originals in one place and the secured versions somewhere else
Add a compression step before the Drive upload to keep file sizes manageable for email workflows
Replace the Google Drive Trigger with a webhook, an email trigger, or a Slack event if your documents arrive through a different channel

Google Docs Is a Toy. Here's What Professionals Actually Need.

Kevin — Wed, 04 Mar 2026 20:13:06 +0000

Google Docs works great for drafts, meeting notes, and quick sharing. The moment your work actually matters, its limitations become impossible to ignore.

TL;DR: Google Docs is excellent at what it was designed for: lightweight, shareable text editing in a browser. But version control is primitive, citation management does not exist, custom styling breaks constantly, and automation requires a workaround on top of a workaround. If you are producing documents that represent your work to the outside world, you need a platform that was built for that purpose. Autype is one option. This article explains why the gap exists.

Google Docs has 3 billion users. It is free, it runs in a browser, and it syncs in real time. For a large share of those 3 billion people, those three things are all they need.

But there is a category of documents where "good enough for a browser app" is not the bar. Client reports. Research papers. Technical specifications. Legal contracts. Investor-facing materials. These documents carry weight. They reflect directly on the person or organization that produced them. And Google Docs, for all its convenience, consistently fails them in specific and predictable ways.

Not because Google Docs is badly built. Because it was built for a different purpose.

The Version History Problem

Google Docs has version history. You can see it, restore from it, and even name specific versions. So what is the problem?

The problem is granularity and control. Google Docs creates automatic saves constantly, but the version list quickly becomes hundreds of unnamed entries with timestamps like "April 3, 10:47 AM." There is no way to create a structured checkpoint before a major rewrite. No way to leave a note explaining why a version matters. No diff view that shows you what actually changed between two states.

If you share a document for client review, make revisions based on their feedback, then receive more feedback two weeks later that contradicts the first round, recovering the exact state of the document from before either round of changes requires scrolling through a timeline of dozens of unlabeled saves and hoping you can identify the right one visually.

Professional version control means named snapshots with optional notes, a clear diff view showing exactly what changed, and one-click rollback to any point. Autype's version history works this way: automatic versions are created in the background, manual named versions can be saved at any time (before sending to a client, after a major revision, before a meeting), and the diff view compares any two versions side by side in Markdown or JSON format.

This is not a premium feature. It is how version control should work for documents, in the same way it works for code.

Citations Do Not Exist in Google Docs

If you are writing anything that requires references, Google Docs' built-in citation support is so limited it is almost satirical. The native citation tool supports a handful of styles, requires manual entry for every source, and produces no bibliography that updates automatically when you remove a reference.

The real-world workflow for most academics and researchers using Google Docs: write in Google Docs, manage citations in Zotero or Mendeley, use a Google Docs plugin that connects to the reference manager, hope the plugin still works after the last Google Docs update, export to Word, fix whatever the plugin broke, submit. This is not a workflow. It is a series of workarounds duct-taped together.

A purpose-built document platform handles the full citation lifecycle natively. In Autype: import your bibliography from BibTeX, RIS, or Zotero export in one step. Cite inline with @[smith2023]. Add page locators with @[smith2023, p. 42]. Change the citation style globally from APA to IEEE or Chicago with a single dropdown. The bibliography generates automatically and only includes sources that are actually cited. Broken citations are flagged in real time before you export.

This result aligns with prior findings @[jones2022, pp. 14-16].

...

::bibliography{title="References"}

That is the entire workflow. One syntax, one place, no plugins. For Management of your sources you can import bibtex or CSL-Json entries and lists or just add a source manually:

Styling Is a Constant Battle

Open a Google Doc that three people have edited over three months. Count the different font sizes in the body text. Count the different heading styles. Count the tables that each look slightly different because someone pasted content from outside.

Google Docs has "styles" in the sense that you can define Heading 1, Heading 2, and Normal Text. But applying them consistently across a document that multiple people have touched is a manual and ongoing task. There is no concept of a global style preset that enforces consistent spacing, fonts, colors, and heading behavior across all documents in an organization.

The result is that every "professional" document produced in Google Docs carries the visual fingerprint of having been edited by multiple people with different habits. The solution in most organizations is a PDF export that someone manually reformats before it goes to a client.

With Autype, the style is defined once as a JSON configuration: font family, font size, heading styles, line height, colors, headers with logos, footers with page numbers. That style is applied consistently across every document in the organization. No individual can accidentally break it by pasting in content with different formatting. The output always looks like it came from the same place.

{
  "defaults": {
    "fontFamily": "Inter",
    "fontSize": 11,
    "lineHeight": 1.4,
    "header": {
      "left": { "type": "image", "src": "logo.png", "width": 80 },
      "right": { "type": "text", "content": "{{documentTitle}}" }
    },
    "footer": {
      "right": { "type": "text", "content": "Page {{pageNumber}} of {{totalPages}}" }
    }
  }
}

Define it once. Every document looks right, automatically. You can simply use the Style-Editor (With AI integration to generate a style in seconds)

Automation Requires a Workaround Stack

If you need to generate documents from data, Google Docs has Google Apps Script. Which means you are writing JavaScript that calls Google's API to manipulate document structure, managing authentication tokens, dealing with rate limits, and debugging a scripting environment that exists largely outside of standard developer tooling.

For anything beyond basic mail merge, this approach breaks down quickly. Dynamic charts from live data: not supported without a plugin. Multi-format output from one template: not supported. Bulk generation of 100 personalized documents from a CSV: not supported natively. Webhook-triggered document generation when a form is submitted: requires a chain of Google services.

An API-first document platform handles all of these as first-class capabilities. With Autype's REST API, you send a JSON payload and receive a rendered PDF, DOCX, or ODT. Template variables fill dynamically. Bulk jobs generate up to 100 personalized documents per run from CSV or spreadsheet data. Webhooks fire when jobs complete. No script environments, no authentication workarounds.

The integration with n8n, Make.com, or any HTTP-capable platform takes minutes, not days.

Real-Time Collaboration That Does Not Create Chaos

Google Docs' real-time collaboration is genuinely excellent for its original use case: multiple people writing a shared document together. But it has no mechanism for structured review workflows. Comments exist, but there is no way to formally request a review, track which comments have been addressed, or manage an approval flow.

In practice, teams using Google Docs for professional document workflows end up adding process on top: a Slack message saying "I've left comments in the doc," a spreadsheet tracking which feedback was addressed, a manual email when the document is ready for the next round.

Autype's collaboration model includes line-anchored threaded comments with resolve and deleted states and real-time sync built on CRDT technology (the same approach used in the most advanced collaborative editors) that means no merge conflicts even with many concurrent users.

The difference is not the technology. It is whether collaboration was designed into the document model from the start or added on top of a single-user writing tool.

What Google Docs Is Actually Good For

None of this means Google Docs is a bad product. It is an outstanding product for what it was designed to do: quick documents, meeting notes, shared drafts, lightweight collaboration without any setup. For a significant portion of document work, it is the right tool.

The mistake is using it for documents where it was never designed to perform. When formatting consistency matters. When citations need to be correct. When the output represents you to a client or a committee. When the document needs to be generated from data, not typed by hand. When version history needs to mean something.

That is where the gap between a convenient browser app and a purpose-built document platform becomes unavoidable.

Autype is a professional document editor and generation API with real-time collaboration, version history, citation management, and automation. Start free at app.autype.com.

The Next Generation of Actually Useful Micro-SaaS Ideas (2026 Edition)

Kevin — Tue, 03 Mar 2026 21:40:47 +0000

Document automation is the infrastructure layer most indie hackers are ignoring. Here is why that is a mistake, and five ideas you can build this weekend.

TL;DR: Most micro-SaaS ideas die because the hard part (generating a polished, client-ready PDF or DOCX output) takes months to build. Document automation APIs like Autype eliminate that entirely. On the input side, tools like Mistral OCR and markitdown handle converting messy real-world documents into clean, LLM-readable Markdown. But the real differentiator is not the renderer. It is combining your personal domain expertise with the right data sources (Google Trends, Perplexity, industry APIs) and LLMs to build something that actually earns its price tag.

There is a pattern in the micro-SaaS graveyard that nobody talks about enough. The idea is fine. The landing page looks great. The founder validated demand in three Reddit threads. And then they spend four months building a custom PDF renderer, fighting Puppeteer's page break behavior, and debugging font embedding across operating systems. By the time they ship, they are burnt out and the market has moved.

The problem is not the idea. It is choosing the wrong infrastructure layer to fight on.

Document generation is one of those problems that looks simple from the outside ("just export a PDF, how hard can it be?") and turns into a full-time engineering project the moment you try to do it properly. Professional layout, consistent fonts, page numbering, headers and footers, dynamic charts, template variables, bulk rendering for hundreds of clients at once. Each of these is a solved problem, just not one you should be solving yourself.

But there is a second, more interesting problem worth unpacking before we get to the ideas.

The Real Differentiator Is Not the Output Format

Every one of the micro-SaaS tools listed below has one thing in common with its competitors: they all produce a PDF at the end. The rendering is table stakes. What actually separates a $5,000 MRR product from a dead side project is what goes into the document before it gets rendered.

The blueprint that consistently works looks like this:

Your domain expertise tells you what information belongs in the document and what structure makes it credible. A business plan written by someone who has pitched investors looks different from one produced by a generic template engine. A market analysis report written by someone who understands how to read Google Trends data is worth something. A compliance document built by someone who has actually navigated GDPR is trusted more than one generated from a boilerplate.

Real data sources make the output dynamic instead of static. Instead of asking the user to fill in a market size field, you pull it from a live API. Instead of a generic competitive landscape section, you run a Perplexity deep research query against the user's niche and summarize the results. Instead of a blank financial projections table, you pre-populate it with industry benchmarks from a data provider. And if the user has existing documents to bring in (old contracts, prior reports, scanned forms), tools like Mistral OCR or Microsoft's markitdown convert them into clean, structured Markdown that an LLM can actually work with. The user provides direction. The tool provides research and context.

LLMs do the heavy lifting on content generation. The user provides a few key inputs. An LLM (GPT, Claude, Gemini) drafts the sections, in a structured JSON format that maps directly to your document template. You review, adjust, and export. The LLM is not writing a Word document. It is filling variables in a structured schema that Autype renders into a professional PDF.

Put these three things together and you have a product that is genuinely hard to replicate. Not because the technology is complex, but because the expertise behind the prompts, the data connections, and the document structure is yours.

Here are five concrete ideas that apply this blueprint, each built on document automation infrastructure you do not have to build yourself.

1. Business Plan Generator (with Live Market Data)

The pitch: A founder answers ten questions about their business. The tool pulls current market size data, runs a Perplexity query on the competitive landscape, and generates a structured, investor-ready business plan PDF in under two minutes.

Why it works: Business plans have a well-defined structure. But the generic versions all look identical because they contain only what the user typed in. The interesting version enriches each section automatically: market size from Statista or SimilarWeb, competitor analysis from a Perplexity deep research call, trend data from Google Trends API, and financial projections built from industry benchmark databases.

The LLM takes these inputs and generates the prose for each section, structured as JSON variables. Autype renders the final document with consistent formatting, a cover page, financial tables with alternating row styling, and a chart showing projected revenue growth.

{
  "variables": {
    "companyName": "Acme Inc",
    "targetMarket": "SMB accounting teams",
    "marketSizeData": { "type": "table", "columns": ["Region", "TAM", "CAGR"], "data": [
      ["Europe", "$4.2B", "14%"],
      ["North America", "$6.8B", "11%"]
    ]},
    "competitorSummary": "Based on current search trends and market activity, the three primary competitors are...",
    "projectedRevenue": { "type": "table", "columns": ["Year", "ARR", "Customers"], "data": [
      ["2025", "$120k", "200"],
      ["2026", "$480k", "800"],
      ["2027", "$1.2M", "2000"]
    ]}
  }
}

What you charge: $29 one-time per plan, or $49/month for unlimited plans with live data refreshes. The cost per render is a few cents. The research automation is worth hours to the user.

2. Niche Market Research Reports

The pitch: A user enters a product niche or industry vertical. The tool automatically compiles a structured market research report: Google Trends data for search volume over time, a Perplexity deep research summary of the competitive landscape, Reddit and forum sentiment analysis, and a curated list of potential customers or distribution channels.

Why it works: This one requires almost no user input at all. The entire content pipeline is automated. Google Trends API provides the search interest chart. Perplexity handles competitor discovery and summarization. An LLM structures the findings into a coherent narrative. Autype renders a multi-section PDF report with embedded charts, a table of contents, and a one-page executive summary at the front.

The product is essentially a research assistant that delivers a formatted report instead of a wall of text. Analysts, consultants, and indie hackers pay for this because the alternative is three hours of manual research and then formatting it all in Word.

What you charge: $19 per report, or $79/month for unlimited reports. The data API costs are negligible at this volume.

3. Proposal Builder with Smart Scope Suggestions

The pitch: A freelancer enters a client name, project type, and a few bullet points about what they want to build. An LLM expands the scope into detailed deliverables, suggests a timeline, and generates a pricing table based on the project type and market rates. The result is a polished PDF proposal ready to send.

Why it works: Every freelancer sends proposals. Most of them are either embarrassingly basic (a Google Doc with inconsistent formatting) or take forever to produce (a carefully crafted Canva template that breaks every time the scope changes). The interesting version here is not a blank template with fields to fill in. It is a tool that actually understands what a web development project or a brand design project typically includes, and pre-populates the scope accordingly.

This is where domain expertise matters. The prompts that generate realistic deliverable lists, sensible timelines, and market-appropriate pricing need to be written by someone who has actually done the work. That is your moat. It cannot be replicated by someone who just spins up the same tech stack.

Autype handles the rendering: text variables for client details, table variables for the itemized pricing breakdown, list variables for the deliverables, and a structured layout with the freelancer's logo in the header.

What you charge: $19/month for unlimited proposals. Freelancers bill hundreds per hour. If your tool saves them two hours a month and makes their proposals look more credible, the math is obvious.

4. Automated Monthly Client Reports

The pitch: Connect to a client's data source (Google Analytics, Stripe, a database query, or even a simple CSV upload). Once a month, the tool automatically generates a branded PDF report with charts, key metrics, and an LLM-written narrative summary. The client gets a polished report delivered by email without the agency touching it.

Why it works: Agencies and consultants send monthly reports to every client. Most of them are manually assembled in PowerPoint or Google Slides, which takes two to four hours per client per month. At ten clients, that is a significant recurring cost that has no business still being manual in 2026.

The automation stack here is straightforward: a cron job pulls the data, an LLM writes a one-paragraph commentary on each key metric (with context about whether the numbers are good or bad for this specific industry), and Autype bulk-renders all ten client reports in a single job with different variable sets. Each report has the correct client logo, correct branding colors, and correct data.

What you charge: $49/month per workspace (covering multiple client reports). Agencies pay this without blinking because it saves them days of work per month.

5. Compliance Document Generator with Regulatory Monitoring

The pitch: Small businesses enter their company details and jurisdictions. The tool generates privacy policies, terms of service, and data processing agreements. When regulations change (GDPR updates, new US state privacy laws), users get notified and can regenerate updated documents with one click.

Why it works: This space has incumbents (Termly, iubenda, Docracy), but most of them produce documents that look like they were designed in 2009. The market is not won by having the best legal templates (none of us are lawyers anyway, and users understand this). It is won by having the cleanest output, the fastest time-to-document, and a monitoring layer that makes the subscription feel essential rather than optional.

The monitoring angle is what justifies the recurring revenue. A one-time PDF generator is a commodity. A service that watches regulatory changes via a legal news API or a Perplexity scheduled search, flags when your document templates need updating, and lets you regenerate with one click is a subscription product with genuine retention.

What you charge: $29/month for up to ten active documents with auto-update notifications.

The Blueprint

Strip away the specific niches and every one of these products follows the same structure:

Domain expertise defines what makes the output actually useful (not just formatted)
Data sources replace manual user input with live, enriched information (Google Trends, Perplexity, industry APIs, CRM integrations)
An LLM transforms the raw inputs into structured content, mapped to document variables
Autype renders the variables into a professional, consistently formatted PDF or DOCX via a single API call
Delivery happens via download link, email, or webhook to whatever the user needs

Steps 2, 3, and 5 are where your product differentiation lives. Step 4 is infrastructure. Autype handles step 4 with a single POST request, supports up to 100 documents per bulk job, delivers results via webhook when jobs complete, and works with n8n, Make.com, or any HTTP-capable automation tool if you want to skip writing backend code entirely.

The render cost per document is a few cents. The margin on a $49/month subscription is significant. The engineering time you save by not building a custom renderer is measured in months.

The Actual Moat

The business plan generator, the research report tool, the proposal builder: none of these are new ideas. Plenty of tools already do each of them. The ones that win are the ones built by people who understand the domain deeply enough to know what makes the output genuinely useful rather than just formatted.

Your advantage is not access to Autype's API or an LLM. Everyone has those. Your advantage is the ten years of freelancing experience that makes your proposal templates actually credible, the finance background that makes your projections tables structurally sound, or the legal familiarity that makes your compliance documents trustworthy.

The technology handles the output. The expertise makes it worth paying for.

Autype is a document generation API and editor for teams and developers. Render PDFs, DOCX, and ODT from JSON or Markdown with variables, charts, and bulk rendering built in. The API is free to try.