Non-logged in curls are auto purged after 30 days.

The container has restricted outbound access—only HTTP/S requests are allowed. It runs inside an isolated network namespace with no access to the host network or other infrastructure components. There's no inbound access, and the container can't receive unsolicited requests from the outside world.

The sandbox container can only communicate with other containers in the same network, the main application container and sandbox container are on the same network, allowing them to communicate.

I have a feature working to allow users browser side execution, but as others have also pointed out CORS is a big blocker for client side execution not working for all APIs.

I hadn’t actually considered dict:// usage, I see the bug report as well, thanks, will see if I can include it.

https://github.com/uncurl/uncurl-support

Yes, delete is unauthenticated as highlighted, will be working on a fix for this. And you can delete any API if it is created as a logged in user.

You can absolutely delete your curl if you have created as a logged in user.

uncurl.dev kind of grew out of that same spirit, but with the goal of making the output shareable and executable in a browser, especially for folks who might not have an IDE set up or are outside the usual dev loop (PMs, etc.)

Security is a top priority for this project, and I'm actively working to tighten things up. This initial version was launched to validate the concept, and admittedly, there were oversights (including an unauthenticated DELETE endpoint that was highlighted).

If you're open to it, I'd love to learn more about what you'd want to see from a security standpoint in a tool like this. I'm building in public and happy to be corrected where needed.

Thanks again for keeping things real.

CORS was a blocker for client side requests, I have a separate branch where this is integrated, maybe will add it alongside server side execution to let the person creating the curl decide whether they can execute on browser or server side.

I kept finding myself sending curl requests in Slack or email, and it felt clunky—especially when non-devs or support teams needed to test something quickly. uncurl.dev started as a way to make that share-and-execute process more visual and frictionless.

For the auth part—embedding API keys in payload is a no-go in most cases. For now, sending out auth headers separately for them to fill in themselves is what I did within my workplace.

I'm exploring a couple of ideas to help with this:

Team-scoped secrets: For logged-in users or teams, saving common auth headers that aren’t part of the shared link.

One-time, encrypted secrets: The link works once and destroys the sensitive payload after execution.

Really appreciate you taking the time to look and let me know (even if it had to be in public). I have added a github repo for filing bugs (https://github.com/uncurl/uncurl-support) in the docs page :)

I built uncurl.dev to scratch my own itch: I kept getting curl commands in API docs, bug reports, or Slack messages and wanted a quick way to visualize, run, and debug them without firing up Postman or writing code to dissect them. It was also sometimes painful to create a test page specifically for non-tech users to consume an API. I originally vibe-coded this over a weekend just to make it easier for myself to debug API requests shared as curl commands. It slowly grew into something I found surprisingly useful in my workflow, so I decided to clean it up and share it.

uncurl.dev takes a curl command and: - Converts it into a visual representation - Lets you edit and inspect all parts of the request - Allows sharing via a unique link - (Optionally) executes it from the server, so business or non-technical users can see results

Execution is currently behind login, with a cap (5/min) to avoid abuse and manage costs. Non-logged-in users can still build and share curl commands—they just can’t execute them. The server runs each request in a Docker sandbox with strict resource/time limits (cpu, memory, timeout, no network access outside the request).

It’s not meant to replace full-featured tools like Postman or Hoppscotch. It’s more of a “CLI-to-UI bridge” for fast sharing and debugging, especially in dev workflows where curl is the starting point. Think of it like Pastebin or JSFiddle, but for curl commands.

If you’ve ever copied a curl from an API doc and wanted a cleaner way to see it or send it to someone else, I’d love your feedback.

Thanks! (You can try it without signup here: https://uncurl.dev)

Comments URL: https://news.ycombinator.com/item?id=43607744

Points: 115

# Comments: 59

I wanted to build something similar, but at that time photos did not expose APIs to get list of photos.

What was your work around? Or have they opened up the APIs now?