I recently built something similar to this. I split job management into the following:
* POST /jobs creates an initial job (which you can get with GET /jobs/{id})
* POST /jobs/{id}/tasks adds tasks to a job (bulk inventory data in this case). The idea is that the client can call this repeatedly to add task to an open job
* PUT /jobs/{id}/run start processing tasks in a job. I know, "run" isn't a noun and not very "restful" in the narrow sense, but I don't think it matters that much in this case.
* GET /jobs/{id}/status this starts a server-sent-events response, if instructed by the client, and streams back real-time status updates (JSON-encoded). Or a single status response if it's a regular GET
* PUT /jobs/{id}/revert reverts successful tasks in a job (tasks store the current state before running, so they can be reverted. There's edge cases in doing this but it works for my use case)
* PUT /jobs/{id}/retry retries failed tasks in a job.
* GET /jobs/{id}/tasks{?status} list tasks in a job, optionally filtering them by status (pending, failed, successful, reverted)
Job entities include links to the available actions depending on current status (using HAL). So for example an open job includes the "add_tasks" and "run_job" links, but not the "revert_job" one (since there's nothing to revert yet). This simplifies the client somewhat, because it just needs to present the user with relevant controls and views depending on the actions present in the API response at any given time.
Hope that helps.