Changelog

What's new in Inkrun.

Releases, improvements and fixes — across the render pipeline, the REST API and the MCP server.

Document blocks: invoices, quotes and receipts from Markdown

Inkrun has always rendered Markdown literally: headings become headings, tables become tables. That is right for prose, and wrong for an invoice — which isn't prose at all, but a set of named regions. A masthead with your logo, two parties, a strip of reference fields, line items, a totals ladder, payment details.

Document blocks give those regions a vocabulary.

Added

  • Five document blocks — fences tagged ```masthead, ```parties, ```meta, ```totals and ```payment, using the same settings-and-table syntax as chart fences. Line items stay an ordinary Markdown table. Blocks work in every theme and inherit its palette and typography, so a custom theme restyles them for free.
  • An invoice theme — sans throughout, hairline dotted rules, borderless zebra line items, and a totals ladder that puts the amount due where the eye lands. Built for transactional documents: invoices, quotes, receipts, statements, purchase orders.
  • Computed totals — set compute: true, name your net and tax columns, and write {net}, {tax} or {gross} where the amounts go. Inkrun sums the line items and formats them for your currency and locale. This matters most when an agent writes the invoice: the model describes the work, Inkrun does the arithmetic.
  • Logos — a logo: URL in your frontmatter is fetched and embedded in the PDF. PNG, JPEG or WebP, verified by magic bytes rather than by file extension. An unreachable logo costs the document its logo, never the render.
  • Footer notesfooter_note: and footer_page_label: print a standing line on every page, for the registration or certification text business documents carry.
  • Document blocks reference — the full vocabulary, with a worked invoice.

Note

Inkrun renders a document that looks like an invoice; it does not issue one. Where invoicing is certified — Portugal's ATCUD, Italy's SdI and similar — legally valid invoices must come from certified software. Use these blocks for quotes, proposals, statements and receipts, or to render documents whose numbering comes from your invoicing system.

Document extraction, credits, and data controls

Inkrun closes the round trip: it has always turned Markdown into PDFs, and it can now turn PDFs back into structured data your agent can work with.

Added

  • Extraction APIPOST /api/v1/inspect reports what a document contains; POST /api/v1/extract pulls structured data out of it, including tables. Deterministic extraction handles clean digital PDFs; a model-assisted tier and an OCR fallback cover scans and awkward layouts.
  • Extractions dashboard — browse past extractions at /extractions, with filtering and per-extraction detail.
  • Credits — one meter for everything. Renders and extractions draw from a single monthly credit balance, with usage-based overage and a clearer tier ladder instead of a hard stop at the quota line.
  • Data retention controls — choose how long extraction inputs and outputs are kept, from the settings page or the API.
  • Data handling docs — a plain-language page on what Inkrun stores, for how long, and where.

Improved

  • Billing — plan changes now show a proration preview before you confirm, and invoices carry your billing address.

API completeness, rate limiting, and PDF email delivery

Added

  • Render history over the APIGET /api/v1/renders lists your renders with cursor pagination, and GET /api/v1/render/:id fetches a single render's status, metadata and download URL.
  • Email delivery — ask a render to be emailed on completion and Inkrun sends the finished PDF to the recipient for you; no more piping bytes into your own mailer.
  • API versioning policy — documented guarantees for what can and can't change under /api/v1.

Improved

  • Rate limiting — per-key request limits with standard 429 responses and Retry-After headers, so a runaway loop can't starve everyone else.
  • Input limits — Markdown size and structure caps with clear 413 errors, protecting render latency for well-behaved documents.
  • Templates API — create and manage templates over the public API, not just the dashboard.

Fixed

  • Coupons now apply correctly at checkout after pinning the Stripe API version the integration is tested against.

Docs site, template gallery, and GitHub sign-in

Added

  • Documentation site — a quickstart (curl → PDF in 60 seconds), a full render API reference, and step-by-step MCP setup guides for Claude Desktop, claude.ai and other MCP clients.
  • Template gallery — browse every built-in template at /templates-showcase, each with a live sample document you can render yourself.
  • Custom themes and cover pages — fork a built-in theme from the dashboard, adjust palette, typography and page margins, and design a full-bleed cover page in the visual editor.
  • GitHub sign-in — create an account or log in with GitHub alongside email and password.
  • Blog — playbooks for getting consistent, on-brand PDFs out of AI agents.

Improved

  • MCP OAuth discovery now lives at the standard /.well-known/oauth-authorization-server and /.well-known/oauth-protected-resource locations, so connectors find the endpoint without manual configuration.

Inkrun 1.0

Inkrun is live. One pipeline — Markdown → themed HTML → PDF — exposed three ways, so the thousandth document looks exactly like the first.

Added

  • Dashboard editor — write or paste Markdown, pick a template, preview and download the PDF from the browser.
  • REST APIPOST /api/v1/render with a sk_ API key returns a designed PDF (or JSON metadata with a download URL).
  • Remote MCP server — connect Claude Desktop, claude.ai or any MCP client and let your agent call create_pdf directly. OAuth for connectors, API keys for everything else.
  • Templates — theme, accent colour, fonts and page size live in the template; content never carries styling.
  • Plans and quota — a free tier with monthly included renders, paid plans via Stripe, and atomic quota accounting that holds up under concurrent renders.
  • Production hardening — renders run in a bounded worker pool (one Chromium per worker), with structured logs, health/readiness endpoints and optional Prometheus metrics.