Can a conversion be corrected or removed after it was sent?

No. The Conversions API only accepts new events, so Meta has no way to retract one. This is why the deleted-row policy offers **Ignore** and nothing else, and why a wrong mapping is best caught with a test event code before the first real run.

Why did Meta accept fewer events than my model has rows?

A row without a single identifier cannot be matched to a person, so Renta drops it before the request. Map at least email, phone number, or the click id to make every row deliverable.

My rows have a purchase amount but Meta shows no value. Why?

Meta requires a currency whenever a value is present. Map a currency column or set **Default currency**. Without either, Renta drops the amount and sends the event without it.

How do I check the setup without polluting my pixel?

Put a code from the **Test events** tab of Meta Events Manager into **Test event code**. Events then land in that tab instead of your reporting, and you can see exactly what Meta received. Clear the field before the pipeline goes live.

I already send the same conversions from my website pixel. Will they be counted twice?

Map your order id to **Event ID (deduplication)** and use the same value the browser pixel sends. Meta then treats the browser event and the server event as one conversion.

How old can an event be?

Meta accepts conversions reported within seven days of the moment they happened. Older event times are rejected, so a daily or more frequent schedule matters here more than it does for an audience sync.

Meta Conversions API

Renta reports conversions from your data warehouse to a Meta Pixel through the Conversions API: every row in the data model becomes one server-side event, such as a purchase, a lead, or a subscription.

The row carries when the conversion happened, who it belongs to, and what it was worth. Renta hashes the identifiers before they leave, so Meta attributes the conversion to a person without receiving raw contact data.

Authentication

Renta authenticates with Meta OAuth. Authorize the Facebook account that can manage the ad account owning the pixel you report to.

Renta checks that the authorized account can see at least one ad account and refuses the connection otherwise. If you hit that, give the Facebook user access to an ad account in Meta Business Settings and authorize again.

Connect Meta Conversions API destination

Go to the CatalogStep 1

Navigate to the Connections > Catalog section in the left sidebar and open the Destinations tab.
Open the Reverse ETL category and click the Meta Conversions API card.

Meta Conversions API card in the Reverse ETL category of the Renta destination catalog

Start the authorizationStep 2

Click Log in to your Meta Conversions API account. Meta opens in the same tab.

Authorize connection page with the Log in to your Meta Conversions API account button

Grant accessStep 3

Confirm the Facebook account and click Continue. Use Edit settings if you need to change which businesses and ad accounts Renta may reach. Meta returns you to Renta.

Meta login dialog with the Edit settings and Continue buttons

Name the connection and saveStep 4

Renta confirms the granted access and shows the authorized account. Finish the setup:

Destination name.
Specify a name for this destination. This is used exclusively in the Renta interface.

Click Save to finish.

Set up your Meta Conversions API connection page with the destination name field

Destination createdStep 5

The new destination appears in the Destinations list with the Active status. You can now use it in Reverse ETL pipelines.

Destinations list with the new Meta Conversions API destination in Active status

Prepare a data model

A Reverse ETL pipeline reads from a data model: a SQL query saved in the Data models section that decides which warehouse rows to sync and what each row holds. Build it before the pipeline, because the mapping dropdowns are filled from its columns.

A conversion model holds one completed event per row. Give every row the moment the conversion happened as a Unix timestamp in seconds, at least one identifier of the person behind it, and whatever the conversion was worth.

-- Purchases prepared for the Meta Conversions API.
-- The query returns rows only, no table is created.
WITH demo_purchases AS (
  SELECT
    'ord-1001'                  AS order_id,
    UNIX_SECONDS(TIMESTAMP '2026-08-15 14:20:00 UTC') AS event_time,
    129.00                      AS value,
    'USD'                       AS currency,
    'james.miller@example.com'  AS email,
    '+12125550101'              AS phone
  UNION ALL SELECT 'ord-1002', UNIX_SECONDS(TIMESTAMP '2026-08-15 15:05:00 UTC'),  59.00,'USD','olivia.johnson@example.com','+13125550102'
  UNION ALL SELECT 'ord-1003', UNIX_SECONDS(TIMESTAMP '2026-08-15 16:40:00 UTC'), 249.00,'USD','william.davis@example.com','+12145550103'
)
SELECT * FROM demo_purchases

