Skip to main content
An investor purchase is a purchase at arm’s length that the build flagged. Three facts flag a purchase: the buyer is an entity, the buyer bought twice in a year, or the parcel sold again inside a year. Each investor purchase carries one outcome: one word of six over its resale and the data end of the state. The words are predicates over served facts. The API computes no score and no class, and the facts the predicate reads ride beside the word on each item. GET /v3/properties/{id}/transactions answers one parcel. POST /v3/properties/transactions answers up to 500 parcels and transactions at once. POST /v3/jobs/transactions answers up to 10,000 in the background. The API measures windows from the data, not from today. The data end of a state is deeds_through, the newest purchase at arm’s length of its deed cut. Each block carries it. A purchase inside the 365 days before the data end with no resale is open. The window has not closed, so the outcome is not known yet.

The six outcome words

The thresholds are the ones of the organization profile of GET /v3/orgs/{id}. Its counts n_quick_resales, n_flips, n_flip_window_other, n_long_holds_sold and n_held count the same words over the purchases of one organization.

What rides on an item

Each item carries the purchase leg and the resale leg with their dates and prices, days_held, spread and the three flags of the build. It names the investor in the party shape of the deal routes. That shape has the display name, the organization and the person behind a name that reads as a person. This is the fast shape, and it is the default: a few index probes for each item, so 50 parcels answer at once. detail: true adds the blocks that cost a probe each. The investor then carries the track record of its organization. The seller and the end buyer ride in the same shape. The entry says if the investor bought at an auction, as an REO sale or through a marketplace closing. The exit names the sold listing of the feed that closed within 45 days of the resale deed. The block carries the holder of the roll. Without detail each of these reads null. The API gives a company name to every key. This host does not name a person: the name is null, and the ids stay. The organization id opens GET /v3/orgs/{id}, and the person id opens GET /v3/people/{id}.

The role of a transaction

The list form and the job form take transactions: a parcel id with a date, or a deal id. The answer gives the role of that deed among the investor purchases of its parcel. A deed can be the resale of one investor purchase and the purchase of another on one day. The answer then carries two roles for the one transaction.

The status of a block

Each block carries a status. served says the parcel is in a served state. no_deeds says the parcel is in the set and has no purchase at arm’s length. not_served says the id is in the place index of no served state. The API measured nothing for it, so an empty list is not the answer.

The job form

A job holds up to 10,000 parcels and transactions. The API computes it in the background, 500 at a time, and keeps the results for 24 hours. The job id is the hash of the key, the body and the build. So a repeated request with one body answers the job that exists. wait holds the request up to 20 seconds. A job that is done in time answers 200 with its record, else the answer is 202. GET /v3/jobs/{id} reads the record until the status is done. GET /v3/jobs/{id}/results pages the blocks in the order of the request. Accept: application/x-ndjson answers one block a line. A job that is not done answers 409 with Retry-After.

Partners and staff

On the internal host a key with the contact scope reads the name of a person on an item. Without the scope the name is null, and the item says contact_redacted: true. The results route of a job also answers Accept: text/csv there: one row for each investor purchase, with the block facts repeated on each row.