configuring-imports

Configuring Imports

An import is the data destination in a Celigo integration. It takes records from an upstream step and writes them to an external system -- REST APIs, databases, ERPs, file servers, or AI models. Every import has one adaptor type and, apart from the connection-less kinds in Minimum Required Fields, is bound to exactly one connection.

Imports handle six concerns:

• Field mapping -- transforming source fields into the destination system's expected format (including value resolution via static maps and lookup tables). Uses Mapper 2.0 (mappings[] array) by default, including NetSuiteHTTPImport. SalesforceImport and WrapperImport support only Mapper 1.0 (mapping.fields[] / mapping.lists[]), and NetSuiteDistributedImport uses its own Mapper 1.0 dialect at netsuite_da.mapping
• Operation logic -- create, update, upsert, delete, attach/detach
• Hooks -- JavaScript pre/post processing at various pipeline stages (preMap, postMap, postSubmit). File-based imports that generate files from records also support postAggregate; an HTTP records import refuses it (422 invalid_hook)
• One-to-many -- fan out a child array already on the input record. Set oneToMany: true and pathToMany to that path (e.g., "lineItems") when one source record should create one import operation per child. After fan-out the child is record ({{record.sku}}) and the parent (without the array) is record._PARENT ({{record._PARENT.id}}). Leave pathToMany blank when the arriving record is itself an array (grouped rows from a groupByFields export or a file group) -- each element then becomes the record, with no _PARENT. A path on an array record processes zero children and still reports success; a blank path on an object record fails with oneToMany_error. oneToMany doesn't batch by itself: templates see batch_of_records only when http.batchSize is above 1 (the default varies by API) or an RDBMS query runs per_page
• Response mapping -- extract fields from the import's API response back into the record for downstream steps. Configured on the flow's pageProcessors[] entry, but planned when building the import. Extracts read the response envelope: id (the destination-assigned record ID), statusCode, ignored, errors, _headers, dataURI (the record's link, when the import sets dataURITemplate), and _json (the response body after any response transform, whose top-level fields are also flattened onto the envelope). Use id for a created record's ID and _json.fieldName for other response fields (e.g., _json.output.1.content.0.text for OpenAI responses) -- _json.id works only when the body itself has a top-level id. Flow test runs never send imports, so id is empty there. Response mapping uses Transformation 1.0 syntax (extract/generate pairs), not the newer expression-based transforms
• postResponseMap hook -- JavaScript processing after response mapping merges the response back into the record. Configured on the flow's pageProcessors[] entry, but planned when building the import. Use to transform or enrich the merged record before downstream steps

Imports are used across flows, APIs, and tools.

Import Execution Pipeline