Check CometAPI Endpoint Health Before Fallback Routing

Last reviewed: 2026-07-16.

Direct answer

Run CometAPI endpoint health checks before fallback routing by testing the exact API family your fallback path will use, recording a minimal request and response contract, and refusing to promote traffic when the smoke test cannot prove the route is reachable and shaped as expected.

For a chat-completions fallback, verify the Chat Completions contract. For a Responses-based fallback, verify the Responses contract separately. Do not treat one successful endpoint family as proof that the other endpoint family is ready. The CometAPI documentation presents Chat Completions and Responses as separate text API references, and the routing decision should respect that separation.

A practical workflow:

1. Setup assumptions: use a non-production test credential represented as <API_KEY_PLACEHOLDER>, a low-risk test input, and the same base URL and endpoint family named in the current CometAPI documentation.
2. Happy-path request plan: send one minimal request to the chosen endpoint family, with the required credential header and required body fields shown in the linked reference.
3. Error-path check: repeat the request with a deliberately invalid placeholder credential in an isolated test environment and confirm the route returns an authentication failure instead of a successful response.
4. Minimum assertions: record endpoint family, HTTP status class, response object family, presence of expected top-level fields, request id when provided, and whether the response can be parsed by the fallback adapter.
5. Pass/fail logging fields: check_id, endpoint_family, credential_scope, request_shape_version, http_status_class, response_parse_result, fallback_adapter_result, checked_at, and operator_decision.
6. What not to assert: do not infer uptime, latency guarantees, rate limits, model availability, pricing, billing behavior, or provider-wide health from a smoke test.

For adjacent runbook context, see Check CometAPI Authorization Before Fallback Routing and Check CometAPI Response Shape Before Promoting Fallback Traffic . If you are evaluating CometAPI as the upstream route, use Start with CometAPI after you have a health-check plan and know which endpoint family your route will exercise.

Sanitized log-record template:

check_id: "cometapi-endpoint-health-<date>-<sequence>"
endpoint_family: "chat_completions_or_responses"
credential_scope: "test_key_placeholder"
request_shape_version: "docs_checked_2026-07-16"
http_status_class: "2xx_or_4xx_or_5xx"
response_parse_result: "pass_or_fail"
fallback_adapter_result: "pass_or_fail"
checked_at: "2026-07-16T00:00:00Z"
operator_decision: "hold_or_continue"

The operator decision should be boring and narrow. A pass means the selected route can continue to the next readiness check. A fail means the route stays out of fallback traffic until the team can explain the mismatch. It does not mean the provider is down, the account is misconfigured, or the model is unavailable unless separate evidence proves that narrower conclusion.

Who this is for

This guide is for engineers who own LLM fallback routing and need a small preflight check before moving traffic to a CometAPI-backed route. It is especially useful when chat-style requests and Responses-style requests share gateway code but use different endpoint contracts.

It also helps on-call engineers who need to decide whether a failing fallback path is a routing problem, a credential problem, a request-shape problem, or an adapter problem. The check is intentionally smaller than a full production readiness review. It gives the team a repeatable way to say, “this endpoint family was reachable and parseable under this exact request shape,” without turning one smoke test into a claim about global service health.

Use it before enabling a new fallback route, after changing the client base URL or credential wiring, after switching between Chat Completions and Responses, and before interpreting fallback errors as provider incidents. For broader routing controls, pair this check with CometAPI Failover Rollforward Checks for Safer Routing .

Key takeaways

• Check Chat Completions and Responses separately because the documented endpoint paths and response objects are different.
• Keep the smoke test narrow: reachability, authentication behavior, parseability, and adapter compatibility.
• Use placeholders for credentials and test inputs; do not log prompts, full responses, or secrets.
• Treat a passing check as route evidence, not as proof of uptime, cost, rate limit, billing, or account entitlement behavior.
• Record what was checked, which endpoint family was used, which request shape was sent, and which adapter accepted or rejected the response.
• Escalate commercial, account, concurrency, and maintenance questions to the relevant CometAPI support or account evidence instead of inferring them from a single request.

Sources checked

• CometAPI documentation - accessed 2026-07-16; purpose: verify current CometAPI documentation navigation.
• CometAPI chat completions reference - accessed 2026-07-16; purpose: verify chat completion contract areas.
• CometAPI responses reference - accessed 2026-07-16; purpose: verify responses endpoint contract areas.
• CometAPI help center - accessed 2026-07-16; purpose: verify support and escalation documentation areas.

Contract details to verify

Failure modes

• Endpoint-family confusion: a chat-completions request succeeds, then the team promotes a Responses route without checking the Responses contract. Keep the check bound to one endpoint family and one adapter path.
• Credential ambiguity: a failed request is treated as provider health evidence even though the credential scope, environment, or header placement was not verified. Confirm the credential path with a placeholder credential in a controlled environment before interpreting the result.
• Request-shape drift: the application gateway sends fields that differ from the documented example or from the adapter’s expected payload. Record a request-shape version and compare only sanitized structural fields.
• Response parsing gap: the endpoint returns a response, but the fallback adapter cannot parse the object family. A route is not ready until the adapter accepts the response shape it will see in production.
• Overbroad success claim: a single smoke test is used to claim model availability, latency, cost, billing behavior, or uptime. Keep those claims out of the endpoint-health record unless separate current evidence supports them.
• Weak handoff: the final note says the route is healthy but omits the source URLs, endpoint family, status class, parse result, adapter result, and remaining uncertainty. That makes the next operator repeat the investigation.
• Unsafe logging: prompts, full model outputs, real credentials, or account-specific data are copied into the health-check record. Store only sanitized structural fields and use <API_KEY_PLACEHOLDER> for credential examples.

Reader next step

Before enabling fallback traffic, create a one-page endpoint-health record for the route you are about to promote. Start with the endpoint family, the current source URLs, the sanitized request-shape version, and the expected parser behavior. Then run one happy-path check and one authentication-failure check in an isolated environment. If both checks produce the expected status class and the fallback adapter can parse the happy-path response, mark the route ready for the next readiness review. If either check fails, hold the route and write down the exact mismatch: source contract mismatch, credential behavior mismatch, response-shape mismatch, or adapter mismatch.

Keep that record next to the fallback route configuration so future operators can see why the route was allowed to receive traffic. If the route later changes from Chat Completions to Responses, repeat the check instead of editing the old record. Endpoint-health evidence expires when the endpoint family, client base configuration, credential scope, request body, adapter parser, or fallback route changes.

FAQ

Can one health check cover both Chat Completions and Responses?

No. Use one check per endpoint family. The linked references describe different request and response contracts, so fallback routing should not promote both paths from one passing request.

Should the health check use a production prompt?

No. Use a sanitized, low-risk test input and avoid logging full prompts or full responses. The goal is to prove contract compatibility, not output quality.

What should block fallback promotion?

Block promotion when authentication behavior is unexpected, the response cannot be parsed, the fallback adapter rejects the response shape, or the source documentation cannot be verified.

Does a passing smoke test prove CometAPI availability or pricing?

No. A smoke test only supports the narrow route decision it checks. Availability, pricing, concurrency, and billing details need separate current evidence from the linked documentation, dashboard, support records, or account-specific sources.

When should the endpoint-health record be refreshed?

Refresh it when the route switches endpoint family, the client base configuration changes, the credential scope changes, the adapter parser changes, or the documented source contract changes. A stale health record is still useful history, but it should not be used as approval for a new route shape.