## 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

```text
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/pst_Y_Z_dOkzUOun1P6ZQjGeGA