vlad/autoreg-skills-max
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
f58eafeb48979991591e8b4c53ff7b2c015091a7
autoreg-skills-max/skills/account-validation/references/v0-platform-api-key-proxy.md

2.5 KiB
Raw Blame History

v0 Platform API key/proxy validation notes

Session learning from v0.app / Vercel v0 Platform API work.

What worked

  • Validate a v0 key with:
    • GET https://api.v0.dev/v1/user
    • GET https://api.v0.dev/v1/user/billing
  • GET /v1/user identifies the account email/role for the presented key.
  • GET /v1/user/billing exposes billing type, plan, remaining/total balance, on-demand balance, and billing-cycle timestamps.
  • Chat generation works with POST https://api.v0.dev/v1/chats using body shape:
    • {"message":"Create a React button component..."}
  • For an existing chat, send a follow-up message with body shape:
    • {"message":"..."}
  • The response object uses id for the chat id, not necessarily chatId.

Key-creation pitfall

When the user asks to “make/request a new key for this v0 account”, do not substitute a chat-generation request. First attempt the actual key-management path or explicitly say it is unavailable.

Probed public endpoints with a valid v0 team key:

  • GET /v1/keys → not_found_error
  • GET /v1/api-keys → not_found_error
  • POST /v1/keys → not_found_error
  • GET /v1/user/keys → not_found_error
  • GET /v1/user/api-keys → not_found_error
  • GET /v1/account/keys → not_found_error
  • GET /v1/auth/tokens → not_found_error
  • Vercel GET https://api.vercel.com/v5/user/tokens with a v0 key → forbidden, invalidToken: true

Current conclusion: the public v0 Platform API does not expose API-key creation/listing endpoints. Creating a new key appears to require the web settings page (https://v0.app/settings/keys) or an internal/private API/session, not a bearer v0 API key.

Encoding note

On Windows shell/curl, Russian prompt text sent to v0 was received as question marks. English prompts worked. For quick API smoke tests, use ASCII/English prompts unless you explicitly handle UTF-8 encoding in the shell/request layer.

Proxy/routing notes

For a local round-robin v0 proxy, validate each candidate key independently against /v1/user and /v1/user/billing before adding it to the pool. Multiple keys from the same account share balance but can still increase effective request throughput; keys from a separate account provide separate balance and independent limits.

If a /stats implementation truncates keys for display, keys with the same prefix can collapse in per_key display even when routing works. Verify routing via request counters/logs or by preserving a distinct key identifier internally.