Skip to main content
Send your access token on every request:
Tokens are issued by Compute Index — contact david@compute-index.com to get one, or to change what an existing token can read. They are long-lived, so treat one like a password: keep it in an environment variable or a secrets manager, and never commit it to source control.
v2 needs an access token, not a legacy API key. If you call v1 today with a gpi_… key, that key will not work here — v2 replies 401 and tells you so. Ask us to issue you a token; your data access carries across unchanged.The v1 API continues to accept API keys, so nothing you have built breaks.Moving across? See Migrating from v1.

​
What your token can read

Access is granted per data type, and separately for current and historical data — so a token can be set up to read today’s rental prices without being able to read last year’s. /latest and /metadata return current values. /as-of and /history return historical data. Two things worth knowing:
  • Aggregated Transactions is historical by nature. A settled deal is an event, so there is no “current value” to read — see Migrating from v1 if you are moving across from /v1/txn-aggregate.
  • Indices are granted index by index. Your token may cover some indices and not others; /metadata lists the ones you hold, and an id you do not hold returns 404 rather than 403.
A 403 means your token does not cover what you asked for. Contact us and we will adjust it.
Access to v2 is enabled per token. If you already call v1, your existing data access carries across, but v2 has to be switched on before your first call will succeed. Ask us and we will enable it.

​
How far back you can read

Your organisation may be licensed to a particular depth of history. You never have to guess where that limit is:
  • /metadata reports it as history_starts_at
  • /history trims a window that starts earlier, and says so in meta.window.clamped
  • /as-of at a date before your limit returns an error rather than a different date’s answer

​
Rate limits

Tokens are Pro unless a different tier is agreed for your organisation. Limits are enforced on a sliding window, so there is no reset instant to wait for and no fresh allowance at the top of the minute — budget regrows continuously as your earlier requests age out of the window. Every response tells you where you stand, in the X-RateLimit-Limit, X-RateLimit-Remaining and X-RateLimit-Reset headers — read those and pace your requests rather than waiting for a 429. X-RateLimit-Reset is the seconds until the next single request frees up, not until your full allowance returns, so honour it one request at a time: a client that treats it as a restored quota and fires a burst gets one request through and the rest rejected. A 429 repeats the same figure in Retry-After.

​
Errors

Errors are RFC 9457 problem details, served as application/problem+json, with a code you can branch on. Match on code, not on detail — detail is written for people and its wording may change.
request_id matches the X-Request-Id response header and is repeated in the body so it survives being logged or pasted — quote it when you contact us about a failing request. Where it helps, an error carries extra fields — anchors above lists exactly what would make the request valid, so your code can correct itself without a trip to these docs. v1 returns a different error shape, and is unchanged.