Sume webhook_url with :8443 is rejected: HTTPS default port only

A Sume job webhook_url must be a public HTTPS URL with no explicit port, so https://hooks.example.com:8443/sume is refused with a 400 invalid_request. Put the receiver behind the default HTTPS port, or skip the webhook and poll the job.

This comes from the URL check in the Sume repo (the shared public-URL helper that the API schema and the delivery worker both call), not from a sentence in the docs. The docs say the URL must be public HTTPS; the port rule is the part that surprises people who test with a dev server on 8443 or 3443.

What the check accepts

The helper requires the https scheme, no username or password, no explicit port, and a hostname that is not private. An explicit :443 is accepted only because URL parsing drops the default port before the check sees it.

Where it runs

The check runs twice. The first run is at submit time, where the API schema limits the URL to 2048 characters and answers 400 with the message that webhook_url must be a valid public HTTPS URL. The second run is at delivery time, so a URL that was fine at submit but now resolves somewhere private is still blocked.

Because the first check is at submit, you find out before any credits are reserved for a job that could never notify you. That is the useful side of a strict rule.

What to do instead

If your receiver can only listen on a non-default port, you have three options.

• Put a reverse proxy or load balancer on 443 and forward to your port.
• Use a tunnel that exposes a public HTTPS hostname on 443 while you develop.
• Do not use a webhook: poll GET /v1/jobs/{id} until the job is terminal.

Tradeoffs

A proxy is one more thing to run and secure. Polling costs reads but needs no inbound network at all, which is why it is the better choice behind a strict firewall. Either way, the job itself is not affected by the webhook choice; it runs and bills the same.