Integration · ERPNext

Your ERP knows the numbers. It should not have to typeset the contract.

ERPNext holds the record. Wraft turns it into a document that can be negotiated, approved and signed — both running on your own infrastructure, both open source.

Read the API docs Read the source

AGPLv3 · Self-hostable · No data leaves your network

erpnext → wraft

# ERPNext webhook: Quotation on submit
Authorization: token <api_key>:<api_secret>

POST /api/v1/builds
{
  "template": "msa@v7",
  "source":   { "doctype": "Quotation",
                "name":    "SAL-QTN-2026-00184" }
}

→ 201  { "build": "b_9f2a", "state": "legal-review" }

Your ERPYour renderer

Where this stands

What exists today, stated plainly

Wraft is open source, so this is checkable in one click. Rather than have you check, here it is.

Available now

Wraft's REST API and webhooks, and ERPNext's REST API and webhooks. Everything described on this page can be built against the two public surfaces today.

You write the glue

Field mapping between a DocType and a template, and writing the artifact back onto the record. A few dozen lines against two documented APIs — not a project.

Not yet shipped

A packaged connector: an installable ERPNext app, DocType discovery, and mapping configured in the UI rather than in code. It is on the roadmap and not in the repository.

The gap

Print formats stop where the contract starts

ERPNext generates transactional documents well. The trouble begins with the ones that get argued over before they get signed.

Print formats are built for printing

Jinja and HTML render a Sales Invoice competently. They are a harder place to express a twelve-page master services agreement with numbered clauses, cross-references, and a schedule that has to renumber when a clause is removed.

The document has no life after it is generated

A print format produces a file. It does not carry an approval state, a counterparty who has to sign it, a version history against a negotiated redline, or a renewal date that should raise a task ninety days out.

Signing usually means leaving the building

The common answer is a hosted e-signature service, which means the contract — pricing, terms, the names of both parties — leaves the infrastructure you deliberately self-hosted the ERP to keep it inside.

The division

Neither system does the other's job

The integration is worth having because the boundary is clean, not because the two overlap.

ERPNext owns the record

Customer, item, price, tax, delivery date, approval hierarchy. It is the system of record and nothing here changes that — the document reads from it rather than duplicating it.

Wraft owns the document

Template, typesetting, clause library, version history, approval flow, signature, and the archive the finished artifact lands in. The parts an ERP is not trying to be.

The boundary is one REST call

A DocType goes out of ERPNext as JSON and comes back as a build id. No shared database, no plugin inside either application, nothing to re-do when either side upgrades.

The path

From a submitted DocType to a signed artifact

Nothing polls, nothing is duplicated, and the ERP stays the system of record throughout.

DocType Quotation, Order, Contract

Webhook On submit or on status change

Map Fields into template slots

Render LaTeX or Typst

Return File back onto the record

Worth generating

DocTypes that earn a real document

Not everything needs typesetting. These are the records where the output is read by someone outside your company.

Quotation

Proposal with terms, validity and signature block

Sales Order

Order confirmation and delivery schedule

Contract

Negotiated agreement with clause history

Purchase Order

Supplier agreement with penalty terms

Employee

Offer letter, appointment order, NDA

Salary Slip

Payslip typeset to statutory format

Sales Invoice

Invoice matching a jurisdiction's layout rules

Project

Statement of work with milestone schedule

How you wire it

Four steps, two documented APIs

Until the packaged connector ships, this is the whole of it — and it is worth knowing that the packaged version will not be doing anything you cannot see here.

01 Issue an API key pair in ERPNext User → API Access → Generate Keys. Requests authenticate with an Authorization: token <key>:<secret> header — ERPNext's own scheme, no separate OAuth app to register.
02 Point a webhook at Wraft ERPNext fires webhooks on document events, so a Quotation reaching Submitted can trigger a build without anything polling. Configure it once per DocType you care about.
03 Map fields to a template The webhook payload is the DocType's JSON. Fields map to named template slots, including child tables — an invoice's line items are a repeating block rather than eight separate mappings.
04 Write the artifact back Wraft returns a build id and a file. Attach it to the originating record through ERPNext's File API so the document lives beside the data that produced it.

An honest comparison

Wraft against ERPNext print formats

Print formats are not a weak feature, and most ERPNext installations should keep using them for most documents. The comparison is about which documents, not which tool is better.

Dimension Wraft ERPNext print format

Dimension Layout engine Wraft LaTeX or Typst — built for pagination, numbering and cross-references ERPNext print format HTML and Jinja rendered to PDF through a browser engine

Dimension Long documents Wraft Clause numbering, schedules and references renumber together ERPNext print format Workable, but page breaks and numbering are hand-managed

Dimension Who edits the template Wraft Legal edits clauses; layout is a separate concern they cannot break ERPNext print format Editing a print format means editing HTML in the ERP

Dimension Approval before sending Wraft Document-level flow with ordered states and a recorded transition per version ERPNext print format ERPNext workflow governs the record, not the rendered document

Dimension Signature Wraft Signing is part of the document's own lifecycle ERPNext print format Typically a third-party service the file is uploaded to

Dimension Where it runs Wraft Your infrastructure, AGPLv3 ERPNext print format Your infrastructure, GPLv3 — already the same posture

Dimension Right choice when Wraft The document is negotiated, signed, or has a life of its own ERPNext print format The document is a transactional printout of a record

Written about ERPNext v14+ print formats and the Frappe webhook and REST surface. Both projects move quickly — check against your own version before deciding.

Before you build against it

The questions an ERPNext team actually asks

Is there an installable ERPNext app for this?

Not yet. Today the integration is built against both REST APIs — ERPNext webhooks out, Wraft builds back in. A packaged app with DocType discovery and UI mapping is planned. If you want to be told when it lands, or want to shape it, the issue tracker is the place.

Does Wraft replace ERPNext print formats?

No, and it should not. Print formats are a good fit for transactional output — invoices, delivery notes, receipts. The case for Wraft starts where a document is negotiated, signed, versioned or has a renewal date: a master services agreement, an offer letter, a supplier contract.

Do we have to send data outside our network?

No. Both systems are self-hostable and the traffic between them is yours to route — the same VPC, the same cluster, or the same machine. This is the main reason the pairing works: adding a hosted document service to a self-hosted ERP undoes the reason the ERP was self-hosted.

How do the licences interact?

ERPNext is GPLv3, Wraft is AGPLv3. They are separate programs talking over HTTP, not linked code, so neither licence reaches into the other. If you modify Wraft itself and offer it over a network, AGPLv3 asks you to publish those changes. Running it unmodified alongside ERPNext carries no obligation. This is a plain reading, not legal advice.

What about Frappe apps other than ERPNext?

The mechanism is the Frappe framework's REST and webhook layer, not anything ERPNext-specific, so a custom Frappe app with its own DocTypes works the same way. ERPNext is the one we describe because it is the one most people are running.

Which version of ERPNext does this assume?

Version 14 and later, which is where the webhook and API surface described here settled. Earlier versions can still be integrated by polling the API instead of receiving webhooks.

Running ERPNext and want the packaged connector sooner? Telling us which DocTypes you generate from is the most useful thing you can do — it decides what ships first.

Open an issue Talk to us