```mdx
Quick Summary
Cloudflare's Workers script upload endpoint (PUT /accounts/{account_id}/workers/scripts/{script_name}) has received three breaking schema changes alongside a body-type generalization in the version range 904f351e29fe → 84ab13ca4e89. The top-level files and metadata request properties have been removed entirely, replaced by a new allOf subschema composition (workers_multipart-script, subschema #2). At the same time, the request body's explicit object type constraint has been relaxed to an untyped format, signaling a shift toward a more flexible multipart schema model. Teams deploying or automating Workers script uploads should audit their request payloads before this change reaches production traffic.
---
Editor's Note: We see this as more than routine housekeeping — Cloudflare is actively restructuring how Workers script uploads are modeled in their OpenAPI spec, likely to better accommodate multipart form data semantics that the previous flat-object schema couldn't cleanly express. This fits a broader pattern we've tracked of Cloudflare progressively tightening and formalizing their Workers API surface. Our practical tip: if you're using any SDK or generated client that was built against the old schema, regenerate it from the updated spec before your next deployment pipeline runs.
---
Changes by Severity
#### 🔴 Immediate Action Required
files — The files field on PUT /accounts/{account_id}/workers/scripts/{script_name} no longer exists in the schema. Any client or automation sending a top-level files key in the request body will be working against an unsupported structure.metadata — Similarly, the metadata field has been dropped from the request body definition. Bindings, compatibility dates, and other script configuration previously passed under metadata need to be re-mapped to the new schema structure.allOf subschema added: workers_multipart-script, subschema #2 — The request body now includes #/components/schemas/workers_multipart-script, subschema #2 in its allOf list. Clients must conform to this composed schema, which replaces the prior flat-property approach.#### 🟡 Plan Ahead
object/'' has been broadened to ''/'' (no explicit type). This is a behavioral shift: validators that previously relied on the object type assertion may pass or fail differently depending on their strictness settings. Review any schema validation middleware in your deployment tooling.---
Migration Playbook
1. Audit existing upload clients. Identify every integration that calls PUT /accounts/{account_id}/workers/scripts/{script_name}. Check whether the request body explicitly sets files or metadata at the top level — these are the two removed properties.
2. Pull the updated OpenAPI spec. Fetch the latest schema from the Cloudflare API schemas repository at commit 84ab13ca4e89 and regenerate any auto-generated clients or type definitions.
```bash
curl -o cloudflare-openapi.yaml \
https://raw.githubusercontent.com/cloudflare/api-schemas/84ab13ca4e897653b9c01f0628b215279cd4071b/openapi.yaml
```
3. Resolve the new allOf composition. Inspect #/components/schemas/workers_multipart-script, subschema #2 in the spec to understand which fields are now expected. Map your previous files and metadata values to the fields defined in this subschema.
```yaml
# Example: locate the subschema in the spec
components:
schemas:
workers_multipart-script:
allOf:
- $ref: '#/components/schemas/workers_multipart-script/subschema/0'
- $ref: '#/components/schemas/workers_multipart-script/subschema/1'
- $ref: '#/components/schemas/workers_multipart-script/subschema/2' # <-- new
```
4. Update your multipart form construction. If you're sending the request as multipart/form-data (which the generalized body type now more explicitly accommodates), restructure your parts to align with the new subschema rather than passing files and metadata as JSON object keys.
```js
// Before (no longer valid)
const body = {
files: [...],
metadata: { main_module: "index.js", compatibility_date: "2024-01-01" }
};
// After: construct per the new allOf subschema fields
const form = new FormData();
form.append("worker.js", scriptBlob, { contentType: "application/javascript+module" });
form.append("metadata", JSON.stringify({ main_module: "worker.js", compatibility_date: "2024-01-01" }));
```
5. Update schema validation middleware. Because the body type has been generalized from object to untyped, any strict JSON Schema validators in your CI or API gateway that check type: object on this endpoint's request body should be updated or disabled for this route to avoid false rejections.
6. Test against a non-production Worker. Before rolling out to any production script, run a full upload cycle against a staging or throwaway Worker script name to confirm the new payload structure is accepted end-to-end.
7. Update internal documentation and runbooks. Any internal guides referencing the files or metadata fields for Workers script uploads should be revised to reflect the new schema model to prevent future confusion.
---
Verification Checklist
files as a top-level request body property to the Workers script upload endpointmetadata as a top-level request body property to the Workers script upload endpoint84ab13ca4e89workers_multipart-script, subschema #2 fields are correctly populated in all upload requeststype: object on this endpoint's request bodyfiles or metadata propertiesmetadata) after migrating to the new schema---
References
```