ImgBB
StorageHost images on ImgBB and get instant public links, accepting a FlowRunner file, a public URL, or base64 content. Agents publish generated or processed images so downstream systems can embed them.
What This Integration Enables
ImgBB is filed under storage and it is not really storage. It is publication. The moment Upload Image returns, the file is reachable by anyone holding the link, with no login and no access check, and that is the feature: it is what lets an email client render the chart, a chat card fetch a thumbnail, or a social post display an asset that existed only as bytes inside a flow a second earlier. FlowRunner agents can hand it a FlowRunner file, a publicly reachable URL for ImgBB to fetch server-side, or a raw base64 string, up to 32 MB, and get back the viewer page, the direct image URL, thumbnail and medium renditions, byte size, pixel dimensions and a delete URL.
The interesting control is the one most people skip. An upload is permanent by default, or it can be set to auto-delete after a chosen period anywhere from five minutes to six months. Most flows that need a public URL for an image need it for about four minutes, long enough for the message to be composed and delivered, and then never again. Treating the expiry as the default and permanence as the deliberate exception is the difference between a tidy integration and a slow accumulation of company material sitting on a public host with nobody's name on it. That matters more than usual here because the API surface is genuinely one operation: ImgBB documents no way to list, search or delete previously uploaded images. The delete URL returned in the response is the only handle that will ever exist for that file, so a flow that discards the response has published something it can no longer manage.
Without FlowRunner
With FlowRunner
Use Case Scenarios
A generated chart into an outbound report
An agent renders the weekly performance chart with QuickChart and needs it inside an email rather than as an attachment, because attachments break the layout the client asked for. It calls Upload Image with an expiry set a few days past the send date, takes the direct URL for the image tag and the delete URL for the job record, and sends the report. When the window passes, the image goes away on its own, which is the correct outcome for a report that has already been read.
An inbound attachment turned into a shareable link
A support workflow receives a photo from a customer as a binary attachment. Passing binary through three downstream systems is fragile, so the agent uploads it once and passes the direct URL instead, attaching it to the ticket in Zendesk and to the record in the CRM. The expiry is set to match the retention the support policy allows, so the link stops working on the same schedule the ticket data does rather than outliving it indefinitely.
A one-time preview for an approval step
An agent produces a design variant that a person needs to look at before anything is published. It uploads the image with a short expiry, posts the direct URL into the approval message in Slack, and stores the delete URL. Once the decision comes back the agent calls the delete URL immediately rather than waiting for the expiry, so the preview exists for roughly as long as the conversation about it did.
Human-in-Loop Highlight
Publishing is the whole point of this connector, so publishing is the whole risk. Upload Image does not put a file somewhere with an access policy in front of it. It makes the file reachable by anyone with the link, immediately, and uploads are anonymous, meaning there is no account-side inventory to audit later. If the image was assembled from customer data, a rendered invoice, a chart with named accounts on the axis, a screenshot of a dashboard with real records visible, then the call that makes it convenient is the same call that makes it public.
So the agent stops before the upload, not after it. It presents the image itself and the exact terms of the publication to the person who owns the account: "This chart has three named client accounts on it. Upload to a public ImgBB URL with a fifteen minute expiry, upload with no expiry, or send it as an attachment instead?" The third option is the one that matters, because it lets a person decide the image should never become a public URL at all, which is a decision no expiry setting can make for you. When the answer is upload, the agent captures the delete URL in the same step and writes it to the job record before doing anything else, because that string is the only means of removal that will ever exist. This is the small version of the pattern FlowRunner is built around: the agent does the work, and a person holds the one decision that cannot be taken back.
Agent Capabilities
1 actionsImages
1- Upload Image Upload an image to ImgBB and return its public hosting links. The source can be a FlowRunner file whose bytes are downloaded and sent as base64, a publicly accessible image URL that ImgBB fetches server-side, or a raw base64 string, and exactly one of the three is supplied. Images may be up to 32 MB, and a file name and an auto-deletion time can be set. Returns the viewer page URL, the direct image URL, thumbnail and medium variants, the delete URL, byte size and pixel dimensions. Used whenever a workflow has an image in hand and the next system in the chain can only accept a link. Uploads are anonymous and permanent unless an expiration is chosen, and ImgBB provides no API to list or delete images afterwards, so store the returned delete URL if the image may ever need removing.
Frequently Asked Questions
What can FlowRunner do with ImgBB?
FlowRunner agents can run Upload Image in ImgBB.
Does connecting ImgBB to FlowRunner require OAuth?
No. ImgBB connects to FlowRunner with an API key, no OAuth flow required.
Can ImgBB trigger a FlowRunner workflow automatically?
ImgBB doesn't currently expose triggers in FlowRunner. It connects as an action step inside workflows started by another trigger.
Start building with ImgBB
$100 in credits. No card required. Connect in minutes.