No. You do not need to add a salt to an API key's hash.
The API key should have been created from a high entropy random source, capable of resisting attacks that attempt to guess future keys based on past keys.
Most passwords are created from very low entropy sources: Users. Additionally, most passwords will also be reused, so there's value in pre-computing hashes for the most common passwords.
The largest easily available brute-force rainbow tables are MD5, alphanumeric, up to 9 characters long tables, which assuming that means Arabic numerals and the upper and lower case US-English alphabet, without accents, then we have 58^9 possibilities. I don't expect to see rainbow tables longer than 10 characters for any hashing algorithm, so as long as your API key is more than 60 bits (58^10 ~= 430 quadrillion, which is less than (2^61)-1 ~= 576 quadrillion), you're probably safe from rainbow tables.
Use 128 bits to be sure, though. That way you'll be safe from rainbow tables until the heat death of the universe, even if the person attempting to build such a table has a planet sized computer.
You can still add salt if you want to, though, or if you have a manager with an incomplete understanding of security who assumes that salt must always be used with hashes. Just be sure that the key itself is still long and was created from a high entropy source.