Some API endpoint improvements/changes/suggestions

API Feedback
, ,
1

Hi, I’ve been using the Assistant API over the last few days. In the main it’s been a good experience. I do have a few suggestions:

  1. Avoid _ in field name - can make serialization require more code (maybe consider (CamelCase).

  2. Object of the same name existing at different level should be named differently, eg, ThreadMessage (or example) rather than message (can be confusing as there is already a Message)

  3. JSON rule consistency across request and response - in request null fields are not allowed but null fields allowed in the response.

  4. Consider if the Retrieve Assistant should create and an Assistant in the background - this would allow for Assistant created on the UI to be consumable from the API. With no need to create an Assistant in code if you’ve already created in from the UI.

The general use case for the Assistant API seems to be in the vein of a webserver/host with a Thread representing a user connection. Without Retrieve Assistant working something like mentioned in point 5, this doesn’t seem to quite work, at least how I currently understand it at the moment. It seems odd, expensive and slow to upload files at the point the Assistant is created in code (given the files could be many and relatively large).

Additionally, in other use cases such as a desktop application running across a number of machines where each wants to connect to the same assistant seems a potential issue. If each need to create its own version of the same Assistant and associated file.

On the documentation side, really like the structure of the API reference. A couple of suggestions.

  1. Where Path parameters are not required might still be worth have the Path parameters section, but jus says something line None.
  2. The same for Query Parameters.
    These two suggestions would help to keep the documentation a little more consistent across all endpoints.

Do feel free to shoot down any or all of those suggestions with good reasons.
Thanks, and would appreciate clarification of any misunderstanding on my part.

1 Like
2

Since they still must be interacted with by code, and can emit functions you handle yourself, I would liken the calls to:

create assistant: like a AI model, multi-user, that brings along operational methods;
create thread: a conversation session of a user (and the AI internal history);
create run: API call, putting in motion the newest message added to a thread.

That lets you compare: that multiple users or user browser sessions can use ChatGPT, but a chat can be continued only by one session.

CamelCase for not-a-class-or-object? Them’s fighting words!

Null values returned instead of keys appearing and disappearing allows some more predictability and validation.

Null values required makes every new feature parameter a breaking change.

3 Likes
3

Thanks for the quick response and clarificaton. Those points make sense.
Agree on “…predictability and validation point.”

This one is slightly off topic:
Retrieve assistant: does this create an Assistant in the background using the settings of the already created assistant?
Create run: always returns “No assistant found with id …” for the given assistant_id - where assistant_id is from a newly created assistant (just created). Any ideas here (in the most general sense as not sharing code or anything)?

Thanks.

4

I just gave an analogy to think about assistants in terms of other AI usage, although it is quite different.

If it’s going to be an API documentation…

“Retrieve assistant” just lets you obtain information about the already-created assistant you specify, such as its instructions. That can be used in “list” to find the IDs, and “modify” to add or change operations.

1 Like