Canonical: https://botbento.com/blog/openai-background-mode-needs-your-own-job-record/ Format: Markdown representation of the public HTML page. [Home](/) / [Blog](/blog/) FIELD NOTES / 4 MIN READ # OpenAI's Background Mode Runs the Call. Your Bot Still Needs a Job Record OpenAI's Responses API background mode lets a bot submit a long-running call and fetch the result later instead of holding a connection open. It solves the timeout problem, not the job-tracking problem. A bot that uses background mode still needs its own record of what was submitted, what came back, and what to do if the webhook never arrives. By BotBento Editorial · Published 2026-10-26 · Updated 2026-10-26 AI-assisted editorial: researched and drafted with AI using the primary sources linked below. Examples are illustrative; they are not measured product results. [Editorial policy](/editorial/). ## In this article - [What background mode actually fixes](#the-timeout-problem) - [What background mode does not do](#what-it-does-not-do) - [Worked example: a weekly competitor-report bot](#worked-example) - [The decision](#the-decision)[Read as Markdown ](/text/blog/openai-background-mode-needs-your-own-job-record/index.md) ## Key takeaways - Background mode means you submit a request, get an id and a queued status, then poll or wait for a webhook — the connection does not need to stay open. - Response data from a background call is only kept for about 10 minutes unless the request sets store=true, and background mode is incompatible with Zero Data Retention. - The API gives you a status and an id. Whether a webhook arrived twice, whether a poll should keep running, and what counts as a stuck job are decisions your bot has to make and record itself. ## What background mode actually fixes A bot that asks a reasoning-heavy model to do real work — summarize a long document set, run deep research, review a large codebase — can wait several minutes for an answer. If that wait happens on a held-open HTTP connection, something in the chain usually gives up first: a serverless function's timeout, a proxy, a flaky mobile connection. Background mode exists so the call does not depend on that connection surviving. Background mode works by submitting the request with a background flag and getting back an id and a queued status immediately, instead of blocking until the model finishes. The caller then either polls that id or waits for a webhook to find out when the response is ready, and fetches the full result separately from the original submission. OpenAI's own guidance frames the clearest use case directly around its deep research models, which routinely take too long to hold a connection open: it recommends running them in background mode and configuring a webhook for completion rather than blocking the client. Sources: [Background mode](https://platform.openai.com/docs/guides/background), [Deep research](https://platform.openai.com/docs/guides/deep-research). ## What background mode does not do Background mode changes how long a call can run, not what happens to the data afterward or what your application is responsible for tracking. Response data from a background call is stored only long enough to support polling — roughly ten minutes — unless the request explicitly sets store=true, in which case it follows the project's normal retention period instead. If your bot polls slower than that window, or misses a webhook delivery, the result can simply be gone. That retention rule has a second consequence worth flagging for any bot operating under Zero Data Retention requirements: background mode's temporary storage of response data for polling is explicitly called out as incompatible with ZDR. A bot built for a regulated workflow needs to check this before switching a synchronous call to background mode, not after. Webhooks cover delivery notification, not job bookkeeping. OpenAI's webhook system can notify you when a background response, a batch, or a fine-tuning job finishes, by subscribing a dashboard endpoint to an event like response.completed and then triggering a background request. But a webhook delivery is a notification, not a ledger entry. Networks retry. Endpoints can receive the same completion event twice. Nothing in the API decides for you whether a second delivery for the same response id should be treated as new work or ignored. Sources: [Data controls in the OpenAI platform](https://platform.openai.com/docs/guides/your-data), [Background mode](https://platform.openai.com/docs/guides/background), [Webhooks](https://platform.openai.com/docs/guides/webhooks). ## Worked example: a weekly competitor-report bot Say a small team runs a bot that generates a weekly competitor research report using a deep-research-capable model. The call routinely takes four to eight minutes, so it is submitted with background mode and store=true, with a webhook pointed at response.completed. Illustratively: the bot submits the request Monday at 6 a.m., writes a local record — job id, response id, submitted\_at, status: queued — and goes idle. Three things can happen next, and only one of them is the happy path. The webhook arrives once, the bot fetches the response, marks the local record completed, and files the report. That's the case the API is designed around and the one every blog post demos. The other two paths are where a job system earns its keep. First: the webhook never arrives — maybe the endpoint was briefly down, maybe the delivery was dropped. If the bot has no fallback poll and no staleness check, that record sits at queued forever, and nobody notices until someone asks where Monday's report went. Second: the webhook arrives twice, because that is how at-least-once delivery works. If the bot's webhook handler isn't idempotent on the response id, it processes the same report twice — filing a duplicate, re-sending a Slack message, or double-charging a downstream action that runs on completion. Neither failure is a background-mode bug. Both are gaps in the surrounding job record that background mode was never built to fill. The fix is unglamorous: store the response id as a unique key before marking anything processed, run a periodic sweep that polls any job still queued or in\_progress past a reasonable deadline, and treat 'no webhook and no completed status after N minutes' as its own alert condition rather than silence. ## The decision Use background mode when a call's expected duration is close to or past the timeout of anything in its path — a function runtime, a proxy, a client connection. For short calls that finish in a few seconds, it adds a polling or webhook round trip for no benefit. Whether or not you use it, build the same three pieces of bookkeeping around any long-running tool call: a local record keyed on the response id before you submit, a deduplication check on whatever notifies you of completion, and a timeout sweep that catches jobs stuck below a terminal status. Background mode removes the need to hold a connection open. It does not remove the need to know, independently of the API, whether a given job actually finished. ## Primary sources Sources checked 2026-10-26. Standards and product documentation can change; follow the linked version when implementing. - [Background mode](https://platform.openai.com/docs/guides/background) — OpenAI - [Webhooks](https://platform.openai.com/docs/guides/webhooks) — OpenAI - [Deep research](https://platform.openai.com/docs/guides/deep-research) — OpenAI - [Data controls in the OpenAI platform](https://platform.openai.com/docs/guides/your-data) — OpenAI BotBento is in development. [Suggest a correction](/contact/).