Direct Feed Delivery to Google Merchant Center and Facebook Catalogs: What Changes for Your Ops

TL;DR Direct delivery hands the timing, the first error, and the retry behaviour to you. The delivery log then answers one narrow question — did the transport succeed? That is not the same as "is the product live at the destination," and treating the two as one is where operators get caught. ## In this insight - Pull delivery versus push delivery as two genuinely different jobs - What changes for timing, errors, and retries when you push - Why a successful batch is not a processed catalog - A delivery verification record you can actually keep ## Pull delivery and push delivery are two different jobs A hosted feed URL is a pull. You publish a file at a stable address and the channel decides when to come and collect it. Google Merchant Center fetches on its own schedule and applies its own processing window. A Meta catalog configured with a feed URL fetches on its own timetable as well. Your job in that model is to keep the file correct and reachable. You do not control when the change lands, and you are not expected to. Direct delivery to Google Merchant Center or a Facebook catalog is a push. When the feed channel finishes building, your system sends the products through the destination's API. You decide the timing. The destination answers, per item, with what it did with the payload. That reads like a straight upgrade, and in most cases it is one. It also moves a set of responsibilities from the channel onto you, and those responsibilities are what actually change for an operator. ## What changes when you move to API push ### You own the clock With a pull, "when does the channel see the new price?" is answered by the channel's fetch schedule. With a push, it is answered by your delivery schedule. If a channel rebuilds every four hours and pushes on completion, your delivery cadence is now the upper bound on how fresh the catalog is. Nothing in the platform will tap you on the shoulder to say that you set the schedule and can change it. Read the channel's build cadence and its delivery trigger together. If you expect hourly freshness but the channel rebuilds twice a day, every push is accurate and still late. ### The failure surface moves closer to you A failed pull surfaces as a fetch error inside the destination. A failed push surfaces first in your own delivery log, and only reaches the destination if it is left unresolved. That is a gain in diagnosis and a new thing to watch. A delivery that never ran leaves no trace at the destination at all, because the destination has no reason to know about a file it was never told to expect. Whatever you use to notice failed pulls, extend it to cover pushes that did not happen. ### A successful batch is not a processed catalog This is the trap worth internalising. The Facebook catalog batch API is asynchronous: the request returns handles for work that has been queued, not a verdict on each product. A batch can be accepted while the individual items are still unprocessed. Google's product-insert path is closer to per item, so you get item-level errors back in the same call, but the meaning of a clean response is still narrow. It says the software accepted the payload. It does not say the item is eligible, approved, or live. So the delivery log answers exactly one question: did the transport succeed? That is not the same question as "is this product live in the destination?" Keep the two apart in your reporting, and never let the first stand in for the second. ### Required field mappings are not symmetric Each destination needs a different minimum before it will even attempt a delivery. Google's direct delivery expects a mapped offer ID, title, link, price, and availability. The Meta batch path needs far less to start — at minimum the identifier the catalog keys on. The practical consequence is that a feed can push to one destination cleanly and fail the other for a missing field, and the two failures look nothing alike. Validate the field mappings per destination, not once for the channel. The same logic applies to accounts. A feed channel can carry more than one destination: multiple Merchant Center accounts, multiple catalogs. A green delivery against one destination says nothing about the others. Verify per destination. ## Two ways to push to a Meta catalog Meta does not offer a single push; it offers two, and they are not interchangeable. One is a batch endpoint that upserts items and is aimed at fast-moving values like price and availability — it is an update path. The other is a catalog feed path that manages the listing lifecycle, including creation and removal. Choosing the batch path for everything is the common mistake. It is excellent at what it does and blind to what it does not: it will not remove a product you have deleted in the source. Decide which path owns which kind of change, and write that decision down, because the two behave differently the moment a product stops being sold. ## The delete problem Batch updates are upserts. They change and add. They are not, by themselves, a full replacement of the catalog. If you remove a product in the source and only ever push updates, the destination can keep serving the last version it accepted. This is where the choice of method carries real weight, and it is worth testing rather than assuming. Pick one product you have removed and confirm it is gone at the destination, not merely absent from your feed. If it survived, the delivery path does not carry deletions and needs a method that does. ## Tokens, retries, and failures that look like success Direct delivery depends on a connected account and a valid token. An expired credential does not produce a quiet degradation; it produces a failed delivery. The integration has to stay authorised, and it has to be the right account. When a delivery fails, the system retries with backoff before it gives up, which is the right default and has one consequence worth naming: the same push can run more than once. Confirm your delivery is idempotent — that sending the same product twice changes nothing harmful — before you lean on automatic retries. For an upsert that is usually true. For anything that appends, increments, or replaces wholesale, it is not, and it needs checking. ## A delivery verification record | Question | Where the evidence lives | Who owns it | |---|---|---| | Did the push run? | Your delivery log: status, time, trigger | Ops | | Did the destination accept each item? | Item-level API response, or handles for queued work | Ops | | Is the item live and correct? | The destination's own product view | Catalog owner | | Did demand change? | Campaign and margin reporting | Marketing | Four rows, four different systems. The common mistake is to read the first row and report the fourth. A delivery log cannot tell you whether a product is eligible or selling; it can only tell you whether your system managed to hand the payload over. ## Hypothetical example A store moves from a hosted Merchant Center feed URL to direct delivery so it can keep prices tight during a sale. The first pushes look clean. A week later someone notices a discontinued line still active at the destination. The delivery log is fully green, because every push was an update and no push ever carried a removal. Nothing was broken in the transport; the deletion simply had no path. The remedy is to define how removals travel, and the lesson is to test a deletion the same way you would test a price change. The example is hypothetical. The useful part is the check, not the story. ## Keep the transport and the outcome apart Direct delivery gives you control and speed, and it hands you a new set of checks. You decide the timing, so you own freshness. You receive the API response, so you own the first diagnosis. You can push a batch cleanly while the catalog has not finished processing, so acceptance proves nothing customer-facing. And if every push is an update, removed products can survive at the destination indefinitely. None of that is a reason to stay on a hosted file. It is a reason to tell the two layers apart: delivery is a transport event you can automate and monitor, and the catalog result is a destination fact you have to verify. Automate the first, sample-check the second, per destination, on purpose. ## FAQ ### Does a successful delivery mean the products are live? No. A successful delivery means the destination accepted the payload. Processing, eligibility, and the live product view are separate states, and they have to be checked at the destination. ### Should I switch every channel to direct delivery? Not automatically. Direct delivery is strongest where timing matters most, such as price and availability. A hosted file remains a fine fit where the channel fetches reliably and freshness is not critical. Match the transport to the requirement rather than the other way round. ### How do I confirm a deletion reached the destination? Remove one product in the source, let the delivery run, and look it up at the destination by its identifier. If it is still present, the delivery path does not carry deletions and needs a different method. ### Can I run direct delivery to more than one account or catalog? Yes, per destination. Because each destination is verified on its own, treat a clean push to one account as evidence for that account only. ## Sources Use the current API documentation and account guidance for the destination you operate — Google's Merchant API product-input reference and Meta's catalog items batch reference. Requirements and processing behaviour change; check the version your own account uses rather than a summary of it.