The problem is not building a general purpose API, the problem is over thinking it. There’s a sweet spot where you build the API just slightly more flexible than your FE needs at the time, yet without wasting time on making it fit ‘all possible future use cases’.
Then you can later on whip up a mobile app if needed, let the clients use it, whatever. And evolve it accordingly.
I disagree. Trying to generalize a single implementation into an interface is always problematic. And that's exactly what inserting an API between the FE and BE is if your only UI is a web page.
If, later on, you want a mobile app, then an API can easily be deduced from your current, working UI, instead of trying to imagine what the UIs of your web FE and mobile app have in common.
Then you can later on whip up a mobile app if needed, let the clients use it, whatever. And evolve it accordingly.