> ## Documentation Index
> Fetch the complete documentation index at: https://docs.gpuoutlet.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# API overview

> What the GPU Outlet API does, what it deliberately does not expose, and what you can rely on staying stable.

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](/api/radar), browse whole physical nodes and put your own up for sale.

```
https://api.gpuoutlet.ai/v1
```

Every endpoint takes and returns JSON, authenticates with a bearer token, and
speaks HTTP status codes with a consistent error envelope.

<CardGroup cols={2}>
  <Card title="Get a key and make your first call" icon="rocket" href="/api/quickstart">
    Five minutes from nothing to a running GPU.
  </Card>

  <Card title="Browse the catalog" icon="magnifying-glass" href="/api/offers">
    Every filter on `/offers`, with worked examples.
  </Card>

  <Card title="Rent a machine" icon="server" href="/api/renting">
    Quote, create, poll, connect.
  </Card>

  <Card title="Whole nodes on Radar" icon="satellite-dish" href="/api/radar">
    Browse them, enquire, or propose one of your own.
  </Card>

  <Card title="Error reference" icon="triangle-exclamation" href="/api/errors">
    Every code we return, and what to do about each.
  </Card>
</CardGroup>

## What you can do

| Area                  | Endpoints                                                                                                                                                             |
| --------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Account**           | `GET /me` — what this key is and what it may do                                                                                                                       |
| **Catalog**           | `GET /offers`, `GET /offers/{id}`, `GET /gpu-models`, `GET /gpu-families`, `GET /regions`, `GET /prices`                                                              |
| **Rentals**           | `POST /rental-quotes`, `POST /rentals`, `GET /rentals`, `GET /rentals/{id}`, `POST /rentals/{id}/stop`, `GET /rentals/{id}/events`                                    |
| **Radar**             | `GET /radar/nodes`, `GET /radar/nodes/{id}`, `POST /radar/nodes/{id}/inquiries`                                                                                       |
| **Radar submissions** | `GET /radar/submissions`, `POST /radar/submissions`, `PUT /radar/submissions/{id}`, `POST /radar/submissions/{id}/withdraw`, `POST /radar/submissions/{id}/republish` |

Catalog and Rentals are self-serve end to end: a call rents a machine and the
money moves. [Radar](/api/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.

<Note>
  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.
</Note>

## 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.

```json theme={null}
{
  "error": {
    "type": "invalid_request_error",
    "code": "invalid_cursor",
    "message": "The cursor does not match the current filters or sort order.",
    "doc_url": "https://docs.gpuoutlet.ai/api/errors#invalid_cursor",
    "request_id": "req_9f3c1a7e42b8"
  }
}
```

Quote that `request_id` when you write to [help@gpuoutlet.ai](mailto:help@gpuoutlet.ai)
and we can look at the same request you did, rather than a reconstruction of it.