Skip to main content

collect_app_view_records

Internal beta — config shape is being migrated

The Automation API is an internal beta and is not released yet — endpoints and payloads may change or be withdrawn without notice. This action's config is being migrated to a typed schema; the fields below reflect that in-progress shape. Always read the authoritative, live shape from GET /v1/automation/meta/action before building against it.

Collect app view records — collects the records of an app view into a record collection. group: "action". No specific trigger context is required.

Part of the Record collections family. This page documents the typed config; for how an action sits inside an automation definition, see Actions and Action examples.

Config​

KeyTypeRequiredDescription
app_idintegernoId of the app to collect records from.
app_view_idintegernoId of the app view to collect records from.
limitintegernoMaximum number of records to collect. Defaults to the editor default when omitted.
limit_enabledbooleannoWhether limit is applied. false when omitted.
Discovery requires app_id and app_view_id

The typed DTO carries both ids as optional (a not-yet-configured action may have neither), but discovery serves them in required and validation reports action_app_missing / action_app_view_missing when either is absent — a usable action must supply both. Prefer the DTO shape, but treat app_id + app_view_id as effectively required.

Example​

An action entry inside an automation definition's actions[]:

{
  "type": "collect_app_view_records",
  "config": {
    "app_id": 4201,
    "app_view_id": 9317,
    "limit": 100,
    "limit_enabled": true
  }
}

Validation & behavior​

  • This is a producer: it needs a real app_id and app_view_id to collect anything, and validation rejects an action missing either.
  • app_view_id is only checked for presence at validate time — a syntactically valid but non-existent view passes validation and then fails at run time.
  • limit defaults to the editor default when omitted, and limit_enabled defaults to false, so an omitting caller still yields a complete action (no cap applied unless limit_enabled is true).

See also​