In short: It does not matter and it will not protect you.
It does not matter if you try to restrict access to certain clients only or not, since everyone can still use it.
Let’s you put client token inside your client code. All it might do is keep away some really basic bots. But if token exists in client side code, malicious user can take this token and put it into their own code / client and use it from there.
They could also inspect requests and see some tokens moving. Steal it and use it in their own client.
Mobile apps are little but more secure, since inspecting mobile app requires tools, not just regular browser and F12 (in most cases) button on keyboard
What I also see a lot is that people make proxy, hide token in there and let their own clients do requests to this proxy not to API directly. But it would allow anyone to do requests to this proxy, thus protecting nothing.
You can build some fancy obfuscated method so that your token changes every time on both side by some algoritm. It will make things little bit harder, since it would take some time to normalize / deobfuscate it, but that’s about it.
What I’d suggest you to do is rate limit requests, so one client can’t do 30k POST /login requests per sec