CONNECTIONS / File drops / Files to Meta Offline CAPI
Sales files to Meta offline conversions, automatically.
Your POS or DMS keeps exporting like it always has; Signals watches the drop, cleans and hashes each batch, and Meta receives the conversions.
- ● files → meta.offline_capi :: live
- > ingest File drop pos_offline_2026-07-04.csv
- hash sha256(email,phone) rejects=quarantined
- route meta.offline_capi deliver
- ✓ delivered · 6,890 matched
WHAT THIS ENABLES
POS / SFTP files to Meta Offline CAPI
POS and SFTP files to Meta Offline CAPI validates and hashes each export the moment it lands on SFTP, S3, or GCS, then delivers it to Meta's offline endpoint on schedule with match-rate feedback per batch, so in-store revenue finally reaches campaign optimization.
- Legacy export jobs feeding a modern conversions pipeline unchanged.
- Meta campaigns learning from sales your systems only report as files.
- Malformed rows quarantined with reasons while the batch continues.
The click, the conversion, and the credit.
The conversion happens off Meta, away from any pixel. Here is how File drops closes the loop.
Built for the teams that own the number.
Dealer networks whose DMS can only write files.
From kickoff to verified events.
-
Connect
Signals watches your existing SFTP, S3, or GCS drop location.
-
Map
Batch columns validated against Meta's offline spec before hashing.
-
Deliver
Each accepted batch forwarded to the offline endpoint with match feedback.
What changes when the CSV goes away.
| Capability | Manual CSV upload | Datahash |
|---|---|---|
| Reporting | Offline sales sit in a separate export, reconciled by hand. | Revenue counted in the same Offline CAPI reporting as web conversions. |
| Deduplication | A re-uploaded file risks counting the same conversion twice. | Deduped delivery, so a resent record never counts as a second conversion. |
| Match visibility | Match quality is a guess until the numbers look off. | Match rate reported per upload, tied to the source event set that produced it. |
| Effort and latency | An analyst exports and uploads on a manual cadence. | Server-side and automatic the moment File drops records the event. |
What Offline CAPI actually receives.
- ● signals :: event payload
- > POST /offline_conversions source=files.pos_offline_2026-07-04.csv
- event_name "Purchase" · event_time 2026-07-04T23:15:00
- value 156.00 · currency AED
- em sha256 "6cf920…" · ph sha256 "3a80de…" · external_id "row-6621"
- ✓ accepted match=84%
Adjacent moves on the same stack.
from File drops
File drops to Google OCI
File drops to Google Offline Conversions: your file drops, hashed and consent-checked, feed…
Learn morefrom File drops
Files to Google Store Sales
POS and SFTP files to Google Store Sales validates and hashes each nightly export the…
Learn more
same use case
ActiveCampaign to Meta Offline CAPI
ActiveCampaign to Meta Offline CAPI: Signals reads your ActiveCampaign contacts and deal…
Learn moregeneric
Meta Offline CAPI
Datahash ingests offline transactions from your POS, CRM, or warehouse and routes them to…
Learn moreAsked on almost every call.
What happens when a file has messy rows?
Signals validates every file as it arrives and quarantines the bad rows instead of failing the whole batch, so a handful of malformed records never blocks a delivery to Meta. Each quarantined row is logged with the reason it failed, and the team fixes it at the source and reprocesses on the next drop without re-uploading the records that already landed.
How fresh does the offline file need to be?
Meta accepts offline events up to 62 days old, so a daily incremental file is the norm and even a weekly batch stays inside the window. Signals reads each drop as it lands, hashes the identifiers, and deduplicates against pixel traffic before the Offline Conversions API records the conversion, so a sale that closed days after the click still credits the right campaign.
NEXT STEP