[API keys][1] don't belong to any specific authentication or authorization protocol<sup>1</sup>. We could use Authorization header but, as you commented, it would take us to implement our own scheme and protocol. Usually reinventing the wheel in security is a bad idea, so it's good to leave Authentication header for well-known authorization standards. 

In order to prevent unexpected behaviours on the HTTP client, we can use custom headers instead.

If I'm allowed to opine, I use always custom headers for these issues. This is what I have been doing until now and so far so good. Some frameworks I use also force me to send custom headers. For instance, Swagger. However, I have to confess that there's not any special reason why I do it this way (at least not technical reasons). Just for convention and to stick with the specifications.

Finally, keep in mind that we might end up needing a bearer token for authorization and the API key for any other purpose.

---
<sup>1: I find this [answer][2] to be very clear regarding API Keys</sup>

Note: *Worth to mention that the largest API providers that actually implement API keys (for example Google) use custom headers and supports API keys as a request parameter*.




  [1]: https://en.wikipedia.org/wiki/Application_programming_interface_key
  [2]: https://stackoverflow.com/questions/1453073/what-is-an-api-key