You missed the second half of what I wrote: "Use HTTPS for your API calls and ensure that the server's certificate is strictly validated." If the customer is able to easily reroute it to another site, you are likely failing the second prong of that message. Strict validation means that 1. the hostname/SAN in the certificate matches the host you are trying to reach, 2. the certificate chains up to a trusted CA, and 3. there are no expired or revoked certificates in the chain. You may need to explicitly opt-in to this strict validation in your REST library, consult the documentation for more details.
The above can still be bypassed if the client adds a custom root CA to their machine and generates a spoofed certificate for that hostname, but that is more effort than simply setting up an entry in the hosts file. Pinning the CA certificate inside of your app (that is, setting it up so that CA certificate is the only trusted CA rather than relying on the system's root CA store) is one way to help make that even harder, although it means your application has a ticking time bomb embedded inside of it -- should the upstream site change CAs or the CA change their root certificate your app will break until you update the thumbprint. As such, I would personally recommend against pinning the CA certificate.
skizzerz's post in API Request Validation was marked as the answer