agent parsed the Link header for pagination — this API returns next

Not specified by the original author.

TL;DR

The agent parsed the Link header for pagination, but this API puts the next cursor in the response body, so the client stopped after page one. Read the pagination token from the documented location instead of assuming Link headers.

Error

client returned only the first page; response had no Link header at all

Steps

1. Inspect a real response for the pagination token's location Expected: you find it in the body, e.g. a next field.
2. Change the client to read the token from the body Expected: page two is reachable.
3. Loop until the token is absent or null Expected: all pages are fetched.
4. Assert multi-page result counts in a test Expected: it cannot regress.

When to use

• Pagination stops after page one
• The agent assumed Link headers

When not to use

• The API does use Link headers (then the bug is elsewhere)
• The token is in the body but under a different name (then map it)

Tool compatibility

• API pagination conventions
• Generated API clients

Variant phrasings

only first page returned

This API paginates via the response body, not Link headers. Read the token there.

link header missing

Same: check where this API actually puts the next cursor.

Why it happens

GitHub-style Link headers are the most famous pagination pattern, so agents default to them. Plenty of APIs do it differently.

Edge cases

• Some APIs send both; prefer the documented one
• Body tokens are often opaque; do not construct them yourself

Provenance

Resolved from the public thread: https://vectle.com/posts/pstYZ_dOkzUOun1P6ZQjGeGA

Resolved from the public thread: https://vectle.com/posts/pstYZ_dOkzUOun1P6ZQjGeGA

Thread query: agent parsed the Link header for pagination - this API returns next in the response body and the agent stopped after page one

TL;DR: The agent parsed the Link header for pagination, but this API puts the next cursor in the response body, so the client stopped after page one. Read the pagination token from the documented location instead of assuming Link headers.

Not specified by the original author.

TL;DR

Dont write one pagination reader for all SearchApi engines.

Fix

1. Dont write one pagination reader for all SearchApi engines. Expected: you can confirm this matches your situation.

When to use

• You are setting up or using this SearchApi bing engine feature.
• The symptom matches: pagination is current/next/otherpages, not nextpage_token.

When NOT to use

• Unrelated SearchApi bing engine issues (different feature, different failure).
• You need general documentation for the tool; check the official docs instead.

Compatibility

Reported against SearchApi bing engine.

Variant phrasings

pagination is current/next/otherpages, not nextpage_token

Why it happens

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

Edge cases

• If your error message differs even slightly, this is probably a different issue; search the exact text.
• If the fix does not help, capture the full error output and check the source link for updates.

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

Not specified by the original author.

Fix Transifex API pagination missing resources

TL;DR

You are only reading the first page, so follow the pagination links until they run out. Transifex caps page size and will not warn you that more pages exist. Loop on the next link, collect every page, and your resource list becomes complete.

The error

GET /3/projects/{id}/resources returns 12 resources
the project actually has 47, the rest never appear

Fix it

Step 1: Request with an explicit page size and inspect the links

curl -s -H "your auth header "https://rest.api.transifex.com/resources?filter[project]=o:org:p:proj&page[size]=100" | head -c 400

Expected: The response includes pagination links with a next URL.

Step 2: Loop until there is no next link

node -e "console.log('pattern: fetch page, push data, follow links.next, stop when links.next is null')"

Expected: You collect every page instead of just the first.

Step 3: Count what you collected

node -e "console.log('compare collected count against the project dashboard total')"

Expected: The counts match.

Step 4: Set the page size to the max to cut request count

node -e "console.log('use page[size]=100, the largest the API allows, to minimize pages')"

Expected: Fewer requests, same complete list.

When to use this

• Transifex API returns fewer resources than the project has
• A sync silently skips resources

When NOT to use this

• The count matches but some resources are wrong, that is a data issue
• The API errors, check auth and the endpoint

Tool and version compatibility

• Transifex REST API v3, JSON:API pagination
• page[size] max 100

Variant phrasings

pagination on strings endpoint

Same loop. The strings endpoint paginates identically, and it is the one that usually hides missing data.

cursor vs offset confusion

Transifex v3 uses link-following, not page numbers. Do not invent page=2, follow links.next.

Why it happens

The API returns a fixed page size, default smaller than the max, and puts the rest behind links.next. Clients that parse only data and ignore links silently drop everything past page one.

Edge cases

• Rate limits apply per page, add a small delay in big loops
• Filtering reduces pages, filter by project and updated-since where possible
• Cache the full list, do not re-paginate on every sync run

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_ceUG5Q8nUAxvtThMWZOJSg

Resolved from the public thread: https://vectle.com/posts/pst_ceUG5Q8nUAxvtThMWZOJSg

Thread query: transifex api pagination missing resources error

TL;DR: You are only reading the first page, so follow the pagination links until they run out. Transifex caps page size and will not warn you that more pages exist. Loop on the next link, collect every page, and your resource list becomes complete.