For an integration like this, there isn't really anything that the hosting application (e.g. Forms) can do. The problem is that in most scenarios, you should consider the browser to be an untrusted environment, but you also want to prevent it from misusing some of the data you give it. Yes, Forms could provide a way to obfuscate credentials, but the page must also necessarily include instructions for how to decode and use those credentials. Not only must the credentials be available to script in the page, but the user can also see all of the headers and parameters included with the http request.

Taking a step back, the reason the application wants to assert this control over the browser is usually because the security model of the API is not as sufficiently rich as the application would like. That is, the credentials would give access to sensitive information that the user should not have access to. So one approach is for the API to have a richer security model, and to use it to limit the scope of what the credentials provide access to, so that "leaking" the credentials to the user doesn't allow them to gain more information than they could just by using the application. And here, I am using "credentials" in the most generic sense - mirroring your application users in a remote system is often not feasible or desirable.

If the remote API can't enforce the policy you would like, you might need to proxy all of the calls through your own application, where you can enforce your own access policy.

Another common scenario is when there isn't really a security policy to enforce but you still want to prevent a user from accessing all of the data. This is definitely trickier, and your tools might be rate limiting and auditing.