Is it a good idea to move the work with the interface to a single API?

Question

API

Actually, it is worth putting in order and upgrading one highly loaded project in the tasks. It is based on a self-written framework, which slightly aggravates the task. But this is all introductory, but the question is this:
One of the tasks is to create an API for connecting a mobile application with access to a personal account and statistics. How adequate is the idea for the separation of responsibilities and simplification of all this on the backend to implement one universal API, to which both the interface (which eventually accesses via REST) ​​and the mobile application would be tied? All this looks very beautiful in my head - a single entry point, a single documentation, a small adaptation in the API based on the origin of the request, which affects the type of authentication and the need for CSFR verification.
What is fraught with such an attempt to tie everything together?

Answer 1

There are a few issues, here are a couple.
It often happens that the functionality of a mobile application requires some other logic of work, for example, it is often simplified.
If the API is separate, you can flexibly and without much concern make any changes to the browser version of the API without affecting the mobile application. The latter is always more demanding on the stability of the API, because if you break backward compatibility it is not enough just to update the build of the application, you also need to have users update it on their devices.