---
updatedAt: 2025-05-14T00:15:06.000Z
agentTools:
projectIndex: https://docs.ometria.com/llms.txt
---
# Contacts
We recommend reading the following pages before integrating with Ometria:
* [Ometria API introduction](https://ometria-api-reference.readme.io/docs/ometria-data-api-introduction)
* [Ometria data architecture](https://ometria-api-reference.readme.io/docs/ometria-data-architecture)
The easiest and quickest way to add contact data to Ometria is to use the [Push endpoint](https://ometria-api-reference.readme.io/docs/push-endpoint); the **contacts endpoint** should only be used for specific cases.
The contacts endpoint provides methods to:
* list the different collections (which can be viewed as sources of data),
* retrieve lists of contacts,
* retrieve **one** individual contact, and;
* create a new contact.
A **contact** is a child object of a **profile** - it represents the contact listing which makes up a customer profile.
> 📘 If you need to retrieve the profile, use the [profiles endpoint](https://ometria-api-reference.readme.io/reference#profiles).
# Contacts and profiles
Records about people (customers / contacts / leads / subscribers) are supplied as 'contacts' records.
Contacts are organised into **collections**. For example, you might have a **customers** collection (customer records from your eCommerce platform) and a **subscribers** collection (contact records from your ESP).
Each record in a collection is uniquely identified by a string ID.
In cases where the same person exists in each list (or even more than once in each collection) Ometria will attempt to merge these contacts records into a single 'profiles' record (based on `customer_id` and then `email`).
**This means a single profile record can have several contacts records attached.**
You can't write profile records directly as they are automatically clustered by Ometria.
> ❗️ Important
>
> We recommend that you pass contacts from different sources into Ometria with different collections.
>
> This will help to ensure that data on the record is not over-ridden by missing data from another source.
# Customer IDs
If you have a unique customer/account identifier that you want to use in your reporting (e.g. row ID from your eCommerce importer), you can optionally supply this for each contact as the `customer_id`.
This value is also supplied in the contact's records when an order is placed by a registered customer (i.e. not a guest checkout) and is used to connect the **profile record** and the **order**.
This is different to a **[contact listing ID](https://support.ometria.com/hc/en-gb/articles/8760310580765)**, as a profile can have many "contact listings" (with multiple contact IDs) but only one customer ID.
> ❗️ Note
>
> It's very important that IDs sent to Ometria **do not contain personally identifiable information** (PII) such as email address, phone number or name. This is in case the ID is exposed publicly.
# Contact listings priority
When merging contact records to create a profile, there are sometimes non-matching parameters in the contact records.
In this case, Ometria will use the following two **rules of priority** to determine which value to assign to the profile:
## Standard Rules of Priority
1. Preferences centre
2. API, App, CSV
3. Ometria Form
4. Importer (Magento or Shopify)
5. Third party sync
> 📘 Note
>
> * If there are two contact records with the same level of priority, then the varying parameters from the **most recent contact record** will be used.
> * `firstname` and `lastname` parameters will always be taken from the same contact record.
## Marketing opt-in rules of priority
These rules only apply only to a contact's `marketing_optin` value.
The order of preference:
1. Any Ometria controlled source (e.g. Preference centre, an Ometria form, CSV upload).
2. Any Client controlled source (e.g. API, Magento or Shopify importer).
3. Any third party controlled source.