Connect Reverse ETL Source to Custom Audience

This guide takes you through the steps to connect a Reverse ETL source to your Custom Audience destination and configure field mappings.

You can connect multiple Reverse ETL sources to the Custom Audience destination.

Setup

1. Set up and configure your Reverse ETL source.
2. In the Overview tab of the source page, click Add destination > Create new destination. You can also select an already-configured destination here.
3. From the list of destinations, select Custom Audience and click Continue.
4. Configure the following settings to specify how RudderStack connects to your API:

Audience delivery API configuration

Authentication

Endpoint configurations

Configure how RudderStack adds, updates, and removes audience members:

Action-specific settings

Each action’s (add/update/remove record) settings follow the same structure.

HTTP method and endpoint path

The resolved URL is the base URL plus the evaluated endpoint path.

Batch size

Request body template

Define the JSON body sent to your API. The template follows JSONata syntax.

Templates are validated when you save the destination. An invalid syntax is rejected with an error that identifies the action and issue.

A sample request body template is shown below:

{
  "audience_id": $$.connection.audienceId,
  "elements": [$$.records.{
    "userIds": [
      {"idType": "SHA256_EMAIL", "idValue": sha256_email},
      {"idType": "GOOGLE_AID", "idValue": google_aid}
    ],
    "firstName": first_name,
    "lastName": last_name,
    "nested": {
      "org": "static_value"
    }
  }]
}

Global objects available at runtime

Allowed operations

• Object and array construction
• Path expressions ($$.records, $$.connection.audienceId)
• Iteration with { ... } — for example, $$.records.{ "email": email, "user_id": user_id }
• String, number, and boolean literals
• Number() casting where needed, for example,$number($$.connection.audienceId)

Template example

A template for generic batched members is shown below:

{
   "audienceId": $$.connection.audienceId,
   "users": [$$.records.{
    "email": email,
     "user_id": user_id
  }]
}

Template fields

After you define a template, RudderStack extracts field names referenced under $$.records and lists them under Template fields. Click Refresh to re-scan the template, or Manage fields to configure each field.

If you rename or remove template fields after syncs exist, make sure to update mappings on each affected sync manually.

See Troubleshooting for more information.

Request preview

Use Fetch preview to build a sample HTTP request from test records.

Preview does not send traffic to your API.

1. Choose how many sample records to include (for example, 1 record).
2. Edit sample data if needed.
3. Click Fetch preview to see the resolved method, URL, headers, and JSON body.

5. Proceed to configure the mapping settings.

Mapping settings

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

Specify target audience

Create the audience on your platform before entering these values. RudderStack does not create audiences at the destination for this integration.

Sync mode

RudderStack supports only Mirror mode for this integration.

On the first run, the full membership is sent to the platform. Later runs send only inserts, updates, and deletes.

Map identifiers

Map warehouse columns to each template field defined in the Custom Audience destination.

You can map two types of fields:

• Warehouse fields: Dropdown of warehouse columns
• Static fields: Specify literal values for fields configured as Static in the destination settings

Required destination fields appear with an asterisk (*) during mapping.

Advanced settings

Sync settings

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

Sync observability settings

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

Data hashing

The Automatically hash PII data setting lets you hash your user data before sending it to your API.

• Configure the setting to Yes if your incoming data is not pre-hashed
• Configure this setting to No if your data is already hashed

Incorrect configuration of the Automatically hash PII data setting will result in failures.

• If the Automatically hash PII data setting is configured to Yes and your data is pre-hashed, the event will fail.
• If the Automatically hash PII data setting is configured to No and your data is not pre-hashed, the event will fail.

Such events are rejected with a clear error message, for example:

Hashing is disabled but the value for field EMAIL appears to be unhashed. Either enable hashing or send pre-hashed data.

You will also see errors in the Events tab for cases that were previously marked as successful but resulted in no matches, helping you identify and fix data quality or configuration issues.

Troubleshooting