DEV Community: Lucas Him

How to Turn ChatGPT Images 2.5 into an API

Lucas Him — Mon, 12 Oct 2026 16:10:02 +0000

I could already ask my agent to generate an image through MCP. But I wanted to try something less conversational: send a prompt from a script and get a file back.

That was the gap I wanted a ChatGPT image generation API to fill. No agent choosing a tool for me, and no manual download at the end. Just a request my code could submit and a result it could retrieve.

The answer was in the BrowserAct ChatGPT image template I had already been using. Its published Bot could be called through HTTP as well as MCP. I tested that route with a perfume-bottle prompt and downloaded the resulting PNG.

What interested me was having one reusable image tool: I could call it from code, use it from a compatible agent, and keep the ChatGPT login in one configured browser environment.

I Wanted the Image Workflow in My Code

My earlier MCP walkthrough was about requesting images inside an agent. This time, I wanted to handle the inputs, waiting, and files myself.

For a script, “generate an image” needs a little more structure. Has the job been accepted? Is it still running? Where is the actual image, rather than a message saying it exists?

The template is named ChatGPT Image 2.5 API (Copy Before Use). BrowserAct runs the ChatGPT web task using the session saved in the personal Bot's browser environment. Its API gives my code a way to start that task and retrieve the result.

My code talks to BrowserAct, which runs the image task on the ChatGPT website. That means using BrowserAct's endpoints and task responses rather than the OpenAI SDK. For me, the appeal was reusing the image workflow I already had.

Setting Up the Bot and Getting an API Key

I already had my personal Bot published from the MCP setup. To start from the public ChatGPT image template, follow these steps:

Click Create Editable Duplicate to make your own Bot.
Keep a consistent browser environment. If you use a proxy, choose a static one before logging in rather than repeatedly changing it.
Open Build → Improve and restore your ChatGPT login without rebuilding the Bot.
Publish the personal Bot, then use its ID for the API request.

Here is the setup-to-image path, including both ways to call the published Bot:

The login instruction from my earlier setup was:

My login session is no longer available. I need to log in again. Do not rebuild or refactor the Bot. Keep the existing workflow, inputs, and outputs unchanged.

The setup walkthrough with screenshots covers those pages. If ChatGPT asks you to log in again later, return to Improve to restore the session.

Once the Bot is published, get a BrowserAct API key for your script. The API key guide shows the screens:

In the BrowserAct dashboard, open Integrations → Manage API Keys.
Select Create New API Key, give it a name, leave Confirmation Required selected for CLI actions, and click Confirm.
Copy the key and store it as an environment variable, such as BROWSERACT_API_KEY, rather than putting it in source code.

Use that key in the request's Authorization: Bearer header, together with your published personal Bot's ID—not the public template ID. The ChatGPT login stays with the Bot; the HTTP request does not need your ChatGPT password.

One POST Started the Image Task

I started with a Node.js HTTP client and a simple product-photo prompt:

Create a cinematic product photo of a transparent glass perfume bottle on dark green stone

There was no reference image. These were the request fields:

{
  "input": {
    "prompt": "Create a cinematic product photo of a transparent glass perfume bottle on dark green stone",
    "reference_images": "none",
    "max_prompt_characters": 4000,
    "max_reference_images": 4,
    "max_reference_image_mb": 10
  }
}

I set reference_images to none for text-to-image and left the prompt-length and reference-image limits at their defaults.

Here are the request details to use in your own HTTP client. Replace {BOT_ID} and {BROWSERACT_API_KEY} with your personal Bot ID and key at runtime.

The request went to:

POST https://api.browseract.com/v3/bots/{BOT_ID}/runs
Authorization: Bearer {BROWSERACT_API_KEY}
Content-Type: application/json

The response was HTTP 200 with status: "created" and a task_id. I saved that ID locally: it was how my script would follow the image job while ChatGPT worked on it.

From there, the integration had three separate jobs:

Step	Request	What my script did with it
Submit	`POST /v3/bots/{BOT_ID}/runs`	Saved the returned task ID
Check	`GET /v3/bots/runs/{TASK_ID}/status`	Waited for a terminal state
Retrieve	`GET /v3/bots/runs/{TASK_ID}`	Read the output and download information

