Skip to main content

Resend Failed Invoice

POST 
/api/v1/transactions/:transaction_id/resend

Resend a previously failed invoice transaction, rebuilt from the original invoice data.

What happens depends on the rebuilt document's identifier, which is derived from the seller, document type, invoice number, issue date and tax totals:

  • A new identifier (for example, a new issue date): a new transaction is created and sent. The original keeps its failure for audit. outcome is new_transaction.
  • The identifier of an existing failed or retrying transaction (usually the one being resent, when the date is kept, whether or not its send carried an Idempotency-Key): no second document is created under that identifier. The existing transaction's stored document is queued for delivery again under the same transaction and message id, as /retry does. outcome is requeued. If another retry or resend queued it a moment earlier: 409 ALREADY_QUEUED.
  • The identifier of a transaction that is not failed or retrying (for example, a forced resend of a delivered invoice with its date kept): nothing is sent; 409 SAME_DOCUMENT_EXISTS.

transaction_id in the response is always the transaction to track.

An Omani invoice (sent as PINT OM, or from an Omani seller) is never rebuilt or re-dated: its invoice UUID and QR code are worked out from the issue date, so a new date would be a different invoice reported under the same number. Its stored document is queued again under the same transaction and message id (outcome requeued), as /retry does; a transaction that is not failed or retrying answers 409 SAME_DOCUMENT_EXISTS. update_timestamps left out does not re-date it; "update_timestamps": true is refused with 422 OMAN_RESEND_CANNOT_REDATE and nothing is sent. To change an Omani invoice, issue a credit note and a new invoice. An Omani seller's invoice that went out as Peppol BIS 3.0, not PINT OM, cannot be reported, so it is not resent at all: 422 OMAN_RESEND_NOT_PINT_OM, whatever the body; send a new invoice instead.

Requirements:

  • Transaction must be in 'failed' or 'retrying' status (or force set)
  • Original invoice data must be stored
  • Transaction must be outbound (sent)

Request​

Responses​

Successful Response