Create a serverless endpoint
Create a Runpod Serverless endpoint with GPU or CPU compute, container or template settings, worker limits, and scaling policies.
Authorizations
Runpod API key authentication. Generate an API key in the Runpod console and send it in the Authorization header as Bearer <api_key>. Keys are scoped to the permissions granted when created; requests may return 403 when a valid key lacks access to the requested resource or action.
Body
Reusable container configuration shared across templates, pods, and serverless endpoints. Adding a field here automatically propagates to all three resources.
1"my-inference"
Autoscaling signal — a discriminated union on type: QUEUE_DELAY
(queue-based endpoints only) or REQUEST_COUNT. The scaler is chosen
independently of the endpoint's routing type and can be switched on
update.
- Option 1
- Option 2
Request-routing model. Required — it determines the valid scaler and request URLs, so it must be chosen explicitly on every create.
QUEUE, LOAD_BALANCER Arguments passed to the container entrypoint
""
Container disk in GB (ephemeral, wiped on restart)
x >= 150
Environment variables as key-value pairs
Docker image reference
"runpod/pytorch:1.0.2-cu1281-torch280-ubuntu2404"
Exposed ports, formatted as port/protocol
Container registry credential ID (for private images)
null
GPU request for an endpoint create. Carries the CUDA constraints, which live here rather than at the body's top level so they are unrepresentable on a CPU endpoint.
Eligible CPU configurations for each worker. Memory is derived from the selected flavor's catalog RAM multiplier. Exact duplicate configurations are rejected; the same flavor may be listed at different vCPU counts.
1Preferred data centers for placement. Omit or pass an empty array to let the scheduler choose.
FlashBoot cold-start acceleration mode.
OFF— disabledFLASHBOOT— enabledPRIORITY_FLASHBOOT— enabled with priority capacity
OFF, FLASHBOOT, PRIORITY_FLASHBOOT ID of a serverless template to base this endpoint on. The
template is resolved at create time into the same container
settings you could otherwise spread into this body (image,
args, disk, ports, env, registry); explicit body fields
override the template's, except env, which is merged per
key with body values winning. The template's
allowedCudaVersions seeds gpu.allowedCudaVersions when the
body omits it — but only for a GPU create, since a CPU endpoint
has no gpu block to seed into, and not when the body sets
gpu.minCudaVersion, since seeding a set beside a floor would
manufacture the mutual-exclusion 400 from a valid request. Its
pod-specific startSsh/startJupyter flags are
ignored. Later template edits do not affect the endpoint.
The template may be one of your own or a public catalog
template — see GET /v2/catalog/templates (unknown or
inaccessible ID → 404) — and must be a serverless template
(→ 422).
1"30zmvf89kd"
Response
Created
Reusable container configuration shared across templates, pods, and serverless endpoints. Adding a field here automatically propagates to all three resources.
"ep_abc123"
"my-inference"
Autoscaling signal — a discriminated union on type: QUEUE_DELAY
(queue-based endpoints only) or REQUEST_COUNT. The scaler is chosen
independently of the endpoint's routing type and can be switched on
update.
- Option 1
- Option 2
Per-request execution timeout in milliseconds
300000
FlashBoot cold-start acceleration mode.
OFF— disabledFLASHBOOT— enabledPRIORITY_FLASHBOOT— enabled with priority capacity
OFF, FLASHBOOT, PRIORITY_FLASHBOOT "2026-03-13T20:00:00Z"
Arguments passed to the container entrypoint
""
Container disk in GB (ephemeral, wiped on restart)
x >= 150
Environment variables as key-value pairs
Docker image reference
"runpod/pytorch:1.0.2-cu1281-torch280-ubuntu2404"
Exposed ports, formatted as port/protocol
Container registry credential ID (for private images)
null
Request-routing semantics for a modern serverless endpoint.
QUEUE— submit asynchronous or synchronous jobs through the managed queue.LOAD_BALANCER— send requests directly to worker-defined HTTP paths. Configure viaenv:PORT(server port, default 80),PORT_HEALTH(health-check port, default 80), andHEALTH_CHECK_PATH(path the load balancer polls for worker health, default/ping).
QUEUE, LOAD_BALANCER Request URLs appropriate to the endpoint's top-level type.
Queue-based endpoints provide job submission and management URLs;
load-balancing endpoints provide base and health because their
remaining paths are worker-defined.
Request and response bodies for the queue-based URLs are documented in the serverless operation reference. Load-balancing endpoints are documented in Load balancing endpoints.
- Option 1
- Option 2
Eligible CPU configurations for each worker, in the order they were submitted. Present for CPU endpoints and omitted for GPU endpoints. Memory is derived from the selected flavor's catalog RAM multiplier.
1