> ## 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 Source > How to configure the Ometria source component to read customer profiles, orders, products, and lists from the Ometria Data API in your Integrate.io ETL pipeline. Use the Ometria source component to read customer profiles, orders, products, and audience lists from the [Ometria](https://ometria.com/) Data API and load them into your Integrate.io ETL pipeline. Ometria is a customer data and marketing platform for retailers. ## Connection setup Create an Ometria connection from **Connections → New connection → Ometria**. | Field | Description | | :------ | :--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Name | Display name for the connection inside Integrate.io. | | API Key | Your Ometria Data API key. Create it in the Ometria dashboard under **Settings → API keys**. The key is account-scoped and is sent as the `X-Ometria-Auth` request header on every call. | The same API key works for both the read endpoints this source uses and the `/v2/push` write endpoint used by generic REST destinations, so a key that already works for a push feed works here unchanged. Click **Test connection** to confirm the key. The test issues a single bounded request against the products endpoint. ## Source objects Select an object in Step 02 of the component editor. Four objects are available in this release: | Object | Endpoint | Incremental load | Contents | | :------- | :---------- | :--------------------- | :---------------------------------------------------------------------------------------------------------------------------------------------------- | | profiles | `/profiles` | Yes (after-only) | Customer profiles with nested date, stats, channel, and identifier fields. | | orders | `/orders` | Yes (after and before) | Customer orders keyed by `timestamp`. | | products | `/products` | No | Product catalog including special-price windows. The product record carries no created or updated timestamp, so incremental filtering is unavailable. | | lists | `/lists` | No | Audience lists and segments with refresh and stats timestamps. | Unsubscribes and contacts are not available in this release. ## Load type Choose how records are loaded on each run: * **Full Load.** Fetches all records for the selected object on every run. This is the only mode for `products` and `lists`. * **Incremental Load.** Available on `profiles` and `orders`. Uses Ometria's server-side date filters to fetch only records that changed since (or, for orders, changed before) a reference date. ### Incremental load settings When **Incremental Load** is selected, three additional fields appear: | Field | Description | | :-------------- | :----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Sync date field | The datetime column to filter on. On `orders`, this is `timestamp`. On `profiles`, pick any of the flattened `dates_*` fields (`dates_account_created`, `dates_first_purchase`, `dates_last_purchase`, and so on). | | Load records | The filter direction. `newer than ( > )` is supported on both objects. `older than ( < )` is supported on `orders` only. | | Reference date | `Last successful run` auto-fills the date from the previous successful job. Use this for scheduled pipelines. `Fixed Date` and `Variable` are useful for one-off backfills. | ### Why profiles is after-only The Ometria profile record has no top-level update timestamp. Every profile datetime lives in the nested `dates` object and is exposed as `dates_last_seen`, `dates_last_purchase`, and so on. The API's `updateSince` parameter is the only filter that reliably includes every profile whose picked date advanced. Offering an "older than" direction against a picked `dates_*` field would silently drop profiles whose picked date is old but were touched recently. The **Load records** dropdown hides the `older than` option on `profiles` for that reason. On `orders` the record carries a real `timestamp` field and the API exposes both `timestampSince` and `timestampBefore`, so both directions are honored. ### Server-side and client-side filtering on profiles For `profiles`, the connector filters in two passes. The server-side call uses `updateSince`, which returns every profile touched since the reference date. The connector then compares each record's picked `dates_*` field against the reference date and drops rows that do not match. This is why picking a narrower field like `dates_last_purchase` returns fewer rows than `updateSince` alone would. ## Field flattening The Ometria API returns nested JSON objects on profiles (`dates`, `stats`, `channels`, `identifiers`). The connector flattens these into individual columns with underscore-separated names, so each value lands in its own column instead of a serialized JSON blob. For example, the nested `dates` object: ```json theme={null} { "dates": { "account_created": "2024-01-15T10:30:00Z", "last_purchase": "2025-06-20T14:12:00Z" } } ``` becomes the columns `dates_account_created` and `dates_last_purchase`. ## Field aliases and `@type` Ometria records carry a top-level `@type` key. When you select all fields, the connector strips the leading `@` and aliases it as `type`. If your source object also has a plain `type` field (the `lists` object does), the alias collides and the field selector reports "must be unique". Rename one of the two aliases, or deselect `@type` since it is a constant per object. ## Pagination and rate limits The connector pages through `/profiles`, `/orders`, and `/products` 250 records at a time using offset pagination, up to 2.5 million records per object per run. To load a history larger than that, window the backfill with the incremental date filter. Ometria's `/lists` endpoint ignores `limit` and `offset` and always returns every list in one response. The connector handles this by requesting the endpoint once per run. The connector throttles to Ometria's documented default of 4 requests per second per account. It retries up to 3 times on HTTP 429 with backoff, capped at 60 seconds per retry. ## Schema After configuring the source properties, the **Schema** section (Step 03) displays the discovered fields with detected data types. Typical fields on `profiles`: | Field | Type | Notes | | :---------------------- | :------- | :---------------------------------------- | | id | string | Ometria profile ID. | | email | string | Primary email address. | | dates\_account\_created | datetime | Flattened from the nested `dates` object. | | dates\_last\_purchase | datetime | Flattened from the nested `dates` object. | | stats\_revenue | float | Flattened from the nested `stats` object. | | type | string | Aliased from Ometria's `@type` key. | Use the field selector to choose columns, rename aliases, and override detected types. ## Best practices * **Use `Last successful run` on `orders` and `profiles`** for scheduled pipelines, after seeding the destination with one full load. This keeps recurring syncs cheap. * **Pick the right `dates_*` field for profiles.** `dates_account_created` catches new customers only. `dates_last_purchase` catches repeat buyers. If in doubt, use `dates_last_seen` for the broadest coverage. * **Window large backfills.** The 2.5 million record cap per object per run is enforced silently. For accounts with more history, run two or more incremental loads with `Fixed Date` at chosen midpoints. * **Restart clusters after changing the connection.** Connection settings are applied when a cluster starts. Jobs on an already-running cluster keep the old settings until the cluster is restarted. ## FAQ **Q: The `products` object has no incremental load option. Why?** Ometria's product record carries no created-at or updated-at field. The only datetimes on a product are the special-price window (`special_price_dt_from`, `special_price_dt_to`), which describe a promotion, not the record's own history. Without a stable watermark, incremental filtering would either miss updates or double-count them, so the option is not offered. **Q: Why is `older than ( < )` disabled on profiles?** See [Why profiles is after-only](#why-profiles-is-after-only). Ometria's `updateBefore` filter combined with a picked `dates_*` field would silently drop profiles that were touched recently but whose picked date is old. **Q: Can I connect Ometria as a destination?** This release ships the source only. Ometria writes are still handled by generic REST destination pipelines using the same API key against Ometria's `/v2/push` endpoint. **Q: Is the API key visible after I save it?** No. The key is write-only: it is stored encrypted and never returned to the browser. The connection form shows a masked placeholder with a change link. ## Related