Set RUN_ID to the ID returned by submission. Use the first example to print events as the run progresses. Save next_cursor after each page and pass it as after on the next request so you do not repeat events.
2. Check the terminal result
Read state, result.exit_code and cleanup_status. A successful invocation does not mean “no vulnerabilities”: the tool’s report says what it found. If the run is outcome_unknown, review retained output before deciding whether to run it again.
3. Download outputs
The second example saves the returned files under results/RUN_ID and verifies their SHA-256 values. To get a tool-generated report, request its path in invocation.outputs when submitting the run. Stdout and stderr are returned separately.
4. Check for incomplete output
Inspect stdout_truncated, stderr_truncated, outputs_truncated and output_errors. If a report is too large, narrow the tool’s output or request fewer files and run it again.
Events show command progress and captured output. For process, file or kernel-event collection, use an explicit Sysmon or Tetragon run. Those events are not automatically collected by every tool.