How Upscayl made API testing repo-native with Requestly Local Workspace

About Upscayl

Upscayl is a free, open-source AI image upscaler for macOS, Windows, and Linux.  It enhances low-resolution images using advanced AI models, and now also offers a cloud API for programmatic upscaling

Core API surface (simplified):

• POST /start-upscaling-task — kick off an upscaling job (supports multipart uploads and options like model and scale; authenticated via X-API-Key).
• POST /get-task-status — poll progress, get output links/metadata, and handle credit deduction when processing completes.

The challenge

Before adopting Requestly, contributors often tested those endpoints with ad-hoc cURL snippets or personal notes. That caused:

• Friction for newcomers (headers/tokens/params easy to miss).
• Duplication and drift (the “right way to test” lived outside the codebase).
• Limited privacy controls (sharing examples could expose secrets if not handled carefully).
  Upscayl wanted an approach that was simple to run, lived with the code, and kept sensitive data local by default. (Endpoints and required auth are documented publicly, but day-to-day testing still needed to be safe and repeatable.) 

Solution: Requestly API client [Local Workspaces] 

Local Workspace is a Requestly workspace type where all API collections, requests, and environments are stored on the developer’s machine—nothing is synced to a vendor cloud unless the developer explicitly shares or commits files. That makes it ideal for API keys, localhost servers, and work-in-progress changes.

Key reasons it fits Upscayl’s workflow:

• Privacy-first by design. Collections, requests, and environment data live only on disk, so tokens (e.g., X-API-Key) never leave the developer’s machine unless they choose to commit them (and you shouldn’t).
• Repo-native, version-friendly. A Local Workspace folder can sit right inside the project (e.g., apis/upscayl/). API examples evolve in lockstep with the code, so changes to model, scale, headers, or payloads are reviewed like any other change.
• Clone → open → run. Devs clone the repo, open the workspace folder in Requestly Desktop, set baseUrl and X-API-Key, and immediately run start-task → get-task-status. That’s minutes, not hours.

What changed for Upscayl contributors 

• Faster onboarding. One folder to open; ready-made requests; environment variables captured once. New contributors can run real flows immediately.
• Single source of truth. Testing lives with the codebase. If the API evolves, the runnable examples evolve too—no more stale gists or screenshots.
• Safer day-to-day testing. Since data stays local, teams avoid accidental token leaks and can still use Git to review structure (collections, request shapes) without exposing secrets.
• Covers real-world cases. Upscayl’s API includes multipart uploads for big images; the Local Workspace keeps that multi-step flow as first-class requests, so it’s easy to reproduce and debug.

60-second quickstart (how a contributor uses it)

1. Clone the Repo & Open the workspace locally
   Requestly Desktop → Workspaces → Create Local Workspace → select the repo’s API folder (e.g., apis/upscayl/). Your data stays on your device.
2. Set environment values
   baseUrl = https://api.upscayl.org
X-API-Key = <your key>
3. Upload file and start upscaling:
   1. Start Upscaling Task
      1. POST /start-task with multipart/form-data, including file(s) (or URL(s)), model, scale, etc. 
      2. Response includes taskId. 
      3. Poll with POST /get-task-status (with JSON body containing taskId) until status indicates completion and files are present.
      4. Once files are ready, retrieve / download them via the path(s) returned.

Conclusion

For Upscayl’s simple, task-based API—start a task and check its status, with optional multipart steps for big files—this turns onboarding into “clone → open → run,” and makes repeatable testing the default. It’s a practical pattern any team can adopt to get repo-native, private-by-default, ready-to-run API examples without managing a separate cloud workspace.
In short, Upscayl shows that when your API tests live with your code and on your device, contributors move faster, secrets stay safer, and the docs never fall out of step with reality.