Automate Repetitive Image Work
Manual image processing does not scale well when a catalog, user upload system or creative pipeline contains hundreds or thousands of images.
An API can move the same image-upscaling rules into a repeatable workflow.
Add image enlargement and enhancement to your website, application or content workflow without maintaining a local GPU-processing system.
The Upscayl API accepts supported image files, starts an asynchronous upscaling task and returns a task ID that your application can use to check progress and retrieve completed outputs.
Choose an AI model, select a 2×, 4× or 8× scale, enable face enhancement when appropriate and export the result as JPG, PNG or WebP.
View API pricingAPI features, model identifiers, file limits, rate limits and credit requirements can change. Treat the current API reference as the authoritative implementation source.
| Capability | Current documented behavior |
|---|---|
| API type | Asynchronous image-processing API |
| Base server | https://api.upscayl.org |
| Authentication | API key through X-API-Key |
| Direct uploads | Supported |
| Multipart uploads | Supported through presigned URLs |
| Input formats | JPG, PNG and WebP |
| Output formats | JPG, PNG and WebP |
| Scale options | 2×, 4× and 8× |
| Face enhancement | Optional parameter |
| Batch mode | Represented in the task model |
| Task states | Pending, processing, completed and failed |
| Results | Completed file details and download links |
| Billing information | Credit status and deductions represented in task data |
These details reflect the current public Upscayl OpenAPI specification. Validate the live specification before implementation.
Open the Current API ReferenceThe Upscayl API is a hosted image-processing interface for developers.
It allows a product or internal system to submit an image for AI-assisted upscaling without installing the Upscayl Desktop application or operating a dedicated local graphics-processing environment.
Authenticate with an API key.
Submit an image and processing settings.
Receive a task ID.
check the task until it reaches a final state.
Retrieve and validate the completed output.
This asynchronous approach is useful because image processing may take longer than a standard web request. Your application can continue other work while Upscayl processes the task.
Manual image processing does not scale well when a catalog, user upload system or creative pipeline contains hundreds or thousands of images.
An API can move the same image-upscaling rules into a repeatable workflow.
The Upscayl API moves the documented processing task to hosted infrastructure. Your team remains responsible for integration logic, user authorization, input validation and output review.
The API exposes several model options rather than forcing one model onto every source.
This is useful when a product handles different classes of images, such as photographs, illustrations and ecommerce assets.
Users can submit an image and receive a processed output without being sent through a separate manual application.
The task-status endpoint exposes processing state and progress, allowing an application to present a queue, progress indicator or background job.
JPG, PNG and WebP outputs let the integration match different delivery requirements.
Use JPG for suitable photographic delivery, PNG where lossless output or transparency behavior is required, and WebP for supported web workflows. Verify exact transparency handling through a first-party test.
The documented start-task operation accepts a direct binary file upload through a multipart request.
Keep the API key on the server. Do not expose it in client-side JavaScript, mobile application code or a public repository.
The current API includes operations for obtaining multipart upload URLs and completing a multipart upload.
This workflow is suitable for larger files or upload flows that benefit from sending the file in parts.
The API returns a task ID instead of requiring the client to keep one request open until image processing finishes.
The official task-status endpoint documents pending, processing, completed and failed states. Get Task Status documentation.
The current specification lists model options intended for different image characteristics.
Do not expose raw model identifiers without guidance. Add a user-facing model name, recommended source type, example crop and limitation summary.
An optional face-enhancement setting is documented for the start-task operation.
Use it selectively for portraits, older photographs and appropriate group images. It should not be enabled automatically for every image.
AI face enhancement can create plausible detail that was not present in the source. Applications should not present the output as a factual reconstruction.
The documented API supports 2×, 4× and 8× scale parameters.
Choose the smallest scale that meets the final requirement. Larger output dimensions can increase credit use, processing time, storage and artifact visibility.
The application should select an output based on intended use rather than applying one format to every image.
The documented task model includes batch-mode behavior and arrays of processed files.
Obtain an API key through the current Upscayl account or developer-access process.
Never put a production API key inside public frontend code.
The current API specification documents JPEG, PNG and WebP input MIME types and a 100 MB maximum file-size field. Confirm these values against the live API specification before enforcing them in production.
Model selection should be based on image type, not the most dramatic model name.
Submit the source image and selected settings to the documented start-task operation.
A successful request returns a task identifier.
Start Upscaling Task documentation.
Store the task ID with your internal job record.
Poll the task-status operation at a controlled interval.
Do not issue continuous status requests. Use backoff, stop polling when the task reaches a final state and respect documented rate limits.
Retrieve the documented download link.
Download the file to controlled storage.
Confirm its MIME type and dimensions.
Scan or validate the output where required.
Attach it to the correct internal asset.
Apply your own retention policy.
Remove temporary data when no longer needed.
Do not assume that a completed API status means the output is visually suitable.
The following example is intentionally conceptual. Copy the exact request structure from the current API documentation before deployment.
POST /upscale
X-API-Key: ••••••••••••••••
file: product-image.webp
model: photography
scale: 4
output_format: webp
face_enhancement: false
→ { "task_id": "task_…" }
X-API-Key: YOUR_SERVER_SIDE_API_KEYThe API key must be sent from trusted server-side code.
Implementation note: the public endpoint documentation and OpenAPI examples should be checked for request-shape consistency before code is copied into production.
A model should be selected through testing with representative source images.



