Limit repeated requests to one API route served by Edgenivo Functions. This prompt helps you connect application checks to a Edgenivo Firewall rule and test the behavior callers receive.
Open or import your existing project and identify the route and expected traffic. Your agent needs repository access and the intended limit policy separately from this prompt. Firewall setup also requires access to the correct Edgenivo project.
Expect a focused implementation, local checks, and a configuration guide. Local mocks cannot verify deployed counters, and rate limiting complements the endpoint’s existing authorization and input validation.
Add server-enforced rate limiting to one public-facing API route served by Edgenivo Functions in my existing project. If the repository is missing, ask me to open or import it first. Read repository instructions and inspect the route, installed SDK versions, request validation, authorization, and tests. Reuse the framework and package manager. Ask for the target route, expected request volume, and acceptable rejection policy if these are unknown. Identify whether callers are anonymous or authenticated before selecting a bucket key. Use a dashboard-configured Edgenivo Firewall rule with checkRateLimit from @vercel/firewall, using documentation compatible with the installed version. Pass the incoming request for the default client-IP bucket. Use a custom key only from verified server-side identity, with unambiguous encoding for multiple identifiers. Never trust a client-supplied account ID or forwarded header as identity. Preserve existing request verification and authorization before application-level counting. Do not substitute process-local counters for shared enforcement. Return a documented 429 response before performing the protected operation when limited. Keep the endpoint's response format and avoid exposing identities or secrets. Handle limiter failures explicitly; for costly or state-changing work, do not silently continue when enforcement is unavailable. Document the selected failure policy and any timeout supported by the installed SDK. Counters are regional, so do not describe this as a strict global quota or complete protection against abuse. Add focused tests with the external limiter boundary controlled. Verify allowed requests, rejected requests without downstream work, separate verified callers where applicable, forged identity input, limiter errors, and recovery when requests are allowed again. Keep authentication and handler behavior real. Do not describe mocked counts as proof of the deployed time window or concurrency behavior. Document the matching rule ID, counting policy, project configuration, and a bounded preview smoke test for rejection and recovery. Confirm current preview requirements from official docs. Ask before changing dashboard rules, protection settings, deploying, or generating live traffic. Prepare local work without those actions. Run relevant tests, lint, and type checks. Report commands and results, local setup, missing configuration, and which deployed checks remain unrun.