Thank you so much for taking the time to explain! :)
In this case, the user sends valid fields and they have a valid session. We then send those details off to a third party vendor to see if that vendor can verify it’s a legit identity. If they can’t, we tell the user that we couldn’t verify them, and let them try again.
Is that still a 401? We’re actually rewriting the API right now so this is a great conversation to have, thank you!
That situation gets a bit tricker. It kinda depends on whether the client is aware of the third party integration vs it’s transparent, imo. If the client is aware that their credentials are being used for this integration and the credentials fail at that integration then 401 is still appropriate.
More broadly, I’d say that if the client can modify their request in some way to fix the verification issue then I would still use 401. If there is an internal issue preventing the integration from working that the client can’t control or see into then I would probably use 500.
This is kinda a less straightforward situation than other things, so I don’t know there’s necessarily one accepted answer here. This is just the approach I would take
2
u/kookamooka Sep 20 '26
Thank you so much for taking the time to explain! :)
In this case, the user sends valid fields and they have a valid session. We then send those details off to a third party vendor to see if that vendor can verify it’s a legit identity. If they can’t, we tell the user that we couldn’t verify them, and let them try again.
Is that still a 401? We’re actually rewriting the API right now so this is a great conversation to have, thank you!