Bookmark folder endpoint ignores max_results and returns no pagination cursor (reproduced with curl)

[martinnormark]

Problem

GET /2/users/{id}/bookmarks/folders/{folder_id} returns the same 20 post IDs regardless of the requested page size, and provides no pagination cursor. This prevents an export workflow from continuing beyond those 20 IDs.

The token was obtained with xurl token, but the folder requests were made directly with curl. The same behavior was also observed with Python's urllib, so this may be an X API service/documentation issue rather than a defect in xurl's request handling. Reporting here for confirmation and routing.

Environment

• Observed: 2026-09-23; curl checks at approximately 20:45 UTC
• xurl: 1.3.1
• curl: 8.17.0, macOS ARM64
• Authentication: OAuth 2.0 user-context token from xurl token
• Response header: api-version: 2.168

Steps to reproduce

With an authenticated xurl account and an existing bookmark folder, substitute your own user and folder IDs. The following curl commands reproduce the requests; jq only summarizes the responses.

X_USER_ID='YOUR_USER_ID'
X_FOLDER_ID='YOUR_FOLDER_ID'
X_ACCESS_TOKEN="$(xurl token)"

for PAGE_SIZE in 5 100; do
  printf 'Authorization: Bearer %s\n' "$X_ACCESS_TOKEN" |
    curl --disable --silent --show-error --get \
      --header @- \
      --header 'Accept: application/json' \
      --dump-header /dev/stderr \
      --url "https://api.x.com/2/users/${X_USER_ID}/bookmarks/folders/${X_FOLDER_ID}" \
      --data-urlencode "max_results=${PAGE_SIZE}" \
      --output "bookmarks-${PAGE_SIZE}.json"

  jq '{keys: keys, count: (.data | length), meta: .meta}' \
    "bookmarks-${PAGE_SIZE}.json"
done
unset X_ACCESS_TOKEN

# Both responses contained identical ordered post IDs:
jq -s '.[0].data == .[1].data' bookmarks-5.json bookmarks-100.json

Expected results

• max_results=5 returns at most five entries.
• If additional entries exist, the response exposes a continuation cursor that can be passed as pagination_token to retrieve the next page.
• Repeated requests with returned cursors allow traversal of the folder. If pagination is unsupported or intentionally capped, the endpoint documentation should state that limitation.

The folder endpoint documentation lists max_results from 1 to 100 and pagination_token. The pagination guide describes reading meta.next_token and passing it as pagination_token.

Actual results

Client	Requested max_results	HTTP status	Returned IDs	Top-level response keys	Next cursor
curl	5	HTTP/2 200	20	data only	Absent
curl	100	HTTP/2 200	20	data only	Absent
Python urllib	1	200	20	data only	Absent
Python urllib	100	200	20	data only	Absent

All four responses contain exactly the same 20 IDs in the same order. There is no meta object, next_token, or pagination link/cursor in the response headers, and no API error is returned.

The summary for either curl response is:

{
  "keys": ["data"],
  "count": 20,
  "meta": null
}

No valid continuation token was returned, so a next-page request could not be made. The folder's total size was not independently verified; the confirmed defect is that requests for 1 or 5 entries still return 20, alongside the undocumented absence of pagination metadata.

Impact / request

An attempt to export up to 500 bookmarks from one folder stopped at 20. Could you confirm whether this endpoint currently supports pagination, and route this to the API team or clarify the documented contract if needed?

Account identifiers, folder identifiers, bookmark contents, and access tokens have been omitted.