api design – Should I combine or separate APIs for related but distinct entities?

Right now I’m working on a project that’s basically a marketplace. The project separates backend (Django + DRF) and frontend where frontend can hit different endpoints based on user interactions with web interface.

The project has two distinct but related entities:

So original engineers decided to combine a lot of business logic into common APIs without separating who is interacting with the endpoint – buyer or supplier.
So you hit the API, it calls this or that view and then the view (using service layers) filters out the results based on which group this user belongs to.

On one hand this reduces the number of endpoints, routes and somewhat helps to reduce code duplication.

But on the other hand, when I have to refactor a method I have to mentally trace both entities interacting with this API which introduces a lot of complexity into the code logic.

To me code simplicity and “understandability” is more important than DRY – I can deal with code not being DRY by breaking out part of the code into modules or in the worst case by leveraging my RegEx skills together with pretty powerful “Search and Replace” functionality of PyCharm.

So is there a preferable way to design APIs in this regard?
Are there any advantages to combination of API’s that I’m not seeing?