SpocketDOCS
MCPPanelDeploy now→
RUNNING APPS

Inbound HTTP

Webhook URLs, and pointing your own domain at an app.

Listening for requests

Most apps never need this. A Discord gateway connection, Slack Socket Mode and Telegram long-polling all reach out from your container — nothing has to reach in.

If your app does need to receive requests, bind the port we give you. There is nothing Spocket-specific about it: PORT is what Express, Fastify, FastAPI and Flask already read by default.

BIND THE PORT AND YOU HAVE A PUBLIC URL.
// Node
app.listen(process.env.PORT);
THE SAME IN PYTHON.
import os
uvicorn.run(app, host="0.0.0.0", port=int(os.environ["PORT"]))
Bind 0.0.0.0, not localhost. A server bound to localhost inside a container is unreachable from outside it, and this is the single most common reason a webhook URL returns nothing.

Your free URL

Every app gets https://<name>.spocket.dev the moment it deploys, with HTTPS already set up. Nothing to configure — if your app listens on its port, that address serves it.

It is a real URL you can give someone. Point your own domain at the same app whenever you want; the free one keeps working either way.

The name comes from your app name, so "invoice-api" becomes invoice-api.spocket.dev. Some names are reserved — www, api, docs and similar belong to us.

The webhook URL

Every app also has a path-based URL, which is the better one to paste into Stripe or GitHub. Ask your agent for it with spocket_urls, or find it under Networking on the bot page.

  • Paths pass straight through: /hooks/<slug>/webhook reaches /webhook on your bot.
  • Every method works — GET, POST, PUT, PATCH, DELETE.
  • The URL survives restarts, redeploys and moves between machines, so it is safe to paste into Stripe or GitHub.
  • A request waits up to 25 seconds. Anything slower should return immediately and do the work in the background.

Custom domains

An app that serves HTTP can answer on your own domain instead. The flow is the one you already know from Netlify or Vercel: add the domain, create two DNS records, verify.

  1. 01
    Add the domainFrom the Networking tab, or ask your agent to add it. You get back the exact records to create.
  2. 02
    Create the DNS recordsAt whoever hosts your DNS — your registrar, Cloudflare, wherever the domain currently points. One record routes traffic, the other proves you own the domain.
  3. 03
    VerifyPress Verify, or ask your agent. If it fails immediately that is usually propagation rather than a mistake; wait a few minutes and try again.
Nothing is served on your domain until it verifies. That is deliberate: pointing a CNAME at us is not proof you own a domain, so we ask for a TXT record only someone with access to the zone can create.

Once verified, your paths reach your app unchanged and visitors only ever see your own domain.

When a domain will not verify

WHAT YOU SEEWHAT IT USUALLY MEANS
No TXT record foundThe record has not propagated yet, or it was created under the wrong name. It belongs at _spocket, not at the root.
Found a TXT record, wrong valueTwo records exist, or the old one was edited rather than replaced. Delete any stale _spocket record.
Verified, but the site does not loadThe routing record is missing or still points somewhere else. Verification and routing are separate records; both have to be right.
This domain is not connectedThe domain resolves to us but is not verified, or it was removed. Re-add it and verify.
DNS changes are usually live within a few minutes, but a provider can cache an old answer for as long as its TTL. If a record is definitely correct and still failing, the wait is on their side.
PREVIOUSRuntimes and limitsNEXTBilling