Availability and connectivity
Verify an approved integration and recover safely from temporary service or dependency unavailability.
Verify an approved integration
After HPH supplies your Customer Testing API origin and authentication setup, use GET /v1/capabilities as the connectivity check. It exercises the authenticated caller boundary and lists the operation codes the deployment serves; GET /v1/company/capabilities returns what your represented Company may use.
- A successful response confirms only that this request reached the API and its current authority was evaluated.
- A capability snapshot does not grant authority or guarantee that a later business operation will be available.
- Use the check during startup, configuration validation, or troubleshooting rather than as high-frequency polling.
Keep deployment probes separate
HPH operations may use coarse liveness and readiness probes to manage deployed services. Those probes are deliberately omitted from the public OpenAPI contract and operation reference. Consumers must not call them, depend on their paths or response shapes, or treat them as evidence that a particular company, permission, or operation is available.
Recover from temporary unavailability
A timeout or 503 response can represent a temporary service or dependency failure. Use bounded exponential backoff with jitter and stop after the retry budget approved for the operation. Branch on the documented status, stable problem code, and retryable value rather than title text.
- Retry only when the problem response reports retryable as true.
- A read-only request may be retried within its documented retry budget.
- After an ambiguous state-changing outcome, replay the same idempotency key and identical business content; do not create a new operation identity.
- Retain the problem correlation_id and UTC timestamp for support without retaining credentials, item bodies, candidate tokens, or complete responses.
- Repeated failure should open the approved support path instead of continuing unbounded polling.
Service-status communication
A future published version may link to a customer-facing service-status channel after ownership, support, incident communication, and availability commitments are approved. Until then, this documentation makes no uptime or environment-availability claim.