Should I Return a 200 Status Code for Invalid API Calls?

While it's good to keep your API functioning, using 200 status codes inappropriately creates a bad habit. If your API is for a number of users or teams, it's best to adhere to conventions to prevent confusion. If your API is only for your own team, then maybe you could explain this change to them. Bottom line: consider the implications before going against established standards.

It's really important to stick with the correct HTTP status codes. Returning a 200 for invalid requests could mislead users about the status of their calls. It's better to block those spam bots at the source and address the underlying issue rather than masking it with a 200 status. That said, if you can't implement bot protection, consider other ways to handle this situation without compromising standard practices.

You really shouldn't return a 200 for invalid calls; it just goes against HTTP usage conventions. There are many valid status codes for different errors, like using 400 for bad requests or 404 for not found. Instead of just switching to a generic success code, it might be more effective to handle the spam issues properly and keep your API responses accurate.

Going for a 200 status code as a workaround is definitely odd! But hey, I understand the desire to keep your environment healthy. Just be careful; using 200 may lead to confusion for users who expect proper error feedback. If you're having trouble with permissions for the WAF, maybe there's another way to limit the bot traffic before it reaches your server.