AI Upscaling API for Developers: Build Image Enhancement Into Your App

Why developers need an upscaling API

Users upload phone photos, supplier PNGs, and screenshots that look fine on a laptop and fall apart on a retina display, a marketplace zoom, or an 8K export. Bicubic resize does not invent detail. A real enhancement step has to run a model.

Hosting that model yourself means a GPU, a queue, model weights, and a failure mode every time a driver or CUDA version drifts. Most product teams do not want that surface. They want a request that accepts an image URL and returns a larger file they can store next to the original.

That is the job of an AI upscaling API. You keep your app's auth, billing, and storage. The enhancement step is one HTTPS call. UpRes exposes 14 public aliases — Flare, Prism, Lumen, Mirage, Motion, and Motion X — so product shots, portraits, old scans, and video do not share a single generic model.

REST integration

The public base URL is https://api.upres.ai. Authenticate with a bearer token from your dashboard API keys. Send a JSON body with the source URL, the model name, and the scale factor. A 4× Flare call looks like this:

curl -X POST https://api.upres.ai/v1/jobs \
  -H "Authorization: Bearer $UPRES_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "image_url": "https://cdn.example.com/product.jpg",
    "model": "flare",
    "scale": 4
  }'

A successful response includes a result URL you should copy into your own bucket before you show it to the user. Do not treat a provider CDN link as permanent storage. If the source is a private object, pass a short-lived signed URL; the API fetches it once and does not keep your credentials.

Images return when the job finishes, typically well under a minute for a 4× still. Video is slower, so poll the job id or register a webhook instead of holding the HTTP connection open. Timeouts on your side should be longer than a browser fetch default if you call the API from a server that also renders the page.

Batch processing

Catalog imports, archive rescans, and nightly asset pipelines should not loop one request per file on the request path of your web server. Submit a batch, get a job id back, and let a webhook tell you when each item is done.

curl -X POST https://api.upres.ai/v1/batch \
  -H "Authorization: Bearer $UPRES_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "items": [
      {"image_url": "https://cdn.example.com/sku-1.jpg", "model": "flare", "scale": 4},
      {"image_url": "https://cdn.example.com/sku-2.jpg", "model": "flare", "scale": 4}
    ],
    "webhook_url": "https://your-app.example/hooks/upres"
  }'

Keep concurrency bounded. A few hundred SKUs is a queue, not a thundering herd. Store the source id next to the UpRes job id so a retry does not double-charge a SKU that already succeeded. Idempotency on your side matters more than clever client retries: if the webhook arrives twice, your handler should no-op the second write.

Choosing the right model

Model choice is the difference between a sharp packshot and a waxy face. Match the mode to the content, not to a default you copied from a README.

• Flare — product and graphic work where edges and type must stay crisp.
• Prism — general photos when you want detail without an aggressive texture.
• Lumen — softer scenes and portraits where skin should not turn plastic.
• Mirage — damaged scans and old prints that need restoration before the scale-up.
• Motion / Motion X — video, including generative clips, where frame-to-frame consistency matters.

Scale 2× is enough when the source is already close to the target size. Use 4× for phone photos headed to a marketplace or an 8K master. 8× is for small sources that must fill a large canvas; it costs more compute and will invent texture if the source has almost none. If you are unsure, run the same image through two modes on the free tier and keep the one your designer picks.

Pricing

You do not need a GPU line item to ship this. API keys are available on the Business plan ($49/mo) and above; Free, Creator, Pro and Studio accounts cannot create API keys. You can try the web app on a lower plan first, then move to Business when you are ready to call the API from your own code.

A free allowance exists so you can wire the call, inspect a real response, and decide on a model before you attach a card. Check the pricing page for the current monthly caps; the dollar amounts above are the plan prices, not a per-image quote.

MCP server for AI agents

REST is the integration your backend should call. Agents need a different door. The UpRes MCP server exposes upscale, batch, model listing, and job status as tools, so Claude, Cursor, or your own agent can enhance an image without you pasting curl into the chat.

{
  "mcpServers": {
    "upres": {
      "command": "npx",
      "args": ["-y", "upres-mcp"],
      "env": { "UPRES_API_KEY": "upres_live_..." }
    }
  }
}

Point the server at the same API key you use for REST. The agent asks for an upscale; MCP translates that into a call against https://api.upres.ai and returns the result URL. That is useful in design review, support macros, and internal tools where a person describes the asset instead of writing HTTP. Production traffic from your app should still go through your server, where you can enforce quotas, log the source asset, and store the output.

If you are comparing architectures, the companion post on building a multi-model AI upscaling API covers routing and latency. This page is the integration path: one endpoint, a batch job when you have a folder, a model matched to the content, Creator at $9/mo or Studio at $39/mo, and MCP when the caller is an agent rather than your own code.