Create the data model

Write the queryStep 1

In the left sidebar, open Data models and click New model. Then:

Source.
Choose the warehouse connection the query runs against.
Write your model query.
Paste your SQL. Keep SQL query as the query type.
Run preview.
Check the rows and column names before moving on. The event time column has to come back as an integer, so wrap a timestamp in UNIX_SECONDS in BigQuery or its equivalent in your warehouse.

Choose Reverse ETL only as the scope, then click Next step.

Data source step with the SQL editor holding the purchase query and the preview showing ten rows

Confirm the columns and pick the keyStep 2

Review the columns Renta read from the query and mark the one that identifies a row. For conversions this is the id of the event itself, such as the order id, not the person: two orders by the same customer are two separate conversions.

Name the model on the last step and click Create model. The name is what you pick from the Data model dropdown when you build the pipeline.

Schema step with the six columns of the purchase model and the unique key marked on order_id

Create a Meta Conversions API pipeline

The destination and the data model have to exist before you start.

Select your warehouseStep 1

In the left sidebar, click New pipeline. On the Source step, switch the toggle to Reverse ETL and pick your data warehouse, such as Google BigQuery.

Select a source step with the Reverse ETL toggle and the Google BigQuery card

Select the warehouse connectionStep 2

Choose the warehouse connection that holds your data models and click Next step.

Select your Google BigQuery connection step with the warehouse connections listed

Select Meta Conversions API as the destinationStep 3

On the Destination step, select Meta Conversions API under Already connected, pick the Meta connection you created earlier, and click Next step.

Select a destination step with Meta Conversions API listed under Already connected

Pipeline configuration

On the final step, choose where the conversions land, what they are called, and which columns describe them.

What Renta sends

Pick the object, the data model, and the pixel that receives the events.

Meta pipeline settings with the Conversion event object, the data model, the ad account, and the pixel dropdowns

What would you like Renta to send to Meta.
Conversion event is the only object here. Audiences are built by the separate Meta Custom Audiences destination.
Data model.
Choose the model to sync. The columns available for mapping below come from it.
Ad account.
The Meta ad account that owns the pixel. It also filters the pixel list underneath.
Pixel / Dataset.
The pixel the conversions are reported to. Pick the same pixel your website or app already sends events to. That is what lets Meta recognise a browser event and a server event as one conversion.

Event defaults

Describe the conversions the model holds. These values apply to every event that does not carry its own.

Action source, default event name, default currency, and test event code fields

Action source Where the conversions happened. Meta uses it to pick the right attribution rules, so answer for the moment of the conversion rather than for the pipeline.

Value	When to pick it
Website	The conversion happened on your website.
App	The conversion happened in your mobile app.
Phone call	The conversion happened over a phone call.
Chat	The conversion happened in a chat or messaging conversation.
Email	The conversion happened over email.
Physical store	The conversion happened offline in a physical store.
System generated	Your CRM or backend produced the conversion, which is the usual case for a warehouse replay.
Business messaging	The conversion happened on a business messaging surface.
Other	None of the above describes the channel.

Default event name.
What the conversion is called in Meta. Pick one of the Meta standard events, such as Purchase, Lead, Subscribe, or CompleteRegistration, or choose Custom event and type your own name of up to 50 characters. One pipeline reports one kind of conversion, so a model mixing purchases and leads needs a pipeline for each.
Default currency (optional).
The ISO 4217 currency applied when the model has no currency column. Meta requires a currency whenever an event carries a value, so set this unless every row supplies its own.
Test event code (optional).
A code from the Test events tab of Meta Events Manager. Events sent with it show up in that tab instead of your reporting, which is how you verify the mapping before the pipeline goes live. Clear the field afterwards.

Leave Test event code filled in and your real conversions keep landing in the testing tab instead of your campaign reporting.

Field mapping

Connect warehouse columns to the parameters of a Meta server event. Event time (unix seconds) is pre-selected and cannot be removed, and at least one identifier is needed for Meta to attribute the conversion to a person.

Mapping data model columns to Meta Conversions API event parameters

