No, this is not safe, but not in the way that you think.
HTTPS is encrypted at the transport layer if you think about the OSI layer model, but http headers are at the application layer. Everything that is sent above the transport layer is encrypted and this includes http headers and the URL. We usually don't recommend to send authentication tokens in the URL because those end up in web server log files where they might be readable by many people and enable them to impersonate the user.
The issue is that the encryption can be easily broken by an active network-based attacker. We usually call it a man-in-the-middle. This is due to the unchecked certificate. If the client doesn't check the certificate, then an attacker might impersonate the server to the client and at the same time impersonate the client to the server by using their own certificate (one where they hold the private key for). They can learn the API key and use it afterwards.
You can fix this either by using (public) certificates that are valid (full certificate chain that is validated by the client until the trust root with valid dates and domain names) or self-signed certificates (those don't have a certificate chain) where the client actually checks the fingerprint.