Skip to main content
This walks the whole path once: mint a key, find capacity, price it, rent it, connect, stop it. Every response below is real, trimmed only for length.
1

Mint a key

In the dashboard, go to Settings → API keys → Create key. Give it a name you will recognise in six months, tick the scopes it needs — for this walkthrough, all three — and copy the key. It is shown once.
Confirm it works:
2

Find capacity

Ask for H100s that are free right now, cheapest first:
Every filter is documented in Browsing the catalog.
3

Price it

A quote tells you what the rental costs per hour at the size you want, and whether it can start right now.
price_per_hour_cents is for the whole rental, not per GPU. A quote reserves nothing — see Quotes.
4

Rent it

Creating a rental spends money, so Idempotency-Key is required. Generate one per intent and reuse it verbatim on every retry of that same intent.
provisioning means the machine does not exist yet. access is null and nothing is reachable. Do not treat a 201 as “ready”.
5

Wait for it, then connect

Poll the rental until it is running — usually well under a minute.
Poll about once every two to three seconds. Every member of access is independently nullable — an offer may expose SSH but no Jupyter — so check before you use one.
6

Stop it

stopping is not stopped. Teardown is asynchronous and the final charge lands when the machine is actually gone. Poll until stopped before you trust accrued_cents as final, or before starting a replacement if you are near the concurrency ceiling.

The same thing in one script

Both scripts loop only while the status is provisioning, and treat everything else as an exit condition. Looping on !== 'running' instead would spin forever on a failed rental — the single most common bug in a first integration.

Next

Every catalog filter

Rental lifecycle in detail

Spend limits and safety rails

Error reference