Service health checks
Use liveness and readiness for different operational questions.
No current prepared translation is available. The English source is shown without machine translation.
Health probes require no API key and must not be used to infer model-specific capacity or account eligibility. A healthy gateway may still reject a particular credential, project budget or unsupported model request.
Request
curl --fail https://api.b2b-llm.com/health/live
curl --fail https://api.b2b-llm.com/health/ready
curl --fail https://api.b2b-llm.com/healthResponse interpretation
Read the HTTP status and returned JSON. Liveness answers whether the process is responsive. Readiness checks whether the service can accept work with its required dependencies. The legacy /health path remains available; use the explicit probes in new monitoring configurations.
Do not attach bearer headers to unauthenticated probes. Keep polling moderate and alert on a sustained failure rather than a single transient network error. Share the time, API host and status with Support, not company credentials.
For a model-specific acceptance test, issue a deliberately small authenticated inference call and inspect its result separately. Such a call is not a free health probe and may be billable.
Readiness boundary
GET and HEAD are supported for these health paths. HTTP 503 means the service is not ready to accept work. Check again later and report sustained failures to Support. A ready response is neither permission to execute with a project key nor confirmation that an image operation has completed.