A partner tells you the order update never arrived. Your logs say you sent it. Both of you are right, and settling it can cost an engineer an afternoon, because the proof sits between your system and theirs.
EchoRelay keeps that proof. Paste the request id and you get a delivery receipt for each target: delivered or failed, how many attempts it took, and the exact error if it failed.
When a request goes to a target on queued delivery, the 202 you get back means one thing: we have your request and we are responsible for it from here. It does not mean your target has it yet. Those are different moments, sometimes a second apart, sometimes several retries apart.
The usual way to close that gap is to build a table. Request id, target, attempt count, last error, a column for whether the callback fired. It is the same table every time, nobody enjoys writing it, and it is a second copy of state we are already keeping.
The request id is all you need to keep
The 202 hands you a request id. Give it back and you get every target that request fanned out to, each carrying its own delivery receipt.
A delivery receipt is the record of one delivery. It says whether that delivery is queued, retrying, delivered or failed. It says which attempt it is on, when it was enqueued, when it last moved and when it finished. If it failed, it carries the error it ended on. If the target has a callback URL, it says whether that callback has gone out yet.
It is per target rather than per request because fan-out makes those different questions. One request to three targets is three independent deliveries, and did it work has three answers.
The shape does not change while you watch
A delivery that is still moving is read from live tracking. One that has finished is read from durable storage. The answer looks the same either way.
That is what makes it pollable. Take the request id the 202 returned, ask on an interval, and watch the status move to delivered or failed. There is no point where the format changes because the delivery crossed some line inside our system, and no second place to look once it is over.
Ask in the panel, over the API, or through your agent
The request's own page in the panel, if you are looking at one delivery and want to see it. The REST API, if you are wiring this into your own tooling. The MCP tool, if you would rather ask your agent.
That last one changes what an on-call question looks like. Did the order update reach the fulfilment partner, and how many tries did it take? is a question an agent with a read-only management token can answer without you opening a browser.
Where a delivery receipt has no answer
Synchronous and streaming targets do not have one. They answer inside your original HTTP response, so there is nothing to look up afterwards: what happened is what you already got back. Asking for a delivery receipt on one of those tells you exactly that, rather than pretending there is no record.
Delivery receipts age out. Past the retention window the answer is that there is no record, which is not the same as a failure. If you need to be able to answer a question about a delivery years later, keep that answer on your side. This is an operational trail, not an archive.
A delivery receipt is also about delivery, not about what your target did with it. Delivered means the target accepted the request. Whether it then did the right thing is between you and them.
The dispute ends with a pasted id
When someone says nothing arrived, whoever is on call pastes the request id and answers with the attempt count and the exact error. Nobody on your team builds or maintains a tracking table to get there, and nobody has to be believed.
Open any request in the panel and its delivery receipts are at the bottom of the page.
