This will look quite similar to the other requests in that I agree as well that it's better to show a clear message.
Note that you should apply the IP whitelist as the first check. I.e. you don't parse the json parameters, and error a 400 if they are wrong, then issue a 403. Or, a more extreme case, check if the password is wrong and only if it is right then verify the source IP. No, it's better to check the IP first, and fail early if the IP address is not authorized, without parsing any of their data.†
At this point, the only information provided by a detailed error is that you are checking the source IP. Something which is hard to guess anyway [if not directly (almost) spelled out in the documentation for end users], and that they cannot "bypass" anyway (hopefully).‡
I would go even further and suggest not only to say "Your IP address is not whitelisted", but also the detected IP address such as "198.51.100.85 is not allowed here".
Anonymous mentions that it will make testing and debugging more difficult for the developers, but I add that it's not only testing that will be hampered but production as well.
If it's only used internally, the more verbose error may help the sysadmins or developers deploying the systems connecting to the API when setting it up (or when suddenly discovering that it no longer works after some non-announced routing changes).
If it's also used by end users, it will be even more useful, for both end users ("D'oh!, I needed to be connected from X") and your own support having to help users when "It doesn't work". If you are lucky, when asking "Are you accessing from a whitelisted IP?" you could receive a clear "No, we changed it 2 months ago, our connecting IP address is X now". Other people wouldn't even know what their public IP address is, claim that they are connecting (to your system in the internet) from IP 192.168.1.3 ...
† It's common to whitelist at the firewall level as well, in which case it wouldn't even reach the application layer.
‡ In order to bypass an IP filter options would basically be to perform BGP hijacking, control an intermediate router between the server and a whitelisted client or get a client to open a malicious web page to send the evil request on your behalf (assuming the API will not reject what comes that way). If the API needs to cater to proxys forwarding the original IP address (such as X-Forwarded-For header), there may be vulnerabilities on its handling that could allow additional bypasses.