Wait, why can you can skip the hashing step and still be secure? Because hashing is only neccesary if you call it a 'password', but not if you use it in the same way but call it an 'api key' instead?
I guess it depends on the purpose for hashing. If it's just about 'data breaches', then maybe it doesn't matter if your api keys get out... because they at least won't grant access to any _other_ systems, since they weren't manually entered by users and re-used accross systems. Is that what you're thinking?
But don't you still want to avoid a data breach like this for your _own_ service?
And, I think, isn't the other reason hashed passwords are used, to make it harder to do a brute force attack? Ie, it's quite intentional and deliberate that it increases request overhead. And doesn't this still apply to an api key, possibly even MORE so when you have a single api key instead of a username/pass combo?
Could you spell this one out a little bit more? Do you mean only a single session should be able to use an API credential?
You can still encrypt the secret, e.g. using AES 256 bit encryption with secure random Initialization
Vectors and rolling keys. This too is not easily 'brute forceable', but is very fast to decrypt compared to a BCrypt comparison (key storage should also be in a separate location than the main data store).