Tls Authorize
GET /app-platform/tls-authorize
Caddy on-demand-TLS ask endpoint. PUBLIC, UNAUTHENTICATED, FAILS CLOSED.
Caddy issues a certificate when this returns 2xx. Answering 2xx for a host we do not own would let anyone who points DNS at our edge have a publicly trusted certificate minted by us.
2xx ONLY for a hostname that exists AND is verified. Everything else is a
bare 404 with no body: distinguishing “unknown” from “known but unverified”
would make this a free oracle for which customers are onboarding.
It IS published in the contract. include_in_schema=False was the first
instinct — it is infrastructure plumbing, not a customer API — and it broke
an invariant: the operation manifest is derived from the OpenAPI spec while
operation_tiers is derived from the route table, so hiding a route makes
the two span different universes.
test_the_manifest_covers_the_WHOLE_operation_universe exists to catch
exactly that, and it went red on qa.
Hiding it was never a security control anyway — the endpoint fails closed on its own, and its existence is inferable from any Caddy config. Consistency between the published contract and the route table is worth more than the tidiness of an unlisted endpoint.
Authorizations
Parameters
Query Parameters
Responses
200
Successful Response
422
Validation Error