rrweb VS DynamicDocumentAPI

rrweb's answer

Most session replay vendors are building on the engine we maintain. Choosing rrweb means owning that layer directly.

What that gets you in practice: events are plain JSON, so you store them in your own S3, Postgres or stream, keep them in the EU, and delete them on your own schedule. There's no lock-in at the recorder, because if you leave rrweb Cloud your recordings still replay in an open source player. And the plugin API lets you capture things a closed SaaS recorder will never expose, including canvas, WebGL and custom event types.

Where a competitor wins: if you want replay bundled with product analytics, error monitoring and heatmaps in one dashboard, and you never want to think about infrastructure, a full suite like PostHog or Sentry does more out of the box. Several of them sponsor rrweb, and we'd rather people use the right tool than the closest one.

DynamicDocumentAPI's answer:

Most document APIs do one thing: convert HTML to PDF, or fill templates. Dynamic Document API does both, adds image templates, PDF merging and validated e-invoices, and offers them through a REST API, SDKs for Node and Python, Zapier, Make, n8n and an MCP server for AI agents. Data is processed and stored in the EU only, files come back as signed links that expire, and storing nothing at all is a supported option. Pricing is predictable: one published credit table, the same core features on every paid plan and a spend cap you control. We also publish a render-time benchmark with its method and raw data, so you can check our speed instead of trusting a claim. The free plan includes 50 renders a month without a credit card.

rrweb's answer

Two groups.

Product engineers who need replay inside something they're already building: bug reporting, customer support tooling, QA, AI agent observability, interactive demos. They install the library, own the pipeline, and want format-level control.

Platform teams at companies whose product is replay, or includes it. Observability vendors, analytics suites, co-browsing and customer experience tools. They embed rrweb as the capture layer instead of writing a recorder from scratch, which takes years to get right across browsers, shadow DOM, canvas, iframes and web components.

DynamicDocumentAPI's answer:

Developers and product teams whose software has to send documents: invoices after a payment, certificates after a course, reports, labels and statements. Typical users are SaaS companies, marketplaces, e-commerce and learning platforms. A second group are businesses in Germany and the EU that need compliant e-invoices (XRechnung, ZUGFeRD) for the German B2B e-invoicing mandate and public-sector buyers. No-code builders use it through Zapier, Make and n8n, and teams building AI agents use the MCP server.

rrweb's answer

rrweb started in 2018 as one engineer's side project. Yanzhen Yu wanted to record and replay what users actually did in a browser, and published the result under MIT. There's a short documentary about how it came together, in Chinese with English subtitles.

Adoption moved faster than anyone planned for. A core team formed around the project in 2020, and Justin Halsall (Amsterdam), Eoghan Murray (Dublin) and Yun Feng (San Francisco) maintain it today alongside more than 100 contributors. The library now sits at close to 20,000 stars and powers the replay features inside some of the largest observability and analytics products on the market.

The awkward part of that success is that an MIT library carrying replay for billion-dollar companies was still being maintained on evenings and weekends. rrweb Cloud exists to fix that. It's the hosted version of the project, built by the maintainers, based in Amsterdam, and the logic is simple: revenue from Cloud pays for maintainer time on the open source library.

DynamicDocumentAPI's answer:

Almost every product eventually needs to produce documents, and most teams end up building their own rendering stack: a headless browser, fonts, page breaks, storage and retries. It works until an invoice splits a table row or a certificate shows the wrong date, and then it becomes a support ticket. We built Dynamic Document API to be that layer for them: templates, rendering and delivery as one service, hosted in Europe, treating pagination, fonts and formatting as engineering problems rather than edge cases. When e-invoicing became mandatory for B2B in Germany, we added validated XRechnung and ZUGFeRD output, and with AI agents producing more paperwork, an MCP server followed.

rrweb's answer

The library is roughly 89% TypeScript, deliberately so. Record and replay share a strongly typed event schema, and those types are the contract between the two sides. The remainder is JavaScript, HTML test fixtures, and Svelte for the player UI.

Four packages:

rrweb-snapshot, which serializes the DOM and its state into a JSON tree and rebuilds it rrweb, the record and replay functions rrdom, a virtual DOM that makes replay faster and testable headlessly rrweb-player, the player UI

Underneath it leans on browser primitives: MutationObserver for DOM changes, event listeners for input, scroll and pointer activity, CSSOM for stylesheet state, and patched canvas contexts for 2D and WebGL capture. Events are plain JSON, optionally packed for transport.

Build and test tooling is Yarn, Turborepo, Vite, Vitest, Puppeteer for integration tests, and Changesets for releases. MIT licensed throughout.

DynamicDocumentAPI's answer:

Rendering runs in Rust workers that drive headless Chromium over the DevTools protocol, with MiniJinja for templates. The API and control plane are built with Django and Django REST Framework, with Celery, PostgreSQL, Valkey and NATS JetStream for queues and events, and S3-compatible object storage for files. PDF/A output is checked with veraPDF and e-invoices with the official KoSIT validator. The dashboard and website are built with Next.js. Everything runs on Kubernetes in data centres in Germany.

rrweb's answer

Sentry Datadog PostHog Amplitude Mixpanel New Relic Pendo Highlight Browserbase StatCounter Requestly Gleap Bird Eats Bug Navattic CUX UXWizz Analyzee SmartX

Sentry, PostHog, Pendo and Highlight also fund the project as sponsors on OpenCollective.

DynamicDocumentAPI's answer:

Dynamic Document API is a young product. Our users are mostly developers and small SaaS teams, and we don't name customers without their permission.

rrweb's answer

rrweb is the recording engine most session replay products are built on. Sentry, PostHog, Pendo, Highlight, Mixpanel, Datadog, Amplitude and New Relic all ship replay built on rrweb or its approach.

It serializes the DOM into a typed JSON event stream: one full snapshot, then timestamped incremental mutations. There is no video. Replay rebuilds the actual page in a browser, so text stays selectable, CSS re-renders at any viewport, and a three-minute session weighs kilobytes instead of megabytes. Because the output is structured JSON, an LLM can read a session directly without a vision model in the loop.

It's MIT licensed with close to 20,000 GitHub stars, so the capture layer is yours to own. rrweb Cloud is the hosted backend from the same maintainers, for teams who don't want to run ingestion, storage and replay infrastructure themselves.

DynamicDocumentAPI's answer:

It covers the whole path from data to finished document in one API: you design a template in a visual or HTML editor (or send raw HTML, CSS or Markdown), send JSON, and get a PDF or image back. The same service also creates e-invoices (XRechnung, EN 16931, Factur-X / ZUGFeRD) that are validated against the official rules before they are returned, and can embed them in the PDF. Rendering is deterministic: the same template and data always give the same document, laid out by a headless browser, with no AI model generating content. Everything runs in the EU (Germany). It also ships an MCP server, so AI agents like Claude and ChatGPT can render documents directly.