Source pack

Last reviewed: 2026-07-02

Primary evidence checked for this refresh:

Intent brief

Who this is for: operators and integration engineers who need to keep CometAPI model identifiers, chat request configuration, and runtime validation aligned with the current documentation before production use.

The goal is not to memorize model IDs from a copied list. The safer operating pattern is to treat the model catalog and chat API documentation as the source of truth, validate every configured identifier against those sources, and keep a small runbook for what happens when a configured model stops working.

Related internal reading: browse the latest CometAPI integration notes in the CometAPI tutorials archive and use the CometAPI implementation index when comparing this runbook with other operational checks.

Key takeaways

  • Model identifiers should be copied from the current model documentation, not inferred from provider naming conventions.
  • Chat request fields should be validated against the CometAPI text chat documentation before being promoted to production.
  • Store model IDs as configuration, not as scattered literals in application code.
  • Add a startup or deployment check that verifies each configured model still appears in the approved source.
  • Treat pricing, availability, rate limits, and billing behavior as contract details to verify from CometAPI documentation before relying on them operationally.

What a CometAPI model ID is

A CometAPI model ID is the string your application sends in a chat request to select the model that should handle the workload. For operators, the important point is that the identifier is part of the API contract: if it is mistyped, stale, unavailable for the account, or paired with unsupported request fields, the application can fail at runtime.

Use the CometAPI models overview documentation as the source to verify available identifiers, and use the CometAPI text chat API documentation to verify how the chosen identifier is passed in a chat request.

Operator runbook for model identifiers

1. Build a controlled model registry

Keep one internal registry for CometAPI model IDs. That registry can be a config file, secrets-backed environment configuration, or deployment variable set, but it should have clear ownership.

Recommended fields:

  • logical_name: the internal name your service uses, such as support_chat_primary.
  • model_id: the CometAPI model identifier verified from the current docs.
  • source_url: the documentation URL used to validate the identifier.
  • last_verified: the date your team checked the value.
  • owner: the team or service responsible for updating it.
  • fallback_logical_name: the configured backup path, if your service supports fallback.

Avoid placing model IDs directly in prompt templates, queue workers, notebooks, and one-off scripts. If model selection is decentralized, stale identifiers become difficult to find during an incident.

2. Verify identifiers before deployment

A deployment check should confirm that every configured model ID is still valid according to the current CometAPI documentation. The exact verification method depends on what your system can safely automate. At minimum, reviewers should compare configured values against the CometAPI models overview documentation . For production automation, validate against the supported API or documentation mechanism your team has approved.

The check should fail closed for production changes when:

  • a configured model ID is blank;
  • a model ID exists in code but not in the approved registry;
  • a registry entry lacks a source URL or verification date;
  • the chat request uses fields not verified against the current text chat documentation;
  • an application deploy changes model routing without updating the registry.

3. Validate chat request shape separately

Model ID validation is not enough. Operators should also verify that the request shape sent to CometAPI matches the documented chat contract. The CometAPI text chat API documentation is the source to check for the endpoint path, authentication header, request body fields, response body fields, and error behavior.

Use placeholders until your reviewer confirms exact contract values from the documentation:

curl -sS "<COMETAPI_BASE_URL_FROM_DOCS><COMETAPI_CHAT_PATH_FROM_DOCS>" \
  -H "<AUTH_HEADER_FROM_DOCS>: <REDACTED_API_KEY>" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "<VALIDATED_MODEL_ID>",
    "messages": [
      {
        "role": "user",
        "content": "Return a one-sentence health-check response."
      }
    ]
  }'

This example is intentionally sanitized. Replace <COMETAPI_BASE_URL_FROM_DOCS>, <COMETAPI_CHAT_PATH_FROM_DOCS>, <AUTH_HEADER_FROM_DOCS>, and <VALIDATED_MODEL_ID> only after checking the current CometAPI documentation.

4. Separate fallback from model discovery

Fallback logic should not guess model names. If the primary model fails, the fallback should route to another pre-approved registry entry. That backup entry should have the same level of documentation evidence as the primary entry.

A practical fallback policy includes:

  • which errors are retryable;
  • which errors should trigger fallback;
  • how many attempts are allowed before returning a controlled failure;
  • whether fallback is allowed for regulated or high-risk workflows;
  • how the incident is logged for later review.

Treat numerical thresholds, such as retry counts or timeout values, as examples to tune for your service. Do not assume a universal threshold unless it is supported by the current CometAPI documentation or your own production SLOs.

Contract details to verify

Contract areaValue to verify before productionPrimary source
Endpoint pathsVerify the base URL and chat endpoint path from the official documentation; do not hard-code a path from memory.CometAPI text chat API documentation
Auth headersVerify the required authentication header name, token format, and any required companion headers from the current docs.CometAPI text chat API documentation
Request fieldsVerify the required and optional chat request fields, including where the validated model identifier belongs.CometAPI text chat API documentation
Response fieldsVerify the response object shape your parser depends on before mapping fields into application logic.CometAPI text chat API documentation
Error behaviorVerify documented error status codes, error body shape, and retry guidance before writing fallback rules.CometAPI text chat API documentation
Rate-limit or billing assumptionsVerify current rate-limit, quota, metering, and billing behavior from official CometAPI sources before setting alerts or cost controls.CometAPI API documentation home
Model identifiersVerify every configured model ID against the current model overview before release.CometAPI models overview documentation

Practical validation checklist

Use this checklist during release review:

  1. Confirm every configured CometAPI model ID appears in the internal registry.
  2. Confirm every registry entry has a documentation source and last_verified date.
  3. Compare production model IDs with the CometAPI models overview documentation .
  4. Compare the deployed chat request body with the CometAPI text chat API documentation .
  5. Run a sanitized health-check request in a non-production environment.
  6. Confirm logs capture the selected logical model name, not secrets or raw authorization headers.
  7. Confirm fallback behavior uses approved registry entries rather than guessed model names.
  8. Record any unresolved contract assumptions before approving production release.

Common operator mistakes

The most common mistake is copying a model name from a provider announcement, third-party article, or old internal ticket and assuming it is valid for CometAPI. Use CometAPI’s own documentation as the approval source.

Another common mistake is validating only the happy-path response. Operators should also confirm how the integration behaves when the model ID is missing, invalid, unavailable, or not authorized for the account. The exact error behavior must be verified from the current CometAPI documentation rather than invented in the runbook.

FAQ

Should model IDs be hard-coded in application code?

No. Keep model IDs in controlled configuration so operators can review, rotate, and roll back model routing without searching through application code.

Can we use provider model names directly?

Only use a model identifier after verifying it against CometAPI’s current model documentation. Similar-looking provider names may not be the correct CometAPI identifier.

Should fallback pick the newest available model automatically?

No. Automatic discovery can route sensitive workloads to an unreviewed model. Use a pre-approved fallback entry from your registry.

How often should model IDs be reviewed?

Review them during every release that changes model routing, after relevant documentation changes, and during scheduled operational audits. The exact cadence should match your team’s risk level and deployment frequency.

Where should pricing or billing assumptions live?

Keep pricing, metering, and billing assumptions in a separate reviewed contract note linked to official CometAPI sources. Do not derive cost controls from undocumented assumptions.

Sources checked