An accepted request needs a visible outcome

A success message in a portal should confirm the state the user relies on. Someone expecting a finished report needs a retrievable report. Acceptance of a creation request is an intermediate step towards that. This distinction belongs in the product decision about feedback.

MDN describes HTTP 202 as acceptance of processing that has not finished. The work may fail later. Microsoft shows a separate status query for such asynchronous flows. The HTTP code of the first response therefore does not settle what the portal should display afterwards.

The same acceptance, two interfaces

In our fictional portal, report job J-73 is accepted. The template is initially available but is removed before processing. The comparison below describes two possible interfaces, not a user test that was performed.

Both interfaces could have received the same acceptance response. They still provide different information. In A, technical acceptance may conceal an unmet business expectation. B keeps the job visible until its outcome is known.

A successful status query can show a failure

Our example API returns HTTP 200 for successfully reading the status resource, with this body:

{"jobId":"J-73","status":"failed","error":{"code":"template-not-found"}}

The query worked; report creation failed. Field names and response design are our own example rules, not a requirement for every API. An evaluation counting only successful HTTP calls could miss this job. Accepted requests, completed reports and failed work answer different questions.

If the status query itself is unavailable, the current work state remains unknown. The portal should infer neither a completed report nor a definitely failed job. Another click must also relate to the existing job so that additional requests do not worsen an uncertain situation.

When acceptance is a sufficient outcome

A submission-only function may fulfil its agreed task through durable acceptance. In that case, a confirmation labelled as acceptance is appropriate. A synchronously completed operation likewise needs no extra polling cycle merely as a matter of principle.

The report portal has a different goal: the user wants the file. Evaluation of the integration must therefore extend to that outcome and a traceable failure path. A quick first response is then a separate property, not evidence of an available report.

Sources

• MDN: 202 Accepted

• Microsoft: Asynchronous Request-Reply pattern