@epilot/sdk 2.20.36 → 2.20.37

package/dist/{integration-toolkit.d-BQ0Fj-48.d.cts → integration-toolkit.d-DRYMfItg.d.cts}

@@ -4055,6 +4055,21 @@ declare namespace Components {
              * 2025-01-31T23:59:59Z
              */
             to_date?: string; // date-time
+            /**
+             * Count only the events of ONE run. Every span a run produces carries its `correlation_id` (for a file import, the `import_id`), so this turns the stats call into an exact per-run readout — no time range to guess at, no pagination, and no 2000-span cap as on `/monitoring/traces/{correlationId}`. Applies to the `monitoring` source; the `incoming` feed is counted per received event and ignores it.
+             * example:
+             * imp_01M3799K98B6TG7GV7Q2DQT554
+             */
+            correlation_id?: string;
+            /**
+             * Count the events of THESE runs (matches any). Takes precedence over `correlation_id` when both are present. With `group_by=correlation_id` this returns one row per run, which is how a list of jobs gets a per-row readout in a single query instead of one call per row.
+             * example:
+             * [
+             *   "imp_01M3799K98B6TG7GV7Q2DQT554",
+             *   "imp_01M374YPQ0E7ZB0VYJZSK72M4E"
+             * ]
+             */
+            correlation_ids?: string[];
             /**
              * Filter stats by a single use case type
              */
@@ -4064,9 +4079,9 @@ declare namespace Components {
              */
             use_case_types?: ("inbound" | "outbound" | "file_proxy" | "managed_call" | "secure_proxy")[];
             /**
-             * Field to group the breakdown by
+             * Field to group the breakdown by. `correlation_id` gives one row per run — pair it with `correlation_ids` to bound the result to the runs on screen.
              */
-            group_by?: "use_case_id" | "use_case_type" | "level" | "code" | "date";
+            group_by?: "use_case_id" | "use_case_type" | "level" | "code" | "correlation_id" | "date";
             /**
              * Data source for the stats. "monitoring" (default) aggregates processed events from erp_monitoring_v2 — this counts every event produced throughout the processing tree (fan-out children, post-actions, relation resolutions, etc.). "incoming" counts only the initial inbound events actually received (distinct event_id from erp_incoming_events); only group_by=use_case_id is supported and status/level breakdown is not available for this source (success/error/warning/skipped counts are returned as 0).
              *
@@ -5931,6 +5946,10 @@ declare namespace Components {
              * Timestamp of the most recent error
              */
             last_error_at?: string | null; // date-time
+            /**
+             * Timestamp of the most recent event of ANY level — "is this still moving?", which is a different question from when it last broke. Null when the filter matched nothing.
+             */
+            last_event_at?: string | null; // date-time
             /**
              * Statistics breakdown by requested group_by field
              */

package/dist/{integration-toolkit.d-BQ0Fj-48.d.ts → integration-toolkit.d-DRYMfItg.d.ts}

@@ -4055,6 +4055,21 @@ declare namespace Components {
              * 2025-01-31T23:59:59Z
              */
             to_date?: string; // date-time
+            /**
+             * Count only the events of ONE run. Every span a run produces carries its `correlation_id` (for a file import, the `import_id`), so this turns the stats call into an exact per-run readout — no time range to guess at, no pagination, and no 2000-span cap as on `/monitoring/traces/{correlationId}`. Applies to the `monitoring` source; the `incoming` feed is counted per received event and ignores it.
+             * example:
+             * imp_01M3799K98B6TG7GV7Q2DQT554
+             */
+            correlation_id?: string;
+            /**
+             * Count the events of THESE runs (matches any). Takes precedence over `correlation_id` when both are present. With `group_by=correlation_id` this returns one row per run, which is how a list of jobs gets a per-row readout in a single query instead of one call per row.
+             * example:
+             * [
+             *   "imp_01M3799K98B6TG7GV7Q2DQT554",
+             *   "imp_01M374YPQ0E7ZB0VYJZSK72M4E"
+             * ]
+             */
+            correlation_ids?: string[];
             /**
              * Filter stats by a single use case type
              */
@@ -4064,9 +4079,9 @@ declare namespace Components {
              */
             use_case_types?: ("inbound" | "outbound" | "file_proxy" | "managed_call" | "secure_proxy")[];
             /**
-             * Field to group the breakdown by
+             * Field to group the breakdown by. `correlation_id` gives one row per run — pair it with `correlation_ids` to bound the result to the runs on screen.
              */
-            group_by?: "use_case_id" | "use_case_type" | "level" | "code" | "date";
+            group_by?: "use_case_id" | "use_case_type" | "level" | "code" | "correlation_id" | "date";
             /**
              * Data source for the stats. "monitoring" (default) aggregates processed events from erp_monitoring_v2 — this counts every event produced throughout the processing tree (fan-out children, post-actions, relation resolutions, etc.). "incoming" counts only the initial inbound events actually received (distinct event_id from erp_incoming_events); only group_by=use_case_id is supported and status/level breakdown is not available for this source (success/error/warning/skipped counts are returned as 0).
              *
@@ -5931,6 +5946,10 @@ declare namespace Components {
              * Timestamp of the most recent error
              */
             last_error_at?: string | null; // date-time
+            /**
+             * Timestamp of the most recent event of ANY level — "is this still moving?", which is a different question from when it last broke. Null when the filter matched nothing.
+             */
+            last_event_at?: string | null; // date-time
             /**
              * Statistics breakdown by requested group_by field
              */

package/docs/integration-toolkit.md

@@ -3244,6 +3244,8 @@ const { data } = await client.getMonitoringStatsV2(
   {
     from_date: '2025-01-01T00:00:00Z',
     to_date: '2025-01-31T23:59:59Z',
+    correlation_id: 'imp_01M3799K98B6TG7GV7Q2DQT554',
+    correlation_ids: ['imp_01M3799K98B6TG7GV7Q2DQT554', 'imp_01M374YPQ0E7ZB0VYJZSK72M4E'],
     use_case_type: 'inbound',
     use_case_types: ['inbound'],
     group_by: 'use_case_id',
@@ -3266,6 +3268,7 @@ const { data } = await client.getMonitoringStatsV2(
   "ack_timeout_count": 0,
   "success_rate": 0,
   "last_error_at": "1970-01-01T00:00:00.000Z",
+  "last_event_at": "1970-01-01T00:00:00.000Z",
   "breakdown": [
     {}
   ]
@@ -9542,9 +9545,11 @@ type MonitoringEventV2 = {
 type GetMonitoringStatsV2Request = {
   from_date?: string // date-time
   to_date?: string // date-time
+  correlation_id?: string
+  correlation_ids?: string[]
   use_case_type?: "inbound" | "outbound" | "file_proxy" | "managed_call" | "secure_proxy"
   use_case_types?: "inbound" | "outbound" | "file_proxy" | "managed_call" | "secure_proxy"[]
-  group_by?: "use_case_id" | "use_case_type" | "level" | "code" | "date"
+  group_by?: "use_case_id" | "use_case_type" | "level" | "code" | "correlation_id" | "date"
   source?: "monitoring" | "incoming"
 }
 ```
@@ -9562,6 +9567,7 @@ type MonitoringStatsV2 = {
   ack_timeout_count?: number
   success_rate?: number
   last_error_at?: string // date-time
+  last_event_at?: string // date-time
   breakdown?: Record<string, unknown>[]
 }
 ```

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@epilot/sdk",
-  "version": "2.20.36",
+  "version": "2.20.37",
   "description": "JavaScript/TypeScript SDK for epilot APIs",
   "type": "module",
   "main": "./dist/index.cjs",