Background: true responses return 404 after ~20 minutes despite store: true, while synchronous responses remain retrievable

API
, ,
1

Hi everyone,

I’m trying to determine whether this is expected behavior or a bug in the Responses API.

I ran several tests using the following settings:

  • Model: gpt-5.5
  • Endpoint: POST /v1/responses
  • store: true
  • Same OpenAI project and API key
  • Retrieval using GET /v1/responses/{response_id}

I tested both with and without a conversation ID.

Test results

background store conversation GET /v1/responses/{id} after ~20 minutes
false true No :white_check_mark: 200 OK
true true No :cross_mark: 404 Not Found
false true Yes :white_check_mark: 200 OK
true true Yes :cross_mark: 404 Not Found

For the synchronous request:

{
  "model": "gpt-5.5",
  "input": "Test received.",
  "background": false,
  "store": true
}

More than 20 minutes later:

GET /v1/responses/{response_id}

still returns 200 OK.

For the background request:

{
  "model": "gpt-5.5",
  "input": "Test received.",
  "background": true,
  "store": true
}

After roughly the same amount of time:

GET /v1/responses/{response_id}

returns 404 Not Found.

Adding a conversation ID didn’t change the behavior—the synchronous response remained retrievable, while the background response returned 404 Not Found.

Questions

  1. Is this expected behavior?
  2. Is a response created with background: true intended to be a temporary resource that expires after the background polling window, even when store: true is set?
  3. If so, should the documentation clarify that store: true does not guarantee long-term retrieval via GET /v1/responses/{id} for background responses?

I couldn’t find any documentation or an existing forum post that explicitly addresses this behavior, so I wanted to check whether this is the intended design or something that should be investigated.

Thanks in advance for any clarification!

2

I could not immediately reproduce this issue, and your code looks fine. My best guess at this point is that it was an intermittent glitch. I will keep an eye out for similar reports.

3

Duly noted, thanks for your response.

4

There is a bug right now with background_mode, I’m not sure how this is possible with “Astra” and “AGI around the corner.” But it started ever since the “inference optimization” and “Fast mode” came out.

Can you please file a support ticket to expedite?

5

I replied in the original topic.

6

Can I request that you poll again for those responses that were created with background: true if they still return a response after the couple of hours that has passed?

7

They will eventually leave “in_progress” and become “completed”

This can take 30-60 minutes for a response that would normally take ~2.5 minutes.

8

Yes. Both requests are still stored after approximately 1 hour 47 minutes.

9

@VeitB ohh that’s interesting. Did you have conversation added?

10

I did not because it appeared unnecessary.

11

Okay thank you. That’s helpful.

12

Are you still running into this problem or can you retrieve the stored responses now?

13

Thanks…i’m still running into the problem. I just tested it now