Best free way to share API docs with a partner before launch

The spec is written. The integration partner starts building next week, and the API isn't public until launch. You'd like them reading real documentation, not a PDF export or a screenshot of Swagger UI. Then you open your docs platform and find that "publish" means "publish to everyone".

That's a sensible default on launch day. It's the wrong one the week before.

Will these docs be public on launch day?

If the answer is yes, most of the tooling is already built for you. It just isn't built for the weeks before launch.

Postman is clear about what its publish button does: "Publishing your documentation makes it publicly available to anyone with the link to the documentation." That's the right behaviour for public API docs, which should be found, indexed and linked to. For a pre-launch spec going to one partner under an agreement, you want the opposite: a page that opens for the people you send it to and stays out of search.

So the choice isn't really between tools. It's between two jobs: publishing documentation, and delivering it.

What are the ways to share API documentation?

Six routes come up, and each one is built for a different job:

The details that change are in this table, dated and taken only from each vendor's own pages:

Checked on each vendor's own documentation and pricing pages on 1 October 2026. Vendors change their plans without telling us, so check their site for what's current.

For how public hosting and private delivery split in general, private link vs public deploy walks the whole range, and GitHub Pages vs a private link covers the repository route in detail.

How do I turn an OpenAPI file into one page?

With one command. We ran this on 30 September 2026 against a small test spec:

npx @redocly/cli build-docs openapi.yaml -o api.html

It produced a single HTML file of about 30 KB. The file is small because it doesn't carry the renderer inside it: when the partner opens the page, their browser loads Redoc from Redocly's CDN. So the reader needs an internet connection, which they have if they're opening a link. Scalar is another renderer with a single-page setup, if you prefer its layout.

That one file is the whole deliverable. Upload it and you have a link.

Before you share it, clean the spec, not the page. A renderer shows everything in the file. Three things to check:

• Internal endpoints. If some operations are marked x-internal, a plain render may still show them. Redocly documents a remove-x-internal decorator that its bundle command applies, so bundle the spec with it first and build from the result.
• Example values. Real API keys, bearer tokens, customer names and email addresses end up in examples more often than anyone plans. Search the file for them.
• Server URLs. The servers list tells the reader where the API lives. If it points at an internal hostname, that hostname is now in a partner's hands.

Which one should I use?

The short version:

• The API is public, or goes public now. Use a docs platform (Postman, SwaggerHub, a hosted portal, or a static site). Being found is the point.
• The docs will be your developer hub for years, with guides, changelogs and many readers. A hosted docs portal is built for that.
• The partner's engineers want the spec itself to generate a client. Send the file.
• One partner, before launch, under an agreement. Render one HTML page and send it through a private link, with a password if the agreement calls for one.

These aren't either-or. Plenty of teams send the rendered page and attach the YAML in the same message.

What won't any of them fix?

A Try it console needs your API's cooperation. If the rendered docs include a console that sends real requests, those requests go from the partner's browser to your staging API. That only works if staging allows requests from the page's address (CORS) and the partner has their own credentials. A static page can't safely hold a key, because anything in the page can be read by whoever opens it. Give the partner a sandbox key of their own instead.

A link can be forwarded. An unguessable address keeps the page out of search and away from strangers. It doesn't stop the person you sent it to from forwarding it. If the agreement is strict, put a password on it and send the password separately.

Docs aren't access control for the API. Hiding an endpoint from the documentation doesn't stop anyone calling it. What protects the API is authentication on the API.

When a private link is the right shape

That's the job miinideck is built around: a finished page going to specific people, where you keep hold of the link.

You upload api.html and get a link ending in 32 random characters, with a page that tells search engines not to index it. The partner opens it in any browser. They don't need an account, a Postman workspace or a download.

After you send it, the link is still yours:

• The spec changes, the link doesn't. With an account, rebuild the page, replace the file, and the link the partner bookmarked opens the new version.
• Add a password. It's free on any account and checked before the page loads. Which free plans let you password-protect a page compares where else you can do this.
• Let it lapse after the integration. Free-account links run 7 days by default, and you can keep one on permanently. On Solo and Studio you pick an end date or leave it on.
• See whether it was opened. Every account shows how many times a link has been opened.

The limits, stated plainly: a No-account upload runs for 7 days and can't be replaced, so for partner docs you'll want a free account. The Free tier takes files up to 10 MB, far more than a rendered spec needs. It's a static page: we host the file, and nothing on our side talks to your API.

---

If you have api.html already, drop it in and get a link. There's no account needed to try it. And if you're working out where a file should live more generally, where to put a file online maps every option by what you're holding.