Strovia: Governed data exchange for pensions & finance. Secure, connect, transform, deliver.

The six feedback scenarios

The Feedback Message tells the sender whether a message was processed correctly. It always refers to the original message through originalMessageId, has its own new messageId, and reports status 8 (accepted) or 0 (rejected). A rejection includes one or more errors, each with an error code and an explanation.

The scenarios

  1. Synchronous success: the receiver replies HTTP 200. No feedback message is needed.
  2. Synchronous error: HTTP 400, with a feedback message in the response body.
  3. Asynchronous success: HTTP 202 first; later the receiver calls the sender’s feedback endpoint with an “accepted” feedback message.
  4. Asynchronous error: HTTP 202 first; later a “rejected” feedback message.
  5. Panic after an error: the receiver’s “rejected” callback is itself refused (400).
  6. Panic after success: the receiver’s “accepted” callback is refused.

In the panic scenarios, the parties must coordinate manually through another channel. Asynchronous feedback is only used where both parties have agreed to support it.

Corrections

The standard’s principle is: once-accepted messages are not unilaterally corrected.

  • After a rejection, the sender may and must send a corrected message, with a new messageId.
  • After acceptance, a correction needs agreement between the parties. Reusing a messageId is treated as a duplicate.

Source: VB-PUO manual §4.7 and the OpenAPI specification. Bron: SIVI – VB-PUO Standaard.