Expand description
The Suotar API log tab: one row per HTTP call to the study registry, and what each covered.
The stored bodies are scrubbed at write time — names, student numbers and email addresses read
[redacted] while their keys survive — and are returned exactly as stored. What makes the log
navigable is not the body but credit_registration_ids: every call resolves to the ledger rows
it carried, and those hold the real values.
Structs§
- List
Suotar ApiCalls Query - Suotar
ApiCall Details - Suotar
ApiCall Event - A timeline entry written against this call, one per item the answer moved.
- Suotar
ApiCall Ledger Reference - One ledger row a call carried, resolved from
credit_registration_ids. This is what stands in for the redacted body: the identifiers are here, beside the item they belong to. - Suotar
ApiCall Row - Suotar
ApiCalls Page
Constants§
- MAX_
REFERENCED_ 🔒ROWS - How many ledger rows one call may resolve. A batch is capped well below this by the endpoint’s own batch size.
Functions§
- _add_
routes - get_
suotar_ api_ call - GET
/api/v0/main-frontend/credit-registration-admin/suotar-api-calls/{suotar_api_call_id}- One call with its stored bodies, the ledger rows it covered and the timeline entries it produced. - list_
suotar_ api_ calls - GET
/api/v0/main-frontend/credit-registration-admin/suotar-api-calls- A page of the study registry call log, newest first. - resolve_
ledger_ 🔒references - The ledger rows a call named, in the order the call listed them, so the reference table lines up with the stored body’s items.
- to_
call_ 🔒row - to_
call_ 🔒row_ from_ full - The same summary, from the detail endpoint’s full row rather than the bodyless listing one.