Sandbox webhook subscription rejected as UNREACHABLE_URL although HTTPS endpoint is publicly reachable

Questions
,
1

Hello Square Developer Support,

We are unable to create a Sandbox webhook subscription for our Square application, although the notification URL is publicly reachable.

Application details

  • Application: HB POS
  • Application ID: `sq0idp-r2GuCM5jVxp5eNYxB4oPww`
  • Environment: Sandbox
  • Notification URL: `https://[REDACTED-DOMAIN]/pos-api/api/v1/square/webhooks`

The Developer Console returns HTTP 400:

```json
{
“errors”: [
{
“category”: “INVALID_REQUEST_ERROR”,
“code”: “UNREACHABLE_URL”,
“detail”: “URL is unreachable for `subscription.notification_url`.”,
“field”: “subscription.notification_url”
}
]
}
```

The same Square application successfully accepts this ngrok URL:

`https://[REDACTED-NGROK-DOMAIN]/api/v1/square/webhooks`

We also tested:

`https://www.[REDACTED-DOMAIN]/pos-api/api/v1/square/webhooks`

Both [REDACTED-DOMAIN] URLs were rejected with `UNREACHABLE_URL`.

Architecture clarification

`[REDACTED-DOMAIN]` is an existing, separate website hosted on the same server. Nginx serves that website on HTTPS port 443, while the `/pos-api/` path is reverse-proxied to a separate POS API service listening locally on port 5003. Port 5003 is not intended to be accessed directly from the public internet.

During the Square reachability tests, the exact webhook path was temporarily configured at the Nginx layer to return an immediate HTTP 200 response, specifically to rule out the backend application, signature validation, and response time.

Diagnostic results

  • DNS A record resolves consistently to the expected origin IP.
  • There is no AAAA record.
  • DNSPod authoritative nameservers return the same result.
  • The TLS certificate is valid and covers both `[REDACTED-DOMAIN]` and `www.[REDACTED-DOMAIN]`.
  • TLS 1.2, TLS 1.3, HTTP/1.1, HTTP/2, SNI, and ALPN work.
  • The certificate chain validates successfully and includes the intermediate certificate.
  • The exact notification URL returned HTTP 200 during the reachability test.
  • Fourteen public probes across the US, Europe, Australia, New Zealand, and Japan returned HTTP 200.
  • AWS probes in `us-east-1` and `us-west-2` also returned HTTP 200.
  • TCP port 443 is open publicly in both the cloud firewall and host firewall.
  • The published Square Sandbox webhook IP addresses are not blocked.

Most importantly, during each failed save attempt, we captured **all inbound TCP SYN packets to port 443** for approximately 25–30 seconds. No connection attempt from Square reached the server, and Nginx recorded no access-log or error-log entry.

Failure times

  • Initial failure: approximately `2026-07-13 08:40 UTC`
  • Apex-domain retry: approximately `2026-07-13 08:53 UTC`
  • www-domain retry: `2026-07-13 09:07:51 UTC`

Because no TCP connection reached the origin, this does not appear to be caused by the Nginx path routing or the API service on port 5003. The failure seems to occur before the request reaches our server, possibly in the subscription URL validator’s DNS resolution, egress routing, TLS preflight, security/SSRF/reputation policy, cache, or timeout handling.

Could a Square team member please inspect the internal webhook URL validator logs for the application and timestamps above and advise:

  1. Did the validator resolve `[REDACTED-DOMAIN]` to the expected origin IP?
  2. Did the validator attempt a TCP connection?
  3. Was the domain or IP rejected by a security, SSRF, or reputation policy?
  4. Is the domain’s TLD, Tencent Cloud IP/ASN, or DNSPod path restricted?
  5. Is there a cached unreachable result that can be cleared?
  6. Does the control-plane validator use the published Sandbox webhook IPs or different egress IPs, and what connection timeout does it enforce?

We have not included any access token, signature key, or customer code.

Thank you.

2

Hi,

Thanks for the detailed writeup!

The Sandbox/Production webhook source addresses listed in the docs (see the “Static IP address” section of the Webhooks overview) are for the event delivery system- for allowlisting incoming notifications. They’re not documented as the source of the save-time reachability check you’re hitting, so confirming they aren’t blocked doesn’t rule out the validator. That’s consistent with your SYN capture showing no connection reaching the origin.

Two things that’ll help us narrow this down- the first is quickest, so maybe start there:

  1. Save the same notification URL in a Production app and let me know if it works. That’ll tell us whether this is specific to Sandbox or something on the path/DNS side.
  2. Confirm your domain resolves to the correct IP from multiple regions, not just that HTTP works. DNS providers like DNSPod can return different IPs based on the requester’s location, which would explain a validator failing to connect at all.
3

Hi Ashley,

Thanks for the clarification. I tested the same notification URL in the Production environment at approximately 2026-07-13 21:27 UTC. The save failed there as well, and no webhook subscription was created, so this does not appear to be Sandbox-specific.

I also confirmed DNS resolution from multiple regions. The A record consistently resolves to the expected origin IP from probes in the US, Europe, Australia, New Zealand, Japan, AWS us-east-1, and AWS us-west-2. There is no AAAA record, and the DNSPod authoritative nameservers return the same A record.

Could you please check the save-time URL validator logs for this Production attempt as well?

Thank you,
Sean