An automation client calls a controller endpoint that handles heavy jobs and replies with HTTP 202 plus a task link in the Location header instead of returning the final data. The controller documents that the task URL returns the current status immediately. The client still needs the finished report for its weekly compliance workbook. Which asynchronous consumption pattern should the client use to retrieve the completed result?

The correct approach follows the documented asynchronous contract: the POST accepts the job and returns HTTP 202 with a task link, so the client submits once, retains the task identifier, and checks that task’s status until it reaches success. It then retrieves the report, which is the deliverable needed for the workbook; acceptance of a job is not completion, and completion status is not necessarily the report itself. A webhook is a common alternative for long-running jobs, but it requires the controller to support callback registration and delivery. No such capability is documented here, so relying on a callback could leave the client waiting without a result. Polling until success but treating the status response as the report confuses two resources: the prompt says the task URL returns current status, not the finished report, so the client still needs to fetch the report. Treating the first HTTP 200 from the task URL as completion also misreads the contract: a successful HTTP response can simply mean that the status lookup succeeded, while the job may still be running. Exam caveat: distinguish transport-level HTTP codes from the job’s state, which is typically conveyed in the response body or a documented field. Practical check: inspect a task response for its state and any result URL, and verify that the client fetches the result only after the state is successful.