Half the reason to hash and salt is to prevent an attacker from obtaining the plaintext (often reused) password, which doesn't apply for API keys.
With that said, there's no reason why a service couldn't send you a plaintext API key but only store the hashed and salted key in their database. I suspect AWS, for example, does just that (you can't obtain your API secret except right after generating it). The API consumer needs a way to store/decrypt the plaintext API key, but that also applies to passwords.
That's more than half of the reason. Do you really want to rely on an attacker only getting the password database from a breach and nothing else and then not spending the time to reverse the hashes?
API keys are quite different from passwords and it makes sense to store and secure them differently.
If your site is generating API keys then you should ensure that they are say 128 bits of high quality entropy and use a fast hash.
Nobody is going to invert that, even if you use a single round of SHA-256 / HMAC / whatever.
It’s a good thing too because API keys need to get validated on every request and you wouldn’t want to use a heavy function (tens of millis like a decent kdf) on every request.
