I have an API that users can log into. I don't want it to be hacked. What if I limit each user to 60 requests a minute? Won't this significantly slow hackers down in a brute force situation?
Configure Fail2Ban or its equivalent first to quickly reduce the attacks.
Then look at a tool like mod_security to tighten what's allowed to access your API. If you have time create a strict whitelist of what's allowed and block everything else. Configure Fail2Ban to watch your mod_security logs. Getting the basics in here first will help block attacks but you'll also need to do long-term tuning on this system especially as your API evolves.
Watch your logs for common attacks against paths that don't exist in your API then add them to mod_security as things to trigger bans in Fail2Ban.
Ideally, you can do all of the above on a dedicated proxy server running in front of the system running your API but these can also be implemented on the API system itself.
If there is any way to whitelist the IP's of the users accessing it or require them to use a VPN this would radically reduce the attack surface available to the attackers.
Once you have more time, start measuring the performance of each query against your API if you have one that takes substantially longer to respond (search queries) this may become a target for DoS attacks so you may want to build more defensive rules around this.
Also, it's very important to constantly be hardening your API and the system(s) it's running on. You really want to do vulnerability scanning, use penetration testing tools, AND static code analysis of your code on a regular basis.
Something to also think about, if you have any sensitive data on the database behind this API that will never be requested through the API, something like credit cards might be a good example. It might be wise to export the non-sensitive data subset from the main database and host it on a dedicated server to be used just for the API and block access from this system back into the rest of your network (Think one-way firewall rule). In many cases, this can be a very powerful way to prevent data loss by removing the external attack surface completely from the system with sensitive data. Not every implementation of an API can do this but when it works it can really help.
In regards to the 60 requests per minute per user, there is nothing to stop an attacker from using thousands of fake user accounts in their attack so that won't stop serious attackers but it will throttle abusive users which may be something you also want to do. Likewise, there are MANY different types of brute force attacks. If an attacker aims a terabit of botnet traffic towards your API it really won't matter how you have things configured. Tools like Cloudflare will help in that scenario but again there is a limit to what can be done.
Make sure you also read the OWASP REST Security Cheat Sheet
That would help protect against automated attacks. Most scanners and fuzzers are going to send thousands of permutations, this would slow down these efforts. It will not protect against manual checking and a methodical, persistent attacker. Make sure that you are following secure programming practices within the web service code itself, this is your best defense against attackers.
If you are only concerned about credential brute force, then implement account lockouts. Because this is a web service, you could set the lockout threshold to something quite high (600 failed attempts). If the threshold is met, you know something odd is going on. I would also restrict access to your web services from only those hosts that need to interact with it.