Request ownership and counts
Default release configuration routes personal/api/v1/users/calendar-settings and workspace
/api/v1/workspaces/:wsId/calendar-settings through Infrastructure’s
/api/v1/mobile-calendar gateway to Calendar. Both support GET/PATCH with the
original Supabase Bearer token. These local routes do not use the satellite
fallback rewrite to Web. No satellite browser session is required.
The app-level timezone scope makes one personal and one workspace GET at cold
startup. Opening/reopening Settings displays that scope and adds zero requests.
Same-workspace rebuilds do not reload. Account/workspace changes and OS resume
can revalidate; in-flight loads coalesce and 429 cooldown prevents replay.
Reminder planning separately reads preferences across workspaces; its bounded
traffic can consume a shared allowance but is not a Settings rebuild loop.
A valid unexpired access token does not refresh on each timezone read. Expiry
within the refresh buffer or a rejected 401 can cause a bounded refresh. Refresh
failure is a session error or falls back to an existing token; it is not itself
the API client’s kind=http; status=429 response. There is no automatic 429 retry.
Rejection inventory
Default authenticated proxy read limits are 600/minute, 6,000/hour, 40,000/day;
mutation limits are 60/minute, 300/hour, 2,000/day. Personal and workspace paths
share each actor’s quota across token rotation. Existing environment overrides,
trust/risk decisions, downstream authentication, MFA and IP blocks remain active.
Hosting exception coverage
The legacy native gateway WAF regex covered/api/v1/calendar/**, workspace
/calendar/** and the two cron routes, but excluded both /calendar-settings
endpoints. A matching private credential could therefore still encounter bot
protection on these reads/saves. firewall-policy.test.ts reproduces this exact
predicate gap and verifies the narrow correction without broadening other paths.
Save the owning Calendar project’s active firewall response in a private file
using the authenticated Vercel CLI’s read-only firewall API, then run:
Authenticated native Calendar gateway rule with the audited proposed predicate.
Keep its exact x-tuturuuu-calendar-gateway credential equality, active bypass
action, unrelated rules and managed bot protection. Do not use mere Bearer
presence as a hosting bypass. Review any existing draft before publishing. Then
read back active coverage and verify authenticated native reads/saves plus
forged-credential rejection. Repository deployment alone does not apply this
provider configuration; no firewall publication is implied by the audit or PR.
Diagnostic interpretation
Olderdiagnostics=v1 output with all four fields unknown cannot distinguish
absent headers from unsupported values. New diagnostics record metadata presence
and label a response with no limiter fields upstream-or-edge; that is a source
classification, not proof of a specific WAF/provider policy. Vercel/Cloudflare
header presence is a boolean, never a request ID, credential or arbitrary server
header. Known application rules retain their policy/caller/window and Retry-After.
Content negotiation matters: a Calendar request with Accept: application/json
and the gateway’s Node user agent can receive a JSON 429 with
x-vercel-mitigated: challenge and no application quota fields. The gateway
relays that JSON status; the legacy missing settings-path exception therefore
provides a concrete mechanism for the device’s all-unknown 429 fingerprint.
HTML challenges instead become 502. The fixed gateway preserves only the exact
safe challenge marker and classifies unlabelled upstream JSON rejections.
An unauthenticated control does not establish the affected user’s individual
request receipt. Correlate that build’s effective host/path and timestamp with
Infrastructure/Calendar logs to attribute an exact event. Keep the private
credential condition: direct requests without it should still be challenged.
Never log tokens, cookies, private bodies, actor/workspace identifiers or IPs here.