Runpod's REST API v2 is here: One API for your entire GPU stack

APIs on Runpod have had a storied history: first there was the GraphQL API, then in early 2025 the REST API v1 arrived to give developers a more familiar HTTP interface for managing pods and endpoints. Both worked, but they grew up alongside the platform rather than being designed for it, and it showed in the seams. Some things lived in GraphQL, some in REST, and some only in the console.

The new REST API v2, now in public beta, changes that. It's a single, ground-up API surface that covers everything Runpod does all under one base URL: Pods, Serverless, storage, templates, registry credentials, hardware catalog, and billing.

https://api.runpod.io/v2

Here's what's new, and why you should build your next integration on it.

One API to rule the platform

The headline feature of v2 is completeness. Rather than a management API bolted onto the side of the platform, v2 is programmatic access to all of Runpod's compute resources:

• Pods: create and manage persistent GPU instances for development, training, and long-running jobs
• Serverless: deploy autoscaling containerized endpoints and monitor jobs
• Templates: save and reuse Pod and endpoint configurations
• Network volumes: provision persistent storage that attaches across resources
• Container registry auth: connect private Docker registries
• Catalog: query available GPU types, CPU types, and data centers
• Billing:  pull usage metrics and billing data programmatically

The catalog endpoints mean your automation can discover what hardware is available before it tries to deploy, such as scouting out which GPU types are available in which data centers. Combined with the billing endpoints, you can close the whole loop in code: query available hardware, deploy against it, monitor the workload, and reconcile the cost, without ever opening the console.

Built on an OpenAPI spec

v2 ships with a complete OpenAPI specification, retrievable directly from the API itself:

curl --request GET \
  --url https://api.runpod.io/v2/openapi.json \
  --header 'Authorization: Bearer RUNPOD_API_KEY'

This is a bigger deal than it sounds. With a machine-readable spec, you can:

• Generate typed clients in whatever language your stack uses, instead of hand-rolling HTTP calls.
• Validate requests before you send them, catching schema errors at build time rather than runtime.
• Plug the API into tooling that speaks OpenAPI natively, like gateways, testing frameworks, and internal developer portals.  
• Hand it to an AI agent. Coding agents and MCP-based tools work dramatically better against an API they can introspect. If you're using Claude Code, Cursor, or Runpod's own MCP servers to manage infrastructure, a self-describing API is the difference between an agent that guesses and an agent that knows. We’ve got a guide on that here if you’d like to read up more on it. 

That last point isn't hypothetical. Infrastructure management is increasingly agentic, and v2 was clearly built with that world in mind: predictable REST semantics, standard bearer-token auth, JSON in and out, and a spec that tools can consume directly.

Stricter, more predictable behavior

v1 inherited some looseness from its GraphQL underpinnings, like requests that probably shouldn't have succeeded sometimes did, with surprising defaults filled in. v2 tightens this up. Ambiguous requests get rejected with clear errors instead of silently doing something you didn't ask for. That's briefly annoying when you're migrating a script, and permanently valuable when you're running production automation, because "fail loudly at the call site" beats "quietly deploy the wrong thing" every time.

Getting started

Everything authenticates with the same Runpod API key you already have, passed as a bearer token:

import requests

url = "https://api.runpod.io/v2/openapi.json"
headers = {"Authorization": "Bearer RUNPOD_API_KEY"}
response = requests.get(url, headers=headers)
print(response.json())

From there, the pattern is standard REST: POST to create a Pod, GET to list your endpoints, DELETE to tear things down. If you've used any modern cloud API, you already know how this one works, which is exactly the point.

One honest caveat: v2 is in beta, which means endpoints and behavior may still change before general availability. For most automation that's an acceptable trade for building on the platform's future rather than its past, but if you're wiring it into something mission-critical, keep an eye on the release notes and pin your generated clients to a spec version.

The bottom line

REST API v1 proved that developers wanted to manage GPU infrastructure as code. API v2 is what that looks like when it's designed rather than adapted: one consistent surface for the whole platform, a self-describing spec that both humans and AI agents can build against, stricter validation that protects your production workloads, and a clear signal that this is where Runpod's API investment is going.

Check out the API v2 reference to explore the full endpoint list, or pull the OpenAPI spec and start generating clients today.

‍

‍