01 — Name the action
Give the application’s intended action its own identifier. A provider message identifier may not exist yet when work is queued, so it cannot be the only reference the team uses to follow progress.
02 — Record acceptance
When the provider accepts a request, associate its identifier with the original action. Confirm what that response actually means in the provider’s current documentation. Acceptance does not automatically establish delivery or a read receipt.
03 — Reconcile events
Use documented event identifiers and authenticity checks. Decide how the application handles a duplicate or delayed callback and how it associates an incoming reply with the right thread.
04 — Make failure visible
A human operator should be able to tell whether work is pending, failed or complete. Agree on a supported evaluation case for each state and record the outcome. The manual describes a proposed method, not tests already executed against these vendors.