Quickstart

The published schema is deliberately small: two read-only service-health operations with no order, shipment, rate, carrier, label, or customer data.

No public API host is advertised. The application and API hosts remain authenticated surfaces. The request shapes below explain semantics; they are not instructions to bypass access controls.

1. Check process liveness

GET /healthz answers one question: is the API process alive? A successful response does not prove that dependencies are ready or that an operational workflow is available.

GET /healthz

{"status":"ok"}

2. Check dependency readiness

GET /readyz reports whether the service considers itself ready to receive operational traffic. Consumers should remove a non-ready instance from rotation rather than treating it as healthy.

GET /readyz

{"status":"ready"}

or

{"status":"not_ready"}

3. Handle every documented response

Status	Meaning	Consumer action
`200`	The requested health condition is satisfied.	Use only for the specific liveness or readiness decision requested.
`429`	An ingress control rate-limited the request.	Respect `Retry-After` when present and apply bounded backoff.
`503`	The readiness check is reachable but not ready.	Stop sending new operational traffic and continue bounded health polling.

4. Choose the next document

Read the generated API reference for the exact response fields.
Read authentication and scope before designing a private integration.
Read reliability before designing any future mutation or provider call.

Operational boundary. Authenticated held-order flows exist only as a private synthetic preview. Public access, production data, live provider execution, and writeback require separate contracts and acceptance evidence.