List Org Runs

API key authentication. Get your API key from the Duvo dashboard.

The organization's unique identifier

Number of runs per page (1-500, default 20). The cap is higher than the team runs endpoint's because this route serves bulk export: at 100 requests a minute per key, page size is what bounds how fast a month of runs can be pulled.

Resume after the run a previous page ended on: pass the next_cursor that page returned, with the same filters and sort_order. Runs created or resolved in between cannot shift a boundary you have already passed, so a sweep sees every run exactly once, and a sweep that started under the default 7-day window keeps that window on every page. This list has no offset parameter: skipping rows costs the database every skipped row, and a run created between two requests shifts every later offset by one, so an offset sweep can repeat or miss a run. 400 when the value is not a cursor this endpoint issued.

Sort direction on created_at (default desc)

Filter to runs with this status. needs_attention is the monitoring status: runs that are waiting on a human or failed, plus runs whose latest evaluation flagged a critical issue — a run can finish as completed and still have accomplished nothing.

Filter to runs on this team

Filter to runs for this agent

Filter to runs created from this source (e.g. api, scheduling)

Filter on the run's latest successful evaluation: true returns only runs it flagged, false only runs it did not. Only the latest evaluation counts — an older flag does not match — and a run whose latest evaluation errored, or that has none, counts as unflagged. Omit to return both.

Only runs whose latest successful evaluation has at least one failing rubric at this severity (critical | medium | low). Implies has_issues.

Return runs created at or after this ISO-8601 timestamp. Every run has a creation time, so this is the window that returns all runs in a period whatever state they reached — unlike the started and completed windows below, which exclude runs that never started and runs still in flight respectively. When the request carries no lower time bound (created_after, started_after, completed_after or since), this defaults to 7 days ago and default_window_applied is true in the response: an organization's run history is unbounded, and a monitor wants what is recent. An upper bound alone keeps the default floor. Pass any lower bound to replace it.

Return runs created before this ISO-8601 timestamp (exclusive). Pair with created_after for a period. A closed creation window is also the stable one to paginate: results are ordered by creation time, so runs arriving mid-sweep cannot shift a closed window's pages.

Return runs that started at or after this ISO-8601 timestamp. Runs that never started are excluded. Pair with started_before to bound a stuck-run query to a window — without a lower bound, status=running also counts every run left running months ago.

Return runs that started before this ISO-8601 timestamp. Combine with status=running to find stuck runs — since/until filter on completion, so they never match a run that is still going.

Return runs completed at or after this ISO-8601 timestamp. Runs that have not completed are excluded, including every stuck one — reach for started_after/started_before to bound those. Alias of since; pass one or the other, not both.

Return runs completed before this ISO-8601 timestamp (exclusive). Runs that have not completed are excluded. Alias of until; pass one or the other, not both.

Alias of completed_after, kept because it is the name the public team runs endpoint ships. Prefer completed_after: this endpoint carries a creation and a start window too, and only the column-named pair says which one this is.

Alias of completed_before, kept because it is the name the public team runs endpoint ships. Prefer completed_before.

Skip row selection and enrichment. The normal list response shape is returned with an empty row array and the matching total.

Return total, the count of every matching run ignoring pagination. Off by default: counting walks every match where the page stops at limit, so on a large organization it costs orders of magnitude more than the rows themselves. Ask for it when you are driving a pager, not when you are polling. Implied by count_only.