v4

latestOpenAPI 3.0.32026-08-0161180264.4 KB

erp-imports

abortErpImport

Ask a running import to stop. Valid while the job is VALIDATING or PROCESSING; any other status returns 409. The stop is cooperative: the job passes through CANCELLING and typically reaches CANCELLED within seconds. Rows already published to the platform are kept: this is a stop, not a rollback. Aborting during VALIDATING has published nothing, so it is always clean; aborting during PROCESSING leaves a partial import, and the rows that landed are visible in monitoring under the job's correlation_id.

post/v2/erp/imports/{importId}:abort

Path parameters

importIdstring required

Response

The stop was recorded. The job is still finishing up — poll GET /v2/erp/imports/{importId} to observe CANCELLED.

import_idstring required

imp_{ULID} — time-ordered, also used as the job's correlation_id.

org_idstring required

created_bystring

integration_idstring required

use_case_slugstring

The inbound use case whose mapping drives both phases.

format'csv' | 'xlsx' required

PENDING → VALIDATING → READY → PROCESSING → IMPORTED, with FAILED reachable from any working status, and CANCELLING → CANCELLED reachable from VALIDATING or PROCESSING via :abort. IMPORTED, FAILED and CANCELLED are terminal and final. IMPORTED means every row was handed to the platform, not that the platform finished — per-row outcomes live in monitoring, filtered by correlation_id. A file that fails validation is FAILED with error.type = VALIDATION_BLOCKED. READY is legitimately idle for as long as the user takes to confirm, so it carries no running work and never goes stale. CANCELLING is transient and cooperative: the abort has been recorded but the worker only notices at its next batch boundary. Rows already published stay published — a stop is not a rollback.

correlation_idstring

Scopes this run in monitoring. Always equal to import_id.

activity_idstring

created_atstring date-time required

updated_atstring date-time required