Send Document
Put a document the company issued on the Peppol network (droit document:u).
Answers 202, not 200: the send is asynchronous, so what is acknowledged is that the
request was accepted and handed over — not that the document reached its recipient. The
response is the document unchanged; nothing is written here, SENDSTATUSPEPPOL belonging to
the send workflow.
Two things are checked before handing over: the type must be one Peppol carries (a proforma is not a fiscal document and has none), and the document must not already have left. A send that failed may be started again — that is a retry, not a second send.
Everything else Peppol requires is verified by the send workflow itself, which owns those
rules: the company registered on the network, a customer that is a company rather than an
individual, and carrying a VAT number or a legal identifier. A document that fails one of
them is accepted here and records its refusal on its own — so a 202 means taken in
charge, and the outcome is read on the document afterwards.
When the hand-over itself cannot be started, the answer is 422 send_failed: the document
is unchanged, and the send may simply be retried.
Authorizations
Bearer authentication header of the form Bearer <token>, where <token> is your auth token.
Path Parameters
Body
Which channels a document should leave by.
One flag per channel rather than a single channel field, because the channels are
independent: mail and Peppol are two separate workflows, and a document very often goes
out by one without the other — or by both. A single value could not say that. The day mail
joins, it lands here as a sibling carrying its own recipients and template, and nothing that
already works has to change.
No channel is on by default: sending is always something one asks for explicitly.
Put the document on the Peppol network. Requires a type Peppol carries — a proforma is not one — and a document that has not already left.
Response
Successful Response
A document of the company: an invoice/credit note it issued or a document it
received (purchase invoice, credit note, other). The source table is hidden — the
client sees a single unified document identified by an opaque id.
Monetary amounts are decimal numbers in the document's currency. They may be null
when the document could not be parsed automatically, or for other_document types
that have no financial breakdown.
Both sources are normalised to this shape by the repository adapters; the validators below map the internal codes to their public values.
Opaque unique identifier of the document.
Document type. One of: sale_invoice, sale_credit_note, purchase_invoice, purchase_credit_note, other_document, unknown.
Channel the document came in through. One of: fidly (generated in Fidly), manual, peppol, mail, odoo, billit, api (or unknown).
The document's own number (e.g. invoice number).
Purchase/sales order number referenced by the document.
Reference of the despatch advice (delivery note) related to the document.
Reference given by the buyer, to be quoted back on the document (e.g. a cost centre).
Date the document was issued (ISO YYYY-MM-DD).
Payment due date (ISO YYYY-MM-DD).
Date the VAT becomes chargeable, when it differs from the issue date (ISO YYYY-MM-DD).
Date the goods/services were actually delivered (ISO YYYY-MM-DD).
First day of the period the document bills (ISO YYYY-MM-DD).
Last day of the period the document bills (ISO YYYY-MM-DD).
Communication to quote when paying the document. null when the document carries none.
true when payment_remittance is a structured communication (a bank-checked reference such as a Belgian OGM/VCS) rather than free text. Always true for documents issued by Fidly.
Timestamp the document was created in Fidly (ISO 8601). May be null on rare legacy rows where it was never set.
ISO 4217 currency code of all amounts (e.g. EUR).
Total amount excluding tax.
Total tax (VAT) amount.
Total amount payable, tax included.
Amount already paid.
Amount still to be paid (total_amount minus paid_amount).
Payment state. One of: unpaid, partial, paid (or unknown).
Accounting workflow state. One of: waiting, accepted, transfered, exported, export_error, imported, validated, hidden, exporting, posting, posting_error, deleted (or unknown).
true if a PDF is stored for this document (retrievable via the file endpoint).
true if a structured XML version (e.g. Peppol/UBL) is stored for this document.
Nature of relation_id: company (a registered business relation) or contact (an individual contact). null when there is no linked third party.
Opaque identifier of the third party the document is linked to (resolvable via GET /relations/{id}). Its nature is given by relation_type. null when the document has no linked third party.
Opaque identifier of the journal the document is booked in (resolvable via GET /journals/{id}). null when the document has no linked journal.
Opaque identifier of the saved delivery address the document is delivered to (resolvable via GET /delivery-locations/{id}). null when none is set.
Payment terms the due_date follows from, as <days>-<basis> (e.g. 30-df). Always null on a received document: only documents Fidly issues carry them.
Legal mention printed at the bottom of the document (e.g. a VAT exemption wording). Always null on received documents.
Peppol send state of an issued document. One of: not_sent, sending, sent (delivered to the network), accepted (acknowledged by the recipient), rejected (refused by the recipient), failed (or unknown). rejected and failed can be sent again. Always null on a received document.
E-mail send state of an issued document. One of: not_sent, sent, failed (or unknown). Always null on a received document.
Files attached to the document, in the order they were added. Attach one with POST /documents/{id}/attachments; the API offers no way to remove one. A received document never carries any.
Discounts/surcharges applied to the document as a whole, after the lines and their own. tax_exclusive_amount is already net of them.
Detailed lines of the document (invoiced items/services). Empty when none are stored.