[themanmaran]

I see a fair bit of utility here. We have an API product, and (despite having pretty clear docs) I almost always have to send people curl requests they can copy and run.

So I see this as similar to having a sandbox built into your docs page. Except I can customize a request and send it directly to a user. The only missing piece is the authentication part. Since I wouldn't want to embed an api key in this link.

[darubramha]

Totally with you on that—your use case is exactly what I had in mind when I built uncurl.dev.

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.