Automation platforms are good at producing an HTML artifact — a weekly summary, a rendered dashboard, a client-facing digest — and then stop at the part where a human has to open it. The workaround most communities land on is posting the output to a public gist or paste service, which turns an internal report into a public web page. There's a smaller move: post the file to miinideck from any HTTP step and get back an unguessable, no-indexed URL. Next run replaces the contents at the same address, so the link you gave someone in January is still the link in June, and it's showing this week's numbers.
Try it now
Drop a file — get a private link in seconds. No sign-up.
Drop an HTML file or ZIP bundle, or click to choose.
Single file or ZIP. Max 3 MB.
Up to 3 MB, link self-destructs after 7 days. Sign up free to keep links forever, password-protect them, and store more.
Create a personal API token in your account, and store it in your automation platform's credential store — not inline in the workflow. Any tool with a generic HTTP request step can use it: n8n, Make, Zapier, a cron job, a CI pipeline. There's no dedicated node or plugin to install; it's two HTTP calls.
At the end of the run, post the generated HTML (or a ZIP of the built folder) with the token in an Authorization header. You get back a private link. Identity comes from the token, never from anything the workflow puts in the request body, so a workflow can only ever write into the account that owns the token.
On later runs, replace the contents of the same document instead of creating a new one. The address stays put — which is the part that makes this usable for anything recurring, because the alternative is emailing a fresh URL every week and hoping people open the newest one.
It needs to go somewhere that serves files as web pages, which is why the output sitting in your workflow's memory or on a disk isn't reachable. The common community answer is to push it to a public gist and use that as the page — workable, but it makes the report public, which is rarely what you want for anything with client data in it. Posting it to a private-link host gives you the same one-step outcome with an unguessable, no-indexed address instead.
No, and it's worth being straight about that rather than implying a one-click integration. What exists is a plain HTTP API with token authentication, which every one of those platforms can call using its generic HTTP request step. You configure it once. It isn't as tidy as installing a node, and it works the same in any tool that can make a request.
Only if you create a new document each run. Replace the contents of an existing one instead and the address stays identical, which is what makes a recurring report practical — you hand out the URL once and everyone who saved it keeps seeing the current version. Creating a new link per run is also fine when each run is genuinely a separate artifact, like a per-client export.
In your automation platform's credential store, never pasted into a workflow step where it gets exported with the JSON or shared with a teammate. The token is the identity: whoever holds it can write into your account. If one leaks, revoke it and issue a new one — that's a two-minute job and much better than discovering the leak later.
Yes — both can be set at publish time in the same call, rather than being something you go back and configure in a dashboard afterwards. That matters for automation specifically, because a step that has to be finished by hand later isn't really automated.
Then this isn't the right target. What gets served here is self-contained HTML and ZIP bundles — pages that run entirely in the browser. If the output needs a backend, a database, or saved form submissions, deploy it somewhere built for that, like Vercel or Netlify, and have the workflow publish there instead.
No card to try, no sign-up to get a link. Sign up free to keep links forever, password-protect them, and store more.