POST /v2/certificates, not after: a certificate whose DNS points nowhere is accepted, queued to certmanager, and fails its ACME challenge minutes later with nothing in the UI to show for it.POST /v2/certificates enforces, surfaced before submit: the exact common name already existing, and (for a reseller) a wildcard-aware coverage conflict with a certificate it does not own.replicate=ndp only) — the host must answer /cfg/insight_healthcheck.html./checkip, whose whitelist is the SBus node list plus this box's own addresses. "In the cluster" means "resolves to an SBus node IP", and nothing more."resolves": "no" with in-cluster absent — a batch routinely carries a mix of good and bad names, and one bad alt name must not cost the caller the verdicts on the others. 4xx is reserved for the request itself being wrong: no hostname, more names than NsCertValidateMaxHostnames allows, an unknown replicate, or a scope below Reseller.in-cluster: unknown means certmanager could not be reached — a question that went unanswered, not a hostname pointing somewhere else. Do not render it as a failure the caller should fix."resolves": "not-applicable"): a wildcard certificate is proven by a DNS-01 challenge against the parent zone, so the name has no address of its own. The availability check still runs.Authorization: Bearer ********************curl --location 'https://awqacore01.crexendocloud.com/ns-api/v2/certificates/validate?hostname=portal.example.com%2Cphone.example.com&replicate=yes' \
--header 'Authorization: Bearer <token>'{
"hostname": "portal.example.com",
"available": "yes",
"resolves": "yes",
"cname": "lb1.example.com",
"ip-address": "137.131.3.250",
"ip-addresses": [
"137.131.3.250"
],
"in-cluster": "yes",
"message": "DNS validated. portal.example.com points to lb1.example.com."
}