fix: set sane API key rate-limit defaults

[asmello]

Summary

Better Auth's apiKey plugin ships with extremely restrictive defaults: 10 requests per 24-hour window. Once exceeded, the key is effectively bricked for the remainder of the day (~86,400s Retry-After). This makes API keys unusable for automation tools like n8n.

This PR overrides the defaults to 100 requests per minute — a reasonable limit that supports automation while still providing abuse protection.

• Configure rateLimit on the apiKey() plugin constructor in auth.js
• Optional migration to fix existing keys created with the old 10/day defaults and set sane column defaults. Tested and confirmed working, but not required for new keys created after this change.

Test plan

Validated against a live deployment:

• 110 parallel requests to an authenticated endpoint — 109 x 200, 1 x 429 (rate limit enforced around 100 mark)
• Retry-After header returns 18s (within the 60s window, not the old 86,400s)
• Response body: {"error":"Rate limit exceeded."} — clean error
• Cookie-based browser auth unaffected (rate limit is per API key)
• Manual n8n integration test confirmed working
• Environment variable override confirmed working

[gemini-code-assist]

Summary of Changes

Hello @asmello, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request addresses the issue of overly restrictive default rate limits for API keys, which previously made them unsuitable for automation tools. By configuring the better-auth plugin, the rate limit is now set to a more reasonable 100 requests per minute. Additionally, an optional database migration is provided to ensure existing API keys and future manual insertions also benefit from these improved defaults, significantly enhancing the usability of API keys for automated processes.

Highlights

• API Key Rate Limit Defaults: The default rate limit for API keys has been updated from a very restrictive 10 requests per 24 hours to a more practical 100 requests per minute. This change is implemented by configuring the apiKey plugin in SparkyFitnessServer/auth.js.
• Optional Database Migration for Existing Keys: An optional SQL migration script (SparkyFitnessServer/db/migrations/20260208120000_fix_api_key_rate_limit_defaults.sql) has been added. This script updates existing API keys that were created with the old defaults and sets new column defaults for rate_limit_time_window and rate_limit_max in the public.api_key table, ensuring consistency for both old and new keys.

Changelog

• SparkyFitnessServer/auth.js
  • Configured the apiKey plugin to include rateLimit settings, enabling a limit of 100 requests per minute (60,000 ms time window) instead of the previous 10 requests per 24 hours.
• SparkyFitnessServer/db/migrations/20260208120000_fix_api_key_rate_limit_defaults.sql
  • Added a new SQL migration file to update existing API keys with the old 10 requests/24 hours defaults to the new 100 requests/minute settings and resets their request_count.
  • Altered the public.api_key table to set default values for rate_limit_time_window (60000) and rate_limit_max (100) for new insertions, ensuring sane defaults for manually created keys.

Activity

• The author has provided a detailed test plan, validating the changes against a live deployment.
• Tests confirmed 109 out of 110 parallel requests succeeded, with one 429 (rate limit enforced around 100).
• The Retry-After header correctly returned 18s, aligning with the 60s window.
• The error response body {"error":"Rate limit exceeded."} was clean.
• Cookie-based browser authentication was confirmed to be unaffected.
• Manual n8n integration testing confirmed the changes are working as expected.

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature	Command	Description
Code Review	/gemini review	Performs a code review for the current pull request in its current state.
Pull Request Summary	/gemini summary	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help	/gemini help	Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

Footnotes

1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

[gemini-code-assist]

Code Review

This pull request introduces a much more reasonable rate limit for API keys, changing it from 10 requests/day to 100 requests/minute. This is a great improvement for usability, especially for automation tools. The changes in auth.js correctly configure the new rate limit, and the accompanying SQL migration handles existing keys and sets database defaults. My review includes a couple of suggestions: one to make the rate-limit configuration more flexible by using environment variables, and another to improve the robustness of the SQL migration script to handle NULL values for existing keys.

[CodeWithCJ]

@shantnudon Could you review on this.

[CodeWithCJ]

@asmello Do we want to leave the default as-is and control via the env variable you added? because not sure how many will use N8N and we dont wnat to leave it 10 per 24 hr to 100 per min. Not sure the best practice here.

@shantnudon what do you think?

[asmello]

10 per 24h is ultra conservative. I don't think 100 per min will be harmful, especially because this limit only applies to API keys, not IPs. If someone has a valid token, hitting the API faster than 100/min is the least harmful thing they can do.

EDIT: that said, open to having a slightly more conservative default than 100/min.