v1 is not going away yet, and nothing you have built breaks. Move when it suits you, and move
one endpoint at a time — the two can be called side by side with the same token.
1. Swap your API key for an access token
v2 does not accept legacygpi_… API keys. Ask us for an access token
(david@compute-index.com) and send it as:
- It goes in the
Authorizationheader, notX-API-Key. v2 does not readX-API-Keyat all. - It works for both versions. You do not need to run two credentials during the move; the same token calls v1 and v2, so you can migrate endpoint by endpoint.
2. Find your endpoints
Every v2 data type answers the same four questions, so the mapping is mostly mechanical:current → latest, available / reference → metadata.
Rental prices
/lowest has no direct replacement because it no longer needs one — sorting is available on every
endpoint, so “the cheapest ten” is an ordinary query.
Indices
Every index is served from one place, and a request names one index by
id. Where v1 took a
scope — gpu_family=hopper®ion_group=US, or gpu_group=h100 — v2 takes the id of that series:
rental-hopper-1y-us-daily, rental-h100-1y-us-daily. The 30-minute series v1 called custom
indices end in -intraday instead, so v1’s custom h100-us is v2’s rental-h100-1y-us-intraday.
The id scheme is explained on Indexes, and
/metadata lists the ids your token holds.
Two fields are renamed on every row: index_value is value, and the point’s date or instant is
timestamp on both daily and intraday rows. A row’s type — daily or intraday — says which
it carries. txn_count and the settled-only index_type=raw leg are not carried across.
Transactions
Both v1 endpoints become one. The bulk variant existed to return more rows at once; in v2 you page
through the full result set instead, so a single endpoint covers both uses.
Reference lists
In v1 these were four global lists. In v2 each data type publishes its own vocabulary through/metadata, so the values you get back are the ones that type actually accepts.
If you rely on
/v1/vendors or /v1/regions, keep using them for now. v2 accepts vendor
and region as filters and sorts by them, but does not yet publish either list through
/metadata. Tell us if you need them and we will prioritise it.New in v2
No v1 equivalent exists for these:3. Check these four behaviour changes
Everything else is a rename. These four will change what your code receives.Paging works differently — no page numbers, no total count
Paging works differently — no page numbers, no total count
v1 used Send nothing alongside the next link — it already carries your filters, dates and sort
order. Adding a parameter returns an error rather than being quietly ignored.There is no total count.
offset and told you the total_count. v2 gives you a link to the next page
instead: read meta.next and call it, and stop when it is null.meta.has_more tells you whether another page exists, which is the
question a paging loop actually asks./history returns what CHANGED, not everything in force
/history returns what CHANGED, not everything in force
This is the change most likely to surprise you.v1’s
/history returned every record that was still in force at any point during your window —
so a price set months ago and never changed came back in every window since. Two adjacent
windows returned nearly the same rows.v2’s /history returns records that changed inside the window. Ask for yesterday and you
get yesterday’s changes.- Charting a series over time?
/history— unchanged in spirit, far fewer rows. - Need the price on a particular day? Use
/as-of, which is the endpoint for that question.
Date ranges exclude the end instant
Date ranges exclude the end instant
start is included and end is not, so consecutive ranges join up without returning anything
twice — you can pull a year month by month and not deduplicate.Plain dates still behave as you would expect: ?start=2026-06-01&end=2026-06-01 is that whole
day.Errors carry a code to branch on
Errors carry a code to branch on
v1 returned Match on
{"detail": "…"}. v2 adds a stable code alongside the human-readable message:code. detail is written for people and its wording may change.4. Field names are consistent now
The same thing is spelled the same way everywhere. If a field meant one thing on one v1 endpoint and something slightly different on another, v2 gives it one name and one meaning. The practical effect: check the field names in a v2 response once per data type, rather than per endpoint. Each type’s page lists them in full, and/metadata tells you what you can filter on.