State management (multiple operations, multiple users, refresh)

I would like to know about “state management (stateful or not)” when each API is given multiple operations.
Also, is it possible to control its refresh?

Furthermore, How about the state when the same API account is used by multiple users?

is there any person who know about these?

The API does not have any state. Whatever you send it is a one-time operation.

If you want to build an application using the OpenAI API @shiraishi.takahiro which manages state based on a user session, you need to develop your session management code on top of the OpenAI API.

The OpenAI API does not provide any session management service.

However, if you wait a bit the “hopefully soon to be released” ChatGPT API may (or many not) have some session management features.

Hope this helps.


1 Like

I concur this is a very important feature, it is a show stopper for some projects require chat /dialog like interaction. “you need to develop your session management code”, even dev is able to do son, there no way to pass an session identifier /user id (user parameter is use for abuse detection only) as API parameter to track a dialog thread in a multiple users (using same API key) environment.

Yes ,for reference…

Check out the OpenAI API completion parameter and you will see you can pass a userid to the API.

Hopefully the ChatGPT API improves that for session management.


Thank you for everyone.
I understand The API does not have any state.

sorry, I have the next question.
we are executing by POSTing by API_Key (token), but can we execute as POST of another user even though the API Key is the same?

Yes, you can specify in all OpenAI API competition calls a “user” which you can use to track actions related to that user, but as mentioned,

OpenAI Safety and Best Practices

Sending end-user IDs in your requests can be a useful tool to help OpenAI monitor and detect abuse. This allows OpenAI to provide your team with more actionable feedback in the event that we detect any policy violations in your application.

However, just because the user param on the OpenAI server / service side of the transaction is only used for abuse monitoring by OpenAI, you can still use the userid / name to manage state on your end.

For example, you can have a database where you store each prompt and completion and you can assign those to a userid.

Even though the current OpenAI API is “stateless”, you can still manage the session and the state in your applications.

I already do this with my OpenAI Rails apps and for all transactions I store the transactions in a DB along with the user and when I create a new topic, I assign that topic an topic id, assign it to a user, etc.

It’s all pretty basic stuff, really, if you have experience with stateless API endpoints.

Hope this helps.




Thanks to your help, I could collect necessary information.

I am new to Web API and OpenAI API, so perhaps I have asked you a rather basic question.

Thank you.

Do not worry, at least you know your own programming experience and limitations.

We see a lot of people here who mistakenly expect that they can just make a few API calls and don’t have to write any code to actual build an application using the API.

Or even worse, folks who have little to no software dev experience and also mistakenly think ChatGPT will write “excellent” full applications for them.

Take care.


I dont think storing local database solve the problem.

Lets storyboard this scenario (same API key)

  • 2 users A, B
  • A asked a question (Qa) - AI response (Ra)
  • B asked a question (Qb) - AI response (Rb)
  • A asked a follow up question on Qa (Qaa) – How AI knows this is related to Qa (unless historical dialog -Qa is also sent as part of this prompt) ?

I have exactly same concern that Kyau had. Multiple end users access my web app which has only one API key connect to open AI server. How to let each user get their own subsequent questions in period of time get answered without being mixed up with other users’ questions. This is a fairly typical use case for most of web apps. Without dynamic created session, the web app is not scalable.

1 Like