If check_api_auth() ends up doing internal authentication of a service user whose userid is not the same as its cardnumber, the password can get successfully validated but the overall authentication can fail. This is because, like other authentication pathways, it's possible to pass a cardnumber to identify the user to check_api_auth() and have checkpw() successful validate the password. However, after checkpw() is called, the authentication must pass haspermission(), which _requires_ that it always be passed the userid. Other authentication pathways will result in $userid getting set correctly before it's passed to haspermission(), but check_api_auth() doesn't currently do that. One way that this can manifest is that if you have set up a service user for the OCLC Connexion importer whose cardnumber is not the same as the userid, the importer's attempts to authenticate itself to Koha can subtly fail.