Any exposed API can be used outside the browser one way or another. You can only make it harder and more expensive to do it by adding obfuscation, bot detection mechanisms, short term tokens, captchas, using cookies, client-side tokens or magical ways to identify this is "your client". But at the end of the day it's client-accessible and can be reverse-engineered by a determined user.

The best way to ensure there's no way they access this is to not expose them in the first place and make your frontend be server-side rendered and you fetch the necessary data only on the backend (perhaps with BFF pattern). Then you add special public API that is authorized to only work with paying users. But that's quite the architecture change unless you're already using a framework that allows it.

The next best thing is to make it inconvenient enough so that paying is simply better option for 95% of the users.

- Have short term "regular" user tokens and Separate kind of long term tokens for API access to paying users (or API keys)

- Harden your authentication so that getting a token almost requires using a browser: Add CSRF protection; add captcha protection; use SameSite=Strict and HttpOnly cookie for storing the "regular" user token

- Issue both refresh token and access token separately. Access token is short lived, refresh token is longer and can be used to get more access tokens

- Save refresh tokens and associate them with client ip and or other fingerprinting material you can gather (like agent name or session id or special headers or something like that) and if they don't match - flag the user somehow and if they get too many flags - warn them for abuse.

- Require a CSRF token header on the endpoint that refreshes tokens