So, the documentation still says that, for the search endpoint, the all_ids parameter is optional. However, it still throws the same error as before. Also, the note above implies that the all_ids parameter requires the page parameter which doesn't make sense (since I want them all) and simply results in the all_ids parameter being ignored.

I would really appreciate being able to use the all_ids parameter, if at all possible, but if it won't be fixed and search pagination truly is different from resource pagination, then that should be reflected in the documentation.

The TAC tech docs submteam discussed this issue with . For the search endpoint, the suggested solution was to update the last bullet in the "This endpoint is paginated..." box to read:

Boolean all_ids – Return a list of all object ids (page is required with all_ids)

However, there was concern that the resource and search endpoints handle pagination differently (i.e., that page is required with all_ids for search, but not necessarily required for all paginated endpoints). So just updating the existing pagination documentation at https://github.com/archivesspace/archivesspace/blob/5e1ca66f1f04f142f2695024efb7200825046325/backend/scripts/endpoint_doc.rb#L17 might create an inconsistency. The question is whether to create two versions of the pagination documentation snippet, or revisit handling this differently in the application.

Fine by me. Just so long as the API documentation is clear.

The Development Prioritization Team has taken a look at this issue and we'd like to avoid changing the API as much as possible without versioning the API.

As such, we will have the Technical Documentation team update the API documentation to create more clarity about the necessary query.

will you take a look at this issue and make sure the API documentation is clear that you need to add pagination information?

Per discussion, the fix for this will be in the documentation rather than the application.