Until today, getpeppr carried the answers your recipients gave to the invoices you sent. Now the other direction works too: you can answer the invoices you receive.
Sending a response
curl -X POST "https://api.getpeppr.dev/v1/received-documents/{id}/responses" \
-H "Authorization: Bearer sk_live_..." \
-H "Content-Type: application/json" \
-H "Idempotency-Key: reject-42" \
-d '{
"responseCode": "RE",
"reasons": [{ "code": "REF", "text": "Purchase order number missing" }],
"actions": [{ "code": "NIN" }]
}'
id is the receivedDocumentId of the inbound.invoice.received or
inbound.creditnote.received webhook. The response is a Peppol BIS Invoice Response
3.x, validated against the Peppol rules before it leaves:
responseCode |
Meaning |
|---|---|
AB |
Acknowledged |
IP |
In process |
UQ |
Under query — needs a reason |
CA |
Conditionally accepted — needs a reason |
RE |
Rejected — needs a reason |
AP |
Accepted |
PD |
Paid (PPD reason for a partial payment) |
Reasons use the OPStatusReason codes, actions the OPStatusAction codes. The texts and the note go to the supplier and are not stored by getpeppr.
The answer is 202 with delivery: "submitted". GET on the same path lists the
responses sent on a document and whether each was delivered.
When the supplier cannot receive it
A Peppol participant receives Invoice Responses only if it advertises that document
type, and many do not. Then the call is refused at once — 422,
received_documents.response_not_accepted_by_sender — and nothing is sent: tell the
supplier another way.
Who can respond
A standard key answers documents received by your own legal entity. A platform's master key answers for its sub-tenants, under the same rules as sending on their behalf. In production, answering as your own legal entity requires a verified Peppol identity, like sending.
The guide: Invoice Responses.