IronStratum Get an API key

Image generation API: one route, two FLUX tiers, per-image metering

An image generation API turns a written prompt into a returned image over HTTP. Buyers searching this product type meet a wall of price directories and per-host doc pages. Each has its own request shape, its own metering unit, and its own rounding rules. The decisions that actually matter sit above any single rate. Which request shape your code lives against. Which metering unit your budget can be written in. How the family of models splits between fast iteration and final renders. This platform's images category is one OpenAI-shaped route carrying both tiers of the FLUX family from Black Forest Labs, metered per image, flat in size. This page is the framework for choosing inside it. Each lane's model page carries the complete working contract with the platform's own dated receipts.

Last verified: 2026-09-24

What an image generation API does

Start with the smaller product inside the name. A text-to-image model takes a prompt and produces pixels. That is the whole job. The family tree of those models is what most comparison pages sort by.

The API around the model is a different product. It answers the questions the model does not. How a request is shaped. How many images come back. What happens when one fails. What a retry costs. What the usage accounting says. The ecosystem standardized on one answer, OpenAI's images API. A POST carrying model and prompt and a handful of parameters. A response carrying hosted image URLs. An n bound of ten. Sizes as WIDTHxHEIGHT strings. Client libraries speak it everywhere. That is why a new lane that mirrors it starts compatible with code that already exists.

The market's metering units are the part the directories underplay. Hosts in this class bill per megapixel with rounding rules of their own, per thousand output images, or per image. Same model, same pixels, three different budget arithmetics. This platform's images category normalizes the unit. One metered image, any size. The budget line is written before anything is sent.

One route, two tiers

The images category carries both tiers of the FLUX family, and the split is the family's own.

The fast lane

flux-1-schnell is the speed tier. It is distilled for few-step generation. Its own reseller page positions it as tailored for local development and personal use, with the self-host road that positioning implies. Its host page at fal, read 24 September 2026, sets its knobs with size presets and an inference-step count of 1 to 4. It measured 3.1 to 4.2 seconds to first byte here, across seven dated test requests. That is the iteration tier, cheap enough to loop on.

The quality lane

flux-pro-1.1 is FLUX 1.1 Pro, the quality tier. Its host page at fal, read the same day, tells the split mechanically. Explicit width and height instead of presets. An inference-step count. A guidance scale, the lever that trades prompt adherence against looseness. The levers are the product. This is the tier final renders go to. Together's serverless catalog lists the tier in the same family namespace and bills its whole image catalog per megapixel. That is the market shape this platform's flat per-image meter stands against.

Choosing by workload

The fastest route to a decision is to name the job, not the vendor.

Your jobThe laneWhy
Prototyping, iteration, agent loopsFast3-to-4-second first bytes, per-image metering at the iteration price point, retry-safe with idempotency keys
Final renders, hero and campaign imageryQualityThe guidance-scale and explicit-dimension levers live on this tier
Batch asset generationEither, by stakesn up to 10 per request, billed per image returned
Pipelines with budget ceilingsBothThe wallet is the hard stop; the flat per-image meter is the budget line
Local-first projects needing overflowFastThe tier's own positioning is local development; a metered lane covers the spikes

One honesty note belongs next to that table. Latency figures here are the platform's own dated single-account measurements. One route, one region, one day. They size timeouts honestly. They are not throughput benchmarks. The model pages carry each figure with its basis named.

The images catalog on this platform

This section states the offering at offering level. The model table on this page is generated from the platform's live model list. The list decides what serves.

Both lanes answer one route, POST /v1/images/generations, with one strict parameter set and one metering law. Billing is uniform across the category. Per image returned, flat in size, paid from the prepaid wallet. A call that arrives after the balance is gone is refused with a named error. A refusal at the door is never metered. The usage object on every answer carries the platform's own images count and cost figure at six decimals. The ledger and the response can be reconciled call by call.

Any single key is revocable the moment it leaks, and a revoked key stops spending at once. The wallet is the spend boundary that ships today. The pricing page is where each rate renders. A rate lives there, and a change shows there first. That is why no number is typed here. The bill-shock guide, listed in the block below, works through the routines that stop a metered account from surprising you.

Moderation runs ahead of every generation. The provider's side checks the input. A refusing prompt gets a refusal that names the policy class and the flagged input, as first observed on this platform 24 September 2026. Through this route the refusal surfaces as the platform's standard upstream_rejected error. It names neither provider nor prompt. The refused generation bills zero. It still writes its failure row to the spend ledger.

Running FLUX yourself

The fast tier's own reseller positioning is local development and personal use. That says the self-host road is real for that tier. Iterate locally, and use a metered lane for the spikes. Those are the occasions the local GPU is busy elsewhere, or the day the project outgrows a single card. The quality tier is the rented class in practice. The hosts that carry it set it up for hosted quality work, and its levers assume a hosted service around them.

