Skip to main content
Every id of the lean set is a function of the records it names, never a number the API hands out. A publish of a state rebuilds every row, and an id that reads the same records reads the same. This page says what each id is made of, when it moves, and what to do when it does.

​
What each id is made of

A deal id, a listing id and a parcel id have one shape. GET /v3/ids/resolve/{id} tells them apart by the table that holds the id.

​
What to do when an id moves

The build writes an alias row for each person id, agent id and deal id that moved, from the old id to the new one. GET /v3/ids/resolve/{id} follows the alias rows and answers the current id with the rows it followed. An id the set holds answers itself with no hop. GET /v3/ids/resolve?ids= does the same for up to 100 ids in one call, and answers current_id: null for an id the set does not hold. The person route follows the alias rows on its own. A stored person id opens the current person, and meta.resolved_from names the old ids the walk followed.

​
Cursors and a publish

A cursor belongs to one query, one sort and one build of the set. A publish ends every cursor, and the API answers 400 invalid_cursor with reason: "refreshed". Restart the walk from the first page. Pagination has the four reasons.

​
Where to read the publish

meta.build.states[] on every response names the run id of each served state. GET /v3/build and GET /v3/coverage serve the same rows with their dates. A stored id carries the run id it came from, so a client knows which publish it belongs to.