/v1, and it is additive only. New endpoints, new fields and new enum values arrive
without notice. Investorlift removes or renames nothing that exists inside /v1. If a documented route, field or tool
ever has to go, Investorlift aims to give 30 days’ email notice first. Before it retires a paid plan, Investorlift aims
to give 90 days’ email notice (Developer Agreement Section 12.3). The changelog records the removal on the day
it ships.
Write a client that tolerates addition:
- Ignore fields you do not know. A new block on a row is not an error.
- Treat every enum as open.
kind,verification,outcome,cycle_state,statusand the rest all gain values as Investorlift loads more of the country. Handle the values you render, and fall through on the rest. Do not throw. - Do not depend on key order or on the exact wording of
detail,titleoroutcome_text. Error codes are stable. Their prose is not.
Two numbers that are not the API version
Neither is a thing you request. The API has no version header and no version in the path beyond
/v1.
Cache on the dataset version
dataset_version is an integer per market. It changes at each rebuild of the tables behind that market, and only
then. Put it in your cache key, and every cached answer invalidates itself at the next refresh.
The cache window bounds the rest. Keep a cached answer for at most 30 days. Drop it within a business
day of a version change. While you hold cached answers, check the current version at least once a business day. Use
GET /v1/dataset (not metered) or the X-Dataset-Version header. An example cache key:
400 invalid_cursor, not a silently
wrong second page. See Pagination and
Coverage and freshness.
What a new market changes
A new market is additive too. Its rows appear inside its own coverage area, andmeta.coverage[] gains an entry.
Points that answered 422 outside_coverage before start to answer with data. Read meta.coverage[], and do not
hard-code the market list. Then a market you did not know about works the day it lands.