Public API: project work-items list ignores ?page= and never terminates pagination (v1.3.0)
Nobody has claimed this yet.
- Dominant language
- TypeScript
- Stars
- 59.6k
- Forks
- 5.8k
- Avg merge
- 1d 22h
- Merged PRs (30d)
- 49
Description
Describe the bug
On the public REST API, the project work-items list endpoint does not paginate: the ?page= query parameter is ignored and every page returns the same first per_page results, while the pagination metadata (total_pages, next_page_results) advertises that more pages exist. There is also no usable next link/cursor in the response to advance with.
As a result, an API consumer cannot retrieve any work item beyond the first page, and a client that follows next_page_results will loop forever (re-fetching the identical first page), because next_page_results is always true.
Endpoint
GET /api/v1/workspaces/{workspace_slug}/projects/{project_id}/work-items/?per_page=100&page=N
(authenticated with an X-API-Key)
Steps to reproduce
In a project with more than per_page work items (e.g. ~290 items, per_page=100), request several page numbers and compare the returned item IDs:
page |
results len |
count |
total_pages |
next_page_results |
next |
IDs vs page 1 |
|---|---|---|---|---|---|---|
| 1 | 100 | 100 | 3 | true | (none) | — |
| 2 | 100 | 100 | 3 | true | (none) | 100/100 identical |
| 3 | 100 | 100 | 3 | true | (none) | 100/100 identical |
| 4 | 100 | 100 | 3 | true | (none) | 100/100 identical |
| 50 | 100 | 100 | 3 | true | (none) | 100/100 identical |
| 200 | 100 | 100 | 3 | true | (none) | 100/100 identical |
Every page number — including page=200, far past total_pages=3 — returns the exact same 100 rows, with next_page_results: true and no terminating signal.
Expected behavior
Either:
?page=Nshould return the Nth page of results (distinct items), andnext_page_results/total_pagesshould reflect the true end (so page 4+ returns an empty/short page or 404), or- if the endpoint is cursor-paginated only, it should provide a usable
nextcursor/link and stop advertisingnext_page_results: trueonce the final page is reached — and ideally document that?page=is not supported.
Currently neither holds: ?page= is silently ignored, next_page_results never becomes false, and no next cursor is returned, so there is no correct way to page through results.
Impact
The paginated list API is effectively capped at the first per_page items. Any integration that enumerates work items (sync, export, reporting, automation) either silently misses everything past page 1 or hangs in an infinite pagination loop.
Environment
- Deployment: self-hosted (Docker, via Coolify)
APP_RELEASE: v1.3.0 (makeplane/plane-backend:v1.3.0,makeplane/plane-frontend:v1.3.0)- Access: public REST API (
/api/v1) with a workspace API token
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by reproducing GET /api/v1/workspaces/{workspace_slug}/projects/{project_id}/work-items/?per_page=100&page=N and trace the public REST API work-items list entry point. Compare results and pagination metadata across page values, then verify that distinct pages are returned and pagination stops at the final page.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- django, python
- Domain
- api, backend
- Issue type
- Bug
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 67/100