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 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:

{
  "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. 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

REST API Source

Trustpilot Source

SugarCRM Source

Defining Connections

Sources Overview