The hosted lane earns its keep the same way every category on this platform does. The endpoint stays up through a batch spike. The metering is per image and visible per call. The wallet bounds the damage a runaway loop can do. The maintenance work lives on someone else's desk. The break-even arithmetic for that trade belongs in a spreadsheet, not a hunch. The bill-shock guide below walks it.

Getting started

  1. Request an invitation through the console. The beta is invite-only for now. The wallet, API keys, and full spend history live there.
  2. Create a key and check the rate once. The pricing page renders the live per-image rates. Images times rate is the whole budget arithmetic, flat in size.
  3. Read the lane that matches your job. Each model page carries the complete contract with dated receipts. The fast lane and the quality lane.
  4. Make the first call. One POST with a key, an alias, and a prompt. When one image comes back clean, the rest is n and size arithmetic.

Everything else the platform serves, chat, speech, transcription, embeddings, rerank, parsing, and classification, is mapped on the models index, all drawing from one wallet.

The catalog table

Specialty models — kind and unit price
ModelKindPrice
flux-1-schnellimages$0.003/image
flux-pro-1.1images$0.04/image

Token prices per 1M unless the unit says otherwise; a dash means the value isn't set yet — confirmed when the model goes live. Everything here is served by the same API that bills you: GET /v1/models. The full list with model details lives on the model index.

Guides

Questions

What is an image generation API?
An HTTP service that takes a text prompt and returns a generated image. The term covers a ladder of shapes. At the bottom sits a bare model endpoint. A prompt goes in, pixels come out, and the caller owns everything around it. That means the queueing, the storage, and the retry logic. Above that sits an OpenAI-shaped images API. One POST with a prompt. A response carrying hosted image URLs. A documented parameter set. Usage accounting on every answer. That second shape is what most client libraries already speak. It is why this platform's images route mirrors it. The practical question for a buyer is which shape their code wants to live against. This platform's answer is the one the ecosystem standardized on.
What does the images route accept?
POST /v1/images/generations with a Bearer key. The accepted parameter set is strict. It takes model, prompt (required), n as an integer from 1 to 10, size as a WIDTHxHEIGHT string of positive integers, and response_format with the value url. Anything else is refused with a 400 naming the parameter. Nothing is dropped silently. The strictness matches the provider's own behavior. OpenAI's images API specification documents the same n bound and the same WIDTHxHEIGHT size grammar. The platform checked each field's behavior against fal's live API on 24 September 2026, before the route shipped.
How does billing work on the images category?
Per image returned, counted from the response's data array, not the requested n, and flat in size day-one. A request for three that returns two bills two. A failed generation bills zero. It still writes its failure row. A request refused at the door bills nothing. Spend comes off a prepaid wallet, and the balance is the hard stop. Once it empties, an arriving call is refused with a named error instead of overrunning the deposit. Every response carries a usage object. Its images count and cost figure are the platform's own numbers, never the provider's. Retries are covered by idempotency keys. The same key with the same body replays the cached answer without a second charge.
What about the returned URL?
Responses carry hosted image URLs under fal's media domain. They pass through unchanged. The platform does not proxy, cache, or rehost image bytes. Treat every URL as temporary. fal expires hosted media per the account's media-expiration setting. The market's documented analogue is OpenAI's own url mode, which its specification bounds to 60 minutes. The working law is to fetch the bytes promptly and store them on your side. Base64 responses are not offered day-one because fal's API rejects the parameter. The response_format field accepts url. Any expansion to b64_json lands as a documented flip with a dated receipt, never silently.
FLUX schnell or FLUX 1.1 Pro, which do I call?
Both answer the identical contract. The same route, the same parameter set, the same per-image meter, the same hosted-URL return. The choice is workload. Schnell is the family's fast tier, positioned by its own resellers for local development and personal use. It measured 3.1 to 4.2 seconds to first byte here, across seven test requests. Pro is the quality tier, measured at 6.7 seconds. The provider sets it up with explicit width and height and a guidance scale. Those are the quality levers the fast tier does not carry. The working pattern is to iterate on the fast tier and send the renders that matter to the quality tier. Both model pages carry the complete contracts.
Can I call the images route today?
Yes, with an invited account. The route serves both FLUX tiers, billed per image from the wallet. The platform runs as an invite-only beta in this phase. The console holds the wallet, the keys, and the spend history. A key created there works against the images route the moment the account holds balance. The guides listed with this page include the OpenAI-compatible API guide. It walks the client-library pattern this route mirrors. The bill-shock guide works through the routines that stop a metered account from surprising you.