Platform API `find` endpoints don't list web-app chats/projects. Only API-created ones (Beta)

v0
1

Title: Platform API find endpoints don’t list web-app chats/projects — only API-created ones (Beta)

Summary

Calling the Platform API’s list endpoints (GET /v1/chats, GET /v1/projects)
returns only resources that were created through the API. Chats and
projects I created in the v0 web app never appear in these lists.
They clearly exist, belong to the same account/team, and are fully retrievable
by ID. This looks like a listing/indexing gap rather than intended behaviour, but
I wanted to confirm which it is.

I think the API is creating it against my user but my user in the webapp can only see the team.

Environment

  • v0 Platform API (Beta)
  • Single team workspace (no personal scope); key is team-scoped
  • Account is on a paid plan; key created from the API Keys page

Steps to reproduce

  1. Create several chats normally in the v0 web app (they show fine in the web UI
    under Chats / Projects).
  2. Mint an API key from the same account/team.
  3. Call GET https://api.v0.dev/v1/chats and GET ``https://api.v0.dev/v1/projects.

Expected

The list endpoints return my existing chats/projects (the docs describe find
as “retrieves a list of existing chats”, with no note that it’s limited to
API-created content).

Actual

  • GET /v1/chats → {"object":"list","data":[]} (empty), despite many web-app chats.
  • GET /v1/projects → empty, despite web-app projects.
  • After I create ONE chat via POST /v1/chats, it (and its auto-created project)
    immediately appear in the lists — so the API and auth work; the lists just
    exclude web-app-created content.
  • A project I then created in the web UI did not appear in /v1/projects.
  • Mirror image: the API-created chat does not appear in my web-app feed.

image
image448×688 39.9 KB

image
image448×688 38.5 KB

2

Hi Dubur,

I’d treat the two endpoints slightly differently.

For /v1/projects, the current docs mark v0 Projects as deprecated, so I would not rely on that endpoint as the source of truth for web-app projects. The more durable path is usually to read vercelProjectId from a chat, then use the Vercel API for Vercel project details.

For /v1/chats, your repro does look like either an API/web-app namespace gap or a docs gap. The useful clue is that GET /v1/chats/{chatId} works for a web-created chat, but GET /v1/chats does not include it, while API-created chats do appear. That suggests your API key/auth path is working and the difference is specifically in the list/index behavior.

I’d try these variants once to rule out filters/scope:

GET /v1/chats?limit=100
GET /v1/chats?vercelProjectId=prj_xxx
GET /v1/chats?branch=main
GET /v1/chats/{web_created_chat_id}

If the direct GET by ID works but all list variants remain empty, I’d report it as a v0 Platform API beta bug or documentation gap rather than debugging auth.

As a workaround, for chats created through the API, store the returned chat.id in your own DB and use GET /v1/chats/{chatId} for follow-up operations. For existing web-created chats, the safest non-sensitive detail to add is one redacted example showing: list response empty, direct chat lookup succeeds, and whether that chat has a vercelProjectId.