Support Pagination for `v1/finding/project/{uuid}`

[ybelMekk]

Current Behavior

Hi team,

First off, thanks for all the great work on Dependency-Track! It's an amazing tool, and I truly appreciate the effort that goes into making it better with each release.

I was wondering if there are any plans to support pagination for the v1/finding/project/{uuid} endpoint. Some of my projects have 4,000+ vulnerabilities, and since I primarily use the API rather than the frontend, fetching all findings at once can be extremely slow—sometimes even unresponsive.

I saw this discussion: #3811 but am still waiting for version 4.13 (as referenced in #4352).

Given that Dependency-Track is positioned as an API-first platform, adding this functionality would greatly enhance its usability for large-scale projects.

Proposed Behavior

To improve performance and usability, I propose implementing pagination for this endpoint, similar to how it’s done in other paginated API responses.

• Limit and offset parameters or headers?

This change would greatly improve response times and reliability, especially for users dealing with large projects.

Thanks again for all your hard work. 🚀

Best,

Youssef

Checklist

• I have read and understand the contributing guidelines
• I have checked the existing issues for whether this enhancement was already requested

[nscuro]

Fully agree, and yes this is planned.

Need to be cautious though, as existing integrations will rely on the fact that all findings are returned in a single request at the moment. If we simply change the endpoint to be paginated, it can break those integrations.

[stohrendorf]

I have a client app relying on that the result is not paginated. This would introduce a breaking change for me, implicitly breaking important functionality. There are two options I see here:

• introduce a new REST endpoint with a different path supporting pagination - this would allow for a migration without changing client apps and breaking behaviour, and it would be IMHO most transparent
• add dependent behaviour - like passing an HTTP header or an additional URL parameter which would enable pagination, but this would add behaviour that would silently break client apps if devs don't read the changelogs (which, in my own experience, is very likely)