Workers Builds metadata response schema disagrees with live API

[nicu-chiciuc]

The OpenAPI schema for builds_BuildTriggerMetadataResponse disagrees with live responses from:

GET /accounts/{account_id}/builds/workers/{external_script_id}/builds

I verified this against current schema commit c773f5d46de208d2769eed40a465586431bad5e3.

There are two independent mismatches in builds_BuildTriggerMetadataResponse.

1. build_trigger_source

Response property path:

#/components/schemas/builds_BuildTriggerMetadataResponse/properties/build_trigger_source

Referenced component:

#/components/schemas/builds_BuildTriggerSource

The published enum is:

[
  "push",
  "pull_request",
  "manual",
  "api"
]

Live build-list responses return "push_event" for builds triggered by a Git push. "push_event" is not accepted by the published enum.

2. environment_variables

Schema path:

#/components/schemas/builds_BuildTriggerMetadataResponse/properties/environment_variables

The published schema declares a string map:

{
  "type": "object",
  "additionalProperties": {
    "type": "string"
  }
}

Live build-list responses instead return an object per environment variable with these fields:

{
  "created_on": "...",
  "is_secret": true,
  "value": null
}

That live shape already has a matching component in the published schema:

#/components/schemas/builds_EnvironmentVariablesResponse

Reproduction

Inspect the exact published definitions:

SCHEMA_COMMIT=c773f5d46de208d2769eed40a465586431bad5e3

curl -fsSL \
  "https://raw.githubusercontent.com/cloudflare/api-schemas/$SCHEMA_COMMIT/openapi.json" \
  | jq '{
      build_trigger_source: .components.schemas.builds_BuildTriggerSource,
      environment_variables: .components.schemas.builds_BuildTriggerMetadataResponse.properties.environment_variables,
      existing_response_shape: .components.schemas.builds_EnvironmentVariablesResponse
    }'

Then inspect only the relevant, non-secret shapes from a live build-list response:

curl -fsS \
  "https://api.cloudflare.com/client/v4/accounts/$CLOUDFLARE_ACCOUNT_ID/builds/workers/$CLOUDFLARE_WORKER_TAG/builds?page=1&per_page=100" \
  -H "Authorization: Bearer $CLOUDFLARE_API_TOKEN" \
  | jq '{
      build_trigger_sources: (
        [.result[] | .build_trigger_metadata.build_trigger_source] | unique
      ),
      environment_variable_value_types: (
        [
          .result[]
          | (.build_trigger_metadata.environment_variables // {})
          | to_entries[]
          | .value
          | type
        ]
        | unique
      )
    }'

Observed output across live Workers:

{
  "build_trigger_sources": [
    "manual",
    "push_event"
  ],
  "environment_variable_value_types": [
    "object"
  ]
}

Independent validation

I validated 600 live builds_BuildResponse objects from three Workers directly with Ajv against the exact component at schema commit c773f5d:

• 599 of 600 objects were rejected.
• 588 errors were the build_trigger_source enum rejecting push_event.
• 679 errors were environment_variables values not being strings.
• There were no other validation errors.

I then changed only these two definitions in memory:

1. Allowed push_event in builds_BuildTriggerSource.
2. Pointed builds_BuildTriggerMetadataResponse.environment_variables to builds_EnvironmentVariablesResponse.

All 600 of 600 live build objects then validated successfully.

This validation targets individual builds_BuildResponse objects, so it is independent of the separate response-envelope contradiction reported in #44.

Expected

• builds_BuildTriggerSource accepts the value emitted by the API for Git push events (push_event), or the API emits the documented push value.
• builds_BuildTriggerMetadataResponse.environment_variables uses the existing builds_EnvironmentVariablesResponse shape.

Impact

Strict clients and runtime validators generated from cloudflare/api-schemas reject otherwise successful Workers Builds history responses. Because the endpoint returns an array, one incompatible build object causes the entire response page to be rejected.

[nicu-chiciuc]

@rotem-cloud I'm not sure if you're on the team working on this, but this should be an easily caught mechanical issue using some validator. Because I'm using a small subset of the api, but already caught 3 issues. I'm using some custom AJV to create validators based on the cf openapi.

[jessicayingg]

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]

Additional live evidence from 2026-08-13: after I retried a Worker build from the Cloudflare dashboard, GET /accounts/{account_id}/builds/workers/{external_script_id}/builds returned build_trigger_metadata.build_trigger_source as "retry". The current published schema still allows only push, pull_request, manual, and api. Thus retry is another observed value missing from builds_BuildTriggerSource, in addition to push_event.