@epilot/sdk 2.18.19 → 2.18.21

package/dist/{integration-toolkit.d-CoMi10QU.d.cts → 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.ts → 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
      *