REST API /v1/endpoints ignores computeType=CPU / cpuFlavorIds / vcpuCount - always creates a GPU endpoint

[gregmillard00]

Summary

Creating a Serverless endpoint via the REST API (POST https://rest.runpod.io/v1/endpoints) with an explicit CPU configuration does not actually create a CPU endpoint - the resulting endpoint always comes back (and behaves, per the console UI) as a GPU endpoint with the default GPU type list, even though the request included the documented CPU fields.

Steps to reproduce

1. Create a template with "category": "CPU" (this part works fine and is reflected correctly on the template).
2. Create an endpoint via POST /v1/endpoints with a body like:

{
  "name": "my-cpu-endpoint",
  "templateId": "<template id from step 1>",
  "computeType": "CPU",
  "cpuFlavorIds": ["cpu3c", "cpu5c"],
  "vcpuCount": 2,
  "workersMin": 0,
  "workersMax": 2,
  "idleTimeout": 5,
  "executionTimeoutMs": 900000,
  "scalerType": "QUEUE_DELAY",
  "scalerValue": 4
}

3. Inspect the response (or GET /v1/endpoints/{id} afterward).

Expected

The response/endpoint should reflect computeType: "CPU" and the requested cpuFlavorIds/vcpuCount, and workers should actually be provisioned as CPU workers (confirmed via the console's Serverless tab).

Actual

• The response never includes computeType or cpuFlavorIds at all (both are documented fields in the OpenAPI schema at https://rest.runpod.io/v1/openapi.json, under EndpointCreateInput/Endpoint).
• It instead always includes the default GPU fields (gpuCount: 1, gpuTypeIds: [...default list of ~7 GPU models...]).
• Confirmed via the RunPod console (Serverless tab) that the resulting endpoint is genuinely running GPU workers, not CPU - this isn't just a cosmetic response-serialization quirk.

Tried this 3 times (fresh template + endpoint each time, varying the field set slightly, e.g. with/without vcpuCount), same result every time.

Other observations

• PATCH /v1/endpoints/{id} doesn't accept computeType at all ("key provided in request body which is not in input schema: 'computeType'" isn't literally the error I saw for that field, but it's absent from EndpointUpdateInput in the OpenAPI spec) - so there's no way to fix an existing endpoint's compute type via API either; it seems compute type can only be intended to be set at creation time, and creation isn't honoring it.
• The only place I could find CPU endpoint creation actually documented as working is the console UI ("Create a New Endpoint" > "Select the CPU option") - the announcement blog post for the Serverless CPU feature doesn't mention API usage at all.
• workersMax on PATCH does work correctly, for what it's worth - just the compute-type-related fields are the issue.

Ask

Either fix the REST API to actually honor computeType/cpuFlavorIds/vcpuCount on endpoint creation, or (if this is intentionally console-only for now) document that clearly so people don't spend time on it assuming it's an API oversight rather than a known limitation.

Environment

• Using requests directly against https://rest.runpod.io/v1/... (not the runpod Python SDK's own endpoint-management helpers, though I'd guess those hit the same backend).
• Observed 2026-07-18.