Start with a restrained photography-oriented model.
Reject results with strong halos, plastic skin or repeating texture.
The current API specification includes model identifiers for digital-art workflows, but the production UI should explain their visual behavior instead of relying on identifiers alone.
Watch for repeated or synthetic-looking texture.
AI enhancement should not alter the appearance of the actual product.
Test the base upscale before enabling face enhancement.
Use server-side requests and a managed secrets system.
Do not make a user’s browser wait for the complete upscaling operation.
Create an internal job record and process status updates in the background.
Use a reasonable initial delay followed by backoff.
A webhook would reduce polling, but the reviewed public specification does not document one. Do not claim webhook support unless it is added to the current reference.
Retry only failures that are likely to be temporary.
Do not blindly resubmit every timeout. A request may have started successfully even when the client did not receive the response.
Before production launch, confirm whether the API supports idempotency keys or another duplicate-task safeguard. The reviewed specification does not clearly document one.
A task can fail when the account has insufficient credits. The current specification documents an insufficient-credit error and credit information in task status.
Estimate cost before submission.
Alert before the balance becomes too low.
Prevent partially funded batches.
Record credits used per internal job.
Reconcile API usage with billing records.
Never overwrite the source automatically.
A technically successful API response can still produce an unsuitable image.
Automatically create larger product assets for storefronts, marketplaces, zoom views and campaign layouts.
Use a product-specific quality check to ensure that labels, materials and colors remain accurate.
Offer optional image enhancement after a user uploads a small or compressed image.
Keep processing asynchronous and show a clear job state.
Create higher-resolution derivatives when images enter an asset library.
Store the original, processed version and transformation metadata together.
Prepare larger working images before validating them against print dimensions and output requirements.
Upscaling does not guarantee that every source is suitable for print.
Generate larger versions of thumbnails, campaign images and creative assets.
Preserve editable text and logos separately whenever possible.
Standardize image dimensions while retaining realistic property or item details.
Do not use AI enhancement to misrepresent a property, vehicle or product.
Create larger working copies of scanned photographs before restoration.
Keep the archival scan untouched.
Provide optional 2×, 4× or 8× exports for generated artwork.
Use models that preserve linework, gradients and the intended artistic style.
Connect image upscaling with client intake, content approval and export workflows.
Confirm that client agreements permit Cloud processing.
A user needs only occasional manual upscaling.
Images cannot leave local infrastructure.
A compatible Desktop installation already meets the workflow.
The project requires undocumented latency or uptime guarantees.
The organization needs self-hosting.
Current rate or file limits do not meet expected volume.


