POST /v1/follow-up

Request

{ "search_id"?: "srch_…",   // exactly one of search_id or record_id
  "record_id"?: "rec_…",
  "action": "more" | "update" | "details" | <capability-specific record action>,
  "params"?: { … }            // update: any subset of the capability's request fields }

• search_id + more: next page; response is the execute envelope with the same search_id. Refused with 400 on single-result capabilities.
• search_id + update: merge params into the stored query, reset paging, replace the records; same search_id. The accepted params per capability are the …UpdateParams components in the OpenAPI document and x-aipa-update-params on this operation.
• record_id + a record action: the record envelope { record_id, action, detail, links[], cached?, charged_credits, balance }. Unknown actions are refused with 400 and the list of valid ones.

Semantics (session lifetime, caching, typed next requests) are explained under sessions, paging and records.

Actions per capability

Paging: token/page/offset fetch from the provider; local serves from the session for free. Details: fresh is a billed first fetch then cached; cached is stored at search time and free; mixed is a free provider lookup.