Feature request: Read-only API for ChatGPT conversation archiving and observability

ChatGPT Feature requests
,
1

I would like to request a read-only API for a user’s own ChatGPT conversations, including Projects and Work conversations.

This does not need to be an API for sending prompts or controlling ChatGPT. Even strictly read-only access would solve several practical problems for users who use ChatGPT for long-running technical or research work.

1. Reliable conversation archiving

It would be extremely useful to be able to periodically retrieve and archive my own conversations programmatically.

A minimal API could expose:

  • immutable conversation ID

  • conversation title

  • creation and last-update timestamps

  • project ID/name, where applicable

  • conversation type/mode

  • messages and their timestamps

  • basic attachment/tool metadata

  • current Work run status, where applicable

A stable immutable conversation ID is especially important. UI titles are useful for humans, but they are not a good primary identifier for an external archive because titles can change during the lifetime of a conversation.

Ideally an archive could therefore use:

conversation_id -> current title -> project -> messages

rather than depending on whatever title happens to be visible in the sidebar at that moment.

2. Incremental sync instead of occasional full exports

The existing data-export mechanism is useful as a backup mechanism, but it is not well suited to maintaining a current local archive.

A read-only API could allow something as simple as:

  • list conversations updated since timestamp X

  • retrieve one conversation by immutable ID

  • retrieve messages added since message/timestamp X

This would make it possible to maintain a private user-owned archive without repeatedly exporting the entire account.

Read-only OAuth/API scopes would be sufficient.

3. Conversation capacity / context headroom

For very long conversations, especially conversations involving many tool calls or long Work sessions, it would also be extremely useful to expose some indication that a conversation is approaching its practical limit.

It does not have to reveal implementation details or an exact token count.

For example:

  • Healthy

  • Large

  • Near conversation limit

or an approximate percentage / remaining-capacity indicator.

At the moment, a long-running project conversation can eventually reach a point where continuing it becomes impractical or impossible, but the user has very little advance warning.

For ordinary chat this is inconvenient.

For a long Work session, where significant execution has already happened and the user may have invested substantial Work quota and time into the conversation, reaching that boundary unexpectedly is much more disruptive.

An early warning would let users create a checkpoint and deliberately move to a fresh conversation before hitting the boundary.

4. Work lifecycle observability

For Work conversations, a small amount of additional read-only lifecycle metadata would also be valuable:

  • running

  • waiting for user

  • paused

  • recovering

  • completed

  • failed

  • stopped

and, if available:

  • run ID

  • start/end timestamps

  • last activity timestamp

This would also make it much easier to distinguish a client-side stream problem from an execution that is actually still running on the backend.

Minimum useful version

Even a very small first version would already be valuable:

GET /conversations

GET /conversations/{id}

with immutable IDs, timestamps, title/project metadata and messages.

Everything else — Work lifecycle information and conversation-capacity indicators — could be added later.

The main goal is simple: allow users to keep a reliable, user-owned, read-only archive of their own ChatGPT work and give them enough observability to manage very long conversations safely.

2

I want to add a concrete use case for why this feature would be useful. I recently bought Rokid Style smart glasses. They can already use ChatGPT for AI assistance, but that integration is separate from my actual ChatGPT account, so it cannot access or continue the conversations I already have here.

What I would like is a user-authorized API, similar in concept to how OBS can be authorized to interact with a Twitch account. I could sign into my OpenAI account, explicitly authorize a third-party app, and choose which conversations or Projects that app is allowed to access. The authorization could be scoped and revocable so the third-party app never needs my OpenAI password and does not automatically gain access to my entire account.

With that capability, I could build or use a Rokid companion app that lets me continue a specific ChatGPT conversation through my glasses. For example, while traveling I could open my existing trip-planning conversation and ask questions through the glasses while walking around, rather than starting a completely separate AI session with none of the context from months of planning.

This would also be useful beyond smart glasses. The same permission model could allow wearables, accessibility devices, voice assistants, automotive systems, or other third-party interfaces to become extensions of a user’s existing ChatGPT conversations rather than isolated AI clients.

Ideally, the user could grant permissions such as read-only access, permission to continue selected conversations, access to selected Projects, and possibly Memory as a separate permission. Each authorization should be individually revocable.

For me, the value is continuity. I do not just want access to the same model on another device. I want access to the conversation and context I have already built with ChatGPT.