I believe that this is not possible in a failsafe way, unfortunately. Let me explain why.
You want your frontend app to have a way to identify itself to the API. In other words, you want authentication.
But authentication requires the existence of some kind of unique, secret data that the frontend app can use to distinguish itself from other applications. This can be a shared secret (password, "API key"), a private asymmetric crypto key, or something else yet. But whatever it is, it has to remain a secret, since if another app can copy it, it can pass as your frontend app.
So the question is, where are you going to store that secret?
If it is stored inside of the application code itself, or directly accessible to it, then it is vulnerable to reverse engineering or exploits on your front-end app, no matter how many layers of cryptographic indirection you use to hide it. This is the fundamental security flaw that led to the failure of almost all DRM schemes devised to date.
If it is stored remotely, then you are only shifting the issue of app authentication elsewhere: how is your front-end app going to authenticate on the remote server? Or in other words, what is preventing another app from accessing that remote server in exactly the same way?
My conclusion is that there is no truly secure way to authenticate a piece of JS software. You'll have to design your API in a fashion that is secure from malicious client input and, if you do want a way to ban compromised clients anyway, provide clients with revocable "API keys" that you can easily ban on the server side, the way most web services (and newer DRMs) do it.