PBKDF2, or for that matter, any password hashing algorithm, is designed to be tunable so it can take a variable amount of time, depending on the security level to be desired. The amount of time it takes will be constant assuming the same parameters are taken, whether the password is correct or incorrect, since it's impossible to determine whether it's correct or incorrect until the operation is complete.
Since a commonly recommended target amount of time for a password hashing algorithm is 100ms, you may find that such a speed has an impact on performance. However, typically APIs don't use hashed passwords for authentication. It is much more common to issue some sort of token to a user and have them use that for authentication instead. This is true for web interfaces as well, where we call that token a session cookie.
If you generate a token with at least 128 bits of entropy (256 is better), or you use a secure MAC or signature for your token, then this is generally a secure way to do authentication. You can then store your random token in the database, preferably hashed with something like HMAC-SHA-256 (with a key specific to your application), and then the cost of verifying the token is greatly diminished. Or, if you use a secure MAC or signature, you can just verify the MAC or signature and then check that the token's ID is still valid.
You should never store a password or other low-entropy secret with a simple hash or HMAC, but this is secure if you use a high-entropy secret like a token generated from a CSPRNG because brute-forcing it should be impossible.
Note that PBKDF2 is no longer a recommended algorithm for password hashing. Memory-hard algorithms such as Argon2 or scrypt are preferred by most cryptographers, although government standards are unfortunately slow to adapt.