All three requests use the same BrowserAct key. My script waits for finished before retrieving the image; failed or canceled should stop the wait and surface the task status.

Waiting for the Image and Downloading the Result

I watched the task move from created to running, then finished. I chose to check every 15 seconds and set a timeout so the script would not wait indefinitely.

A small implementation tip: save the task ID before polling. If a status request is interrupted, check that same task again rather than submitting another image job. If the initial POST times out before returning an ID, check the Bot's task history before retrying.

Once the task finished, I fetched its result. The image record in output.data looked like this:

{
  "image_file": "generated-image-1.png",
  "image_format": "png",
  "image_bytes": 2366709,
  "image_public_url": null,
  "mode": "text-to-image",
  "prompt": "Create a cinematic product photo of a transparent glass perfume bottle on dark green stone",
  "prompt_truncated": false
}

To retrieve the image, I used the download URL for resources.zip in download_files. The archive contained generated-image-1.png alongside a JSON result file.

Download tip: use download_files for the image archive. An empty image_public_url does not necessarily mean there is no image. The JSON, CSV, Markdown, and XML entries in output_files are structured-result exports, not the PNG itself.

When I opened the PNG, there was the transparent perfume bottle on dark green stone, complete with a generated AETHER label. This was a new image made from my text prompt, not an edit of an existing product photo.

This image came back at 1370 × 1148 pixels, about 2.37 MB. Its task used 16 BrowserAct credits and took 71 seconds from creation to completion, before I downloaded it. I would use the usage shown for each job when tracking costs, since other prompts can take different amounts of time and credits.

I left image settings to the ChatGPT web experience. For a project that needs an exact model, API quality tier, or output size, I would compare those requirements with the official image API before choosing this route.

Why Reusing a Subscription Is Worth Considering

Getting the file back made the subscription angle more interesting to me. The image is generated through the ChatGPT web subscription, while BrowserAct charges for running the automation. I am reusing the web image tool rather than paying for that request through the separate OpenAI image API.

For recurring image work, I would compare ChatGPT subscription + BrowserAct plan and any additional credits with the official API bill for the same workload. If I already pay for ChatGPT, I would also look at what BrowserAct adds to my existing bill. At enough volume, a lower combined cost could make a meaningful difference month after month.

Before putting a large queue through it, I would try a small batch and check the usable images, credits spent, and time needed. ChatGPT's web usage limits still set the pace. That gives me a better basis for a budget than multiplying the cost of this one image by a few thousand.

There is also a practical way to let a trusted friend call the configured Bot without handing over my ChatGPT password. For HTTP, the caller needs the API key, personal Bot ID, and request details. For MCP, the Bot must be exposed to a server, and the caller connects with that server's URL and matching key. After setup, they can request images from their own code or compatible agent while the Bot uses its saved browser environment.

What I like about that arrangement is keeping the ChatGPT login in the Bot's browser environment instead of passing the password around. Before inviting someone, I would check both the key's permissions and whether the intended use is allowed by the services involved. The key may cover more than this Bot, and their calls would use my account's credits and limits.

What I Would Keep Before Building on This

The small script now had three useful pieces: save the task ID, wait with a timeout, and download the file into storage I control. I would keep that structure when adding more prompts.

One habit worth keeping: use the BrowserAct key only on BrowserAct API requests, not on the image-storage download request. Keep keys and temporary download links out of public code, and save the image before its download link expires.

Reference-image editing would be my next step—the Bot accepts reference images, and I have so far used this HTTP path for the text-only perfume prompt. After that, I would try a small queue of non-sensitive prompts before deciding how much work to send through it.

For now, I had the ChatGPT image generation API workflow I wanted: a prompt went out from my code, and an image file came back. MCP fits the times when I want an agent to choose the tool. HTTP gives me control over when to call it and where the finished file goes.

If that is the gap in your own workflow, make a personal copy of the ChatGPT image template, connect your login, and start with one prompt. I would get that first file back before thinking about a queue.

How to Use ChatGPT Images 2.5 in Your Agent via MCP

Lucas Him — Fri, 09 Oct 2026 02:36:13 +0000

