Skip to content

Glossary

This glossary defines the terms used throughout EZY Integrations documentation. Terms appear in alphabetical order.


API Key A secret token issued per tenant that authenticates machine-to-machine requests to the EZY Integrations API. API keys are scoped to a single tenant and cannot access another tenant’s data. See API Keys.


Canonical Entity The neutral, intermediate data format that all connectors share. When a source connector extracts raw data, it converts that data into a canonical entity. The target connector reads the canonical entity and produces the payload the target system expects. This design means no source connector talks directly to any target connector — they all speak the same intermediate language. See Architecture Overview.


Connection Profile A saved, encrypted set of credentials for one instance of a source or target system. For example, a connection profile for SAP Business One contains the database host, username, and password. A single connection profile can be reused across multiple instances (jobs). See your connector’s page under Connectors.


Connector The component responsible for communicating with one specific external system — for example, the Shopify connector or the SAP Business One connector. Each connector knows how to extract data from or write data to its system. See Connectors.


Cursor A stored value — typically a timestamp — that marks where the last incremental extraction ended. On the next run, the Ingest stage reads the cursor and fetches only records modified after that point. The cursor is advanced at the end of each successful Finalize stage. Configured in the extraction block of the mapping configuration. See Mapping Configuration.


Dead Letter Queue (DLQ) The holding area for records that have failed all automatic retry attempts. A record in the DLQ stays there until you either replay it (re-inject it into the pipeline after fixing the root cause) or discard it. The DLQ shows the error category and message for each entry. See DLQ and Replay.


Entity Type The kind of data record being moved — for example, item, order, customer, or salesquotation. Each mapping configuration targets a specific entity type. The entity type determines which extractor, normalizer, and target fields are available. See Entity Types.


Execute (stage) The fourth pipeline stage. The transformed payload is sent to the target system. The connector resolves whether to create a new record or update an existing one based on its ID mapping table. Target rejections (invalid field values, rate limits, authentication errors) surface here. See Pipeline Stages.


Finalize (stage) The fifth and final pipeline stage. The run outcome is recorded, sync cursors are updated, and per-entity status is written to the run history. A Finalize failure is rare and usually indicates a platform-level issue. See Pipeline Stages.


Ingest (stage) The first pipeline stage. The source connector reads records from the source system using the credentials in the connection profile and the extraction rules in the mapping configuration. If incremental sync is configured, only records modified after the cursor are fetched. See Pipeline Stages.


Instance The EZY Integrations term for a job — the configuration that links a source connection profile to a target connection profile and holds one or more mapping configurations. An instance defines what to sync and between which systems; a schedule or manual trigger defines when to sync. See Jobs Overview.


Mapping Configuration A JSON document attached to an instance that controls how data is extracted from the source, converted to the canonical format, and shaped into the target payload. One mapping configuration covers one entity type. An instance can have multiple mapping configurations for different entity types. See Mapping Configuration.


Normalize (stage) The second pipeline stage. Raw source data is converted into the canonical entity format. Required fields are validated and type conversions are applied. A record that fails normalization (for example, a required field is missing) is sent to the DLQ after retries. See Pipeline Stages.


Output Writer The component that delivers data to a target system that is not an API — for example, writing to a CSV or XML file on disk (Flat File) or posting to an arbitrary HTTP endpoint (Generic API). See Output Writers.


Pipeline The end-to-end process that moves data from a source system to a target system through five sequential stages: Ingest, Normalize, Transform, Execute, and Finalize. See Architecture Overview.


Run One execution of a job instance. A run processes all pending records for the instance’s entity types and produces a status of Success, Partial Success, or Failed. Run details are visible in Run History.


Schedule A timer that triggers a job run automatically at a defined interval using a cron expression. Schedules are attached to a specific instance. Multiple schedules can target the same instance. See Schedules.


Sync Log The record of a single run, including start time, end time, status, record counts (total, success, failed, skipped), and per-entity error details. Sync Logs are the primary tool for monitoring run history. See Run History.


Tenant An isolated workspace in EZY Integrations for one customer or environment. All connection profiles, instances, mapping configurations, runs, and DLQ entries belong to a tenant. Users are assigned to one or more tenants. See Tenant Onboarding.


Transform (stage) The third pipeline stage. The canonical entity is shaped into the exact payload the target system expects. Field mappings, value transformers, static fields, and conditional tags from the mapping configuration are applied here. See Pipeline Stages.


Transformer (Value Transformer) A named function applied to a field value during the Transform stage — for example, a date formatter, a string joiner, or a decimal converter. Transformers are configured in the transformation block of the mapping configuration. See Value Transformers.


Writeback An optional post-execution step where the target system’s response (typically an assigned ID) is pushed back to the source system. For example, after a sales order is written to SAP Business One, the SAP document number can be stored back in the originating EZY Portal record. Not all connectors support writeback.