system There's another community post with 404 debugging tips that might be helpful. Please give these solutions a try and let us know how it goes. https://community.vercel.com/t/debugging-404-errors/437 A human should be around soon to offer more advice. But you can also get helpful information quickly by asking v0.
Pasha Thank you for the reference. I checked the suggested article, but I believe our issue is different from a typical deployment or website routing 404. The error occurs when the existing Vercel Connector calls the Vercel REST API: GET https://api.vercel.com/v2/user Response: 404 / not_found / User not found I have independently verified in the Vercel Dashboard that my account is an Owner of the relevant Team. The issue appears to involve the Connector's authorization principal or identity mapping, rather than a missing website page or deployment route. Could a Vercel Connect engineer or maintainer please review this specific case? In particular, I would appreciate guidance on how to diagnose the existing Connector's principal mapping and authentication context without replacing credentials or changing the current Team membership. Thank you.
Frantisek Following up: the Vercel Support Agent reports that pre-ingestion/storage redaction of specific Runtime Logs query parameters is unsupported across all plans. The Agent offered a support case, but the form directs Hobby users back to Community for Observability → Logs support. Could a Vercel staff member confirm the redaction limitation and clarify whether Hobby’s one-hour retention means query availability or deletion of underlying request metadata, particularly given the documented availability of older logs after upgrading? My reproduction used fake values only. Deployed OAuth remains disabled pending clarification.
Solvion Holdings Not staff, so I can't speak to Vercel's storage. But with PKCE, a logged `code` and `state` are low value on their own, and you can make that hold in your app: - **The code can't be redeemed alone.** Spotify's PKCE token request needs the `code_verifier` your app generated (that interception case is why RFC 7636 exists). Keep the verifier out of the URL: store it in an `httpOnly`, `Secure`, `SameSite=Lax` cookie, delete it after the exchange, and never log cookies. - **It's single-use and short-lived.** RFC 6749 §4.1.2 says a code must expire shortly (10 min max recommended) and must not be used twice. Exchange it in the callback and never retry with the same code. - **`state` is only a CSRF check.** Compare it to a cookie value, then discard it. - **Redirect to a clean URL** after the exchange so the code isn't left in the address bar or sent onward in a Referer. ```ts // app/api/spotify/callback/route.ts (sketch) const verifier = (await cookies()).get('pkce_verifier')?.value if (!verifier || state !== (await cookies()).get('oauth_state')?.value) return new Response('Invalid', { status: 400 }) // POST code + verifier to the token endpoint, store tokens server-side, // delete both cookies, then redirect('/') ``` To verify: after a real login, replay the exact callback URL from the logs in another browser. It should fail (no verifier cookie, code already used). Vercel's docs list 1 hour of runtime logs on Hobby; whether that means deletion is for staff to confirm.
Amy Egan Sorry to hear you had some unexpected high usage, @pabloost. Do you have a support case open? The community isn't able to issue refunds. For security reasons, that kind of thing is limited to the support team. If you don't have a case yet, please open one at vercel.com/help so the support team can assist
Pablo Hey! Thanks for your help. Unfortunately, I can´t as an agents responds automatically without the option to talk with support team :-(
Amy Egan It should let you open a case if you ask to talk to a person. Can you try again and let me know what it tells you if it doesn't help you open a case?