> ## Documentation Index
> Fetch the complete documentation index at: https://developers.investorlift.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Ids and their stability

> What each id of the lean set is made of, which ids survive a publish, and how to resolve one that moved.

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

| Id | Shape | Made of | Moves when |
| - | - | - | - |
| Registry organization | `AZ:L17142520` | The state and the filing number of the business registry | Never |
| Deed-name organization | `AZ:name:ACME HOLDINGS` or `AZ:name:JANE DOE\|85251` | The state, the name key of the deed and, for a person's name, the ZIP | The name rule of the build changes |
| Person | `person:01d108287995` | 12 hex characters of the hash of the person key, the filed name with its place | The person key changes, or two keys share one prefix |
| Buyer | `buyer:ae0ea2a5e902` | 12 hex characters of the hash of the organization id of a buyer with no filing | The organization id changes |
| Agent | `AZ:agt:746abc7438c7` | The state and 12 hex characters of the hash of the anchor of the agent: a licence, a phone or an email | The build folds two agents into one |
| Deal | 32 hex characters | The hash of the parcel, the date and the transaction id of the county record, or its document number, or its price and its buyers | A later delivery fills the transaction id of the record |
| Listing | 32 hex characters | The hash of the parcel and the listed date | Never |
| Parcel | 32 hex characters | The id of the parcel in the feed | Never |

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](/guides/concepts/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.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.