Whether the client actually pays
get_buyer_qualityWhether the client behind a posting actually pays, and how much of that we can honestly claim to know. Call it before spending connects.
upwork_id is the posting's id. ask is your intended HOURLY rate; give it
and you also get how many of their past hourly contracts cleared it. It does
not affect the fixed-price model, whose threshold is fixed.
READ coverage FIRST: how many of their contracts the answer used, beside
their own public counters. A small sample of a big history is a sample, not a
summary — when coverage.thin is true, say so when you relay it.
models is keyed by contract type, 'fixed' and 'hourly'; primary names the
one this posting's engagement type selects. Each entry answers the single
yes/no question written out in its own asks sentence, at its threshold:
p is the probability, prior the population base rate for that same
question, and lift is p / prior — 1.0 is average, BELOW 1 means knowing
about this client is worse news than knowing nothing. p is NULL, never 0,
when known is false: "never paid that" and "no record" are different.
tier = WHICH EVIDENCE it rests on: 'own-history' their own past contracts,
'cohort' what the freelancers they hired charge, 'both', 'none'.
cohort.anchor = WHOSE RATE the cohort median is: 'paid' what this client
actually paid them, 'listed' those freelancers' own asking rates (only when
we hold no paid rate for any hire), 'none'. How p is computed stays private;
what these fields mean does not. The answer repeats the value sets in
legend; describe_fields("get_buyer_quality") documents every field here.
Feed-scoped: answers for postings this corpus has shown you — your own search results and saved-search matches. Any other id is refused, with how to bring it into reach.
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| ask | No | your intended hourly rate in USD. Must not be negative. | |
| upwork_id | Yes | a posting id as search_jobs returns it. Not a URL, and without the leading '~'. |
Output Schema
| Name | Required | Description | Default |
|---|---|---|---|
| note | No | Present when no buyer is linked. | |
| found | No | False when the corpus holds no such posting. | |
| taste | No | What this buyer tends to hire — see Taste. Absent — not null — when `found` is false, or when `buyer_record_known` is false; `note` says which of the two happened. | |
| legend | No | What the closed-value fields mean, carried WITH the answer: the four verdict values and their cut points, the four tier values, and the anchor values. Here because a tool description is truncated by some clients and outputSchema is a validation contract the spec does not ask clients to show a model — the response is the only channel with neither limit. | |
| models | No | One entry per contract type, keyed 'fixed' and 'hourly', each answering one question about their next contract. The estimation method stays withheld; the vocabulary is documented — see ModelAnswer. Absent — not null — when `found` is false, or when `buyer_record_known` is false; `note` says which of the two happened. | |
| record | No | Their contract history as the corpus holds it — see Record. Absent — not null — when `found` is false, or when `buyer_record_known` is false; `note` says which of the two happened. | |
| primary | No | The headline judgement, naming which contract type it is about — the same vocabulary as ModelAnswer.model. Absent — not null — when `found` is false, or when `buyer_record_known` is false; `note` says which of the two happened. | |
| coverage | No | The denominator behind everything above. A verdict without it is a claim you cannot check. | |
| upwork_id | No | The posting. | |
| ask_vs_record | No | Given your `ask`, how many of their past hourly contracts cleared it — see AskVsRecord. The most useful line before quoting. Absent — not null — when `found` is false, or when `buyer_record_known` is false; `note` says which of the two happened. Present with `known: false` when you passed no `ask` — that object is the answer "you did not ask", not missing data. | |
| identity_known | No | A company NAME resolved — exactly what get_buyer.company being non-null means. The two tools cannot disagree. | |
| rate_by_category | No | What their past contracts cleared, by category — see RateByCategory. Absent — not null — when `found` is false, or when `buyer_record_known` is false; `note` says which of the two happened. | |
| buyer_record_known | No | A buyer is linked to this posting, so a contract history is computable. Does NOT mean we know who they are. |