Group	Parameters
Event	Event time (unix seconds), Event ID (deduplication), Event source URL, Action source, Opt out
Hashed identifiers	Email, Phone, First name, Last name, Gender, Date of birth (YYYYMMDD), City, State/Province, Zip/Postal code, Country, External ID
Identifiers sent as written	Click ID (fbc), Browser ID (fbp), Client IP address, Client user agent, Subscription ID, Facebook login ID, Lead ID
Conversion details	Value, Currency, Order ID, Content name, Content category, Content IDs, Content type, Contents, Number of items, Search string, Status, Predicted LTV, Delivery category

Renta normalizes and SHA-256-hashes every identifier in the second group before the request leaves. A column that already holds a hash is recognised and passed through, so a warehouse that hashes upstream keeps working. The browser and click identifiers travel as written, because Meta matches those directly.

The rest are optional and decide how much Meta knows about the conversion. Value together with Currency is what makes return on ad spend reportable.

Map Event ID (deduplication) even if no browser pixel reports the same conversions. Meta uses it to collapse duplicates, which also protects you when a network hiccup makes Renta retry a batch that Meta had already accepted. Without an event id, that retry counts the conversion twice.

A row without a single identifier cannot be matched to a person, so Renta drops it instead of sending an event Meta would discard. A row carrying a value but no currency is sent without the amount rather than rejected.

Sync behavior and privacy

Set what happens to a conversion whose row disappears, and declare which privacy rules apply.

When a source row is deleted dropdown and the Limited Data Use country and state settings

When a source row is deleted.
Ignore is the only option. A conversion already reported cannot be retracted, so a row leaving the data model has no effect in Meta.
Limited Data Use (LDU).
Restricts how Meta uses the conversions for ad personalization. Turn it on for privacy regimes that require it, such as CCPA in California.
LDU country and LDU state.
Which geography the restriction applies to. Auto-detect on both lets Meta work it out from the payload, which is the usual choice. Set them explicitly only when your legal team asks for it.

Then name the pipeline and choose how often it runs.

Integration name field and the schedule type selection with Manual checked

Integration name is the name of your pipeline. Edit it to match your preferences.

Schedule type	Description
Manual	The pipeline runs only when triggered manually through the interface or via API.
Daily	The pipeline runs once a day at the specified update time.
Interval	The pipeline runs at specified time intervals.
Cron Expression	The pipeline runs on a schedule defined by a cron expression.

For Daily schedules, set the Update time (the exact time each run starts), then click Create pipeline.

Renta also supports API triggers and integration with external orchestrators such as Apache Airflow, Dagster, and Prefect. See the full scheduling documentation for details.

The new pipeline appears in the Pipelines section under the Reverse ETL tab, where you can track its runs and progress.

Reverse ETL pipelines list with the new Meta Conversions API integration

Sync strategy

Renta syncs incrementally. A run compares the data model against the state the previous run recorded and reports only the conversions that were not reported before. The first run has nothing to compare against and delivers the model in full.

Row state	What Renta does
New	Reports the conversion to the pixel.
Changed	Reports the row again with the new values. Map an event id so Meta recognises the correction instead of counting a second conversion.
Unchanged	Sends nothing.
Deleted	Nothing happens. A reported conversion cannot be retracted.

The first run of a model holding a long purchase history sends all of it. Meta rejects conversions older than seven days, so restrict the model to a recent window before the pipeline runs for the first time.

Limits

Conversions are append-only.
Nothing sent to the pixel can be edited or deleted afterwards. Verify the mapping with a test event code before the first live run.
Events expire after seven days.
Meta rejects a conversion whose event time is more than seven days in the past, so the schedule has to keep up with the model.
One event name per pipeline.
The event name comes from the pipeline settings, not from a column. Reporting purchases and leads means two pipelines over two models.
Matching happens inside Meta.
Renta reports an event as delivered once Meta accepts it. Whether it resolves to a person, and to which campaign it is attributed, is decided by Meta and visible in Events Manager rather than in Renta.
A run stops when rejections pile up.
Renta halts the run when more than 5% of a batch, or more than 30% of the events delivered so far, come back rejected. Conversions already accepted stay in Meta, and the next run picks up where this one stopped.

Frequently asked questions

Ready to get started?

Build your data pipeline today or get a personalized demo. Start free!

Need help?

Get expert support to ensure your project succeeds. We're here to help!

Feature requests?

Help shape our product! Share your ideas for new features and integrations.