Safe enough, sure, lots of sites do this. An attacker who gets XSS on the site might still be able to extract the token, depending on exactly how the function that adds it to API calls is invoked (for example, the attacker might be able to send an "API" request to their own server, and steal the token that way), and that is a slight loss of security vs. using
httponly cookies. I emphasize slight because an attacker who has XSS on your site generally doesn't really need to steal the token; they can just remote-control the victim's browser, invisibly making all the authenticated requests they want (and reading the responses).
On the other hand, it provides inherent protection against CSRF (since an attacker won't know the token and it won't be added automatically), while using cookies means you need some CSRF protection (although many ways of doing web service APIs are also inherently safe from CSRF unless you blow apart same-origin policy with a really bad CORS configuration).
Httponly cookies plus a strong CSRF protection (the
samesite cookie flag should be assumed only a weak protection, though in some cases it is fully adequate) is the best combination, security-wise, but the marginal value is not always worth the extra complexity.