Access to current user identifier within GPTs

In relation to the GPTs functionality, I know that at the moment you can retrieve your own UserID using the API.

Is it possible to retrieve an ID for the user that is currently using a GPT?

A use case would be where you want to store information in a backend app for each user specifically and retrieve it later via the functions.


I second this question. I think moving forward with custom GPTs, it’s going to be useful to be able to know the user’s ID.

1 Like

You can implement OAuth and have your users sign in. I doubt openai would offer a way to id users without their consent.

1 Like

So then it isn’t possible (via GPTs) to retrieve data relevant to an individual user?

Context is maintained in threads, but you’re not going to get a user identifier that would be consistent across threads/GPTs

1 Like

So then there’s no way to connect an App that’s built with my own custom front-end (and using the OpenAI API) with my GPTs?

That seems like it’s a missing feature as it means we can’t build GPTs that interact with IoTs…

Maybe I’m misunderstanding something? It seems like GPTs will just be narrowed-down versions of ChatGPT and not powerful things that can interact with user-specific content…

If you want to build your own UI, then use Assistants (also new) rather than GPTs. Same concepts just without the GPT UI.

1 Like

I guess the motivation for going the GPTs route was to take advantage of the upcoming store. We wanted our app to be available to others via the store without us having to market it ourselves.

After some testing, I did find that the API calls to our backend from ChatGPT does pass the conversation id and an ephemeral user id, which expires after 24 hours. Unfortunately, this won’t be useful, since it’s not a persistent value. Seems to be the same as what’s available for plugins.


I was thinking about this, and I suppose a user could just identify themselves by just telling your GPT what their username and password is.

It could then just call an action in your schema to store the user for future retrieval, or verify who it is.

1 Like

Yeah I come down to this realization recently, a couple of thoughts:

  1. if you can afford it, make your service stateless so you don’t need to rely on uid, or session id or what not, I know it’s not always feasible but worth a shot;
  2. Use assistant API. You probably lose some traffic from open AI store (in the future), but you gain better control, e.g. uid;
  3. Make some clunky actions that allow user to jump to your login page and you figure out how to wire up whatever in their request and user login event, in my opinion, not worth it.

Am also interested in something like this.
Right now seems like the best solution is to build our own chat as a workaround.

But a feature like this seems like it could be added in the future, rendering the cost/benefit of the effort involved in building our own chats questionable.