workers_Worker.references.domains[].certificate_id is required in OpenAPI but omitted by API responses

[nicu-chiciuc]

The OpenAPI schema for workers_Worker.references.domains[] marks certificate_id as required, but live Cloudflare API responses can omit it.

Schema path:

#/components/schemas/workers_Worker/properties/references/properties/domains/items/required

Endpoint confirmed:

GET /accounts/{account_id}/workers/workers/{worker_id}

Repro:

curl -fsSL https://raw.githubusercontent.com/cloudflare/api-schemas/main/openapi.json \
  | jq '.components.schemas.workers_Worker.properties.references.properties.domains.items.required'

Actual schema output:

[
  "id",
  "hostname",
  "zone_id",
  "zone_name",
  "certificate_id"
]

Then call Worker detail for a Worker that has a custom domain attached:

curl -fsS \
  "https://api.cloudflare.com/client/v4/accounts/$CLOUDFLARE_ACCOUNT_ID/workers/workers/$CLOUDFLARE_WORKER_ID" \
  -H "Authorization: Bearer $CLOUDFLARE_API_TOKEN" \
  | jq '.result.references.domains[] | {hostname, keys: (keys | sort), has_certificate_id: has("certificate_id")}'

Observed live response shape:

{
  "hostname": "samebase.com",
  "keys": [
    "hostname",
    "id",
    "zone_id",
    "zone_name"
  ],
  "has_certificate_id": false
}

Expected one of:

• API responses always include certificate_id for every domain reference, or
• certificate_id is removed from the required list in the OpenAPI schema.

Impact:

Strict clients generated from cloudflare/api-schemas reject otherwise successful Worker responses. In our case, an Ajv validator generated from the schema rejected the response with:

/result/references/domains/0 must have required property 'certificate_id'

[rotem-cloud]

Thank you for submitting an issue! This issue has been flagged for an internal Cloudflare team to take a look. If this is urgently blocking your development or deployment, please open a support case so we can serve you faster.

[nicu-chiciuc]

It's not blocking because I have patches so I can easily handle this. I'm mostly concerned about these slight inconsistencies (#44) since they might signal issues in the tools that generate them.