summary

Data type summary: a per-row rollup defined in the schema, distinct from the _summarize endpoint (probe 020), which aggregates rows named at call time into one number for the whole query. On the probed site, scanning all 114 entity types, one /schema/<Type>/fields each (33s, probe 002), finds 42 summary fields on 41 types under four names, every one of them probed below.

The rollup definition is exposed. GET /schema/<Type>/fields/<field> returns properties with five keys. default_value is {"value": null, "editable": false} on all 42 of them and is not the value of an unpopulated row; the other four define the rollup:

"summary_default": "record_count",  "summary_field": "id",  "summary_value": null,
"query": {"entity_type": "Note", "filters": {"logical_operator": "and", "conditions": [
  {"path": "note_links", "relation": "is",
   "values": [{"id": 0, "name": "Current Entity", "type": "Entity", "valid": "parent_entity_token"}]},
  {"logical_operator": "or", "conditions": [... one per status: "opn", "ip", "rdy"]}]}}

{"id": 0, "valid": "parent_entity_token"} stands for the row being read. Rewrite each leaf condition as a triple with the row in place of the token, keep the logical_operator groups, and send the tree as filters under Content-Type: application/vnd+shotgun.api3_hash+json:

{"path": "note_links", "relation": "is", "values": [<the token>]}
  ->  ["note_links", "is", {"type": "Shot", "id": 862}]

Run that way, Shot.open_notes_count reproduces on three rows: 19, 18 and 18, against 19, 18 and 18. It is the only summary field returning a number here, so that is the whole of the evidence that the translation is right. null is not an empty rollup: CustomEntity01.sg_test_results is a record_count reading null on 100 of 100 rows whose own query counts 70. No row here holds a single_record value, so that aggregate is unproven, its populated shape included.

Read

The value is computed per read, with no lag. Each row below is the next request after the change:

Write Refused; the whole request is rejected rather than accepted and discarded like cached_display_name (probe 004). Re-reading after each attempt returned the value unchanged.

Clear Not reachable.

Filter No operator works, and the 400 names no vocabulary: every other type answers a bogus relation with its Valid relations list (probe 017). source for definitely_not_an_operator:

{"Shot.open_notes_count": " data type cannot be used in a filter. Value: {"path" =>
 "open_notes_count", "relation" => "definitely_not_an_operator", "values" => [nil]}"}

Page the rows and compare in the client, or run properties.query against the target type and aggregate.

Traps

• Fill rate is meaningless on this type. open_notes_count is never null, so it scans as 100% filled while holding one value: 100 Versions all read 0 (probe 007). The other four read null on every row and scan as 0% filled while their queries match rows. Exclude data_type == "summary" from fill ranking; the is_not None probe 400s, as does _summarize grouping.
• Sort fails silently. ?sort=code and ?sort=-code return different orders, ?sort=open_notes_count returns the unsorted order, and so does ?sort=definitely_not_a_field: an unsortable field and a typo are indistinguishable at 200.
• editable: true describes the field-configuration form in the web interface, not the REST value, and the refusal cites the data type rather than the field. Three of the 42 summary fields on this site claim it, so a client building an update form from editable offers three that can never be saved.
• 38 of the 42 are open_notes_count, one per entity type, all counting Notes whose status is opn, ip or rdy. That set is the site's definition of "open", readable from properties.query and site configuration rather than an API constant: read it instead of hardcoding the three codes.