# Connect Reverse ETL Source to Pinterest Audience

This guide takes you through the steps to connect a Reverse ETL source to your Pinterest Audience destination.

You can connect multiple Reverse ETL sources to the same Pinterest account. Each connection syncs to its own customer list audience.

Setup

Set up and configure your Reverse ETL source.
In the Overview tab of the source page, click Add destination > Create new destination. You can also select an already-configured destination here.
From the list of destinations, select Pinterest Audience and click Continue.
Specify a unique name to identify this destination in RudderStack.
In the Pinterest account section, click Select to choose an existing Pinterest account. To add a new account, click Add account and authenticate via OAuth by specifying the following settings:

Setting	Description
Account name	Specify a unique account name.
OAuth settings	Click Connect account, sign in to Pinterest, and give RudderStack the requested permissions. Sign in as a Pinterest user that owns or has access to the ad account you want to sync to.

Click Continue to configure the mapping settings.

Mapping settings

This section lists the settings to correctly map data from your Reverse ETL source to the Pinterest Audience destination.

Select ad account

Select the Pinterest ad account that owns the customer list and its audience. The list shows every ad account the connected Pinterest user owns or has access to.

If you see No Pinterest ad accounts found for this account, make sure the connected Pinterest user has access to at least one ad account, then refresh the list.

Select audience

In this section, you can create a new audience or use an existing one:

Create new audience: RudderStack creates a customer list and a customer list audience on it in the selected ad account when you save the connection. Enter a name of 3 to 500 characters.
Use existing audience: Select an existing customer list audience in the selected ad account. Only customer list audiences are listed.

Pinterest needs at least 100 matched users before an audience can be used for targeting, and it can take 48–72 hours to process an upload. See Pinterest processing and audience size for more information.

Sync mode

Only Mirror mode is supported for this integration.

Map identifiers

Map your warehouse columns to the Pinterest identifiers. You must map at least one:

Identifier	Description
Email	The user’s email address.
Mobile advertising ID (MAID)	The user’s mobile advertising ID, for example, an Android advertising ID (AAID).

Pinterest matches a user if any identifier matches, so mapping both gives a better match rate. See Supported identifiers for the normalization RudderStack applies.

Don’t send IDFAs collected from activity in an iOS app or website. Pinterest’s policy forbids uploading them.

Advanced settings

Setting	Description
Automatically hash PII data?	When set to Yes (default), RudderStack normalizes the mapped values and hashes them with SHA-256 before sending them to Pinterest. Set it to No only if your warehouse columns already hold SHA-256 hashes. See Data hashing for more information.

You can’t change the ad account or the audience after the connection is created. To sync to a different one, create a new connection.

Sync settings

RudderStack determines how and when to run a sync based on the sync schedule you set for your Reverse ETL connection.

Schedule type	Description
Basic	Run syncs at a set interval, optionally starting from a specified time (UTC). If a start time is set, syncs run from that time until the end of that day.
CRON	Run syncs based on a specified CRON expression (in UTC).
Manual	Run syncs manually.

Sync observability settings

Setting

Description

Retain sync logs

This setting is toggled on by default and instructs RudderStack to store the sync logs in your warehouse. You can also configure the below settings:

Setting	Description
Sync log retention	Specify the retention period of the sync logs in your warehouse. If you set it to 1, then RudderStack deletes any sync log older than a day (in UTC time).
Snapshot table retention	Specify the number of snapshot tables to retain.

Retry failed records

This setting is toggled on by default and causes RudderStack to continually retry sending the failed records.

Retain and show failures

This setting is toggled off by default. Turn it on to have RudderStack write the error recorded for every failed record to a failed records table in your warehouse and show it in the sync’s failed records view. It applies from the next sync and can take up to a minute to reach your data plane.

Setting	Description
Failure retention	Number of days RudderStack keeps each sync’s failed records in your warehouse. The default is 30 and the minimum is 7.

Storing sync logs, snapshot tables, and failed records may incur additional warehouse costs.