I already had access to image generation in ChatGPT. What I wanted was to use it from the agent I was working in.

That sounds like a small change, but it was the missing part of the workflow for me. I could get an image from ChatGPT Images 2.5 in the browser; I wanted to send the request in my agent and have the image come back there.

Could I connect my own ChatGPT account to an image tool through MCP?

I ended up using this BrowserAct template for ChatGPT Images 2.5. Here is how I connected it, and what happened when I asked my agent for an image.

I Started with a Ready-Made ChatGPT Images 2.5 Template

The template I used is called ChatGPT Image 2.5 API (Copy Before Use).

The part that caught my attention was that the browser task was already built. I could make a copy, connect my own ChatGPT login, and make the resulting Bot available to my agent. I did not have to describe an entire image-generation process from scratch.

The name includes “API,” but the connection I used runs the ChatGPT website through BrowserAct. The Bot uses the login saved in its browser environment. MCP gives my agent a way to call that Bot.

That suited what I wanted to try: reusing the image access in my own account from another tool.

Getting My ChatGPT Login into the Copied Bot

I clicked Create Editable Duplicate on the template page. This gave me a personal copy to work with. The public template itself cannot run as my account.

I started with an editable copy of the template.

The account connection came next. In the copied Bot, I opened Build → Improve and used this instruction:

My login session is no longer available. I need to log in again. Do not rebuild or refactor the Bot. Keep the existing workflow, inputs, and outputs unchanged.

The last two sentences matter here. The image task was already built; I only needed to supply my own login. I wanted to keep the existing inputs and output behavior while completing that step.

The instruction I entered in Improve: restore the login and leave the Bot unchanged.

I completed the ChatGPT login in the browser and then published the Bot. The password stayed in the login process; it was not something I needed to pass to the agent as part of an image request.

One setup detail I would keep consistent is the Browser Profile. If you use a proxy, I would choose a static proxy after copying the template and keep using that environment. It reduces changes between sessions, although it does not guarantee that ChatGPT will never ask you to log in again.

Making the Image Tool Available to My Agent

With the Bot published, I still needed to make it available through MCP.

I opened Integrations, then the settings icon on the MCP card. The tool name in my example was chatgpt_image_generator. I used the template README’s descriptions and set the inputs to AI-inferred, so the agent could fill them from the request.

The image tool configuration, with the agent supplying the request inputs.

There was another step after saving that configuration: exposing the tool to an MCP server. In MCP Server → Server Management → Exposed Tools → Not Exposed, I selected the image tool and clicked Expose.

Then I took the server URL and its matching API key from Connect to Clients and configured the connection in my agent. Once connected, the image tool appeared among the available tools.

The connection details I used in my agent. The server URL and key are hidden here.

That was the setup I needed for MCP image generation: a Bot with my ChatGPT session, plus a tool my agent could call. The BrowserAct MCP guide covers client connection settings, and this setup walkthrough with screenshots shows the pages.

I was ready to send an actual image request.

The Image Request I Sent—and the File I Got Back

Here is the prompt I sent from my agent:

I want to create an image of a little duck riding a pink bicycle and smiling happily by the seaside, surrounded by a group of children watching.

It was a text-to-image request, with no reference photo. For this template, that corresponds to reference_images: none and max_reference_images: 0.

In the conversation, I could see the agent call chatgpt_image_generator. After the image was returned, the client downloaded it, saved it, and read it back. The result message included a link to the PNG and a separate prompt record.

My image request and the tool call in the agent conversation.

The image report showed 1660 × 948 pixels, PNG, 2.63 MB. It also described the duck, pink bicycle, watching children, and seaside scene from my request.

The returned image report, including the PNG dimensions and file size.

This was the useful moment for me: the image request and the saved file were both in the agent conversation. I could open the result from there. The client had handled the download and local save.

I used DeepSeek for this example. The same setup is intended for agents that support BrowserAct’s remote MCP connection and authentication; the model name by itself does not determine compatibility.

The output also made one practical detail clear: I was getting the ChatGPT web result. I had not selected an API quality tier or requested that particular pixel size. Those were the dimensions of this image.

Where This Fits into My Work

