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 taketransactions: 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 astatus. 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 sayscontact_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.