Since your own JavaScript client is accessing the API directly, anyone’s going to be able to look at what it’s doing and mimic it, including use the same API key. You can try to make it more difficult, like by obfuscating your code or putting various hurdles in the way, but you and the person you’re trying to restrain have fundamentally the same access. Instead of trying to create a difference in privileges, you’ll need to construct a system where it’s totally OK that the unofficial client uses all the access in its scope, but the system is arranged in such a way that official use across all clients is greater.
This is often done with per-user access tokens, as opposed to one token for the entire application. Each token’s limit should be plenty for typical use of your API, but restrictive for someone trying to abuse it. For example, 100 calls per minute might be more than enough to support typical browsing, but if I want to scrape you, I can’t do it effectively on that budget.
There will always be an arms race – I can get around the limit by creating lots of bot user accounts. That, though, is a pretty solved problem if you just add a captcha to your signup flow, at a tiny bit of expense to the real human. When you get into these scenarios, everything’s just a tradeoff between convenience and restriction. You’ll never find something totally bulletproof, so focus on making it good enough and wait until someone exploits you to learn where the holes were.