What I wanted to keep was the ability to make an image request where I was already working. This run gave me that: my agent called the tool, and the resulting file came back into the conversation.

Using my own account was part of the appeal. I could connect the image tool without putting my ChatGPT password into the agent. The MCP URL and key become the connection credentials, so the key still needs to be kept private. Prompts and images also pass through the services involved in the workflow.

There is room to use the same Bot for ChatGPT image editing. It accepts reference images alongside an instruction, so a product photo and a background-change request can use the same connection. The duck example above is the text-to-image run I have to show here.

In testing, I saw BrowserAct usage of roughly 28 credits per run. I would check actual usage before planning a large batch, because that number is an observation rather than a fixed charge. ChatGPT’s image limits still apply, and an expired login still needs to be restored.

The published Bot also has a BrowserAct API route. For the way I wanted to use it—asking an agent for an image—the MCP connection was the one I needed.

My starting question was whether I could use my ChatGPT image access from an agent. I now had a working ChatGPT image MCP example, with a prompt I could repeat and a file I could open. If you want to try it in your own agent, you can make your own copy of the ChatGPT image template and start with a single image request.

Writing note: This article was drafted and edited with AI assistance.

Dynamic Web Scraping Tools in 2026: Where BrowserAct Fits

Lucas Him — Tue, 28 Jul 2026 06:46:32 +0000

Dynamic web scraping is no longer a niche engineering problem.

It shows up in market research, product monitoring, lead generation, review tracking, creator research, and competitor analysis. The hard part is not fetching one page. The hard part is working through JavaScript-rendered interfaces, filters, tabs, scrolling, pagination, detail pages, and website changes without turning every task into a custom maintenance project.

That is why "best dynamic scraping tool" is usually the wrong question.

The better question is: what kind of dynamic scraping workflow are you trying to run?

Some teams need raw page content. Some need full browser control. Some need a repeatable scraper without writing code or managing selectors. Those are different jobs, and the tool choice should reflect that.

This is where BrowserAct fits.

Why Dynamic Scraping Is Harder Than Simple Extraction

Static scraping is often about reading visible HTML and parsing it once.

Dynamic scraping usually involves more moving parts:

Content appears only after JavaScript runs
Filters and tabs change the page state
Data is split across listing pages and detail pages
Infinite scroll or pagination hides part of the dataset
Login, CAPTCHA, or protection layers interrupt the flow
The same task has to run again with new inputs next week

That last point matters more than people think.

Many tools can help you extract something once. Fewer tools help you turn a business request into a reusable, repeatable workflow that still makes sense after the first run.

Three Common Types of Dynamic Scraping Tools

When teams say they need "a dynamic scraping tool," they usually mean one of three categories.

1. Extraction APIs

This category is useful when you mainly want page content, HTML, or cleaned text as an input to another system.

It is often a good fit when:

Your team already has engineering resources
You want to plug page content into your own parser or LLM pipeline
You are comfortable owning the transformation layer after retrieval

This category is not always the best fit when the real problem is multi-step browser behavior, repeated business tasks, or non-technical users who need structured results without building the rest of the workflow themselves.

2. Browser Automation Frameworks and Infrastructure

This category is useful when engineers want full control over browser behavior.

It is often a good fit when:

You need scripted interaction with complex page states
Your team wants low-level control over navigation and extraction logic
You are comfortable maintaining code, selectors, retries, and browser execution

This is powerful, but it is still an engineering workflow. It is usually the right answer for developer-owned automation, not for every business user who needs repeatable structured data.

3. No-Code Prompt-to-Bot Products

This category is useful when the goal is not "control a browser" but "get a reusable data workflow from a plain-language request."

That is the category BrowserAct is built for.

BrowserAct starts from the data request. You describe the website, the records to collect, the conditions to apply, and the fields to return. The agent explores the live website, tests the task in a real browser, builds a reusable Bot, and returns structured results when you run it.

A Practical Comparison

Tool category	Best starting point	Who it fits best	What you still own
Extraction APIs	"Get me page content"	Developers building their own pipelines	Parsing, navigation logic, repeatability, output shaping
Browser automation frameworks	"Let me script the browser"	Engineering teams needing full control	Browser logic, maintenance, retries, task design
BrowserAct	"Get me this dataset from this site"	Teams that want a reusable scraper without writing scraping code	Task definition, permissions, input parameters, output review

