Share a local HTTP API with curl, Postman and webhooks

MyShare gives a local or LAN HTTP/HTTPS API a temporary public endpoint for colleagues using curl, Postman or webhooks. Your backend needs no HTML homepage or separate frontend. The share passcode and your API’s own authentication both apply.

Share the API’s service address first

  1. Start the API and check that your sharing computer can reach it, for example at http://localhost:8080 or http://192.168.1.20:8080.
  2. On the homepage, select Website or API and enter the service’s root URL. A readable 401, 403, 404 or 405 at the root is acceptable; connectivity, browser permissions and CORS requirements still apply.
  3. Complete the security check and first-use sharing agreement, then choose Create share link. Replace the link’s path with your actual API endpoint and keep the share passcode.

Supported targets are localhost, 127.0.0.1, [::1] and RFC1918 private IPv4 addresses. Internal hostnames and public targets are not supported. One main service can have up to two explicitly approved additional origins; the list is fixed after creation. If your frontend already proxies /api, share the frontend address. See the local website and LAN guide for address and permission details.

Call the endpoint with curl or Postman

The hostname, passcode and API token below are placeholders. Replace them with your share address, its six-character temporary passcode and the visitor’s API credentials. The __myshare_password URL parameter unlocks access directly, without a browser visit or MyShare access-cookie exchange.

curl 'https://YOUR-SHARE.example.invalid/api/echo?__myshare_password=YOUR_SHARE_PASSWORD' \
  -H 'Authorization: Bearer YOUR_API_TOKEN' \
  -H 'Content-Type: application/json' \
  -d '{"message":"hello"}'

Alternatively, remove the passcode from the URL and send the X-MyShare-Password: YOUR_SHARE_PASSWORD header. Both methods grant the same access. Conflicting values are rejected if you send both. The gateway removes its passcode parameter and header before forwarding to the local service.

In Postman, enter the same complete endpoint URL and configure your API’s method, authentication and body as usual. Webhook senders that preserve URL query parameters can POST directly to the passcode-bearing endpoint. Your sharing computer, browser and API must all be online when the callback arrives.

Keep API sign-in separate from the share passcode

The passcode grants access to this preview. Your API can still require the visitor’s own valid Authorization: Bearer … or Authorization: Basic …. Methods, paths and bodies are forwarded. Keep the share passcode out of the business Authorization header. Malformed values and other Authorization schemes are not supported.

For business Cookie/HttpOnly sign-in, use the extension or add the project adapter to an existing Node development server. You can then send the visitor’s own Cookie: session=YOUR_SESSION. Ordinary browser sharing filters Cookie/Set-Cookie. The adapter supports loopback addresses only; use the extension for LAN cookie sign-in. Visitors do not inherit the owner’s existing browser login.

CORS and additional origins

Browser sharing reads the local service through the owner’s browser. Local CORS must allow the exact MyShare Origin, handle OPTIONS and explicitly allow Authorization, Content-Type and other required request headers. Under More options → Backend & sign-in, copy the AI setup instructions for your project assistant. Extension sharing requires approval for each selected address.

Calling the public API from another webpage’s JavaScript involves a separate origin check. Mapped preview origins within the same share can call one another; arbitrary third-party websites do not gain cross-origin access merely by knowing the passcode. curl, Postman and server webhooks do not depend on browser CORS. A successful call from them does not establish that a third-party webpage can make the same cross-origin request.

Limits and troubleshooting

Share an HTTP API ↗