--- title: 'Meta offline conversions: setup and checks' description: 'Send offline sales to Meta using the Conversions API. Check event fields, upload windows, matching and store-event deduplication.' canonical: 'https://plainrouter.com/library/meta-offline-conversions' format: Guide published_at: '2026-10-09' last_updated: '2026-10-09' --- # Meta offline conversions: send sales and check what arrived Meta offline conversions connect sales or other outcomes outside the website—such as store purchases, phone orders and bookings—with Meta's advertising measurement. Meta recommends the Conversions API for sending offline and physical-store events, with a dataset and customer information for matching. Sending a sale does not guarantee that Meta can match it to a person or attribute it to an ad. ## What are offline conversions in Meta ads? Offline conversions are business outcomes that happen away from the browser event Meta would otherwise see. A store receipt, a completed phone order or a later-confirmed sale can provide information that a website visit alone cannot. Separate the location of the sale from the location of its record. A CRM can hold both website sales and in-store sales; storing an order there does not automatically make it a physical-store event. Describe where the action actually happened when choosing the event's action source. Meta's offline-conversions help page describes purchases in stores, phone orders and bookings. Its technical offline-events guide focuses on offline and store events for omnichannel optimization; it directs CRM lead-optimization integrations to a separate guide. Decide which outcome you are sending before copying a payload from another integration. ## How do I send offline conversions to Meta today? Use the Conversions API through a direct integration or an appropriate partner, or use the manual dataset upload described by Meta. Create or select the dataset and associate it with the intended ad account before using the data for campaign reporting. Meta's current documentation calls the older Offline Conversions API its legacy API. Its offline-events guide recommends the Conversions API. This guide does not claim a shutdown date or call the legacy API discontinued: those claims are not established by the cited documentation checked October 9, 2026. For a direct integration, Meta documents sending events to the dataset's ` /events ` endpoint with authorized credentials. Use the current API version and integration prerequisites from Meta's documentation; do not reuse a token or dataset from a different business. A preparation sequence is: 1. Identify the source of truth for the completed transaction. 1. Select the correct dataset and confirm the integration's access. 1. Map event fields and permitted customer information. 1. Decide how retries and duplicate records will be handled. 1. Test the mapping before sending production records. 1. Monitor receipt, errors and attribution as separate outcomes. Read the [Meta Conversions API guide]() for the general browser and server relationship. ## What does an offline event need? An event needs its name, occurrence time, customer information and truthful action source. Purchase events also need value and currency; not every useful field is universally required. | Field | Purpose | Requirement or distinction | | --- | --- | --- | | ` event_name ` | Names the action, such as ` Purchase ` | Required server event field | | ` event_time ` | Records when the action occurred | Required Unix timestamp in seconds; use the actual sale time | | ` user_data ` | Contains customer information for matching | Required object; follow the customer-information schema | | ` action_source ` | Describes where the conversion happened | Required; a store purchase uses ` physical_store ` | | ` custom_data.value ` | Gives the transaction value | Required for Purchase events | | ` custom_data.currency ` | Identifies the value's currency | Required for Purchase; three-letter currency code | | ` event_id ` | Identifies an event for applicable deduplication | Optional in the general schema; recommended for browser/server pairing, not a substitute for store-event rules | | ` custom_data.order_id ` | Identifies the transaction | Used by Meta's order-based offline deduplication | | ` custom_data.item_number ` | Distinguishes items within a transaction | Optional; part of the offline duplicate comparison when supplied | | ` event_source_url ` | Identifies the browser page where an action occurred | Required for website events; do not invent a page for a store purchase | Field requirements checked against Meta's server-event and offline-event references on October 9, 2026. The general action-source list also includes ` phone_call `, ` email `, ` website ` and ` system_generated `; select the truthful value rather than using ` physical_store ` to obtain a longer upload window. For example, a synthetic store sale could be a ` Purchase ` with ` physical_store `, order ` example_order_104 `, value ` 49.00 ` and currency ` USD `. That is a field-mapping example, not a complete request. Customer information must be collected and processed under the applicable permissions, and sensitive matching fields must follow Meta's normalization and hashing rules. ## How long after the sale can I send it? Meta's offline-events guide specifies uploading physical-store transactions within **62 days** when ` action_source ` is ` physical_store `. The general server-event reference specifies a **seven-day** event-time limit, so do not apply the store window to all backend or phone events. Meta recommends real-time or daily offline uploads. Treat 62 days as a maximum documented window for that source, not a recommended delay. Preserve the actual occurrence time rather than changing it to the upload time to make an old sale look new. The general API documentation warns that an out-of-window event can reject an entire request. Validate the age and action source of each record before batching. If your sales close days after a lead, keep the lead time and sale time distinct: a newly completed sale is different from a sale that happened weeks ago and was only just uploaded. ## How does Meta match an offline sale to an ad? Meta uses the customer information you provide to try to connect the event with a person, then applies its advertising measurement rules. A valid upload, a successful match and an attributed conversion are three different results. Use accurate information you are permitted to send. Meta's parameter reference requires hashing for fields such as email and phone, while some identifiers have different handling. Follow the field-specific rules rather than hashing everything or sending every field unchanged. Do not manufacture a browser click ID for an in-store sale. If there was a relevant earlier online interaction, preserve the genuine information through a documented integration. More fields are useful only when they are accurate and appropriate for that event. The [Event Match Quality guide]() explains matching inputs and their limits. Matching quality is not proof that an ad caused a sale. Compare Meta's reported attribution with the source system's completed transactions over a consistent period; the totals need not be identical. ## How do I avoid counting a sale twice? Use the deduplication rules for the event source you are actually sending. Meta explicitly says its offline events can be deduplicated against other offline events only; they are not browser events with a different transport. For offline/store events, Meta documents order-based or user-based comparison using the dataset, event time, event name, item number and the relevant identifying fields. Order-based deduplication uses ` order_id `; without it, Meta falls back to its customer-information comparison. The documented maximum deduplication window is seven days. For a website purchase sent through both Pixel and Conversions API, matching event names and event IDs are the recommended pairing mechanism. Read [Meta event-ID deduplication]() for that separate case. Do not relabel the same website purchase as a store event and assume the shared ID will remove it. Before launch, identify one owner for each sale. Check whether an e-commerce integration, CRM export and manual upload can all send the same transaction. Retain identifiers when retrying a record, and keep an upload log so an operator can distinguish a retry from a genuinely new order. ## How do I check that Meta received the events? Use the integration response and the intended dataset in Events Manager to inspect receipt and errors. Meta's offline-events guide points to its Payload Helper and Test Events tool for checking an integration. Check the event name, action source, timestamp and mapped fields with a controlled test record, then check production processing separately. A test result does not prove ad attribution. Use the [Events Manager task guide]() to find the dataset and interpret diagnostics. When reconciling, keep three counts: transactions confirmed by your business, events accepted by the destination, and conversions Meta attributes to ads. Investigate the difference instead of treating one number as a substitute for the others. ## Where does Plainrouter fit? After you [sign up]() and configure Signals, Plainrouter sends eligible, consented backend conversion events to Meta through the Conversions API and retains a delivery record for each event. It can also record confirmed Stripe Checkout revenue. Those are released capabilities; they do not establish a general in-store upload or CRM-import product. Plainrouter's delivery acceptance is not attribution or incrementality, and a backend event is not automatically a physical-store event. See [Signals]() for the supported collection and revenue workflow before choosing it for your source system. ## Frequently asked questions ### What is offline conversion tracking? It connects completed outcomes outside a website session with advertising measurement. In Meta's setup, sales data is uploaded to a dataset so Meta can attempt matching and attribution. ### Is the Offline Conversions API discontinued? The current Meta sources cited here call it legacy and recommend the Conversions API. They do not establish a shutdown date; use Meta's current integration guidance instead of assuming one. ### Can I upload purchases from a CRM? Meta supports direct or partner Conversions API integrations, but choose the guide for the actual event. CRM lead optimization and physical-store sale reporting have different requirements; a CRM export is not automatically a valid store-event payload. ### Does a successful upload mean an ad gets credit? No. Receipt confirms processing, not successful identity matching, attribution to a particular ad or proof that advertising caused the sale. ## Sources Meta documentation checked October 9, 2026: - [About offline conversions](). - [Send offline events with the Conversions API](). - [Server-event parameters](). - [Customer-information parameters](). - [Pixel and server-event deduplication](). ## Related guides Compare [Conversions API and Meta Pixel]() for website events, then use the linked matching, deduplication and Events Manager guides for the appropriate verification step.