@epilot/sdk 2.18.20 → 2.18.22

package/dist/{integration-toolkit.d-CoMi10QU.d.ts → integration-toolkit.d-Dj-tULW0.d.cts}

@@ -1347,6 +1347,12 @@ declare namespace Components {
              * Return a sample of the file's first rows in `preview`. Only controls whether the sample comes BACK — the head is read either way, because that read is how an unreadable file gets refused.
              */
             include_preview?: boolean;
+            /**
+             * Repoint an EXISTING import at this file instead of registering a new one — same row, same id, so iterating on which file to import leaves one entry in the history rather than one per attempt.
+             * Only a PENDING import may be repointed; any other status returns 409 with code `IMPORT_NOT_REPLACEABLE`. Past the first check the previous verdict is what tells the user what to fix, and a job that reached the execute phase may already have published rows under `correlation_id`.
+             * An id that names nothing returns 404. It never falls back to registering a new import: a stale id must fail loudly rather than quietly produce a second one.
+             */
+            import_id?: string;
         }
         export interface CreateErpImportResponse {
             job: ErpImportJob;
@@ -2659,9 +2665,10 @@ declare namespace Components {
         }
         /**
          * Upload-side settings for a file_proxy use case with `direction: upload`.
-         * Everything about WHAT is sent lives on the outbound mapping
-         * (see `FileProxyDeliveryConfig`); this object only governs HOW the transfer is bounded
-         * and judged.
+         * The surrounding file_proxy configuration owns WHAT and HOW to send: `fan_out`,
+         * `file_source`, `params_mapping`, lookups, constants, auth, and steps. This nested object
+         * governs upload-specific limits and how the final external response is judged. The
+         * outbound mapping remains a pure pointer to the recipe (see `FileProxyDeliveryConfig`).
          *
          */
         export interface FileProxyUploadConfig {
@@ -2673,10 +2680,10 @@ declare namespace Components {
              */
             max_file_bytes?: number;
             /**
-             * Maximum delivery attempts per item before the delivery is marked failed and the
-             * message is dead-lettered. Attempts are spaced by an exponential, jittered backoff
-             * spanning roughly 16 hours over the default 8 attempts, so an ERP maintenance window
-             * does not exhaust them.
+             * Maximum delivery attempts per item before the delivery is marked failed. Attempts
+             * are spaced by an exponential, jittered backoff. The default 8 attempts schedule at
+             * most 7 delays, totaling about 7 hours 40 minutes before jitter, so a normal ERP
+             * maintenance window does not immediately exhaust them.
              *
              * Lives here rather than on the outbound delivery because how hard to retry is a
              * property of the transport — the same judgement as `max_file_bytes` — and the outbound
@@ -2853,9 +2860,10 @@ declare namespace Components {
             direction?: "download" | "upload";
             upload?: /**
              * Upload-side settings for a file_proxy use case with `direction: upload`.
-             * Everything about WHAT is sent lives on the outbound mapping
-             * (see `FileProxyDeliveryConfig`); this object only governs HOW the transfer is bounded
-             * and judged.
+             * The surrounding file_proxy configuration owns WHAT and HOW to send: `fan_out`,
+             * `file_source`, `params_mapping`, lookups, constants, auth, and steps. This nested object
+             * governs upload-specific limits and how the final external response is judged. The
+             * outbound mapping remains a pure pointer to the recipe (see `FileProxyDeliveryConfig`).
              *
              */
             FileProxyUploadConfig;
@@ -5345,7 +5353,7 @@ declare namespace Components {
          */
         export interface OutboundMapping {
             /**
-             * Unique identifier for this mapping
+             * Unique identifier for this mapping; generated by the API when omitted
              */
             id?: string; // uuid
             /**
@@ -7474,9 +7482,12 @@ declare namespace Paths {
     namespace CreateErpImport {
         export type RequestBody = /* Register an already-uploaded file as an import. The use case is chosen later, via `:validate` — upload and interpretation are separate decisions. */ Components.Schemas.CreateErpImportRequest;
         namespace Responses {
+            export type $200 = Components.Schemas.CreateErpImportResponse;
             export type $201 = Components.Schemas.CreateErpImportResponse;
             export type $400 = Components.Responses.BadRequest;
             export type $403 = Components.Responses.Forbidden;
+            export type $404 = Components.Responses.NotFound;
+            export type $409 = Components.Responses.Conflict;
             export type $500 = Components.Responses.InternalServerError;
         }
     }
@@ -9358,12 +9369,13 @@ interface OperationMethods {
    * createErpImport - createErpImport
    * 
    * Register an already-uploaded file (S3 ref) as a pricing-file import job. Returns the job and a file preview. Nothing runs yet: no use case is chosen and no validation starts here. Optionally rank candidates with POST /v2/erp/imports/{importId}:suggest-use-cases, then start validation with POST /v2/erp/imports/{importId}:validate.
+   * Pass `import_id` to repoint an existing PENDING import at a different file instead, keeping its id and its place in the history.
    */
   'createErpImport'(
     parameters?: Parameters<UnknownParamsObject> | null,
     data?: Paths.CreateErpImport.RequestBody,
     config?: AxiosRequestConfig  
-  ): OperationResponse<Paths.CreateErpImport.Responses.$201>
+  ): OperationResponse<Paths.CreateErpImport.Responses.$200 | Paths.CreateErpImport.Responses.$201>
   /**
    * getErpImport - getErpImport
    * 
@@ -10305,12 +10317,13 @@ interface PathsDictionary {
      * createErpImport - createErpImport
      * 
      * Register an already-uploaded file (S3 ref) as a pricing-file import job. Returns the job and a file preview. Nothing runs yet: no use case is chosen and no validation starts here. Optionally rank candidates with POST /v2/erp/imports/{importId}:suggest-use-cases, then start validation with POST /v2/erp/imports/{importId}:validate.
+     * Pass `import_id` to repoint an existing PENDING import at a different file instead, keeping its id and its place in the history.
      */
     'post'(
       parameters?: Parameters<UnknownParamsObject> | null,
       data?: Paths.CreateErpImport.RequestBody,
       config?: AxiosRequestConfig  
-    ): OperationResponse<Paths.CreateErpImport.Responses.$201>
+    ): OperationResponse<Paths.CreateErpImport.Responses.$200 | Paths.CreateErpImport.Responses.$201>
     /**
      * listErpImports - listErpImports
      * 

package/dist/{integration-toolkit.d-CoMi10QU.d.cts → integration-toolkit.d-Dj-tULW0.d.ts}

@@ -1347,6 +1347,12 @@ declare namespace Components {
              * Return a sample of the file's first rows in `preview`. Only controls whether the sample comes BACK — the head is read either way, because that read is how an unreadable file gets refused.
              */
             include_preview?: boolean;
+            /**
+             * Repoint an EXISTING import at this file instead of registering a new one — same row, same id, so iterating on which file to import leaves one entry in the history rather than one per attempt.
+             * Only a PENDING import may be repointed; any other status returns 409 with code `IMPORT_NOT_REPLACEABLE`. Past the first check the previous verdict is what tells the user what to fix, and a job that reached the execute phase may already have published rows under `correlation_id`.
+             * An id that names nothing returns 404. It never falls back to registering a new import: a stale id must fail loudly rather than quietly produce a second one.
+             */
+            import_id?: string;
         }
         export interface CreateErpImportResponse {
             job: ErpImportJob;
@@ -2659,9 +2665,10 @@ declare namespace Components {
         }
         /**
          * Upload-side settings for a file_proxy use case with `direction: upload`.
-         * Everything about WHAT is sent lives on the outbound mapping
-         * (see `FileProxyDeliveryConfig`); this object only governs HOW the transfer is bounded
-         * and judged.
+         * The surrounding file_proxy configuration owns WHAT and HOW to send: `fan_out`,
+         * `file_source`, `params_mapping`, lookups, constants, auth, and steps. This nested object
+         * governs upload-specific limits and how the final external response is judged. The
+         * outbound mapping remains a pure pointer to the recipe (see `FileProxyDeliveryConfig`).
          *
          */
         export interface FileProxyUploadConfig {
@@ -2673,10 +2680,10 @@ declare namespace Components {
              */
             max_file_bytes?: number;
             /**
-             * Maximum delivery attempts per item before the delivery is marked failed and the
-             * message is dead-lettered. Attempts are spaced by an exponential, jittered backoff
-             * spanning roughly 16 hours over the default 8 attempts, so an ERP maintenance window
-             * does not exhaust them.
+             * Maximum delivery attempts per item before the delivery is marked failed. Attempts
+             * are spaced by an exponential, jittered backoff. The default 8 attempts schedule at
+             * most 7 delays, totaling about 7 hours 40 minutes before jitter, so a normal ERP
+             * maintenance window does not immediately exhaust them.
              *
              * Lives here rather than on the outbound delivery because how hard to retry is a
              * property of the transport — the same judgement as `max_file_bytes` — and the outbound
@@ -2853,9 +2860,10 @@ declare namespace Components {
             direction?: "download" | "upload";
             upload?: /**
              * Upload-side settings for a file_proxy use case with `direction: upload`.
-             * Everything about WHAT is sent lives on the outbound mapping
-             * (see `FileProxyDeliveryConfig`); this object only governs HOW the transfer is bounded
-             * and judged.
+             * The surrounding file_proxy configuration owns WHAT and HOW to send: `fan_out`,
+             * `file_source`, `params_mapping`, lookups, constants, auth, and steps. This nested object
+             * governs upload-specific limits and how the final external response is judged. The
+             * outbound mapping remains a pure pointer to the recipe (see `FileProxyDeliveryConfig`).
              *
              */
             FileProxyUploadConfig;
@@ -5345,7 +5353,7 @@ declare namespace Components {
          */
         export interface OutboundMapping {
             /**
-             * Unique identifier for this mapping
+             * Unique identifier for this mapping; generated by the API when omitted
              */
             id?: string; // uuid
             /**
@@ -7474,9 +7482,12 @@ declare namespace Paths {
     namespace CreateErpImport {
         export type RequestBody = /* Register an already-uploaded file as an import. The use case is chosen later, via `:validate` — upload and interpretation are separate decisions. */ Components.Schemas.CreateErpImportRequest;
         namespace Responses {
+            export type $200 = Components.Schemas.CreateErpImportResponse;
             export type $201 = Components.Schemas.CreateErpImportResponse;
             export type $400 = Components.Responses.BadRequest;
             export type $403 = Components.Responses.Forbidden;
+            export type $404 = Components.Responses.NotFound;
+            export type $409 = Components.Responses.Conflict;
             export type $500 = Components.Responses.InternalServerError;
         }
     }
@@ -9358,12 +9369,13 @@ interface OperationMethods {
    * createErpImport - createErpImport
    * 
    * Register an already-uploaded file (S3 ref) as a pricing-file import job. Returns the job and a file preview. Nothing runs yet: no use case is chosen and no validation starts here. Optionally rank candidates with POST /v2/erp/imports/{importId}:suggest-use-cases, then start validation with POST /v2/erp/imports/{importId}:validate.
+   * Pass `import_id` to repoint an existing PENDING import at a different file instead, keeping its id and its place in the history.
    */
   'createErpImport'(
     parameters?: Parameters<UnknownParamsObject> | null,
     data?: Paths.CreateErpImport.RequestBody,
     config?: AxiosRequestConfig  
-  ): OperationResponse<Paths.CreateErpImport.Responses.$201>
+  ): OperationResponse<Paths.CreateErpImport.Responses.$200 | Paths.CreateErpImport.Responses.$201>
   /**
    * getErpImport - getErpImport
    * 
@@ -10305,12 +10317,13 @@ interface PathsDictionary {
      * createErpImport - createErpImport
      * 
      * Register an already-uploaded file (S3 ref) as a pricing-file import job. Returns the job and a file preview. Nothing runs yet: no use case is chosen and no validation starts here. Optionally rank candidates with POST /v2/erp/imports/{importId}:suggest-use-cases, then start validation with POST /v2/erp/imports/{importId}:validate.
+     * Pass `import_id` to repoint an existing PENDING import at a different file instead, keeping its id and its place in the history.
      */
     'post'(
       parameters?: Parameters<UnknownParamsObject> | null,
       data?: Paths.CreateErpImport.RequestBody,
       config?: AxiosRequestConfig  
-    ): OperationResponse<Paths.CreateErpImport.Responses.$201>
+    ): OperationResponse<Paths.CreateErpImport.Responses.$200 | Paths.CreateErpImport.Responses.$201>
     /**
      * listErpImports - listErpImports
      * 

package/docs/ai-agents.md

@@ -73,6 +73,8 @@ const { data } = await aiAgentsClient.createAgent(...)
 - [`PendingAction`](#pendingaction)
 - [`ExecutionError`](#executionerror)
 - [`ExecutionMetrics`](#executionmetrics)
+- [`AgentExecutionEventStatus`](#agentexecutioneventstatus)
+- [`AgentExecutionEvent`](#agentexecutionevent)
 - [`ToolPreview`](#toolpreview)
 - [`PreviewActionType`](#previewactiontype)
 - [`PreviewEntity`](#previewentity)
@@ -105,7 +107,7 @@ const { data } = await aiAgentsClient.createAgent(...)
 
 ### `createAgent`
 
-Create Agent definition
+Creates a new custom agent. System skills cannot be created via this endpoint.
 
 `POST /v1/agents`
 
@@ -215,7 +217,8 @@ const { data } = await client.createAgent(
 
 ### `listAgents`
 
-List all agent configurations
+Lists agents from both system skills and custom agents.
+Use query parameters to filter by source, availability, or entity schema.
 
 `GET /v1/agents`
 
@@ -292,7 +295,9 @@ const { data } = await client.listAgents({
 
 ### `getAgentById`
 
-Get the agent configuration by ID
+Retrieves an agent by ID. Supports both:
+- System skill IDs (prefixed): "skill:email-categorizer"
+- Custom agent IDs (UUID): "0336a235-9417-4dd8-894c-fe81285bba75"
 
 `GET /v1/agents/{agent_id}`
 
@@ -362,7 +367,7 @@ const { data } = await client.getAgentById({
 
 ### `updateAgentById`
 
-Update the agent configuration by ID
+Updates a custom agent. System skills cannot be updated via this endpoint.
 
 `PUT /v1/agents/{agent_id}`
 
@@ -474,7 +479,7 @@ const { data } = await client.updateAgentById(
 
 ### `deleteAgentById`
 
-Delete the agent configuration by ID
+Deletes a custom agent. System skills cannot be deleted via this endpoint.
 
 `DELETE /v1/agents/{agent_id}`
 
@@ -488,7 +493,10 @@ const { data } = await client.deleteAgentById({
 
 ### `executeAgent`
 
-Execute an agent
+Executes an agent (system skill or custom agent).
+Supports both:
+- System skill IDs (prefixed): "skill:email-categorizer"
+- Custom agent IDs (UUID): "0336a235-9417-4dd8-894c-fe81285bba75"
 
 `POST /v1/agents/{agent_id}/execute`
 
@@ -624,7 +632,9 @@ const { data } = await client.executeAgent(
 
 ### `executeAgentStream`
 
-Execute an agent with streaming response
+Executes an agent with real-time streaming of tokens and tool events.
+Returns Server-Sent Events (SSE) stream with token-by-token output,
+tool call progress, and completion status.
 
 `POST /v1/agents/{agent_id}/execute/stream`
 
@@ -1007,7 +1017,7 @@ const { data } = await client.cancelExecution({
 
 ### `getExecutionTrace`
 
-Get execution trace/iterations
+Returns the step-by-step reasoning and tool calls for ReAct mode executions. Returns empty iterations array for direct mode executions.
 
 `GET /v1/executions/{execution_id}/trace`
 
@@ -1113,7 +1123,7 @@ const { data } = await client.putExecutionFeedback(
 
 ### `approveExecution`
 
-Approve pending action
+Approves a pending tool action when execution is in waiting_approval status
 
 `POST /v1/executions/{execution_id}/approve`
 
@@ -1125,8 +1135,7 @@ const { data } = await client.approveExecution(
   {
     reason: 'string',
     approved_action_ids: ['string'],
-    rejected_action_ids: ['string'],
-    share_scope: 'primary_only'
+    rejected_action_ids: ['string']
   },
 )
 ```
@@ -1234,7 +1243,7 @@ const { data } = await client.approveExecution(
 
 ### `rejectExecution`
 
-Reject pending action
+Rejects a pending tool action when execution is in waiting_approval status
 
 `POST /v1/executions/{execution_id}/reject`
 
@@ -1352,7 +1361,7 @@ const { data } = await client.rejectExecution(
 
 ### `streamExecution`
 
-Reconnect to execution stream
+Reconnects to an execution's event stream after approval. Replays missed events from event log and continues streaming if execution is still running.
 
 `GET /v1/executions/{execution_id}/stream`
 
@@ -1367,7 +1376,7 @@ const { data } = await client.streamExecution({
 
 ### `chat`
 
-Streaming chat with AI agent
+Initiates a streaming chat session with an AI agent. Supports server-side conversation memory via conversationId or client-provided history via clientHistory.
 
 `POST /v1/chat`
 
@@ -1409,7 +1418,7 @@ const { data } = await client.chat(
 
 ### `listConversations`
 
-List conversations
+Lists conversations for the authenticated user, sorted by most recent.
 
 `GET /v1/conversations`
 
@@ -1453,7 +1462,7 @@ const { data } = await client.listConversations({
 
 ### `getConversation`
 
-Get conversation with messages
+Retrieves a conversation and its message history.
 
 `GET /v1/conversations/{conversation_id}`
 
@@ -1517,7 +1526,7 @@ const { data } = await client.getConversation({
 
 ### `deleteConversation`
 
-Delete conversation
+Deletes a conversation and all its messages.
 
 `DELETE /v1/conversations/{conversation_id}`
 
@@ -1531,7 +1540,7 @@ const { data } = await client.deleteConversation({
 
 ### `submitConversationFeedback`
 
-Submit feedback for an assistant turn
+Records a thumbs up/down (with optional comment) for the assistant turn identified by its Langfuse trace id. The rating is persisted on the message and mirrored to Langfuse as a trace score.
 
 `POST /v1/conversations/{conversation_id}/feedback`
 
@@ -1827,7 +1836,6 @@ type ApproveExecutionRequest = {
   reason?: string
   approved_action_ids?: string[]
   rejected_action_ids?: string[]
-  share_scope?: "primary_only" | "primary_and_relations"
 }
 ```
 
@@ -2072,6 +2080,55 @@ type ExecutionMetrics = {
 }
 ```
 
+### `AgentExecutionEventStatus`
+
+Lifecycle status carried on an agent execution event.
+
+Deliberately narrower than `ExecutionStatus`, which is the stored status of
+the execution row: `pending` and `running` both surface as `started`, and
+`cancelled` surfaces as `failed`. Consumers must not assume the two
+vocabularies are interchang
+
+```ts
+type AgentExecutionEventStatus = "started" | "completed" | "failed" | "approval_required"
+```
+
+### `AgentExecutionEvent`
+
+Detail payload of the `agent-execution-status-update` event, published on
+the AI Agents event bus with source `ai-agents`.
+
+`execution_context` and `input` are present on every status, so a consumer
+can tell whether an execution is theirs, and what it belonged to, from the
+terminal event alone — wit
+
+```ts
+type AgentExecutionEvent = {
+  executionId: string
+  agentId: string
+  orgId: string
+  userId?: string
+  execution_status: "started" | "completed" | "failed" | "approval_required"
+  execution_context?: "flows" | "copilot" | "api"
+  input?: Record<string, unknown>
+  output?: Record<string, unknown>
+  error?: {
+    message?: string
+    code?: string
+    stack?: string
+  }
+  duration?: number
+  iterations?: number
+  iteration?: number
+  message?: string
+  toolCalls?: Array<{
+    name?: string
+    args?: Record<string, unknown>
+  }>
+  timestamp?: string // date-time
+}
+```
+
 ### `ToolPreview`
 
 Structured preview data for approval UI. Provides a generic format that any tool can populate.