The content search API provides the concept of a cursor to page through results. The cursor to the next page is provided as the
next field in the response from a previous page of results.
The API is not really designed to be called with a high degree of concurrency. If you do so, there will be an increased likelihood of being rate limited. A better design might be to use webhooks to keep your app in sync with the content.
Further to the above, it may be tempting for you to extract the
cursor query parameter from the
next URL returned in a search response and use this to construct
next URLs with different
start query parameters and call them concurrently, however, I think the
next URL is intended to be opaque and so there is no guarantee about its format. The design of the API is primarily intended to aid a user experience, rather than some kind of robot interaction. See also HATEOAS. In summary, I wouldn’t recommend this approach.