If the server blocks and responds only when the work is finished, HTTP 200 is indeed the way to go. Make sure you document the waiting time, since some clients may have shorter timeouts (and customers awaiting the reply may consider that something wrong happened).

Otherwise, you may return immediately, in which case HTTP 202 is the correct code:

HTTP 202 Accepted

 

The request has been accepted for processing, but the processing has not been completed.

^{Source: RFC 2616}

Remark: instead of (or additionally to) making the endpoint which provides status, you may also consider WebSockets. This may reduce the bandwidth by freeing the client from sending repetitive requests for status: instead, the server will push to the client a notification when the process finishes.

If the server blocks and responds only when the work is finished, HTTP 200 is indeed the way to go. Make sure you document the waiting time, since some clients may have shorter timeouts (and customers awaiting the reply may consider that something wrong happened).

Otherwise, you may return immediately, in which case HTTP 202 is the correct code:

HTTP 202 Accepted

The request has been accepted for processing, but the processing has not been completed.

^{Source: RFC 2616}

Remark: instead of (or additionally to) making the endpoint which provides status, you may also consider WebSockets. This may reduce the bandwidth by freeing the client from sending repetitive requests for status: instead, the server will push to the client a notification when the process finishes.