OpenAI is widening API access to its deep research models, giving developers a way to use models built for current information, advanced reasoning, and longer-running work outside ChatGPT.
What OpenAI is adding to the API
The deep research versions of o3 deep research and o4-mini are now available through the API. These models were already used in ChatGPT, and OpenAI is positioning them for tasks that need up-to-date information and advanced reasoning.
The API access is not limited to a model name change. The source article says developers are also getting tools that support automated web search, data analysis, MCP, and code execution. Together, those capabilities point to a workflow where the model can gather information, reason over it, work with data, and run code as part of a larger task.
For developers, the practical shift is that deep research can move from a product experience into application workflows. Instead of relying only on a chat interface, teams can call these models through the API and connect them to systems where research, analysis, or code-supported reasoning is part of the job.
Why web search matters for reasoning models
OpenAI is also supporting web search across models including o3, o3-pro, and o4-mini. That matters because the source specifically ties these models to tasks requiring up-to-date information. A model with web search can be used in workflows where stale information would limit the answer.
The source gives two pricing details for web search. Reasoning web search starts at $10 per 1,000 calls. For GPT-4o and GPT-4.1 web search, the price has dropped to $25 per 1,000 calls.
Those numbers give developers a clearer way to estimate the cost of applications that depend on search. A research-heavy product, for example, may need to account for search calls separately from other model usage. The article does not provide a full pricing table, so the clearest takeaway is the direction: OpenAI is pairing broader model access with explicit pricing for web search.
Webhooks reduce the need to keep checking status
Another addition is webhooks. In this context, webhooks automatically notify developers when a task is complete, which means an application does not need to keep checking whether the job has finished.
That is especially relevant for longer-running jobs. OpenAI suggests using webhooks for longer-running jobs like deep research because they can improve reliability. The source does not describe the implementation details, but the use case is clear: when a task may take time, developers can wait for a completion notification instead of repeatedly polling for status.
This fits the broader shape of deep research work. Research, data analysis, code execution, and web search can take longer than a simple response. Webhooks give developers a cleaner way to build around that delay while keeping the application informed when the result is ready.
What developers can build around now
The update gives developers a set of API building blocks centered on research and reasoning. Based on the source article, the core pieces are:
- o3 deep research and o4-mini through the API
- Automated web search for current information
- Data analysis support
- MCP support
- Code execution
- Webhooks for task completion notifications
The significance is not any single feature on its own. It is the combination. A developer can design an application around a model that can search, analyze data, use MCP, execute code, and report completion through a webhook when the work is done.
The source does not say how developers should combine these tools, and it does not describe every available model configuration. But it does make the direction clear: OpenAI is expanding access to deep research capabilities through the API, while also supporting web search and completion notifications that fit longer and more complex tasks.
The broader API direction
This release makes OpenAI API access more useful for work that depends on current information and multi-step reasoning. The deep research versions of o3 deep research and o4-mini were already part of ChatGPT, and their arrival in the API gives developers a way to bring similar capabilities into their own products and workflows.
For teams evaluating the update, the key questions are practical ones: whether their use case needs up-to-date information, whether code execution or data analysis is part of the workflow, and whether a longer-running job would benefit from webhooks. If those needs are present, the new API access gives them more direct tools to build around.