> ## Documentation Index > Fetch the complete documentation index at: https://www.integrate.io/docs/llms.txt > Use this file to discover all available pages before exploring further. # ETL: Ometria Destination > Push contacts, orders, and custom events to the Ometria /v2/push endpoint from an Integrate.io ETL pipeline. Use the Ometria destination to write records from your ETL pipeline to [Ometria](https://ometria.com/), a customer data and marketing platform for retailers. The component posts records to Ometria's `/v2/push` endpoint in batches. One component writes one object type: contacts, orders, or custom events. ## When to use it Use this destination to sync customer, order, or event data from your warehouse or other systems into Ometria for segmentation and campaigns. Typical uses: * Load customer profiles from a warehouse table so Ometria profiles stay current. * Push order history so revenue-based segments and lifecycle stages update after each run. * Send custom events (for example, subscription renewals or support interactions) that Ometria does not capture natively. For reading profiles, orders, products, and lists back out of Ometria, use the [Ometria source](/docs/etl/using-components-ometria-source) instead. ## Connection Select an existing Ometria connection or create a new one. The destination uses the same connection type as the source: a single API key sent as the `X-Ometria-Auth` header. A key that already works for the source works here unchanged. See [Connecting to Ometria](/docs/etl/using-components-ometria-source#connection-setup) for how to create the connection. ## Destination properties * **Object** - the Ometria object type this component writes: `contact` (default), `order`, or `custom_event`. The object determines which fields you can map (see [Field mapping](#field-mapping)). * **Merge mode** - when enabled, the component sends each record as a partial update. Ometria updates only the fields present in the record. When disabled, fields you do not map are overwritten to null in Ometria. Enable merge mode when your pipeline carries a subset of the fields a record already has in Ometria. ### Advanced options * **Requests per second** - throttle applied to the push endpoint. Default is `8`, matching Ometria's documented push rate limit, which is double the read-endpoint limit. Maximum is `100`. The component posts from a single process, so this value is the real request rate against Ometria. * **Records per batch** - number of records sent per push request. Default and maximum are both `100`, the cap Ometria enforces per request. * **Maximum failed records** - the job fails once cumulative failed records exceed this value. Default is `0` (fail on the first failure). Set to `-1` for unlimited failures. ## Field mapping Each object type has a fixed payload schema. Map input fields to Ometria fields by exact name. The component raises a build-time error if a required field is missing from the mapping or a mapped field is not supported for the selected object. ### Contact | Requirement | Fields | | :-------------------------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | Required | `id` | | At least one identity field | `email`, `customer_id`, `phone_number` | | Optional | `firstname`, `lastname`, `prefix`, `middlename`, `gender`, `date_of_birth`, `postcode`, `city`, `country_id`, `marketing_optin`, `timestamp_acquired`, `timestamp_subscribed`, `timestamp_unsubscribed`, `timezone`, `preferred_lang` | Ometria uses the identity fields to cluster contact records into a profile. Without one, the record cannot be matched to a customer. ### Order | Requirement | Fields | | :---------- | :-------------------------------------------------------------------------------------------------------------------- | | Required | `id`, `timestamp`, `grand_total`, `currency` | | Optional | `subtotal`, `discount_total`, `shipping_total`, `tax_total`, `status`, `channel`, `store_id`, `customer`, `lineitems` | Orders need no identity field. The customer travels inside the nested `customer` object. The `customer` and `lineitems` fields are JSON fields: the input column must contain a JSON document, not plain text. `customer` is an object and `lineitems` is an array of line-item objects. The component embeds these values as structure in the push payload. Ometria rejects a plain-text value in these columns. ```json theme={null} { "customer": {"id": "cust-1042", "email": "ada@example.com"}, "lineitems": [ {"product_id": "sku-981", "quantity": 2, "unit_price": 19.99} ] } ``` ### Custom event | Requirement | Fields | | :-------------------------- | :------------------------------------- | | Required | `id`, `timestamp` | | At least one identity field | `email`, `customer_id`, `phone_number` | | Optional | `profile_id`, `properties` | `properties` is a JSON field carrying the event's attributes as a JSON object. ### The `id` field `id` is Ometria's stable identifier for the record. It must not contain PII such as an email address or name. Use an internal key like a database primary key or order number. ### Custom fields Contact custom fields you have defined in Ometria are also mappable. When a mapped column is not in the documented set, the component checks it against your account's custom fields before rejecting it. If the component cannot fetch the custom-field list (for example, during an Ometria outage), it allows the column with a warning rather than blocking the build. Ometria rejects a genuinely unknown field itself, and that record counts toward **Maximum failed records**. ## Error tracking Enable **Track failed records** to write a CSV of records that failed to send, one row per failure, to a cloud storage connection and path you choose. Configure the storage connection and output path on the component. Ometria's push endpoint accepts batches asynchronously: it queues records for processing rather than confirming each one. HTTP-level failures (4xx and 5xx responses) are tracked in the errors CSV. Per-record processing outcomes after Ometria accepts a batch are not visible to the job. Check Ometria's own import reporting for post-acceptance validation issues. ## Example: syncing contacts from a warehouse query A pipeline that reads recently updated customers from a warehouse and upserts them as Ometria contacts: ```sql theme={null} -- Source query SELECT customer_key AS "id", email AS "email", first_name AS "firstname", last_name AS "lastname", city AS "city", accepts_marketing AS "marketing_optin" FROM customers WHERE updated_at >= DATEADD(day, -1, CURRENT_TIMESTAMP()) ``` Set **Object** to `contact` and map each aliased column to the Ometria field of the same name. `id` satisfies the required field and `email` satisfies the identity requirement. Enable **Merge mode** so fields not in the query (for example `phone_number`) keep their current values in Ometria. Enable **Track failed records** to an S3 bucket so you can review rejected rows after the run. ## Related