A demo should have hard edges.

Visitors should know where a request goes, what it sends, and whether the response is real or simulated. These are the rules for the first release.

Current version

15 July 2026

Built-in demos stay on DemoAPI.org

The three launch examples use first-party route handlers and labeled sample data. They do not fetch a URL from the request, scan a network, call a model, or control hardware. The destination is fixed in the site code.

The request console is not an open proxy. Editing a browser request cannot change its destination.

A project listing starts narrow

A publisher must control the public HTTPS endpoint or have permission to share it. We review listings before publication. A public demo would expose only the agreed route, method, fields, and example values, with request and payload caps.

The current form records a URL for review. It does not call that URL and it does not publish a page automatically. See the listing terms.

Can I connect a PC or local server?

Not in this release. A future outbound connector could expose approved HTTP routes, but it would need a separate threat model, explicit device authorization, and strong network isolation. It would never provide a shell or general private-network access.

Keep secrets out of public demos

Do not paste API keys, bearer tokens, cookies, customer data, private URLs, or production credentials into a console or submission. The first release does not store publisher API keys. Build a public demo route that works without a production secret, or use a labeled sample response.