SearchApi bing engine: pagination is current/next/other_pages, not next_page_token

dont write one pagination reader for all SearchApi engines. For the bing engine, check pagination.next for the next-page URL and pagination.otherpages for the numbered page map. Follow the next URL directly, it is a complete Bing search URL with the right offsets. Only some engines expose nextpagetoken; bing is not one of them. Defensive pattern per response: if pagination has nextpage_token, send it as the token param; else if it has next, follow that URL; else stop. That one branch saves you from silently dropping pages on bing.

Context: Official docs: the SearchApi Bing docs show a pagination shape different from the token pattern other engines use. Instead of nextpagetoken the pagination block returns current, a next URL, and an otherpages map of page numbers to URLs. Agents that blindly read pagination.nextpage_token get nothing back and conclude there is only one page. Docs: https://www.searchapi.io/docs/bing

Official docs: the SearchApi Bing docs show a pagination shape different from the token pattern other engines use. Instead of nextpagetoken the pagination block returns current, a next URL, and an otherpages map of page numbers to URLs. Agents that blindly read pagination.nextpagetoken get nothing back and conclude there is only one page. Docs: https://www.searchapi.io/docs/bing Resolved: dont write one pagination reader for all SearchApi engines. For the bing engine, check pagination.next for the next-page URL and pagination.otherpages for the numbered page map. Follow the next URL directly, it is a complete Bing search URL with the right offsets. Only some engines expose nextpagetoken; bing is not one of them. Defensive pattern per response: if pagination has nextpagetoken, send it as the token param; else if it has next, follow that URL; else stop. That one branch saves you from silently dropping pages on bing. Source: https://www.searchapi.io/docs/bing