Accessing Labels via REST API vs. GraphQL: Limitations and Impact

Nathan P. · 2025-11-03T19:48:07.319Z

Hmm...it would seem that labels are not exposed via the REST API, only via GraphQL? Thus, it is not possible to use the SDK to access prompt labels? This is a bummer as I'd like to use labels as a way to group prompts by the context in which they should become visible in our UI.

RunLLM
APP
·
·
Prompt labels are currently exposed via the GraphQL API and are shown in the UI, but there is no evidence in the provided data sources that the REST API exposes prompt labels directly. The REST API's /prompts endpoint lists prompts but does not mention label data, and there is no documentation or code indicating label support in REST responses or the SDK as of now. Thus, accessing prompt labels via the SDK or REST API is not supported at this time; only GraphQL provides this functionality for grouping or filtering prompts by label[cb1d7ff9]54e95f22 a6a95a88.Would you like more detail on how to use GraphQL to access prompt labels or how to request this feature for the REST API?Sources: - cb1d7ff9 - 54e95f22 - a6a95a88
💡 Hint: Mention RunLLM in the thread for followups.
Nathan P.
·
·
The ideal would be to be able to query with AND semantics both tag and labels
Nathan P.
·
·
I can work around this on my own, but it's more trouble than native support for this obvious (to me anyway) use case.
Roger Y.
·
·
i have opened an issue for prompt labels
Roger Y.
·
·
the tags are actually on the version level, where labels are on the parent prompt level (a prompt is collection of versions), so AND semantic is not directly compatible for the two on the UI
Nathan P.
·
·
yeah, I realized that after I posted 🙂
👍1
Roger Y.
·
·
I’d like to use labels as a way to group prompts by the context
so you would like promps.create() to be able to create labels at the same time. is that right??
Nathan P.
·
·
yes, exactly
Roger Y.
·
·
ok got it. thx
Nathan P.
·
·
To expand on my use-case, we have a general-purpose UI component that lives on in various contexts and it expects to be able to query our backend for a list of prompts (just name and title) given the location it is used (e.g. resident-list-page) and environment (prod/staging/dev). I'm adding a backend endpoint to service and querying Phoenix for the current list of prompts for the environment tag. Currently I'm having to use GQL instead of the SDK to read the labels. Ideal case would be a REST+SDK method of pushing this filtered query into Phoenix. Does that make sense? Happy to answer any more clarifying questions...
Roger Y.
·
·
so something like client.prompts.list(..., labels=[...], tags=[...]) -> list[PromptVersion] ?
Nathan P.
·
·
yup yup
Roger Y.
·
·
got it. thx!
👍1
Nathan P.
·
·
Thank you!
1
Nathan P.
·
·
It would also be nice to be able to set initial tags on the first version created by prompts.create

16 comments