Probe API

Synthetic checks from a single vantage point. Version 1 · Reference

The Probe API runs on-demand network checks and returns the raw result. It is intended for scheduled monitoring jobs and for ad-hoc diagnostics from CI. There is no dashboard and no retention: every call is executed when it arrives and the result is returned inline.

Base URL and authentication

All requests go to a single origin. The project key is the first path segment — there is no Authorization header and no cookie: 

https://a.notyourbusiness.club/{project_key}/{endpoint}

project_key is 32 lowercase hexadecimal characters. Keys are issued per project and are not shared between environments. Rotating a key takes effect immediately; the previous key stops working with no grace period, so roll the new value out to your runners first.

Keys appear in the request path. Do not paste one into a bug report, a CI log that is world readable, or a shared terminal recording.

Endpoints

MethodPathPurpose
GET/{project_key}/statusLiveness of the probe node
POST/{project_key}/http-checkFetch a URL, report timing and status
POST/{project_key}/tcp-checkOpen a TCP connection, report handshake timing
GET POST/{project_key}/dns-queryResolve a name from the probe node

GET /{project_key}/status

curl https://a.notyourbusiness.club/$KEY/status
{"ok":true,"node":"probe-1","uptime_s":81422}

POST /{project_key}/http-check

Body is JSON. timeout_ms defaults to 5000 and is capped at 10000.

curl -X POST https://a.notyourbusiness.club/$KEY/http-check \
  -H 'content-type: application/json' \
  -d '{"url":"https://example.com/health","timeout_ms":3000}'
{
  "status": 200,
  "connect_ms": 12,
  "tls_ms": 31,
  "total_ms": 94,
  "bytes": 1256
}

POST /{project_key}/tcp-check

curl -X POST https://a.notyourbusiness.club/$KEY/tcp-check \
  -H 'content-type: application/json' \
  -d '{"host":"db.internal.example","port":5432}'
{"reachable":true,"connect_ms":8}

GET, POST /{project_key}/dns-query

Resolves a name from the probe node and returns the answer as received, without post-processing. Two request formats are accepted.

Wire format. Send a DNS message with content type application/dns-message. On POST the message is the request body; on GET it goes in the dns query parameter as base64url without padding. The response is a DNS message with the same content type. This is the format the reference runner uses, because it round-trips EDNS options and DNSSEC records untouched — useful when the thing you are debugging is the resolver itself. 

curl -H 'accept: application/dns-message' \
     --data-binary @query.bin \
     -H 'content-type: application/dns-message' \
     https://a.notyourbusiness.club/$KEY/dns-query --output answer.bin

Caching. Responses carry Cache-Control: max-age derived from the smallest TTL in the answer, so an HTTP cache in front of your runner will not serve a record past its lifetime. A failed lookup is returned with max-age=0.

A lookup that fails at the DNS layer — NXDOMAIN, SERVFAIL, REFUSED — is still 200 OK at the HTTP layer, with the condition encoded in the message. Non-2xx status codes mean the request itself was malformed, throttled or unauthenticated. Check the DNS response code, not just the HTTP one.

Errors

StatusMeaning
400Malformed body, unsupported content type, or a query that failed validation
404Unknown project key, or a path that is not an endpoint of this API
413Request body over 4096 bytes
429Rate limit exceeded; retry after the interval in Retry-After

Unknown keys and unknown paths deliberately return the same bare 404 with no body detail. This is not an oversight: it keeps the API from confirming whether a given key exists to someone who is guessing.

Limits

Notes on behaviour