The one-line difference
DocRaptor is a hosted HTML→PDF service backed by PrinceXML. Send HTML + CSS, get a PDF back. makesPDF is the same shape — a hosted REST API — but the input surface is markdown or a compact DSL (not HTML), the output is PDF/A-2A + PDF/UA-1 by construction, and the API is built for AI agents from day one (public skill file, MCP server, x402 wallet payments).
Feature matrix
| DocRaptor | makesPDF | |
|---|---|---|
| Shape | Hosted REST API | Hosted REST API (/api/v1/*) |
| Engine | PrinceXML (HTML + CSS Paged Media) | Owned deterministic layout engine |
| Authoring surface | HTML + CSS | Markdown, builder DSL, JSON |
| Markdown-native | No | Yes (POST /api/v1/md) |
| Tagged PDF (PDF/UA-1) | Available, requires hand-tuned HTML | Yes, by construction |
| PDF/A archival | Yes (Prince-driven) | Yes (PDF/A-2A) |
| veraPDF-validated | Variable per template | Yes |
| Agent-first | No (REST + docs) | Yes — public skill file, MCP server |
| Wallet payments (x402) | No | Yes — $0.02 per render, no account needed |
| First-party CLI | No | Yes (@makespdf/cli) |
| Pricing model | Tiered monthly subscriptions | Pay-per-render credits + x402 wallet |
Same input, two outputs
DocRaptor — POST HTML:
curl https://docraptor.com/docs \
-H "Content-Type: application/json" \
-d '{
"user_credentials": "YOUR_API_KEY",
"doc": {
"test": false,
"document_type": "pdf",
"document_content": "<html><body><h1>Hello, Ada</h1><p>Welcome.</p></body></html>"
}
}' -o hello.pdf
makesPDF — POST markdown:
curl -X POST https://makespdf.com/api/v1/md \
-H "Authorization: Bearer $MAKESPDF_API_KEY" \
-H "Content-Type: application/json" \
-d '{"markdown": "# Hello, Ada\n\nWelcome."}' \
-o hello.pdf
Or pay per call with a wallet — no account, no key:
# x402 flow: GET returns 402 with payment requirements,
# the wallet client signs USDC, retries with PAYMENT-SIGNATURE header.
# Exact same response: a binary PDF.
Why people switch
- Markdown is the right input shape for most documents. You're rarely starting from polished HTML — you're starting from a database row, an LLM completion, or a report template. Markdown removes the CSS-print stylesheet from the loop.
- Compliance is structural. Getting PDF/UA-1 out of Prince usually means hand-rolled HTML with explicit semantic markup and a careful CSS-paged-media stylesheet. We tag by construction and validate against veraPDF every render.
- Agent-first. A public skill file any model can ingest, an MCP server, and a CLI binary that ships the skill offline make this trivial to wire into AI workflows. DocRaptor is REST + docs; the agent integration is on you.
- x402 wallet payments. Stateless agents can pay per render in USDC without ever creating an account. That's the path for marketplace agents, on-chain workflows, and anything that doesn't want the OAuth dance.
- Pay-per-render pricing. Credits + x402 means your bill scales linearly with use — no $X/month tier you stop hitting halfway through the cycle.
When DocRaptor is still the right call
- You have years of investment in a Prince/CSS-paged-media stylesheet that produces exactly the layout you want. Migrating that to markdown or our DSL is a project.
- You need specific Prince features (advanced CSS Paged Media, complex baseline grids, OpenType feature controls) we don't ship.
- You prefer the predictable monthly subscription to per-render credits.
For new projects — especially those involving AI generation, markdown-first content, or per-call billing — the markdown-native, agent-first surface is faster to integrate.
Migration
If your DocRaptor integration is generating HTML from a templating language (Liquid, Jinja, ERB), the cleanest move is to render markdown instead and POST to /api/v1/md. For documents that need precise tabular layout (invoices, receipts, statements) the builder DSL replaces the print stylesheet with a small typed surface, callable from any language via JSON.