Render a document supplied inline, storing nothing but the PDF.

The stateless path: pass the whole document in the body and get a PDF back, with no customer, business profile or stored document required. To render a document that already lives here, use create_document_render.

Returns JSON with a signed download_url by default. Ask for the bytes directly with output.delivery: "binary" or Accept: application/pdf.

This tool renders asynchronously and waits for the result, so it returns the finished render rather than a queued one. Rendering is CPU-bound and served by a single worker: prefer one call at a time over starting many renders in parallel.

Render a stored document to a PDF.

Use this when the document lives here. To render one you hold yourself, without storing it, use render_document.

The response carries a signed download_url that needs no API key, valid until expires_at.

One render: its status, its totals, and how to download it.

download_url and expires_at are null until the render is completed, and a failed render carries a failure explaining why. Poll this after an asynchronous render.

Fetch the PDF, by signature or by API key.

Two ways in, and the signature is checked first — before the row is looked up — so a forged token cannot be used to tell a real render id from an invented one. It also means the token path costs no auth work at all, which matters because this is the one endpoint a browser hits directly.

Compute the totals for a document without storing or rendering it.

Returns the same breakdown — subtotal, discounts, tax, shipping, total — that a render would print, so a checkout page can show a figure before committing to one.

Check that a document body is well-formed, without pricing it.

The cheapest of the three stateless operations: no totals are computed and no PDF is produced. Use calculate_document for the money and render_document for the document.

Create a document in draft.

Totals are computed and stored at creation, so the figures you read back are the ones that were issued rather than a recalculation. Nothing is rendered — use create_document_render once the document is final.

One document, with the totals stored when it was created.

Every document on the account, newest first.

Cursor-paginated: pass the next_cursor from a response to fetch the page after it. Filter by document_type or status to narrow the list.

Change a document that is still a draft.

A finalized document is a record of what was issued and cannot be edited; 409 if it has moved past draft. Only the fields you send are changed — omit one to leave it alone, and send null to clear it.

Copy a document into a new draft.

The copy gets the next available number rather than the original's, so it can be finalized without colliding with the document it came from.

Queue the document to be emailed, with its PDF attached.

The document must be finalized; sending a draft is a 409. attach_pdf defaults to true, and on that path a render must already exist — the email attaches an existing render rather than making one — so the natural sequence is create, finalize, render, send, and sending straight after finalizing is refused with No render exists for this document. Send with attach_pdf: false and no render is needed, because none is attached.

Returns 202 with the delivery in queued. The mail is sent in the background and retried on transient failure; poll GET /deliveries/{id} for the outcome.

Check a document against an e-invoicing ruleset without rendering it.

Costs no renders: nothing is stored and no PDF is produced, so a caller can check every invoice they are about to send rather than discovering the problem from a rejection weeks later.

Two tiers run, and both are reported. The mandatory-field check names a field of the request you can go and change. Schematron then serializes the document and runs the published rules at a pinned version over the result — the same artefacts an access point runs — so a finding here quotes the rule id a rejection notice would quote.

Read valid together with fully_checked: valid says nothing fatal was found, and rulesets says what actually ran to find it.

The e-invoicing XML for a document, without storing anything.

Takes the same body as /validate-compliance, and the pairing is the point: check first, then take the XML once it passes. Nothing here validates against the ruleset — a document missing mandatory fields serialises to XML missing those elements, which is a more useful artefact to look at than a refusal, and /validate-compliance is where the refusal belongs.

The syntax is not a parameter. It follows from the profile, because a profile already is a syntax plus a ruleset, and asking a caller for both is asking them to know that Peppol means UBL.

The people and companies you bill, newest first.

Cursor-paginated. A customer is optional — the stateless render endpoints take a buyer inline — but storing one lets a document reference it by id.

Store a customer you can bill repeatedly.

tax_id and electronic_address are what e-invoicing needs: a buyer VAT number and the Peppol identifier a receiver is addressed by. Neither is required for a plain PDF.

One stored customer.

Change a stored customer.

Only the fields you send are changed — omit one to leave it alone, send null to clear it. Documents already issued keep the details they were issued with; this does not rewrite them.

The identities you issue documents as, newest first.

One per entity you bill from — a business with two trading names or two tax registrations needs two. For how documents look rather than who issues them, see the branding profiles.

Create an identity to issue documents as: the seller side.

legal_name, tax_id, address and bank details are what appears as the issuer, and what an e-invoicing ruleset checks. Distinct from a branding profile, which sets colours and a logo and says nothing about who you are.

The built-in templates every account can render with.

Your own designs are listed separately by list_custom_templates.

Set up a schedule that issues invoices on its own.

Starts active, so the first invoice is issued when the schedule next falls due. The invoices it produces are ordinary documents — read them with list_generated_invoices.

The schedules on this account, newest first.

These are the recurring definitions, not the invoices they produce; for those, use list_generated_invoices. Narrow with status.

Stop a schedule issuing invoices, for now.

Only an active schedule can be paused; anything else is refused with 409. Nothing already issued changes. Restart it with resume_recurring_invoice.

Start a paused schedule issuing again.

Only a paused schedule can be resumed; anything else is refused with 409. A cancelled schedule cannot be brought back — create a new one.

End a schedule permanently.

Terminal: it cannot be resumed or edited afterwards, and cancelling twice is refused with 409. To stop issuing temporarily, use pause_recurring_invoice instead.

Invoices already issued are left alone.

The invoices one schedule has actually issued, newest first.

The documents produced by this schedule, as opposed to list_recurring_invoices, which lists the schedules themselves.

Move a document through its lifecycle.

• finalized — Issue a draft: fix its number and totals.

• sent — Record that the document reached the customer.

• paid — Record that the document was paid in full.

• unpaid — Undo mark_paid, returning the document to sent.

• void — Cancel a document that was issued.

• archived — Move a document out of the active list.

• restored — Bring an archived document back to finalized.

Each transition is only valid from certain states and is refused with 409 otherwise. To actually email a document to its customer, use document_send — to: "sent" only records that it happened.

Search every InvoicePDFs API operation by what it does, and get back the full input schema of each match. Use this when no tool above covers what you need — most of the API is reachable this way.

Run any operation returned by find_operation, by name.