| Requirement | API | Cloud | Desktop |
|---|---|---|---|
| Primary interface | Programmatic requests | Web browser | Installed application |
| Best for | Product integration | Manual online workflow | Manual local workflow |
| Processing | Hosted | Hosted | Compatible local hardware |
| API key | Required | No developer key for normal UI use | Not required |
| Image upload | Required | Required | Not required for local jobs |
| Automation | Strongest option | Limited to product UI | Manual or local workflow |
| Credits | API/Cloud billing | Plan-based credits | No hosted processing credits |
| Local GPU | Not required by client | Not required by client | Normally required |
| Batch potential | Programmatic | Cloud interface-dependent | Desktop batch workflow |
| Data control | Governed by API service and your storage | Governed by Cloud service | Local user control |
Upscaling must happen inside your product.
Tasks need to run automatically.
You need task IDs and processing status.
Your system manages many user or catalog images.
Hosted processing fits your data requirements.
A person wants to upscale images through a browser.
No integration is required.
Cloud editing or generation tools are useful.
Local processing is important.
A compatible computer is available.
The user wants a free, open-source application.
Image upload is not appropriate.
The documented API task flow includes credit checks and credit deductions.
Do not estimate cost using unverified assumptions.
Current Cloud pricing includes trials, subscriptions, one-time credit options and custom plans, but API pricing should be confirmed separately before presenting Cloud plan prices as API rates. Current Upscayl pricing.
View API Pricing Contact API SalesAn API integration uploads user images to hosted infrastructure. Privacy and security information must be visible before implementation.
Users retain ownership of uploaded content.
Uploaded images are not used to train AI models.
Inputs are generally retained for a limited period.
Generated outputs have a separate retention period.
Cloud service providers assist with authentication and storage.
Encryption in transit and at rest is provided through the service infrastructure.
Review the current privacy policy and terms of service, then confirm whether every Cloud policy applies identically to API jobs.
Keep keys server-side.
Validate file types and dimensions.
Limit upload size before sending.
Authenticate the user initiating the task.
Record who submitted each image.
Avoid logging API keys or signed download URLs.
Rotate compromised credentials.
Download outputs into controlled storage.
Apply your own deletion policy.
Do not expose another user’s task ID or output.
Review sensitive images before Cloud processing.
Read API Security and Data HandlingA production system needs both technical error handling and visual quality control.
The Upscayl API is a hosted image upscaler API for starting image-upscaling tasks, checking processing status and retrieving completed outputs.
Use the current developer-access or account process to obtain an API key. The production page should link directly to the current key-management interface.
The current OpenAPI specification documents an API key sent in the X-API-Key request header.
No. Send requests through trusted server-side code and store the key in a secrets-management system.
The current specification identifies JPEG, PNG and WebP MIME types. Confirm the live documentation before enforcing format restrictions.
The current start-task operation lists JPG, PNG and WebP outputs.
The current specification documents 2×, 4× and 8× options.
Yes. The current start-task specification includes an optional face-enhancement parameter.
The API task schemas represent batch mode and multiple files. Verify current per-task file limits, combined size limits and credit behavior before building a batch system.
Store the task ID returned when a job starts and use the task-status operation to check progress and final state.
The reviewed public specification does not clearly document webhook delivery. Use controlled status polling unless the current documentation confirms webhook support.
The task model includes a failed state and error information. Record the error, classify it and retry only when the failure is likely to be temporary.
Yes. The current OpenAPI specification documents endpoint rate limits. Treat those values as changeable and read the current API reference before setting production throughput.
The current uploaded-file schema lists a 100 MB maximum. Other pixel, plan or batch limits may also apply.
Credit cost can depend on the processing request and current pricing rules. Show an estimate before submission when possible.
The current Upscayl service terms state that uploaded images are not used to train AI models. Confirm that the same provision applies to your API agreement.
Commercial use depends on your API agreement, selected models and rights to the source images. Review the current terms before launch.
No. It can generate a larger interpretation and may improve certain edges or textures, but it cannot recover every missing detail.
The reviewed documentation provides request examples, but a maintained official SDK matrix was not clearly documented. Do not advertise official SDKs unless they are published and supported.
The reviewed material describes a hosted API. Do not promise self-hosting unless a separate supported product or license is documented.
Automate image upscaling with hosted processing, multiple models, task tracking and supported output formats.
Start with a small set of representative images. Measure output quality, processing time, credit use and failure behavior before moving a production catalog or user workflow to the API.
Get Upscayl API Access Read the API Documentation