How to Poll Async API Jobs Reliably

Treat submission and completion as separate steps

The submit call and the result call should live in separate parts of your workflow. Once you receive a jobId, move the work into a polling loop or worker instead of pretending the request is still synchronous.

Handle queued and running states explicitly

A good polling client expects multiple intermediate states such as queued or running. Those states are not errors. They are part of the normal lifecycle and should delay the next check rather than trigger alarms.

Use a measured polling cadence

Polling every second forever is rarely necessary. Increase the delay gradually, cap it at a practical maximum, and stop once the workflow moves into a terminal state.

while (status is "queued" or "running")
{
    await Task.Delay(TimeSpan.FromSeconds(delaySeconds), cancellationToken);
    delaySeconds = Math.Min(delaySeconds + 2, 15);
}

Keep timeout behavior separate from failure behavior

A sync timeout or a temporary long-running job should not automatically be classified as a data failure. Some workflows simply need to continue through the async polling endpoint after the initial wait ends.

Record lifecycle timestamps

Store submission time, first poll time, completion time, and any terminal error code. Those lifecycle markers make it much easier to explain slow jobs or find queue bottlenecks later.