Changelog

What's new in Inkrun.

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

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.