A CometAPI usage response can contain cumulative usage without containing a daily breakdown. Before treating a missing daily_quota field as zero daily spend, validate the CometAPI request: the documented daily breakdown requires both start_date and end_date.
The CometAPI balance and usage documentation describes those parameters as optional strings in YYYY-MM-DD format. Optional here means they are not needed for the basic query—not that either date alone is documented to produce a daily report.
Keep the reporting scopes separate
For a daily per-key report, the important distinction is between cumulative usage and the date-bounded entries:
| Data | What to do with it |
|---|---|
| Cumulative usage fields | Keep them as cumulative figures; do not relabel them as usage for a requested day. |
daily_quota[date] |
Read the array of per-key entries for that returned date. |
token_name, quota_used, request_count within an entry |
Preserve the key name, that entry’s usage, and that entry’s request count together. |
The inclusion rule is explicit in the documentation: daily_quota is returned only when both dates are set. Cumulative totals alone therefore cannot answer the same question as the daily per-key breakdown.
A reporting guardrail
My recommendation is to make the date pair a requirement in the reporting code, even though the query service marks each parameter optional:
- Before requesting a daily report, require both dates in the documented format. Do not silently fall back to a cumulative report if one is missing.
- After receiving the response, check for
daily_quotabefore building daily rows. - Iterate the returned dates and their per-key entries, carrying
token_name,quota_used, andrequest_countinto each row. - If the field is absent, mark the daily breakdown as unavailable rather than filling the report with zeroes or substituting a cumulative figure.
That final step is a reporting recommendation, not a claim about how CometAPI handles every invalid or incomplete request. It keeps “no daily breakdown available” distinct from “a returned entry reports zero usage.”
This is a reading of the documented contract, not a live endpoint test. The cited page does not establish behavior for a request with only one date, nor should its example alone be treated as a complete specification of date-boundary or missing-day behavior. Those details need confirmation before using the output for reconciliation.
For a daily cost check, the first diagnostic is consequently simple: did the request include both dates, and did the report actually consume the returned daily_quota entries?