v0-sdk

And regenerate the SDK

hey-api bundles this in the version we're using!

Summary Three related asks, in order of increasing value: 1. Accept and return on projects parity with what chats already have. 2. Return in list responses (, ), not just on the detail objects. 3. Support server-side filtering by metadata on / . Ask 1 alone doesn't help much without ask 2; ask 3 is what makes this efficient at scale. Scope: all three are v0 Platform API changes first (new request/response fields, plus a new query filter), with the generated SDK following from them. None of it can be done in the client alone; see Note: this needs both an API and an SDK change at the end for why. I'm filing here because this is the public tracker for the Platform API surface, and I'm happy to move it if there's a better venue. Environment : 0.16.4 Node: v24.15.0 Motivation I create v0 projects programmatically from an automated system, and each project needs to carry the identifiers of the record in my own system that produced it. Today there is nowhere on a project to put them. Two concrete consequences: Correlation depends entirely on my own store staying in sync. The only link between a v0 project and the record that created it is a mapping I hold on my side. If my write fails after has already succeeded, the project exists in v0 with nothing on it indicating where it came from unattributable, and invisible to my own tooling. A field set in the same call as the create makes the project self-describing, so that state is recoverable instead of orphaned. Selecting a subset of projects means reading all of them. returns every project with no filter, and exposes no field I control, so any "give me the projects belonging to X" query becomes a full list followed by one per project. This is the same need already serves on chats. I need it one level up, on the object that groups them the project also owns the shared , the env vars and the Vercel link, so it's the natural place for provenance to live. Current state Chats do support metadata: carries a field too, so the concept is already established in more than one place in the API. Projects do not**: And list responses omit the free-text fields entirely: adds , and , but only via . likewise omits , even though has it so metadata is unusable for filtering a chat list today. Neither accepts a metadata filter: Proposed shape Expressed in the SDK's types for precision, but these are the underlying API request and response fields: And, for asks 2 and 3: Exact-match on supplied key/value pairs would be entirely sufficient for my use case no operators or nested querying needed. Note: this needs both an API and an SDK change To be explicit about where the work lands: the API has to accept and persist the new field (and honour the new filter), and the generated client has to be updated. The SDK cannot carry this on its own, and neither can the API alone. builds an explicit body whitelist rather than spreading , so a key passed by a caller is dropped client-side before the request is ever made, even if the API were already willing to store it. likewise sends no query string at all (), so ask 3 needs a new parameter threaded through both layers as well. Happy to help If it's useful, I'm glad to test against a preview or beta and report back I use all three of , and in production code paths and would exercise each part of this.