Skip to main content
The GPU Outlet API lets a program do what the dashboard does: find GPU capacity, price it, rent it, watch it come up, and stop it — and, on Radar, browse whole physical nodes and put your own up for sale.
Every endpoint takes and returns JSON, authenticates with a bearer token, and speaks HTTP status codes with a consistent error envelope.

Get a key and make your first call

Five minutes from nothing to a running GPU.

Browse the catalog

Every filter on /offers, with worked examples.

Rent a machine

Quote, create, poll, connect.

Whole nodes on Radar

Browse them, enquire, or propose one of your own.

Error reference

Every code we return, and what to do about each.

​
What you can do

Catalog and Rentals are self-serve end to end: a call rents a machine and the money moves. Radar is not, and no amount of API access changes that — an inquiry is a lead our team answers, and a proposed node is reviewed by a person before any buyer sees it. Both endpoints return promptly; neither outcome arrives at the speed of an HTTP response.

​
Money is in cents

Every monetary field is an integer number of US cents and carries currency: "usd". price_per_hour_cents: 249 is $2.49 per hour. There are no floats anywhere in the money path, in either direction. This is not a stylistic choice: 0.1 + 0.2 !== 0.3 in every language with IEEE-754 doubles, and a rounding drift in a billing figure is a support ticket you cannot answer. If your language has a decimal type, convert at the edge of your code, not in transit.

​
What we do not publish

Two things are absent from every response, on purpose:
  • The upstream provider behind an offer.
  • The identity of the supplier operating it.
Neither appears in anonymised or hashed form either, so please do not build on inferring them from ids, prices, or timing. The same rule covers Radar from the other side: a node never carries who proposed it, including when the proposer is you reading your own submission back. What you get instead is the thing that actually matters for a scheduling decision — the GPU, the region, the price, and whether it is free right now.

​
What stays stable

We may, at any time and without a new version:
  • add endpoints,
  • add fields to responses,
  • add optional query parameters,
  • add values to response enums.
Your client must ignore fields it does not recognise, and must not crash on an enum value it has not seen. That single rule is what lets us ship improvements without breaking you. Anything else — removing or renaming a field, changing a type, tightening validation — requires a new major version. Endpoints being retired carry Deprecation and Sunset headers for at least 90 days before they stop answering.
Enum widening is the one that catches people. A switch on status with no default branch, or a Rust-style exhaustive match generated from today’s spec, will break the day we add a status. Treat unknown values as “something new I should log”, not as an error.

​
Getting help

Every error response carries a request_id. It identifies the exact request in our logs, including the ones that never reached your side intact.
Quote that request_id when you write to help@gpuoutlet.ai and we can look at the same request you did, rather than a reconstruction of it.