The important difference is not whether one category is "better." It is whether you are starting from content retrieval, browser control, or business outcome.

Where BrowserAct Fits Best

BrowserAct is a better fit when the task looks like this:

"Collect the top products for this category and return price, rating, seller, and source URL."
"Track pricing and product updates across competitor pages every week."
"Build a public business list with names, categories, ratings, websites, and contact details."
"Pull public posts or reviews matching a topic and return structured fields."

In other words, the task is dynamic, structured, and repeatable.

The BrowserAct model is simple:

Describe the data you need in natural language
Let the agent explore and test the live website
Publish the Bot once it works
Run it again with new inputs
Continue optimizing it when the website changes

That makes BrowserAct especially useful for teams that care about outcome speed more than writing their own scraper logic from scratch.

How BrowserAct Handles a Dynamic Scraping Task

1. Describe the task in plain language

Start with the website, the records you want, the filters or conditions to apply, and the fields you need back.

For example:

Go to https://www.amazon.com/Best-Sellers/zgbs.

Collect the top 100 products from the Best Sellers list.
For each product, return the product name, price, product URL,
and other relevant fields shown on the page.

The category should be configurable.

This is the key shift in workflow design. Instead of starting with selectors or browser scripts, you start with the dataset definition.

2. Choose the browser environment

Before the build starts, choose the browser mode and region that fit the target website and market.

That environment becomes part of the task context during the build and future runs.

3. Let the agent explore and test the live website

BrowserAct then works through the actual site in a real browser.

This is where dynamic scraping stops being a theory problem and becomes an execution problem. The agent can validate filters, tabs, pagination, scrolling, and detail-page coverage during the build instead of pushing that responsibility entirely onto the user.

4. Run the published Bot and review structured output

Once the Bot is built, you can run it again with the current input parameters.

The goal is not a blob of scraped content. The goal is ready-to-use structured output aligned with the fields you asked for.

5. Keep improving the Bot when the website changes

Dynamic websites change. A serious workflow needs to account for that.

BrowserAct keeps build and run history, and it lets you continue optimizing a draft before publishing the updated version.

That draft-versus-published separation matters because it gives teams a way to improve a scraper without breaking the current working version.

When BrowserAct Is a Better Choice Than Building From Scratch

BrowserAct is usually the stronger choice when:

You want structured data, not just page content
The workflow spans multiple dynamic page states
The same task will run repeatedly with different inputs
The end user should not have to write selectors or scripts
You want build history, run history, and an explicit optimization workflow

It is also a good fit when your team wants to plug the result into downstream tools instead of rebuilding browser logic internally. BrowserAct's cloud product is designed around reusable Bots and repeatable runs, rather than a one-off scrape.

When BrowserAct Is Not the Right Starting Point

BrowserAct is not the best starting point for every scraping job.

You may want a different approach when:

You only need a single page fetch or raw HTML response
Your engineering team specifically wants low-level scripted browser control
You need to own every part of the execution stack in code
You do not have permission to access the target site or data

And like any real-world scraping product, BrowserAct is not a promise of universal access to every protected website under every condition. Website permissions, login requirements, verification flows, and page changes still matter.

The Real Decision

Most teams do not actually need "the best dynamic scraping tool."

They need the right starting point:

Retrieval-first
Browser-control-first
Or outcome-first

BrowserAct is an outcome-first option.

If your task is "I need this dataset from this website, and I need to run it again without turning it into a custom scraper project," BrowserAct is the category worth evaluating first.

That is the gap between browsing infrastructure and reusable business extraction workflows, and it is exactly where BrowserAct is designed to help.

Start Free Trial and build your first reusable scraper with BrowserAct.

[Boost]

Lucas Him — Wed, 22 Jul 2026 08:23:18 +0000

Lily

Jul 22

Your Claude Code Setup Gets Bloated If You Ignore It — Weekly Auto-Slimming by Watching Injected Bytes, Agent Count, and Frustration Words

#claudecode #automation #launchd #bash

6 min read