The reply arrived after the receiver restarted.
A job went out. The receiver restarted. The reply still came back, because the return token lived in a ledger instead of disappearing with the process.
// 01
Sending was only half the job
In a bot integration recorded on 2 September 2026, an inbound webhook could start work elsewhere. That did not give the local process a reliable way to learn what happened. A successful send only established that the request had been accepted; it did not supply a completed result.
// 02
Give the reply somewhere durable to land
Each package carried a reply URL with a one-time token. The receiver checked that token against a ledger. Package 003 returned after the receiver had restarted, and the handover records that return as verified end to end. That reply took about 33 minutes; earlier recorded replies took roughly two to four minutes. Keeping the token only in memory would have made a restart a very different event.
// 03
One survived restart is the useful claim
This is a historical integration observation, not a reliability percentage. It does not establish how the service behaves through every outage or how quickly a future reply will arrive. The same record verifies that a specification could be served with a hash, but does not prove that the remote bot fetched it. Delivery, return and document retrieval remain separate things to check.